5.1 Register the deployment configuration
Proposed practice. Maintain a deployment manifest containing the business mandate, accountable owner, autonomy tier, model and serving version, system instructions, harness version, tool schemas, authorized data, memory policy, monitor configuration, fallback routing, and delegation topology. Add immutable hashes where feasible and record external versions that cannot be fully pinned.
The configuration digest is the join key between an approved release, an evaluation result, and a production trajectory. An inventory record that contains only the model name cannot establish which controls operated on a particular action. A vendor's moving alias should be recorded alongside resolved versions or documented limits on version visibility.
Figure 4. Proposed reference architecture. The reasoning layer proposes work. The execution layer enforces authority and controls effects. The evidence layer records independently observable decisions and results. The arrows represent permitted information or execution flow, not proof that any particular framework implements these boundaries.
| Plane | Minimum responsibility | Evidence | Independence requirement |
|---|---|---|---|
| Governance | Approve mandate, risk appetite, autonomy, accountable owner, and exceptions. | Signed mandate, assessment, release decision, exception expiry. | Agent cannot approve its own authority or rewrite the applicable policy. |
| Execution | Authenticate, authorize, enforce limits, route reviews, and mediate commits. | Policy decision, action digest, approval record, commit result. | Critical enforcement survives a misleading agent response and a monitor outage. |
| Evidence | Capture externally observed actions and postconditions; support inquiry and recovery. | Correlated tool receipts, state evidence, trace integrity, reconciliation. | Agent and delegated workers cannot delete or alter authoritative records. |
5.2 Prevention and evidence are separate obligations
The runtime-contract position paper distinguishes preventive controls from checkable completion evidence. Contract-monitoring research further proposes separate worker, monitor, and adjudication responsibilities. These are useful architectural ideas; their guarantees depend on specified assumptions and should not be imported as unconditional enterprise guarantees. [S19, S24]
Proposed practice. Implement two gates. Before an action, establish authority and satisfaction of hard policy constraints. After an action, independently confirm the intended postcondition before claiming completion or releasing the next stage. A tool's HTTP success status can be inadequate if its business result is asynchronous, partial, duplicated, or later rejected.
For a payment workflow, evidence may include an accepted transaction identifier, an independently queried status, the exact amount and beneficiary, and a reconciliation outcome. For a research workflow, it may include accessible citations, period and unit alignment, calculation checks, and an identified evidence cutoff. The gate should match the business assertion it supports.
Environment-steering research supplies a concrete example of enforcing record-level data-flow policy through execution state and feedback. That implementation is a replication candidate, with benchmark-specific evidence, rather than a general enterprise guarantee. [S20]
5.3 Specify a failure policy for every dependency
| Failure | Safe operating response to design and test | Release evidence |
|---|---|---|
| Monitor unavailable or too slow | Hold consequential writes or route to a validated lower-autonomy path. | Fault injection showing no bypass, plus queue and review behavior. |
| Policy engine unavailable | Deny new privileged commits; preserve authorized read-only service where justified. | Denial record, outage recovery, and consistency checks. |
| Audit destination unavailable | Hold actions requiring durable evidence; use an approved bounded local spool only with verified integrity and recovery. | Backpressure, loss detection, and replay tests. |
| Credential revoked during a run | Revalidate authorization at the commit boundary and cancel descendants. | Revocation and delegation-tree test. |
| Tool timeout after a possible effect | Query state using an idempotency key or transaction receipt before retrying. | Duplicate prevention and partial-commit reconciliation. |
| Model fallback activates | Apply the fallback's approved permissions, capabilities, and oversight policy. | Fallback-specific evaluation; no automatic authority inheritance. |