Concepts

How it composes with your stack

The capsule is one layer in a stack, not a replacement for the others. It sits alongside the layers you already use — identity, authorization, witnessing — and adds the piece none of them provide on their own: a record any third party can verify without trusting any single party.

Composes, doesn't replace

Most agent-trust layers answer a different question than the capsule does. Identity says who is acting; authorization says whether an action is allowed; a witnessing log says the record was included. The capsule answers what the agent did, in a record anyone can check — and it leans on those other layers for the rest rather than reabsorbing them. There's no need to fork your stack to adopt it. One line: compose([...]) — see the translation page for the dev/auditor/spec breakdown of every verb, including compose.

What this actually establishes

Auditor register — what composition proves, and what it doesn't

Composition is a membership claim, not a new assertion. Binding an authorization grant, identity credential, or upstream evidence by digest says only this action cites that artifact — it does not re-verify that artifact's own truth, and it does not upgrade a self-attested layer into a witnessed one. If the referenced grant was itself never witnessed, composing it into a capsule doesn't witness it retroactively; the capsule just proves the reference existed and was intact at seal time. Each composed layer's own assurance level stays exactly what it was.

How it works: reference by digest

A capsule binds external evidence into its verifiable trail through chain.relation: it commits the digest of another artifact — an authorization grant, a policy decision, an upstream receipt — without copying or exposing it. The verifier checks the binding; the referenced data stays where it lives. (The same mechanism links a confirmation back to the action it confirms — see what is a capsule.)

{
  "action": "submit_order",
  "operator": "acme-co",
  "chain": {
    "relation": "authorized-by",      // this action was permitted by …
    "ref": "sha-256:9f2a…c14"         // digest of the grant / credential
  }
}

Illustrative: the capsule carries only the digest of the authorization grant, policy decision, or identity credential — never its contents. A verifier recomputes that digest from the artifact you (or a partner layer) present, and confirms the binding. The precise relation vocabulary is defined in the spec registry; to register a relation for your layer, open an issue on the spec.

LayerIt answersHow the capsule composes
Identity / delegationwho the agent is acting forreference the identity or delegation credential by digest
Authorization / policywhether the action was permittedreference the grant or policy decision by digest
Witnessing / transparency logthat the record was publicly includedthe SCITT receipt — the capsule is log-agnostic
Input integrity / provenancewhether upstream inputs are authenticreference the input-integrity evidence by digest

What only the capsule adds

A record of what the agent did that any third party can verify without trusting the operator, the model vendor, or the log. That neutrality is the point: it's the piece a single party's own system can't provide for itself, because a party vouching for its own actions is exactly what a verifier can't take on faith.

A capsule records the bytes it is given. Authenticating upstream inputs — that a tool response or grounding source is genuine — is a separate, composable layer; bind its evidence by digest and the verifier checks that too. Composition, not dependency.

The four-leg accountability picture

A fuller framing of agent accountability splits into four questions: CAN (was the action permitted? — authorization), WHO (which accountable principal? — identity), WHAT (what did the agent do? — the Agent Action Capsule), and AUDIT (did the runtime enforce correctly? — observability and gating). Each leg answers its own slice; together they span the accountability gap.

The capsule is the WHAT leg. The four legs compose by a shared action digest: subject_digest = SHA-256(JCS(action)) — any layer that commits to the same action digest binds itself to the same event, so the capsule's witnessed record ties to the authorization grant (CAN), the identity credential (WHO), and the runtime gate's decision (AUDIT) without any layer absorbing the others.

The CAN/WHO/WHAT/AUDIT composition model — how independently-verifiable records join on a shared action digest — is laid out on the Standard's Composition section. Underneath it, the Canonical Payload Binding (CPB) is the small companion spec that lets every record compute the same digest: it defines how a payload binds to a SCITT receipt and how a payload class declares and resolves its canonical form, so any conforming profile composes with a capsule without a custom adapter. CPB has its own site and registry: canonicalpayloadbinding.org ↗.