Concepts
The statement layer vs the transparency layer
Two concerns, deliberately kept apart: what happened (a signed statement) and where it is recorded (a transparency log). The statement never depends on which log technology you choose.
Two layers
| Layer | Answers | Form |
|---|---|---|
| Statement | What action happened, signed by whom? | A COSE_Sign1 Signed Statement (the Agent Action Capsule profile). |
| Transparency | Was this statement recorded in an append-only log, and can that be proven? | A transparency service that registers the statement and returns a receipt. |
Why the separation matters
Keeping the statement independent of the log means a single capsule can be anchored to more than one transparency service, and verified the same way regardless of how each log structures its proofs. The action layer never changes when the log changes — this is what we mean by verifiable-data-structure agnostic.
The stack
Each layer is a separate, open-source library so the boundaries stay honest:
| Component | Role |
|---|---|
| agent-action-capsule | The profile — the Signed Statement format and the reference verifier. |
| capsule-emit | The producer — seal an action in one call, or wrap an existing tool with one decorator. |
| scitt-cose | The verifier — checks SCITT receipts across verifiable data structures. |
| capsule-anchor | The log — a neutral transparency service implementation. |
Read next: what a transparency service is, and how it differs from a verifier.
Go deeper — implementation & usage docs in
capsule-emit: Going deeper — the layers ↗