[pre-v1.0] Verification depth + action_receipts: two-axis verification model

[imran-siddique]

Tracking issue for the verification-depth design discussed in #50. This is maintainer-driven editorial work for v1.0, not a contributor schema merge.

Decision

Two independent verification axes, rather than a single extended depth enum:

verification:
  depth: surface | builder_chain | dependency_chain   # supply-chain axis (nests)
  action_receipts: required | optional | none          # intra-run axis (does not nest)

Rationale (from #50):

• The supply-chain axis nests: dependency_chain implies builder_chain implies surface.
• Action receipts do not nest with supply-chain depth: a complete per-action receipt chain can exist for an agent whose builder is unknown, and full dependency_chain trust can exist with zero action receipts. Folding action into the depth enum would imply a false ordering.

Scope of the editorial change

1. schema/trace-claim.json
   • build_provenance.provenance_depth: surface | builder | transitive (records omitting it MUST be treated as surface, backward compatible).
   • appraisal.provenance_depth_verified: depth the verifier actually executed. Downgrade allowed, upgrade forbidden; MUST be present when build_provenance is appraised.
   • verification.action_receipts: required | optional | none, with appraisal.action_receipts_verified mirroring the same downgrade-allowed / upgrade-forbidden rule.
2. docs/verification.md
   • Per-depth verifier obligations (surface / builder_chain / dependency_chain) and the downgrade rule.
   • Profile floors (default = surface; SLSA L2+ = builder; FIPS / EU AI Act Annex IV high-risk = transitive; cMCP reference = builder).
   • Action-receipt verification section for the required case.
3. Settle the open transitive-coverage-URI question (collapses into the same verification object).

Why depth matters

A SLSA attestation from a trusted builder remains signature-valid even when a maintainer CI token is stolen and used to publish a poisoned input. Surface verification accepts the record; transitive rejects it. Concrete cases: Mastra @mastra/core (2026-06-17) and the CI-token-theft pattern raised on postcss#2096.

Cross-references

• trace-spec#50 (origin discussion)
• cmcp#337 / cmcp#339 (embodied-action evidence profile, related evidence binding)
• demos#10 and integrations#6 (per-action receipt action_ref / Ed25519 / hash-chain shape, the reference for action_receipts: required)

Out of scope

Accepting a contributor-authored normative schema diff directly. The schema and verification.md text will land through the maintainer editorial process.

[arian-gogani]

if the action_receipts axis is landing in v1.0, nobulex can serve as a reference implementation for the receipt primitive.

the shape that already works in production: each agent action produces a signed receipt with action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp_ms})). RFC 8785 canonicalization for cross-implementation determinism. Ed25519 signature verified against a pinned authorized key (not the embedded key). hash-chained for ordering.

the important property for trace-spec: verification is offline and operator-independent. a verifier recomputes the action_ref from the receipt fields, checks the signature against the agent's registered key, and walks the hash chain. no callback to the operator's infrastructure. that's what makes it evidence rather than a log.

LangChain and CrewAI callback integrations ship with the SDK, so the receipt emits at the framework hook layer without custom instrumentation.

happy to align the receipt schema with whatever shape the action_receipts axis settles on. the primitive is small enough that conformance is a fixture, not an integration project.

pip install nobulex / npm install @nobulex/core
https://github.com/arian-gogani/nobulex

[carloshvp]

I think the two-axis model is the right shape, especially for embodied-agent workflows.

One framing that may be worth making explicit in docs/verification.md:

For embodied AI, verification.action_receipts: required should mean every externally consequential action has offline-verifiable receipt evidence bound to the session. It should not mean TRACE proves physical completion, controller safety, or that the real world changed as intended.

That distinction matters because embodied systems have at least three separable layers:

1. session-level evidence: the TRACE record and its policy/build/runtime appraisal;
2. action-level evidence: per-action receipts for tool/controller handoff and authorization scope;
3. physical-world outcome evidence: observations from controllers, monitors, humans, or safety systems.

I’d suggest the verifier obligations for action_receipts: required stay focused on layer 2:

• recompute action_ref from a canonical action preimage;
• verify the receipt signature against a pinned or manifest-bound key, not only a self-asserted embedded key;
• verify hash-chain ordering when receipts are chained;
• verify the receipt binds back to the TRACE/cMCP session or call identifier;
• distinguish missing, stale, mismatched, or unverifiable receipts from negative controller outcomes;
• avoid treating a valid receipt as proof of physical completion or functional-safety certification.

