Proposal: bind the authorization decision to what happened next (outcome events, schema v2)

[rafaelasor]

Revision 5 (final), amended 2026-08-31. Four adversarial reviews, then five sharpenings from the first reviewer, then one amendment from the implementation's code review: the lifecycle labels are four, adding revoked (a cleanly killed node with nothing pending, which never escalates the aggregate) — the three-label list could not represent it.

Scope, first. Earlier revisions tried to specify, in one page, an evidence layer, a runtime
prevention mechanism, a verifier policy language and an observer protocol. Four adversarial review
rounds later, this document specifies one thing: an evidence record that binds each authorization to
what the adapter's wrapper observed afterwards, and the offline checks over those records. Three things
are out, named in section 8 with where they will be specified instead: runtime duplicate prevention,
verifier-side capture policy, and the observer attestation envelope.

The claim shrinks accordingly. This layer does not prevent anything at runtime and does not prove what
happened in the world. It makes the producer's own account of "allowed, and then what" internally
checkable, offline, by anyone holding the bundle and an independently retained anchor.

1. Identity: call_id

Guard.check() allocates call_id inside its locked transition: 16 bytes from the OS CSPRNG, lowercase
hex. It is written on the allow or deny entry and returned on the Decision. If the random source
fails, the call is denied and nothing is written. call_id is not derived from ledger content, so it
survives redacting export unchanged. A repeated call_id across any two allow or deny records in a
chain is duplicate_call_id at verification. Only an allow enters the pending set; a deny never
expects an outcome. An outcome must match exactly one allow, never a deny. Ledger hashes remain
integrity links, never record identity.

The transition, in order under one lock: refuse if the node is finalized; evaluate authority and
ceilings, update meters; allocate call_id; commit the entry to the in-memory chain; register an
allowed call as pending; return the Decision. A failure before the commit point: meters are restored,
nothing is pending, the call is denied. After the commit point, the audit-path file write and every
configured sink are post-commit persistence operations: a failure there raises CommittedAuditError,
which carries the committed entry and the decision, and the guard registers an allowed call as
pending before raising. Callers MUST NOT retry the body merely because this exception was raised. A caller that retries anyway
authorizes a new call and receives a fresh call_id; the two records carry no statement that they were
attempts at one logical operation, and duplicate execution after such a retry is among the things
verification cannot establish. call_id reuse across attempts is never permitted.

Restart rule. A process restart cannot resume an existing chain. It must create a new chain;
pending calls in the old chain remain unaccounted, which is the truthful record. Opening an existing
audit path for a new chain fails without truncating it.

complete() returns CompletionResult(completed: bool, pending_call_ids: tuple[str, ...]): it refuses
while the pending set is non-empty and appends nothing. kill does not write outcomes: it revokes and
records the pending ids as pending_at_kill. A wrapper that later observes its body finish appends the
real record, accepted after the kill. A call that never reports stays exactly that.

2. What the allow carries

call_id. capture: what the adapter's code path will observe for this call, one of wrapper_sync ·
wrapper_async · framework_post_hook · pre_hook_only, together with adapter: module name, version
and hook path. Capture describes observation capability, nothing more; when the observer envelope of section 8 lands,
observer identity gets its own field, and capture never acquires that second meaning. authorized_params_hash, and
params_hash_reason on this record when its hash is absent (section 4).

3. The outcome record

Appended by the capture point named on the allow, when its observation of the call ends. It is an
observation record, not a judgment about the world:

field	value
event	outcome
call_id	from the allow
body_state	returned · raised · abandoned · deferred
invoked_params_hash	section 4; params_hash_reason on this record when absent
error_code	normalized class name, required exactly when body_state is raised. Never a message
duration_ms	non-negative integer, observation start to observation end
receipt	optional, unverified carriage, section 7

returned: the body returned to the wrapper. raised: it raised; a deadline the wrapper itself
enforced and turned into an exception is raised with its code. abandoned: the wrapper stopped
observing while the body may still run, which is what an external cancellation or an unenforceable
timeout actually is. deferred: the wrapper returned a generator, stream or future whose consumption it
does not observe; the record covers the call, not the eventual exhaustion. There is no executed,
blocked, timeout or cancelled at this layer, because each of those words claims knowledge a
wrapper does not always have. Adapters emitting into outcome vocabularies own that mapping (section 6).

