[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