RFC-0017: Commit Boundary and Binding Validation for AGP-1

RFC: RFC-0017
Status: Draft
Version: 0.1.0
Created: 2026-04-04
Updated: 2026-04-04
Author: Ken Tannenbaum, AEGIS Initiative / AEGIS Operations LLC
Repository: aegis-governance, aegis-core
Target milestone: Q3 2026
Supersedes: None
Superseded by: None

Summary

AGP-1 currently collapses admissibility evaluation and binding into a single DECISION_RESPONSE step. This RFC introduces an explicit commit boundary as a first-class protocol concept, separating admissibility (is this transition valid in principle?) from binding (does this transition hold under the state that actually exists at execution time?). It also introduces the admissible set — the recognition that governance evaluation may produce multiple valid transitions, not a singleton, and that the protocol must support deterministic resolution over that set.

This RFC aligns AGP-1’s execution model vocabulary with Willis (2026), “AI Runtime Governance: Vocabulary,” and extends the authority re-derivation work begun in RFC-0011.

Motivation

The collapse problem

AGP-1’s current message flow is:

  1. ACTION_PROPOSE — agent proposes an action
  2. DECISION_RESPONSE — governance evaluates and returns ALLOW/DENY/ESCALATE/REQUIRE_CONFIRMATION
  3. EXECUTION_REPORT — agent reports what happened

The gap is between steps 2 and 3. Once DECISION_RESPONSE returns ALLOW, the agent is free to execute. But in concurrent systems, canonical state may have changed between evaluation and execution:

AGP-1 has no mechanism to catch these. The EXECUTION_REPORT is post-hoc — it tells you what happened, not whether what happened was still admissible at the moment it became real.

The singleton problem

AGP-1 produces a single decision per proposal. In concurrent multi-agent systems, the governance layer may determine that multiple transitions are admissible under the same canonical state. The current protocol has no concept of an admissible set and no mechanism for deterministic resolution when multiple valid transitions compete for the same commit boundary.

External validation

Willis (2026) formalizes a 10-step execution model that draws these distinctions precisely 1:

AGP-1 violates three of these six distinctions in its current form. This is not a theoretical concern — it means AGP-1’s governance guarantees degrade in concurrent deployments where state drift between evaluation and execution is non-trivial.

RFC-0011 (Authority Binding Sub-Spec Revision) addresses a subset of this problem — specifically, authority drift and the conditions under which proposal-time authorization does not imply commit-time admissibility. This RFC extends that work to the full protocol flow.

Guide-Level Explanation

Before this RFC

An agent proposes an action. The governance engine evaluates it and says ALLOW or DENY. If ALLOW, the agent executes. Done.

This works when:

After this RFC

The execution model becomes:

  1. Propose — Agent produces a proposed transition (candidate state mutation, not execution)
  2. Evaluate — Governance evaluates against canonical state, compiled governance, and derived authority to determine admissibility
  3. Admissible set — Evaluation may produce one or more admissible transitions (this is the normal case in concurrent systems)
  4. Bind — At the commit boundary, authority is re-derived from current state, ordering and interaction are resolved, and the admissible set is deterministically resolved
  5. Commit — Successfully bound transitions mutate canonical state and produce a new baseline for all subsequent evaluation
  6. Report — Execution artifacts are captured for audit and replay

The key change: nothing is final until binding. Admissibility is necessary but not sufficient. A transition that was admissible at evaluation time may not be bindable at commit time because the world moved.

What this means for implementers

Reference-Level Explanation

New message types

BIND_REQUEST

Sent by the agent after receiving DECISION_RESPONSE(ALLOW) and before executing the proposed action. Requests binding validation against current canonical state.

{
  "type": "BIND_REQUEST",
  "proposal_id": "<original proposal ID from ACTION_PROPOSE>",
  "decision_id": "<ID from DECISION_RESPONSE>",
  "agent_state_hash": "<hash of agent's current local state>",
  "timestamp": "<ISO 8601>"
}

BIND_RESPONSE

Returned by the governance engine after re-deriving authority and resolving the admissible set against current canonical state.

{
  "type": "BIND_RESPONSE",
  "proposal_id": "<original proposal ID>",
  "decision_id": "<ID from DECISION_RESPONSE>",
  "outcome": "BOUND | REJECTED | SUPERSEDED",
  "rejection_reason": "<if REJECTED: authority_drift | state_conflict | ordering_conflict | delegation_expired | quota_consumed | revocation_issued>",
  "superseded_by": "<if SUPERSEDED: proposal_id of the transition that committed first>",
  "canonical_state_hash": "<hash of canonical state at bind time>",
  "constraints": [ ... ],
  "timestamp": "<ISO 8601>"
}

Outcome semantics:

Revised protocol flow