Exactly one outcome per call_id, enforced at append under the lock within the chain's lifetime; the
restart rule in section 1 is what makes that enforceable. A second outcome reaching a bundle anyway is
duplicate_outcome.

4. Arguments: two commitments

authorized_params is a distinct input to check(): the exact tool-call JSON object presented at
authorization time. invoked_params is the corresponding JSON object observed by the body-owning
wrapper immediately before the actual invocation. Raw values of either are hashed and never logged. The
hashes land as authorized_params_hash on the allow and invoked_params_hash on the outcome. Two
observations at two moments; substitution between them is visible only because both exist. A
pre_hook_only capture has no second observation and never copies the first.

Numeric profile params_c14n_v1, shared by Python and TypeScript: the JSON values the canonicalizer
accepts, with one rule stated runtime-neutrally: every mathematically integral number outside
±(2^53−1) is rejected, regardless of the host's numeric type. Outside the domain: no hash, and
params_hash_reason: unsupported on the record whose hash is absent.

Commitment: decode params_salt (32 lowercase hex characters on the root entry) to its 16 raw bytes,
then SHA-256(raw_salt || UTF8(JCS(params))), lowercase hex. The salt prevents linking argument
equality across chains. It does not help inside a bundle, where a low-entropy argument is recoverable by
enumeration, and multiple exports of one chain share it. A deployment that must not disclose argument
equality omits the hashes; the verifier reports params: not recorded. Cross-runtime vectors are
required for every accepted boundary and every rejection. Every field named in this document is added to
the evidence exporter's allowlist.

5. What the verifier reports

verify_bundle gains execution_binding. Records are schema-validated before classification: field
types, formats, enums and conditional requirements (an unknown body_state, a missing error_code on
raised, an illegal conditional field, a negative or non-integer duration, a malformed hash) are
invalid_allow or invalid_outcome, each naming the record.

Per call, observation: observed (an outcome exists, bound correctly; abandoned and deferred
are observed, reported with their state) · unobserved (capture: pre_hook_only; no outcome was
promised) · unaccounted (an outcome was promised and is absent). Per node, lifecycle:
finalized (done) · in_progress (neither done nor kill; pending calls report
in_progress, a snapshot, not a verdict) · revoked (kill with nothing pending; never escalates
the aggregate) · revoked_with_pending (kill with never-reported calls).
Aggregate: clean · incomplete · failed. clean asserts one thing: the producer's records
are internally consistent. It does not assert the lifecycle of every action is known: an abandoned
call is a precise observation whose action outcome stays unknown, and it leaves the aggregate clean
while its own state says so. Any unobserved, in_progress or revoked_with_pending makes the
aggregate incomplete, never clean, even where it is no producer fault. An unaccounted call in a
finalized node makes it failed.

Binding coverage is its own axis, reported beside the aggregate, never folded into it:
params_coverage: complete | partial | none, from how many calls carry both hashes. A bundle whose
deployment omitted the hashes can be clean with params_coverage: none, and the report says both.

Binding failures, each a reason code: outcome_without_allow (an outcome whose call_id has no allow
in this chain and node; a record copied in from anywhere else lands here), duplicate_outcome,
duplicate_call_id, outcome_before_allow (outcome seq not after its allow's), cross_ref (a
matching call_id on a different node within the same chain), params_mismatch (both hashes present,
different). An entry whose chain_id differs from the bundle's is already chain_id_mismatch, so
cross-chain splicing fails before binding is examined.

Verification never consults current authority state: the committed allow is the historical authority
fact for this layer, and a revocation that happens later does not retroactively turn the chain into a
contradiction. The verifier accepts an independently retained expected anchor or head as input; verifying against only
the bundle's enclosed anchor detects tampering since that anchor, nothing earlier, and the report says
which it had.