For embodied-action profiles, this gives a useful maintainer boundary: TRACE/cMCP can require offline-verifiable action evidence below the session level without over-claiming actuation safety or physical outcome proof.

If helpful, I can follow this with fixture-style examples for a small embodied-action receipt chain: one passing case, one missing-receipt case, one signature/key mismatch, and one receipt that is valid but represents controller rejection rather than physical completion.

[arian-gogani]

@carloshvp the three-layer split (session evidence, action evidence, physical-world outcome) is the right decomposition for embodied systems. the verifier obligations you listed for layer 2 are exactly the shape nobulex implements:

• recompute action_ref from canonical preimage (SHA-256 over JCS)
• verify signature against pinned/manifest-bound key, not embedded key
• verify hash-chain ordering
• bind receipt back to session/call identifier
• distinguish missing/stale/mismatched receipts from negative outcomes

the "not proof of physical completion" boundary is important. a signed receipt proves the agent issued a command to the controller with specific parameters. it does not prove the physical effect occurred. that distinction keeps the verification layer honest about what cryptography can and cannot prove.

fixture examples for an embodied-action chain would be useful for the spec. the negative cases (missing receipt, key mismatch, valid receipt with controller rejection) are where the verification obligations become concrete rather than aspirational.

[0xbrainkid]

Useful split. One small extension that would make this easier to compose with external agent identity systems: keep verification.action_receipts about the intra-run evidence, but add an explicit non-scoring slot for the subject identifier those receipts bind to.

For example:

subject:
  agent_did: did:...
  agent_card_uri: https://...
  external_evidence:
    - type: satp_attestation
      uri: ...
      digest: ...

That keeps TRACE from becoming a directory or reputation layer, while still making the handoff clean for cross-org trust systems. AgentFolio/SATP can consume the resolved DID + receipt digest as external evidence; TRACE remains responsible for saying what was verified in this run and at what depth.

The important boundary is the one already called out above: a receipt proves a specific consequential action was issued under a verifiable key/session. It should not be overloaded into a claim that the physical or business outcome succeeded.

[carloshvp]

I agree with this split. A non-scoring subject slot would make action_receipts easier to compose with external identity systems without turning TRACE into an identity directory or reputation layer.

The boundary I would keep explicit:

• verification.action_receipts stays about intra-run evidence: receipt presence, canonical preimage, signature, hash-chain/order, and binding to the TRACE session or call.
• subject identifies what those receipts are intended to bind to: DID, Agent Card URI, manifest subject, external evidence digest, etc.
• Base TRACE verification should not need to dereference external identity systems to compute its verification depth. It can check local syntax and digest binding, then expose the subject material for AgentFolio/SATP/registry layers to resolve.
• Missing or unresolvable external evidence should be reported separately from a failed receipt verification unless a stricter profile explicitly requires that resolver.

For embodied/action evidence this preserves the three-layer model: session evidence, action issuance evidence, and external-world or business outcome evidence. TRACE can say the action evidence is well-bound and offline-verifiable; it should not imply the physical/business outcome succeeded.

[lywinged]

Strong +1 on the two-axis split — receipt chains and supply-chain depth verify different properties, and the non-nesting call is right.

One verifier-side question I'd like to see settled alongside the axis definition: how does a verifier distinguish "no action occurred" from "a receipt was dropped"? With action_receipts: required, completeness is the property that matters, and a chain can't prove it on its own.

A position from operating a per-action receipt emitter in production: you can't make the emitter gap-proof — any high-throughput writer has a crash window where a tail of receipts is lost. What worked instead was making the emitter detect and disclose its own gaps as first-class signed records ("lost ≤N ms of tail at time T, chain resumes at entry X"), so the verifier can treat a disclosed gap (bounded, operator-attested) differently from an undisclosed one (silent, presumptively adversarial). A chain that can only be "perfect or broken" quietly pressures operators to backfill; one that can say exactly what it lost stays honest under real failure.

If useful, I'm happy to draft this as an ADR for the verification.md obligations side: gap-disclosure semantics + the disclosed/undisclosed distinction as distinct verifier outcomes, with adversarial vectors (dropped-receipt vs. disclosed-gap) for trace-tests.

[Montygogetter]

In thinking about action_receipts: required from a governance and audit perspective, I’m curious about the intended boundary of verification. Is the goal to establish that the referenced action receipt is valid, or should a verifier also be able to establish correspondence between the executed action and the policy decision or authorization state governing that action?

