plimsoll run records as Agent Action Capsules

An Agent Action Capsule ↗ is a signed JSON record of one action an automated system took: why it ended as it did, what is known about its effect, and who vouches for that. This page takes the five calls in plimsoll's published session bundle and states each as a capsule (draft-mih-scitt-agent-action-capsule-05). plimsoll's own verifier checks the bundle first; only a record it accepted becomes a capsule. Then both of the capsule project's verifiers check the result, including copies deliberately broken to be refused.

The capsules

Call 1's own test failed on purpose (the session example plants a bug and fixes it in call 2). It is still executed and confirmed: plimsoll ran the code and observed the result, and the exit code is inside the digested response. A failing program is a result, not an unknown.

What each verifier did

The Python verifier is the capsule project's reference implementation (agent-action-capsule 0.6.0, with its own canonicalization and SHA-256), so it shares no code with the Go emitter that built the capsules. Signatures are checked twice: in Go by the emitter's VerifyEnvelope (go-cose), and in Python by the project's own verify_producer_envelope, which reaches COSE_Sign1 through scitt-cose ↗ 0.4.0. scitt-cose implements COSE_Sign1 from scratch rather than wrapping a COSE library, so the two signature checks share no COSE code either.

The last two rows differ on purpose. Removing a capsule from the middle of the chain is caught because the next capsule names it as its parent. Removing the last one is not caught by a store check, because nothing names it; that is what the capsule project's witnessed log is for, and these capsules were not sent to one. plimsoll's bundle ends in a signed statement of how many calls the session made and which record was last, so its verifier catches a missing tail on its own.

How a plimsoll outcome reads as a capsule

Every row uses effect_attestation: runtime_claimed: the capsule records the daemon's statement, checked against the stored bytes by the harness that signed it, not an observation this program made. The vocabulary's stronger grade, gate_executed, is for a producer that observed the effect boundary itself; whether a collector restating a gate's signed record may carry it is a question put to the specification's author and not yet answered, so the capsules claim the grade this program can vouch for. The bundle above exercises only the first row; the others are built and checked by both verifiers in examples/capsule/mapping_test.go. setup_failed and protocol_error share a class and a status, and a dispatched effect may not carry a response digest, so the reason digest (a digest of {"plimsoll_outcome": ...}, or {"plimsoll_unanswered": ...} for a lost answer) is what keeps them apart. Each session call after the first chains to the one before with relation: follows, which orders without claiming anything about the parent.

What these capsules claim, and what they do not

• They are backfilled, and say so. provenance_mode is backfilled with time_rung: self_attested: the times come from plimsoll's records, which a harness signed, and no witness saw them. source_ref is each call's plimsoll run record, by the SHA-256 plimsoll's verifier checks; import_batch is the SHA-256 of the bundle file itself.
• The producer is a collector. provenance: collector: this program read signed records afterwards; it did not run the code, so the effect grade is runtime_claimed, a recorded claim, and the reversibility class is two_way: every call stated here ran with no host-API grant, so whatever it did stayed inside the sandbox.
• Granted calls and simulator runs are refused, not stated. A call with a host-API grant could have written somewhere outside the sandbox, and its response says nothing about what it did, so its reversibility class is unknown and the class vocabulary has no word for that. A simulator (module) run's floating-point values cannot enter a -05 JSON digest. The program stops on either instead of guessing.
• No model identity. The five calls were written by hand for the session example, so there is no model to attest. An execution layer never learns which model wrote the code it runs; that identity has to come from the caller.
• code_execution is not a registered effect type. The seeded types are write_order, send_payment and inference_completion. The Python verifier reports the value as informational, which is what the specification says it must do.
• Nothing here was sent anywhere. No capsule was registered with a transparency service. The producer key was made for this run and discarded; its public half is producer.pub.
• Refusals are missing. The specification requires a capsule for every verdict, refusals included, and calls a success-only trail survivorship-biased. plimsoll answers a refused run with an error that carries no record today, so there is nothing to state a blocked or denied capsule from.

Check it yourself

git clone https://github.com/plimsollmark/plimsoll && cd plimsoll/examples/capsule
go run . -out /tmp/capsule-check            # Go 1.27; same capsule IDs, new signatures
                                            # another bundle needs -operator, -developer and -imported-at
pip install "agent-action-capsule[envelope]==0.6.0"
agent-action-capsule verify --store ../../docs/examples/capsule/capsules

Files beside this page: capsules/ ↗ (one JSON file per capsule, named by its ID: the store the Python verifier reads), envelopes.jsonl (each capsule's COSE_Sign1 signature, base64), and producer.pub. The import this page states used the bundle plimsoll-bundle:sha256:89af007222df5048b40625238c04230b92bbfc23476a66bb0e88af1e8fc73ed6.