What passing proves. The retained records are internally consistent: every authorization has at
most one bound observation record, none exists without its authorization, the bindings hold, and
nothing was altered since the anchor the verifier held. Parameter equality is established only for
calls where both hashes are present; elsewhere only identity and order binding was checked. What it
does not prove: who wrote the records. The library trusts its own process, and in-process code can
append chain-valid entries; whether the effects happened in the world; or that every call that ran was
recorded — a bypassed interception point leaves nothing, and the bundle verifies. These are the
producer's books, checkable for consistency; they are not a witness.

6. Crosswalk with crewAIInc/crewAI#6030

The PR is open and contract-only; this maps to its text as fetched, and the adapter's alias layer, not
the schema, tracks it.

#6030	here	note
decision_id	call_id	same role; the CrewAI adapter emits decision_id with this value
params_hash	authorized_params_hash	direct correspondence; invoked_params_hash has no #6030 equivalent
outcome ∈ executed/blocked/error/timeout	body_state ∈ returned/raised/abandoned/deferred	theirs is an outcome vocabulary, ours an observation vocabulary. The adapter maps returned→executed and raised→error. It may emit blocked only from its own denial path, when it prevented entry into the body, and timeout only when it enforced and observed its own deadline. An external cancellation maps to neither; it is abandoned here and nothing there
idempotency_key, duplicate-terminal denial	deferred, section 8	a runtime mechanism, reviewed with the implementation that provides it
intent_ref, intent_digest, normalized_scope, target	not carried	#6030 models semantic intent; this layer records the authorized call
boundary_id, running_count	no equivalent	chain_id+node and ledger seq provide correlation and ordering; they do not implement #6030's record-count contract
tool_output_hash	not carried	results are never committed to, by privacy rule
everything else (policy_*, credential_*, expiry, supersession, extensions)	not carried	decision lifecycle lives in the token and grants

7. Receipts

receipt is unverified carriage and labelled so: {type, ref, digest}: the format and version, that
format's own correlation id, and SHA-256 over the envelope bytes as received. The library verifies
nothing about it. A verifier that wants it checked does so in the receipt format's own terms, and can
join the artifacts only where that format carries our call_id in a field it provides.

8. Deferred, deliberately

Runtime duplicate prevention (idempotency_key, reservation states, cross-process coordination):
specified with the implementation that provides its guarantees, as its own reviewed change. Until then
this layer records keys when adapters supply them and claims nothing about duplicates.

Verifier capture policy (required_capture profiles, trust ranking of capture labels): its own
design; capture labels here only route calls into observed/unobserved reporting and are never trusted
as claims of quality.

Observer attestations: the envelope a neutral matching service signs is being designed against a
concrete implementer of such a service and will be reviewed with them. Until then outside observations
travel as receipts, unverified.

9. Versions

One schema version per chain, stated on the root entry. Supported-version and bundle↔anchor equality
checks are on main and ship in the next release; root↔bundle equality and rejection of mixed entry
versions are part of this change. The verifier dispatches on version: v1 bundles get today's checks and
execution_binding: not applicable; unknown versions are unsupported_version. Chains are created at
one version and never mix; upgrading a deployment means new chains, not rewritten ones.

10. Vectors

One per reason code in section 5, and: concurrent duplicate-outcome append; allow-versus-deny pending
behaviour; duplicate ids across allow and deny; pre-commit failure and each post-commit persistence
failure; the restart rule; the CompletionResult shape on complete-with-pending; every body_state
conditional field and each invalid state; raw-salt versus hex-salt hashing; safe-integer boundaries,
integral floats, negative zero, non-finite numbers, lone surrogates and unsupported objects; each hash
independently absent or unsupported; hashes deliberately omitted by a deployment; root, bundle and
anchor version mismatches and mixed entry versions; pre_hook_only without an outcome; every aggregate
state including each way "not clean" arises; a malformed receipt digest; a killed node with a late true
record and with a never-reporting call; a retry after CommittedAuditError (two calls, no shared-operation
statement); an in-progress snapshot; an abandoned call inside a clean aggregate; Python and TypeScript byte-for-byte
parity throughout.

11. The ask