For example, if a policy decision escalates an action for human approval, an auditor may need to establish that the approval preceded execution, applied to the specific action taken, and remained within the authorized scope—not simply that a valid action receipt exists.

If that linkage is in scope, would you see the minimum semantics belonging in TRACE itself, an action-receipt profile or annex, or primarily in the producing runtime?

[tarikskalic33]

One additional negative-control case may be worth separating from missing/mismatched receipts: a cryptographically valid but authority-stale receipt.

If action_receipts: required only checks canonical preimage, signature, chain ordering, and session binding, a receipt could still verify even though the action was issued under an obsolete policy/capability/authority state. That seems distinct from both supply-chain depth and physical/business outcome evidence.

A possible profile-level shape (without making TRACE an authorization engine) would be to let the receipt bind an immutable authority_context_digest or equivalent derived by the governing runtime from the policy/grant/state it actually evaluated. TRACE would verify the binding, not interpret the external policy semantics.

Useful conformance vectors could then include:

• current authority context + valid receipt -> pass;
• valid signature/chain but altered policy or capability digest -> fail binding;
• replay of an old valid receipt under a new authority epoch / fencing generation -> fail binding;
• valid current receipt whose controller outcome is rejection -> receipt evidence passes, outcome remains negative (preserves the session/action/outcome split already discussed).

This would also give appraisal.action_receipts_verified a cleaner fail-closed boundary: cryptographic integrity of the receipt is necessary but not sufficient when the applicable profile says authority-context binding is required.

I'm implementing a similar separation in AEGIS Omega (authority evaluation, stale-state rejection, fencing/replay rejection, then receipt emission), and I'd be happy to turn this into fixture-style negative controls rather than propose a competing TRACE schema.

[tarikskalic33]

I’m exploring a fellowship proposal around executable conformance for the action_receipts axis in this issue. One failure class that seems worth making explicit in the negative vectors is cryptographically valid but authority-stale evidence.

A receipt can be well-formed, correctly signed, and hash-chain consistent while still being inadmissible for the action it purports to justify if the authority context moved between authorization and effect. Examples:

• policy_digest / capability-set digest no longer matches the admitted state;
• a lease/fencing generation advanced, so the signer still has a valid key but no longer has current write authority;
• the same signed receipt is replayed under a different run/action root;
• the receipt binds to the right tool call but the wrong pre-state / expected parent.

I’d suggest keeping this orthogonal to supply-chain provenance_depth, consistent with the two-axis model here: build provenance may verify transitively while the action receipt is stale, and a complete action-receipt chain may verify while build provenance remains surface.

For action_receipts: required, a useful conformance rule could be: the verifier MUST prove receipt completeness and context binding for the exact admitted action/state tuple; signature validity alone is insufficient. The appraisal should report the receipt axis actually verified and fail closed on an unresolvable authority epoch rather than upgrading it.

I’m working on an open governed-agent control plane that uses deterministic execution identity, expected-parent checks, fencing/replay rejection, and receipt chains, so I can contribute negative vectors/reference-verifier work here if this direction matches the maintainers’ intended semantics. I’m not proposing a competing schema or trust score—just executable falsification cases for the decision already made in #66.

[tarikskalic33]

Following up with a concrete non-normative fixture set for the authority-stale class. I’m deliberately not proposing a competing TRACE schema; the point is to make the existing action_receipts decision falsifiable.

Assume the verifier has already established canonical preimage + pinned-key signature + hash-chain integrity. Then evaluate an independent context-binding predicate over the admitted tuple:

B(receipt, admitted) :=
  receipt.session_ref     == admitted.session_ref
  ∧ receipt.action_ref    == admitted.action_ref
  ∧ receipt.policy_digest == admitted.policy_digest
  ∧ receipt.state_digest  == admitted.state_digest
  ∧ receipt.authority_epoch == admitted.authority_epoch
  ∧ receipt.fence_token   == admitted.fence_token

Four useful vectors:

- id: receipt_exact_context_pass
  crypto_valid: true
  chain_valid: true
  context_binding: true
  replay_seen: false
  expected: PASS

- id: receipt_valid_signature_stale_policy
  crypto_valid: true
  chain_valid: true
  receipt.policy_digest: sha256:policy-v2
  admitted.policy_digest: sha256:policy-v3
  expected: FAIL_CONTEXT_BINDING

