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, anchoring — 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; an anchoring 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.
How composition works: reference by digest
A capsule binds external evidence into its verifiable trail through its references array: each entry commits the digest of another artifact — an authorization grant, a policy decision, an upstream receipt — without copying or exposing it, and says why it is cited. The verifier checks the binding; the referenced data stays where it lives. chain is a different field: it links a capsule only to the same producer's previous capsule, such as a confirmation to the action it confirms (see what is a capsule).
{
"action_id": "po-0047-submit",
"operator": "acme-co",
"chain": { // same producer, same stream only
"parent_capsule_id": "3c1e…a07b",
"relation": "follows"
},
"references": [{ // anything outside the stream
"type": "…", // a registered artifact type
"digest_alg": "sha-256",
"digest": "9f2a…c14", // digest of the grant
"citation_purpose": "ran_under" // the authority it ran under
}]
}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. Both vocabularies — chain.relation and citation_purpose — are registries defined in the spec; to register a value for your layer, open an issue on the spec.
| Layer | It answers | How the capsule composes |
|---|---|---|
| Identity / delegation | who the agent is acting for | reference the identity or delegation credential by digest |
| Authorization / policy | whether the action was permitted | reference the grant or policy decision by digest |
| Anchoring / transparency log | that the record was publicly included | the SCITT receipt — the capsule is log-agnostic |
| Input integrity / provenance | whether upstream inputs are authentic | reference 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.
The four-leg accountability picture
A fuller framing of agent accountability splits into four questions: CAN (was the action permitted? — authorization), WHO (which accountable human authorized this exact action? — named-human authorization), 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 anchored record ties to the authorization grant (CAN), the named human's authorization receipt (WHO), and the runtime gate's decision (AUDIT) without any layer absorbing the others.