Section 3's body_state vocabulary, read against what your wrapper can actually see. Section 6's
mapping rules for your own vocabulary, if you carry one. And whether the narrowed scope is worth having:
an observation record and its consistency checks, with prevention and observation-by-others deferred.

Ships as 0.9.0, Python and TypeScript, if the vectors hold.

[aeoess]

Read sections 3 and 5 against what the wrapper can actually know. Most of the epistemic traps I went looking for are already handled, especially refusing executed, blocked and timeout as wrapper claims, keeping in_progress non-terminal, and reporting specific inconsistencies instead of one contradicted bit.

Five things remain.

1. clean is doing two jobs around abandoned.

For abandoned the wrapper has observed something precise: it stopped observing while the body may still be running. What stays unknown is the action outcome. So whether clean is right depends on what clean means.

If it means the producer's record is internally consistent, abandoned can be clean. If it means the lifecycle is fully accounted for, it cannot. I would make that distinction explicit, because a reader will otherwise take the headline as stronger than the per-call state.

2. Parameter-binding coverage disappears at the aggregate.

Section 4 can omit both parameter hashes, and section 5 honestly reports params: not recorded, but a bundle with no explicit argument-binding evidence can still headline as clean.

I would keep lifecycle status and binding coverage as separate axes rather than let one distort the other, and surface the coverage beside the aggregate: params_coverage, binding: complete | partial, something of that shape. Right now the absence is visible only after drilling into the call.

3. The post-commit retry rule carries a correctness assumption the evidence may not expose.

After CommittedAuditError the body may already have run and the caller gets a MUST NOT retry. What would the verifier observe if a caller violates it?

If a retry receives a fresh call_id, there may be two records with no statement that they are attempts at one logical operation. If reuse is possible the ambiguity is worse. Section 10 has the persistence-failure cases; I would add the retry-after-ambiguous-commit case, or list duplicate execution after such a retry among the things verification cannot establish.

4. Keep observation capability and observer provenance separate when section 8 lands.

capture answers what the observation point could see. The future observer envelope answers who supplied or attested the observation. Those are independent facts. I would keep capture strictly capability-only and give observer identity its own field, rather than letting one field acquire both meanings later.

5. One boundary in section 5 should be explicit: does verification ever re-evaluate authority state?

My preference is no. The committed allow record is the historical authority fact for this layer, and a revocation that happens later must not retroactively turn that chain into a contradiction. If that is already the model, one sentence saying the verifier does not consult current authority state would close it. If authority is re-evaluated anywhere, the reference time needs naming.

The narrowed scope is good. The sentences I would defend hardest are that these are observation records rather than claims about what happened in the world, and that they are the producer's books rather than a witness. That is what keeps the rest of the format honest.

On mapping the vocabulary into ours, I am leaving that for a separate decision rather than smuggling it into this review.

[rafaelasor]

All five taken, in the body now.

1. clean is defined: internal consistency of the records, nothing about lifecycle being fully known. An abandoned call leaves the aggregate clean and its own state says what stays unknown.
2. Binding coverage is its own axis beside the aggregate: params_coverage: complete | partial | none. A bundle can be clean with none, and the report says both.
3. Stated: a retry after CommittedAuditError gets a fresh call_id, the two records carry no shared-operation statement, and duplicate execution after such a retry is listed among what verification cannot establish. Reuse is never permitted. Vector added.
4. capture stays capability-only; observer identity gets its own field when the envelope lands.
5. One sentence added: verification never consults current authority state. The committed allow is the historical fact, and a later revocation does not rewrite the chain into a contradiction. That was the intended model; it needed saying.

The two sentences you would defend hardest are the ones I will not trade away either.

[rafaelasor]

Shipped: 0.9.0 (PyPI) and 0.4.0 (npm) implement this proposal as written, including the review amendments recorded above. Opt-in per chain; v1 untouched. The language-neutral params_c14n_v1 vector file ships in the Python package and the TypeScript suite verifies against the same bytes. The deferrals in section 8 stay deferred: runtime duplicate prevention, verifier capture policy, and the observer envelope, which will be designed with the two implementers who engaged on it in the A2A thread.