- id: receipt_valid_signature_stale_authority_epoch
  crypto_valid: true
  chain_valid: true
  receipt.authority_epoch: 41
  admitted.authority_epoch: 42
  receipt.fence_token: fence-41
  admitted.fence_token: fence-42
  expected: FAIL_STALE_AUTHORITY

- id: receipt_replayed_into_new_session
  crypto_valid: true
  chain_valid: true
  receipt.session_ref: session-A
  admitted.session_ref: session-B
  replay_seen: true
  expected: FAIL_REPLAY_OR_SESSION_BINDING

The important appraisal boundary is that crypto_valid=true is necessary but not sufficient for a profile that requires authority-context binding. A verifier should never upgrade action_receipts_verified merely because the signature/hash chain passes when the admitted authority tuple cannot be resolved or no longer matches.

Separately, I’d keep real-world/business outcome outside this predicate. A receipt can pass all of the above while outcome = UNKNOWN or while a controller rejects the requested action. That preserves the session-evidence / action-evidence / outcome-evidence separation already discussed in this thread.

If this matches the maintainer intent, I can turn these into the repo’s preferred fixture format once that format is settled.

[lywinged]

@tarikskalic33 — the concrete set makes this answerable. Intent for v1.0 belongs to the editorial work this issue tracks; what can be answered today is how your set sits against what is already merged, and against the discipline this corpus already enforces.
On the boundary first: the fail-closed you want falls out of what just landed in #173, with #177’s separation folded in. On the depth axis: evidence that resolves and contradicts fails the appraisal, and a verifier does not downgrade to escape it; evidence that does not resolve downgrades honestly — the verifier records the depth it actually achieved; and a configured floor not met by the verified value sets appraisal.status to contraindicated. action_receipts isn’t in the schema yet, but once the axis lands, required plays exactly the role a depth floor plays. So the net behaviour you’re asking for — never upgrade on signature alone when the admitted tuple is stale or unresolvable — is the decided semantics carried over, not a new rule: the stale tuple fails outright, and the unresolvable one downgrades into a floor that refuses it.
On the four vectors, held to the corpus’s own discipline — each vector triggers exactly one rule, and each rule gets two independent vectors split by a named defect:
Three of your six bound fields already have vectors. session_ref: acta 06-session-binding-mismatch plus conformance 12/21. action_ref: conformance 05/10/18/19. policy_digest: acta 05-stale-policy-digest (signature: pass, policy_freshness: fail — your vector 2 is this defect). The genuinely uncovered surface is state_digest, authority_epoch, fence_token, and the replay ledger — build there, and point at the existing vectors for the rest rather than folding them into one predicate; a single B() with one failure code would coarsen a separation the corpus already tests.
Vector 3 carries two defects at once (epoch behind and fence behind) — split it, or define fence_token as derived from the epoch so it’s one defect. Vector 4’s expected code contains “OR”, which is the tell: a vector whose expectation is a disjunction can’t split defects. As sketched (mismatched session_ref) it’s caught by the existing session-binding rule with no new machinery; the uncovered replay case is the one where every binding matches and replay_seen is true.
And the set is missing its fifth member, which your own sentence names: “cannot be resolved or no longer matches” are two outcomes, not one. In the merged semantics they even produce different appraisal shapes — contradicted fails the appraisal outright; unresolvable records the honestly-downgraded value and the floor then sets contraindicated. Same net refusal under required, distinguishable on the record, and the depth corpus already encodes exactly this split vector by vector: 05-…-dependency-publisher-untrusted is the contradicted case, 06-…-resolved-dependencies-absent is the unresolvable one. Your epoch pair should mirror those two.
Your outcome split is already conformance-tested and survives all of this: acta 02-valid-denied.json (decision deny, every check pass) and cA2A’s ACTION-007 both pin “receipt evidence passes, outcome remains negative.”
On format, nothing needs to settle before you draft: expected outcomes declared beside the vectors (acta’s expected.json; agent-manifest embeds the expected VerificationResult per vector — either beats encoding them in tests), deterministic keys with committed private halves, and a generator — the guard merged in #171 auto-discovers any gen_*.py under examples/ and holds it to byte-reproduction; #178 is open on making that the corpus-wide invariant. Since the axis is editorial, attach the drafts to this issue as candidate fixtures — they can’t merge ahead of the schema decision, but they’ll test it the day it lands and inform it before then. Happy to review