Agent                          Governance Engine
  |                                   |
  |--- ACTION_PROPOSE -------------->|
  |                                   |-- evaluate admissibility
  |<-- DECISION_RESPONSE ------------|   (against canonical state)
  |    (admissibility determination)  |
  |                                   |
  |--- BIND_REQUEST ---------------->|
  |                                   |-- re-derive authority
  |                                   |-- resolve admissible set
  |                                   |-- validate against CURRENT state
  |<-- BIND_RESPONSE ----------------|
  |    (BOUND / REJECTED / SUPERSEDED)|
  |                                   |
  |    [if BOUND: execute]            |
  |--- EXECUTION_REPORT ------------>|
  |                                   |-- new canonical state produced

Admissible set resolution

When multiple ACTION_PROPOSE messages are evaluated concurrently and multiple receive DECISION_RESPONSE(ALLOW), the governance engine maintains an admissible set — the set of transitions that are valid under the current canonical state.

At the commit boundary, the engine resolves the admissible set using the following deterministic algorithm:

  1. Re-derive authority for each candidate against current canonical state
  2. Discard candidates whose authority no longer holds (REJECTED with reason)
  3. Resolve ordering — candidates are ordered by proposal timestamp; ties broken by proposal_id lexicographic order
  4. Check interaction — if committing candidate N would invalidate candidate N+1, mark N+1 as SUPERSEDED
  5. Bind the first candidate that passes all checks
  6. Re-evaluate remaining candidates against the new canonical state produced by the bound transition (recursive)

This algorithm is deterministic: same inputs, same ordering, same result. Replay can verify any commit.

Timing and performance

The BIND_REQUEST / BIND_RESPONSE exchange introduces latency between admissibility evaluation and execution. Performance targets:

Interaction with RFC-0011

RFC-0011 defines authority invalidation conditions and failure outcomes. This RFC consumes those definitions:

This RFC does not duplicate RFC-0011’s normative definitions. It specifies the protocol-level mechanism through which those definitions are enforced.

Vocabulary alignment

This RFC adopts the following vocabulary from Willis (2026) as normative for AGP-1:

Willis termAGP-1 mappingStatus
Proposed TransitionACTION_PROPOSEAlready aligned
Governance CompilationPolicy DSL compilation + capability registry resolutionAlready aligned (rename not required)
Canonical StateAuthoritative system state at evaluation/bind timeNew — must be formalized
AdmissibilityDECISION_RESPONSE outcomeSemantics narrowed (was: final decision; now: admissibility determination)
Admissible SetSet of concurrent ALLOW’d proposals pending bindingNew concept
Binding ValidationBIND_REQUEST / BIND_RESPONSENew message types
Commit BoundaryThe point at which BIND_RESPONSE(BOUND) is issuedNew concept
Bound Transition / ExecutionSuccessfully bound + committed transitionClarified (was: any executed action)

Drawbacks

  1. Latency — The additional BIND_REQUEST / BIND_RESPONSE round trip adds latency to every governed action. For low-contention single-agent deployments, this overhead provides little benefit.

  2. Complexity — Agents must now handle three-phase interaction (propose → admissibility → bind) rather than two-phase (propose → decide). SDK implementations become more complex.

  3. Backwards compatibility — Existing AGP-1 implementations that treat DECISION_RESPONSE(ALLOW) as final authorization will need to be updated. A migration path is required.

  4. Admissible set resolution in practice — Many deployments will never have concurrent proposals competing for the same commit boundary. The admissible set machinery may be over-engineering for common cases.

Alternatives Considered

1. Status quo with advisory guidance

Leave AGP-1 as-is and document that DECISION_RESPONSE(ALLOW) should be treated as advisory in concurrent deployments. Rejected because advisory guidance without protocol enforcement is exactly the failure mode Willis identifies: “If these distinctions collapse, governance collapses into approximation.”

2. Optimistic binding with post-hoc validation

Allow agents to execute on DECISION_RESPONSE(ALLOW) and validate binding post-hoc via EXECUTION_REPORT. If binding would have been rejected, issue a rollback. Rejected because rollback is not always possible (external effects, irreversible actions) and because it violates the principle that governance must hold before reality changes.

3. Fold into RFC-0011

Extend RFC-0011 to cover the full commit boundary protocol. Rejected because RFC-0011 is scoped to authority binding specifically (claim sets, behavioral declaration, drift conditions). This RFC addresses the broader protocol flow including admissible set resolution, new message types, and vocabulary alignment.

4. Optional binding phase

Make BIND_REQUEST optional — agents can choose to skip it for low-risk actions. Rejected because optional governance mechanisms tend to become unused governance mechanisms. The binding phase should be mandatory with the governance engine optimizing the fast path (single proposal, no contention → immediate BOUND response).

Compatibility

Implementation Notes

Open Questions

Success Criteria

References

AEGIS™ | “Capability without constraint is not intelligence”™
AEGIS Initiative — AEGIS Operations LLC

Footnotes

  1. Willis, J. M., “AI Runtime Governance: Vocabulary — Walkthrough Style,” v1.0, April 2026. ↩