Give every agent runtime contract a control owner, an enforcement point, and an evidence owner

A runtime contract is incomplete when it names a rule but leaves enforcement and evidence unowned. The design may say that an agent cannot invoke a sensitive tool without permission, yet omit which component denies the call. It may promise an execution record without identifying which component emits it, where it lands, or what happens when capture fails.

Two recent papers offer complementary proposals for closing that gap. The Agent Operating System paper proposes a Control and Governance Plane responsible for policy, authority, auditability, and oversight, alongside a Runtime and Coordination Plane responsible for lifecycle, workflow coordination, routing, context, scheduling, and runtime assurance. Read the AOS paper. A second paper argues that the runtime harness should combine preventive mechanisms, including permission gates, with checkable evidence such as tests, logs, diffs, and citations. Read the runtime-contract paper.

These are architecture proposals, not established standards or evidence of validated production outcomes. Their useful intersection is an operating question: for every clause in an agent runtime contract, who controls the rule, where is it enforced, what evidence can an operator inspect, and what happens when either enforcement or evidence capture fails?

The SGL runtime-contract responsibility matrix

We propose recording five fields for every consequential contract clause:

Contract field	Design-review question
Clause	What action, transition, or state does the contract constrain?
Control-plane owner	Who defines, approves, versions, and can revoke the rule?
Runtime enforcement point	Which component checks the rule before or during execution?
Evidence owner and artifact	Who is accountable for producing a named, checkable record?
Failure disposition	What predetermined result follows denial, timeout, unavailability, or missing evidence?

The separation between control-plane ownership and runtime enforcement is derived from our reading of the proposed plane responsibilities in the AOS paper; the paper itself does not establish this SGL matrix. See the proposed plane division. Likewise, pairing preventive checks with retained artifacts is our operational use of the second paper’s proposed combination of permission gates and execution evidence. See the proposed runtime contract.

“Owner” means accountable party, not merely the service that happens to execute a step. A policy service might evaluate permissions, for example, while a platform security owner approves the policy and a runtime team owns the call interception point. The matrix makes those different responsibilities visible.

Work one clause across all five fields

Consider a derived contract clause: “A tool call carrying a privileged capability may execute only with an active grant scoped to that action.” The matrix might read:

Field	Example assignment
Clause	Validate an action-scoped grant before privileged tool execution.
Control-plane owner	Platform security owns the policy definition, approval path, version, and revocation procedure.
Runtime enforcement point	The tool gateway checks the grant immediately before dispatch.
Evidence owner and artifact	The runtime team owns a decision record containing the policy version, action class, decision, and correlation identifier.
Failure disposition	A missing, expired, or unevaluable grant produces denial; a missing evidence sink prevents privileged dispatch or moves the action to an explicitly approved degraded path.

This row is an SGL design example, not a configuration documented or tested by either paper. Its value lies in exposing incomplete architecture. If the row has a policy owner but no interception point, the clause is advisory. If it has an enforcement point but no evidence artifact, later review may be unable to distinguish a valid denial from a runtime defect. If it names an artifact but no failure disposition, the system’s behavior during telemetry loss remains undefined.

Not every clause warrants the same disposition. A read-only, low-consequence operation might continue while evidence is buffered locally. An irreversible action might be held when its evidence path is unavailable. Those are risk decisions for the operator, not conclusions supplied by the papers. The matrix forces the decision to be explicit before the failure occurs.

Separate evidence production from evidence interpretation

The runtime-contract paper lists tests, logs, diffs, and citations as examples of checkable execution evidence. See the evidence examples. Those artifact classes are not interchangeable.

A log can show that a permission check returned a particular result. A diff can expose a proposed state change. A test can evaluate a stated condition. A citation can connect an output to a referenced source. None of these artifacts, by category alone, proves that an execution was safe or correct.

For design review, give each artifact a narrow claim:

Artifact	Bounded review purpose
Permission decision record	Show which policy version produced which decision for a correlated action.
Tool request and result record	Reconstruct the declared input, disposition, and returned status within defined retention boundaries.
Diff	Expose the state change proposed or applied.
Test result	Report whether named checks passed under a recorded configuration.
Citation record	Identify the source reference attached to a claim or output.

These purposes are our proposed interpretation framework. They prevent “evidence exists” from becoming a substitute for specifying what the evidence can establish.

The evidence owner is accountable for artifact integrity and availability within the chosen operating boundary. The control owner remains accountable for deciding whether that artifact is sufficient for the clause. Assigning both jobs to one undifferentiated “platform” box hides the handoff that the review needs to inspect.

Review the failure path as part of the contract

A matrix row is ready for review when the failure disposition covers both sides of the contract:

• What happens when preventive enforcement rejects or cannot evaluate the action?
• What happens when execution succeeds but the expected artifact cannot be written or correlated?
• Who can authorize a degraded path?
• Which component records that authorization?
• How is normal operation restored after the dependency recovers?

This extends beyond the two papers’ explicit excerpts. It is an SGL prescription derived from treating control and evidence as separate operational responsibilities. The point is not to force every failure into denial. It is to prevent fallback behavior from being invented inside an incident.

The same review can reveal conflicts between planes. A control-plane owner may revoke a permission while a workflow remains queued in the runtime plane. Because the AOS proposal assigns authority and policy to one plane and scheduling and coordination to another, the architecture invites a concrete design question: at which transition is current authority re-evaluated? See the proposed allocation of responsibilities. The paper excerpt does not answer that implementation question; each runtime design has to do so.

A contract is reviewable when ownership is testable

For each row, ask the named owners to produce three things: the versioned clause, a test that reaches the enforcement point, and the expected artifact for both an allowed and a rejected action. Then exercise the declared failure disposition by making the policy evaluator or evidence path unavailable in a controlled environment.

That exercise does not prove the system safe. It can show whether the implemented ownership and behavior match the recorded contract under the tested conditions. Record the configuration, inputs, results, and unresolved gaps so the conclusion stays bounded to that test.

Start with the actions whose consequences are hardest to reverse. The first useful implementation plan is the one that turns its empty matrix cells into named architecture decisions and testable failure behavior. Teams ready to do that can work with Super Genius Labs.