spec: binding attributable human-approval outcomes to step_up and defer execution evidence

[Thru-Echoes]

Spec section affected
§3.1 (Trust Record claims and evidence composition), §3.3 (verification), and the conformance suite (agentrust-io/trace-tests).

Problem
#114 closed with the decision recorded: 1.0 stays unchanged, and any widened step_up and defer verb set lands under a future profile version, with the version boundary being settled in #116. The closing note names the operator-reported STEP_UP and DEFER semantics the substance of that future version. This issue proposes requirements and a design direction for that substance, so the discussion has a concrete starting point when the version boundary lands.

What the enum alone loses is documented in the #114 thread: who satisfied an escalation, and what its terminal outcome was. Approver identity has to be frozen at emission or the receipt's answer decays by audit time, and a defer without a required terminal state becomes a laundering verb, both per the production report there.

The record currently has no place for either fact. delegation joins machine-delegated authority into the Trust Record (parent_record_hash, credential_id). Human-granted authority has no equivalent join. agent-manifest ADR-0006 defines an attributable approval record (approver-signed, action-bound via evidence_hash, time-bounded, with #40 requiring a human-attributable approver_id), but nothing connects that approval to the run and call that consumed it. The PIC/TRACE authorization bridge binds a pre-execution authorized decision to execution evidence and deliberately keeps authorization and runtime attestation separate; it is allow-only, records no escalation outcomes, and requires no human authorizer, so the escalation lifecycle remains uncovered.

Proposed change
Requirements first, then a candidate direction. Requirements a solution should meet:

1. A verifier can determine, offline, from an evidence bundle: whether an escalated call's authorization was approved, denied, expired, cancelled, or explicitly closed unresolved, and whether approval evidence was consumed by the recorded run.
2. Authorization outcomes and execution evidence stay separate lifecycles, joined by identifiers, preserving the boundary the PIC/TRACE bridge establishes.
3. Approval evidence is attributable to a human principal per ADR-0006 and docs: full doc site upgrade — Getting Started, Integration, Platforms, Schema #40, and is signed by a key the record's subject does not control.
4. Unresolved outcomes are representable and never silently coerced into approval, denial, or expiry.
5. Unknown or unsupported profile versions are refused or reported per the obligations proposed in verification.md: format-versioning and verifier-compatibility obligations (evidence outlives verifiers) #116, which controls version and fallback behavior; this issue does not prejudge verification.md: format-versioning and verifier-compatibility obligations (evidence outlives verifiers) #116's resolution.

Candidate direction, offered for discussion rather than as settled design:

Authorization outcome
requested -> approved | denied | expired | cancelled
requested -> closed_unresolved, only through explicit closure evidence

Execution linkage (approved requests only)
approved -> consumed (enforcement allow) | rejected_by_policy
consumed -> executed | fault

• Each escalation carries a stable decision_id and a canonical action digest, not a transcript index; indexes shift under retries, concurrency, and redaction.
• The approval evidence is an ADR-0006-form artifact signed by the approver's own key over the decision_id, action digest, audience, run, and validity window. Reuse against another decision or run can leave the signature cryptographically valid, but verification fails on the mismatched bindings.
• Separation of duties, machine-checkable: the approval key must not be the record's cnf confirmation key, and the approver principal must not resolve to the record's subject under the verifier's identity policy. A platform-asserted approver_id with no approver-verifiable signature fails; it is otherwise the operator-forgery class LIMITATIONS.md names for software-only records.
• step_up opens an authorization request; defer holds one pending across a policy boundary. Neither authorizes execution by itself. These semantics are proposed here, not current ecosystem behavior.
• closed_unresolved requires explicit closure evidence; the shape and signer of that evidence is a design question for this thread. In deployment data from a decision-provenance protocol I maintain (github.com/Thru-Echoes/TRACE, a different layer from runtime attestation), 117 of 461 recorded decisions were never resolved, so a schema that forces every escalation into expired misdescribes real workflows.
• Privacy: portable records carry a scoped pseudonymous approver identifier; identity resolution stays in restricted evidence. This also addresses the identity-decay problem reported in Widen the per-call decision enum under a new profile version, not in 1.0 #114 without freezing personal identifiers into portable, possibly anchored records.

Container: a detached, separately versioned artifact in the bridge's pattern, or an oversight claim in the Trust Record under the new profile version. The bridge precedent suggests the detached artifact; maintainers are better placed to make that call, and this proposal works in either container.

Conformance fixtures I can draft for trace-tests, mirroring the action-receipts set: step_up approved and consumed; step_up denied; approval expired; action digest mismatch; same-party approval (with the verifier identity mapping needed to make the check deterministic); approval reused across decisions; step_up or defer with no oversight binding; defer closed unresolved; missing closure evidence; unsupported profile version.

Backward compatibility

• Non-breaking

Depends on the container, stated plainly: a detached, separately versioned artifact leaves the Trust Record schema untouched and is non-breaking; an in-record oversight claim is breaking for closed-world v0.2 validators, because additionalProperties: false rejects unknown properties, and so belongs to the next profile version (the vehicle #114 chose), with unknown-version behavior governed by the direction #116 settles. Absence of oversight evidence means no oversight assertion, never that no approval occurred.

Motivation
Auditors ask who approved an escalated call before they ask anything else, per the production report in the #114 thread. Within any profile that records step_up or defer, a decision without an oversight binding should fail verification of a purportedly complete bundle; otherwise an implementation can emit step_up, omit the evidence, and still conform. On the regulatory side, EU AI Act Article 12(3)(d) requires logs for Annex III point 1(a) systems to include the identification of the natural persons involved in verification of results; with the Digital Omnibus in force, those Annex III obligations apply from 2 December 2027. Where an escalated-call approval is part of result verification, attributable oversight outcomes are evidence deployers will need; this proposal supports that evidence without asserting compliance by itself.

Related issues or PRs
#114 (decision recorded; the production report), #116 (format-versioning and verifier obligations; controls version and fallback behavior), the PIC/TRACE authorization bridge (composition precedent; boundary preserved), #66 (two-axis verification; oversight receipts are the human end of the intra-run axis), #117 (GapDisclosure coherence for undisclosed outcomes), agent-manifest ADR-0006 and #40 (attributable approval artifact and approver identity rule).

[imran-siddique]

Holding this, and saying so rather than leaving it quiet, because it is a serious proposal and the wait is structural rather than a judgement on it.

The gap you name is the right one. delegation joins machine-delegated authority into the Trust Record through parent_record_hash and credential_id, and human-granted authority has no equivalent join. agent-manifest ADR-0006 defines an attributable approval record, approver-signed, action-bound via evidence_hash, time-bounded, and #40 requires a human-attributable approver_id, but nothing connects that approval to the run and the call that consumed it. Your reading of the PIC/TRACE bridge is also correct: it binds a pre-execution authorized decision to execution evidence and is deliberately allow-only, records no escalation outcomes and requires no human authorizer, so the escalation lifecycle is genuinely uncovered rather than covered elsewhere.

Both failure modes from the #114 thread are worth keeping in the eventual text in the form you put them: approver identity has to be frozen at emission or the receipt's answer decays by audit time, and a defer with no required terminal state is a laundering verb.

Two things gate it.

It is normative, so under CONTRIBUTING it goes through the spec change process with a sponsoring organization rather than being accepted or declined on this thread. I am routing it internally on that basis.

Independently of that, the substance sits behind #116. #114 closed with the widened verb set landing under a future profile version, and #116, which settles the version boundary and the verifier-compatibility obligations that go with it, is still open. There is no version for this to land in until that is decided, and settling the join before the boundary would mean specifying a field without knowing which format version declares it or what a verifier that does not understand it must do.

So this stays open as the record of the requirements. Nothing here needs restating when the boundary lands.

[Thru-Echoes]

@imran-siddique Thanks for the detailed read. Understood on the internal routing and on #116 settling the version and verifier-compatibility boundary first.