]> iSoluce

France laurent@isoluce.net

Security SCITT SCITT provenance decision human approval software release action binding transparency service Build attestations, bills of materials and Signed Statements in a Transparency Service record what was built and by whom. Authorization receipts for agent actions can establish who approved an exact action; the statement profiles for agent actions record a human approval as the producer's claim. None of them carries the decision behind the action, the options considered, the reasons, the authority, and what the approver was shown, as a record a verifier can check. This document describes how a decision record and its action-binding attachment, as the extension proposals of the Decision Provenance Standard define them, sit under a release statement, a build attestation or an agent action record by typed digest references; how a verifier checks them offline, including the approver's signature where one is carried; and how the witness checkpoints of the anchoring extension are registered in a Transparency Service. Nothing in the SCITT architecture, in Signed Statements or in Receipts changes. A software release decision and an agent action capsule are the worked examples; the model has no feature specific to either. This document is independent of the Decision Provenance Standard, is not part of it, does not change it, and is not endorsed by its Steward.

Introduction The SCITT use cases and the formats a software supply chain already carries, build provenance , attestations and bills of materials , answer the question "what is this artifact, and how was it built". Registered as Signed Statements in a Transparency Service , with Receipts , they become evidence anyone can check later. None of them answers "who decided to ship it, on what, and under which authority": the release decision is a ticket, a chat message or a button, and the record of it, where one exists, is neither signed by the decider nor bound to the artifact that shipped. The statement profiles written for AI agent actions have the same gap, and are careful to say so. A capsule records an action's disposition ; an AgentInteractionRecord its inputs and outcomes ; a receipt its risk class and verdict, and may record a permission, a refusal or a deferral as well as an execution outcome . Each says that its human-approval field is the producer's claim: an enumeration value or an opaque label, not an authenticated act. Where a profile carries the reasoning behind the action at all, it stays private or is reduced to a hash: the capsule's reason digest, the AgentInteractionRecord's reasoning hash; the receipt commits to the action parameters and, optionally, to the policy, and carries no rationale. Authorization receipts such as do establish who approved an exact action, with a signature; they carry no record of the decision, its alternatives or its reasons. What this document adds is that record and its composition with those receipts and statements; the signed approval itself is not new. The Decision Provenance Standard records the decision: what was decided, under which charter, which options were considered and with what rationale, and the affirmative human act that closed the record. Its action binding extension , a proposal in the Standard's repository, records the stages from a proposed action specification to its execution: what the attachment states the reviewer was shown, what was approved, signed where a signature is carried, what was requested, re-checked and executed, bound to one another by equal digests. Its anchoring extension , also a proposal, gives those records evidence that their bytes existed by a given point, and witness checkpoints, including, since its SCITT source, a witness-signed checkpoint registered in a Transparency Service with its Receipt. A deploy pipeline and an AI agent are two executors of decisions; the Standard does not distinguish them. Decision provenance serves accountability and later review. A relying party may need to identify who approved an action, distinguish that approval from the authority to act, inspect the reasons and the alternatives that were recorded, and follow a later correction. Each verification result in this document says which of these questions it answers and which stay with evidence outside it. This document is an applicability statement: it defines no new format, and it does three things. It uses two artifact types, declared in the Standard's repository, so that a build attestation, a release statement or an agent action record may cite, by typed digest reference , the decision record and the action-binding attachment it executes. It describes how a verifier holding both checks the approval and the binding offline. And it describes the registration of the anchoring extension's checkpoints in a Transparency Service, by reference to the anchoring extension at a fixed commit. Two worked examples: a software release decision, and an agent action capsule citing a decision. Nothing in the architecture , in Signed Statements or in Receipts changes: the decision layer is cited by digest from a statement a service already registers, and its checkpoints are registered as any statement is.

Relation to the Decision Provenance Standard This document is an independent, downstream description. It is not part of the Decision Provenance Standard, does not change it, and is not endorsed by its Steward. The name is used only to identify the Standard and its extensions, which are the source: where this document and the repository differ, the repository governs, and any change a reader asks for in a format described here is made in the repository first, as a pull request. The extensions are proposals in the repository; they are not part of the Standard itself. Only the version cited here, at that commit, governs this revision; a later change in the repository does not change this document, and a revision of this document names the commit it is written against. "Decision Provenance Standard" is a trademark of Etsion Brands Ltd., used here to identify the Standard, with attribution: The Decision Provenance Standard, Yohay Etsion, 2026, CC-BY 4.0, https://decisionprovenancestandard.org.

Versions and commit This document is written against the extensions as they stand on the repository's main branch at commit 007f8c9 (28 October 2026): anchoring 0.2.0, signatures 0.2.0, portable verification 0.3.0 and action binding 0.3.0, each a proposal written against Core v1.3 rev. 11 and the reference files 5.2.0. The names of are those the extensions index declares at the same commit , with the digest contexts stated in the terms of the Canonical Payload Binding since that index's revision of 27 October. Since 28 October the anchoring extension reads a Receipt whose protected header carries alg -8 (EdDSA), with a finding that deprecates it in favour of -19; a statement stays pinned to -19. Each extension states its version in every document it defines; this document names them so that a reader can check the same tree.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Decision record, action-binding attachment, stage, checkpoint, witness, trust policy and verification report are used as the Standard and its extensions define them. Signed Statement, Transparency Service and Receipt are used as and define them. Build attestation, provenance predicate and bill of materials are used as , and define them.

What the decision layer adds A verifier holding an action record (a release statement, a build attestation, a capsule) and the decision record and attachment it cites can establish, offline:

• where the approver's signature is carried, that the approver signed the outcome stage with a key the verifier's own trust policy maps to a named person, in the role person of that policy; the authority reference that points into the deployer's charter stays the issuer's statement unless the verifier checks it against an independent source, such as the permission system;
• that the specification the attachment says was shown to the approver, the one approved, the one that was requested, re-checked and executed, are one and the same, by equal digests, or exactly where they differ; for a release, that specification names the artifact digest, the bill of materials digest, the migrations and the rollback;
• the options considered and the rationale as the record states them, with the time the rationale was recorded relative to the decision;
• and, through the anchoring extension, evidence about when those bytes existed, each source with what it does and does not show: an RFC 3161 token gives a time from an authority the verifier trusts; a SCITT Receipt states no time, only that the service registered the statement into its log; an OpenTimestamps proof shows only that the bytes existed before a block was mined.

It cannot establish that the decision was right, that the action was, or what the reviewer actually saw or read: the check shows what the attachment says was shown; the verification reports of the extensions say so in every result, and this document inherits those limits. What each signature covers, and what a verifier may conclude from it, is not the same for every member of the records:

• the approved specification (operation, target, parameters, policy version): the person's person_approval signs the specification's digest and the view's digest; the conclusion is that the holder of a key the verifier's own trust policy maps to this person approved these exact bytes, shown in this view;
• the decision record (options, rationale, charter, accountable owner): its seal is a digest; a person_affirmation over the record's covered digest, where one is carried, makes the rationale a statement signed with a key that policy maps to the person; without it the rationale is the issuer's record, and an approval signs the record's identifier and a stage, not the record's content;
• the stages and their times: the issuer's seal over the attachment, where one is carried; the issuer's statement either way;
• the authority reference: the issuer's statement, until checked against an independent source.

The worked examples say which of these each carries.

Where it attaches in the software supply chain Nothing here replaces a build attestation, a provenance predicate or a bill of materials; they say what was built, and they say it well. The decision layer sits beside them and is linked to them in both directions by digests:

• The action specification the approver sees, carried in full in the attachment, names the artifact by its digest, the bill of materials by its digest, and the build by its identifier. A verifier that holds the SLSA provenance or the SBOM recomputes those digests and reads whether the release that was approved is the artifact that was built.
• A release statement registered in a Transparency Service, or the build attestation itself where its format allows additional references, cites the decision record and the attachment by the typed digest references of . The Receipt over that statement then covers the references, that is the two digests, beside the artifact's; the decision documents themselves travel beside the statement or are obtained from the issuer.
• A Transparency Service that registers the anchoring extension's witness checkpoints () gives each checkpoint over one issuer's chain of release decisions a Receipt from the same service the artifacts use. A Receipt shows the statement's inclusion; the anchoring extension does not yet check that the log only grew, so this is not evidence of an append-only history of decisions.

The stages an action-binding attachment records map onto a release pipeline without change: the proposal is the release candidate as the assistant or the pipeline drafted it; the review is the release manager's reading of it; the outcome is the approval under the release charter, signed by the release manager where a signature is carried; the request is the deploy job; the re-check is the permission or policy gate just before deployment; the attempt and the result are the deployment and what the target reported. A change of the artifact digest between the approval and the attempt fails the binding, by construction.

Artifact types for typed digest references The Canonical Payload Binding defines a typed digest reference, {type, purpose, digest_alg, digest}, and leaves artifact types to the consuming profile: an artifact type is identified by a stable specification, whose declaration binds the exact type token to a digest context (its pre-image, its canonicalization named by its CPB identifier, the hash function, the digest_alg token and the output representation), and the consuming profile names the declarations it accepts (CPB -05 section 8.1, -06 section 9). An entry's identity is the {type, digest_alg, digest} triple. This document uses two, both declared in the Standard's repository under its own namespace, org.decisionprovenancestandard . The repository declares each name, what it identifies and which digest context it uses in those terms: the decision record is cited by its seal, taken over the covered bytes that portable verification defines; the attachment by the SHA-256 of its bytes, as the action binding extension defines them. This document does not restate the rules and only says how the references are carried. A name never changes meaning; a different digest rule would get a new name.

decision_record

• type: org.decisionprovenancestandard.decision_record
• digest: as declares it for this name, by reference to portable verification ; the same value as the entry's seal_hash.

action_binding_attachment

• type: org.decisionprovenancestandard.action_binding_attachment
• digest: as declares it for this name: the plain SHA-256 of the attachment's bytes, computed as the action binding report computes its attachment_digest; not the sealed digest of the signatures extension .

What a verified reference shows A reference that verifies shows only that the cited bytes have the digest it carries. It does not show that they are a decision record or an attachment, which one they are, or anything they state: that is for the document's own check, which reports it.

Carrying the references In a capsule, the references are carried in references[] as the capsule profile allows, in the style of ; in an AgentInteractionRecord, in external_refs; for a receipt whose object is closed (Section 3 of ), this document describes a separate Signed Statement carrying typed references to the receipt and to the decision record, subject to the Transparency Service's registration policy, while leaving the receipt and the bytes of any existing envelope carrying it unchanged; Section 8.4 of discusses separate signed artifacts for the claims listed in its Section 8.1, but does not define this composition; the reference's type is the identifier the receipts carry in their spec member, "noa.receipt/0.1", and its digest is the profile's own value, "sha256:" followed by the lowercase hexadecimal SHA-256 of the receipt's canonical form with only chain.hash and sig.value omitted, which for a valid receipt equals its chain.hash, kept in that prefixed representation by the declaration; the reference binds that canonical receipt content, does not itself authenticate the receipt's signature, which is the profile's own check, and binds neither the serialized file, nor a COSE statement carrying the receipt, nor its Transparency Receipt; in a release statement, in the cpb-refs protected header of CPB -06 section 9.3, marked critical where the consuming profile requires the references to be understood, or in the statement's own payload. A capsule's Producer Envelope, a COSE_Sign1 over the raw capsule identifier with exactly alg, content type and kid in its protected header, is unchanged by the references, which live in the capsule's payload. Nothing in the citing profile's protected header or verification changes. The cited artifacts travel beside the citing record, in a portable verification export and a signatures attachment, or are obtained from the issuer.

Verification A verifier that holds the citing record, the decision record, the attachment and its own trust policy:

1. resolves each typed digest reference as CPB describes, and stops at Failed for a digest that does not match;
2. runs the action binding reference check on the attachment with the record, which reports the stages' consistency, the issuer signature where there is one, the time, and the pairing of the report with its documents;
3. runs the signatures check on the approver's signature over the outcome stage, where one is carried beside;
4. compares what the citing record commits to about the action, its operation or tool, its target, the digest of its arguments or of its recorded input, and the execution occurrence, with the approved specification the attachment carries, member by member as each composition defines, and reports each agreement on its own: a reference that resolves to a valid record and attachment approving a different action fails here and nowhere earlier, since resolving a reference is not accepting its content ( says so of its references); carries that case for each composition;
5. where it holds the artifact, the build attestation or the bill of materials, recomputes the digests the approved specification names and reports each agreement on its own;
6. reads the result dimension by dimension; it MUST NOT merge them into one pass or fail, and it MUST NOT report more than those checks find. A relying party may still decide, under its own policy, whether the results it reads are enough for its purpose; the report itself keeps them apart.

The reference checks, their cases and their vectors are in the repository under extensions/*/tests; this document does not restate them.

Checkpoints in a Transparency Service A witness's checkpoint over a chain of decision records is a signed statement whose payload is the checkpoint's signed bytes under the anchoring extension's shared rule, with its Receipt, as the anchoring extension defines under "A transparency service as a checkpoint source" at commit 007f8c9. This document adds no rule; it names what a Transparency Service operator and a verifier need:

• the statement's protected header : alg -19, kid the witness key's reference, CWT claims iss the key's holder and sub the chain;
• the leaf: the statement's bytes as registered, under the leaf hash; a Transparent Statement is carried with its receipts taken out. A service that defines its entry otherwise, for example as the digest of the statement's Sig_structure, issues Receipts the extension does not verify, and says so ();
• what a Receipt shows: that the service signed the statement into its log at a tree size; not the log's consistency, which the extension reports as not checked in this version; and the extension reads no registration time from it;
• the registration policy is the operator's . A verifier never relies on it: it accepts only statements from the witness keys and chains its own trust policy lists for that service. A service may mirror that list in its policy.

Worked examples

A software release decision The appendix carries a decision record for shipping release 2.3.1 of a claims-intake service, and the action-binding attachment of its deploy pipeline: the release assistant's proposal, the release manager's review and approval under the release charter, the orchestrator's request, the permission re-check, the deployer's attempt and the observed result. The approved specification names the build, the artifact digest, the bill of materials digest, the migration and the rollback. The record states three options and why the first was chosen. The action binding reference check verifies the stage dimensions; the example carries no signature, so the issuer signature and the time are not checked.

An agent action capsule citing a decision The same record and attachment, cited from an Agent Action Capsule by two typed digest references in references[]. The capsule reference library parses the capsule strictly and verifies it; a verifier of the Standard resolves both references to the documents it holds. Nothing in the capsule's protected header or verification changed.

A signed approval composed with an execution receipt The release example carries no signature, on purpose: it is the lower level of evidence. (interop/aer1-decision) carries the full path for a refund of 120.00 EUR: the support lead's person_approval over the specification's digest, verified against the verifier's trust policy; the attachment sealed by the merchant; the agent runtime's call to the payment gateway, which issues a receipt of (schema 0.4) whose recorded input carries the attachment's request identifier and exactly the approved parameters, under the receipt's own digest; the attempt citing the receipt's identifier and its output digest; and the report, dimension by dimension. Decision record DR-2026-1104 (seal 3615cd70...), specification e5052c21..., receipt d9f0200e-793e-4fec-a4ae-0687e0d92cac with output_hash sha256:3ca5904b...; ten failing cases, among them the gateway recording 150.00 EUR against 120.00 EUR approved, where the receipt verifies, the approval verifies, and the join of step 4 fails.

Related work The SCITT working group holds, in October 2026, some fifty individual drafts that record something about an agent's action, its authorization or the decision behind it. Most record the action, its authorization by a policy, or a named person's authorization of one action; this document records the decision of a person, with what was considered and why, and binds it to the action. Where each stands relative to it, as its author reads them:

• The composition model joins four records of one action by a shared subject digest: who authorized it (WHO), was it permitted (CAN), what the agent did (WHAT), did the runtime enforce it (AUDIT). Its WHO slot is a named person's signature covering the digest of the exact action bytes, with validity, one-time or reusable semantics, fail-closed behaviour and a verifier that keeps signature, digest, freshness and verified-versus-accepted apart; any record form meeting those requirements conforms. The action-binding attachment of the Standard is a candidate for that slot. The decision record is not: it sits in the layer the composition model places above itself, whether this authorization was the right one, with the options considered and the reasons, and it is cited from the composition by digest.
• The EMILIA authorization receipts , the first-instance WHO profile of the composition model, record a named principal's device-bound signature over the canonical bytes of one action, with a nonce, a validity window, one-time consumption and quorum rules, verifiable offline; companion documents bind what the approver was shown and the observed effect , and declare bounded execution programs . They answer who authorized this exact action, and answer it thoroughly; they carry no record of the decision, its alternatives or its rationale, and the stages of the action binding extension (shown, approved, requested, re-checked, executed) are one record where EMILIA composes several. A decision record can cite an EMILIA receipt as its approval evidence, and an EMILIA receipt can cite the decision it executes.
• The checkpointed local log gives a producer's records order, completeness and contemporaneity through signed checkpoints registered with a Transparency Service, and says what that does not prove; the anchoring extension does the same for chains of decision records, with a verifier-held list of witnesses. The two are orthogonal to the decision layer and to each other, and a checkpoint of either can be registered where the other is.
• The Pre-Execution Authorization Record, or Permit , records a policy engine's allow, deny or challenge before dispatch, bound to the canonical bytes of the authorized request, with a Closure Record after dispatch and an authority lineage between Permits. The subject is a workload identity; the reason is a code. A Permit may reference a human-authority artifact by URI and digest; the decision record and attachment of this document can be cited the same way, so that the Permit records what the policy allowed and the attachment records what the person approved.
• The Seal receipts and action records record an enforcement point's ALLOWED or BLOCKED decision on a proposed tool call, bound to the digest of its arguments, with refusals as first-class records. Its section 8 states the properties an approval needs for an action record to be read as evidence that a person approved a specific action, binding to exact values, single use, expiry, policy version, independence, a designated approver, a view rendered from the canonical action, and leaves the approval record to a later revision. The signed outcome stage of the action binding extension, with the signatures extension's person approval over it, meets those properties except the digest of the designating policy and a short validity, which can sit under the person's signature through the specification the approval signs, as the Standard's Steward read it; whether that meets section 8 is its author's reading (); carries a worked example of its section 8.3 in that form, verified by both sides, with the failing cases.
• The Operating Model Protocol records, at the moment of a routing state, whether the named accountable officer can be bound to a valid delegation instrument: the SHA-256 of the instrument's canonical form (instrument_hash, section 4.4.4 of that document), a root of authority that the law or a professional register establishes, how the instrument was selected relative to the decision (instrument_selection_mode, section 4.4.1) and the hash of an authority registry's state at decision time; a binding that cannot be made is sealed as AUTHORITY_UNBOUND, a result in its own right, with the reasons it failed; its domain profiles include financial regulation and insurance. It records the authority of the person, not their approval of exact bytes; this document records the second. Its authors read the -00 of this document and the question of a reference from the attachment's authority member to an instrument by that hash, and answered that the hash gives non-modification of the document named and nothing about timing; that a reference added once a decision record exists is, in their vocabulary, post_hoc_attached, which their document says MUST raise a review flag and SHOULD NOT be treated as fully bound; that a bound record needs the registry snapshot, which a deployer's charter cannot give; and that, by section 8.1 of their document, the instrument stays the deploying organisation's to produce. What that leaves of the open question is argued in .
• Signed permissions and action receipts let a principal sign a permission with machine-checkable limits and an agent sign a receipt for each action, verifiable offline; the standing approval of the action binding extension, a person's approval of bounds with a count and a period, is the nearest construction here.
• The briefing-and-binding envelope is the delivery contract by which an agent surfaces a decision to its principal, who commits, declines, amends or rejects; it names by digest what the principal was shown and defines no signature over the resolution. The review stage of the action binding extension names the same thing, and the signatures extension gives it the signature.
• Execution and audit records , , and the AgentInteractionRecord record what ran, what it touched and what came out, with recomputable digests and offline verifiers; the decision record sits above them and is cited from them. The approval-binding contract published beside the audit record's corpus binds one approval to one use by identifier, key, principal, event, phase, bytes, validity and the policy served; the action binding extension binds an approval to the bytes of a specification and the digest of a policy, and the two readings differ on who may use an approval and on when a policy was served (the table is in the repository).
• The AUDIT architecture defines Action Records at the boundary where an action took effect and Authorization Transition Records for changes of permission, including step-up approvals, without a signed record of the approval itself; the AIMS best practices require that a local confirmation in a user interface not count as authorization on its own and that audit records be tamper-evident, and define no signed decision record. The outcome stage with the person's signature is the record both leave to be defined.
• On the regulatory side, gives transparency receipts for Article 50 of the EU AI Act, including the exemption for content a person reviewed; a decision record can be the evidence of that review. applies SCITT to the audit trail of algorithmic trading decisions under MiFID II.
• For time, specifies the verification of an OpenTimestamps proof against a chain the verifier holds; the anchoring extension uses the same proofs for the same purpose, with the same statement of what they show.
• The PALA-1 audit log is a header-chained wire format whose chain verifies without keys and without bodies, with a SCITT bridge: the chain head expressed as a Signed Statement whose payload commits to the head and, in its third construction, to a derived root over every record so far, so that two statements of one chain connect by a prefix-consistency proof without the chain. It records what a device produced; the decision record is cited from such evidence, not carried in it, and the author's verification record is built on readings from the text alone, which this document's repository joined.
• The P10 underdetermination profile binds, in a Transparent Statement, an adjudication that the evidence closed at a point did not decide a claim: two witness worlds of a model class committed before the first admission, compatible with the same closed evidence set and giving the claim different values, with the verifier and its limitations committed as well. It establishes underdetermination relative to the declared profile and does not identify the actual world. Its revision -02 reads this document as decision provenance rather than evidential underdetermination, which is right: a decision record states what a person considered and decided, a P10 statement that a claim was left undecided by the evidence at a point, and a decision taken under such a claim can name the adjudication statement among its inputs. The repository's case interop/plan-checkpoint shows the shape: a plan approved as a whole, a check in the middle of it that leaves a claim undecided, a second decision record naming the exact state of the run and an adjudication in the form of that profile's section 9 (built there, synthetic, and said to be), and the steps after the checkpoint citing that decision.
• Outside these drafts, W3C PROV describes where something came from: entities, activities and agents, and relations such as used, wasGeneratedBy, wasAssociatedWith and actedOnBehalfOf. It has no canonical bytes to digest, no signature semantics, no verifier and no content for a decision, its options, rationale and authority: anyone can state that a person approved something, and nothing binds the statement. The two do not compete. Once verified, a decision record, its action-binding attachment and a person's approval can be read as PROV, which does with a JSON-LD context, an exporter and queries, under a vocabulary of its own and without changing a member of the records.

Open questions This revision is a base for discussion. The questions its author would like the working group's reading on:

• Whether a decision record should itself be registered as a Signed Statement, with the decision identifier as its subject, rather than only cited by digest from the statements that execute it. The anchoring extension registers checkpoints over chains of records, not the records; registering a record would be a new rule, made in the repository.
• Whether the capsule profile will name, among the artifact-type declarations it accepts, the two names of , so that its library resolves the references itself; today they resolve on the verifier's side of the Standard. The question was put to the capsule profile's author on 29 October 2026.
• The mandate at the instant of the decision. The attachment's authority reference points into the deployer's charter, which is the issuer's statement. The authors of the Operating Model Protocol, asked whether a reference from that member to one of their delegation instruments by its hash would change this, answered that it would not on its own () and asked this document to argue whether their Invariant 3 closes the gap or formalises its shape. The argument of this revision is that it does half of each. On timing: the authority member sits in the outcome stage; where the issuer seals the attachment the seal covers it, and where the anchoring extension is used an independent timestamp over the issuer's or the approver's signature bounds when those bytes existed; an instrument hash carried there was selected no later than that bound, and one added once the record exists gives other bytes, another seal and, where those are anchored, a later bound. What the record cannot show is that the instrument existed before the decision rather than being written with it: the registry snapshot shows that, a charter has none, and the same anchoring applied to the instrument itself before the decision would show it too, which nothing in this document does today. On the party: the instrument is issued by the organisation whose authority is in question, so the claim becomes testable and its absence a sealed result, AUTHORITY_UNBOUND, which this layer would carry rather than silence; it is not independently grounded, and this document grounds no other fact the issuer states either. The ground, where there is one, is a root outside the deployer; for an insurance intermediary in France the public register grounds the firm's standing to distribute, not the officer's mandate inside the firm, and which root a profile names is the remaining question. A worked case against the instrument and vectors those authors are publishing, with four failing forms (an instrument revoked, outside its mandate scope, with a mismatched hash, attached after the fact), is planned for the -02.
• The digest of the policy that designates the approver, and a short validity on a single approval, which the Seal draft asks to find in an approval record. The Standard's Steward answered (issue 93 of the repository) that both can already sit under the person's signature through the specification the approval signs: the policy version written as the SHA-256 of the policy's bytes, and, where a deployer needs a deadline for each approval, a member of the specification it declares material; the executor's recheck before each attempt is where an approval that is too old can be refused, on the enforcement point's clock. Nothing in the extensions changes. carries the Seal section 8.3 example in that form, with the cases proposed on that issue: a policy digest that does not match the policy held, a policy not held, an attempt after the policy's limit, and relabelling. Whether that form meets section 8 of the Seal draft is its author's reading. A standing approval keeps its period in its bounds; the difference is intended.
• Which definitions of the log entry the anchoring extension should accept when it reads a Receipt. Today it verifies only an entry that is the leaf hash over the registered statement's bytes; a Transparency Service whose verifiable data structure defines its entry otherwise issues Receipts the extension reports as not verified. Whether the extension should follow the Receipt's declared structure instead, and how a verifier learns it, is the question (it was raised on issue 89 of the repository and is to be opened on its own).
• Which media type or CoAP Content-Format, if any, a checkpoint payload should carry when registered, and whether the vendor tree is the right place ().
• Whether a Transparency Service should recognise witness checkpoints in its registration policy by their witness keys, as a verifier does in its trust policy, or treat them as any statement from any issuer.

Implementation Status Note to the RFC Editor: this section is to be removed before publication as an RFC. It records implementations known to the author at the time of writing, following ; listing one implies no endorsement, and the author has verified only the ones he ran. Chronology, for the record: the action binding and portable verification proposals were documented in the Standard's repository on 29 September 2026 (issue 21, by its Steward, naming their author); their first versions, with schemas and reference checks, were merged on 5 and 3 October; anchoring and signatures followed on 15 and 16 October. This document composes those existing mechanisms with SCITT. The dates give the chronology of these contributions, not a claim over neighbouring work, which has its own history and scope. The items below establish different things: syntax and digest agreement, verification by another author's library, the consistency of a composition across formats, the behaviour of a Transparency Service, and operation in a deployment; a verifier written by the author from another draft's text checks that draft independently of its reference code and is not a second independent implementation of this document's composition.

• The reference checks of the Decision Provenance Standard's extensions (repository above, Apache-2.0 for schemas and tests): action binding 0.3.0, signatures 0.2.0, anchoring 0.2.0 and portable verification 0.3.0, each with a runner, cases by mutation (over four hundred for anchoring, over four hundred for signatures, over three hundred for action binding) and published vectors, reviewed by the Standard's Steward before each merge. They produce the reports this document's verification section reads. Maturity: proposal; test fixtures and the author's own deployments.
• , the author's working repository, Apache-2.0, with a continuous integration that replays everything below from a clean machine on every change: the two worked examples of this document; seven interoperability cases with the Agent Action Capsule reference library 0.12.0 (typed references that resolve, an altered digest, an unsigned attachment, an attachment that resolves and then fails its own check, a re-encoded record; the capsule registered at the library's Transparency Service with its COSE Receipt; a Producer Envelope the library verifies and a CPB-bound Signed Statement carrying the references in the cpb-refs protected header, with its negative forms); the Seal section 8.3 example with its failing cases; one agent pass carried three ways, the action binding extension's standing approvals of exact lists and exact approvals of each comment with their signatures, the Seal action records of what the enforcement point allowed and blocked, and a capsule for each action, with the joins across the three and ten failing cases, one of which only the policy signed through the specification catches; a decision record and a receipt of joined both ways at that draft's author's request, the attempt citing the receipt's identifier and output hash and the receipt's recorded input carrying the request identifier and the approved values, with the receipt's execution context naming the record reported as the producer's assertion, and ten failing cases; a receipt of , taken from its published conformance vectors, cited with the decision record and the attachment by a separate Signed Statement, its own signature verified as a separate result, with the negative forms its author described; a plan approved as a whole and executed as steps, one exact approval of a plan of three steps whose specification carries the hash of its executable steps, three capsules chained in run order, and a run manifest between them that lists, for each step, the capsule that executed it, the outputs it recorded and the state of the run's context before and after it, each capsule citing the state it read, with ten joins (membership, completeness, order, arguments resolved from an earlier step's committed outputs, the growth of the context) and fourteen failing cases; the same plan stopped after its first step on a claim the evidence left undecided, with a second decision record whose specification names the exact state of the run and an adjudication in the form of section 9 (synthetic, and said to be), five joins more and eight failing cases; and verifiers written from the text of four neighbouring drafts and run on their published vectors, the Seal receipts (67 of 67), the OpenTimestamps verification of (its four vectors, against a header set the verifier checks for proof of work and linkage from a checkpoint it holds), AER-1 (119 of 119 across its kit's seven suites) and the agent audit record (184 of 184 members of its corpus at release 0.31.0, read against its -03, every anchor of its retained records validated offline against the tree heads and block headers the corpus pins and the dating reported in full; 141 of 141 at release 0.28.0, the run posted on the corpus's issue tracker at its author's request; and the OpenTimestamps proof of a live run recorded in that corpus replayed to a Bitcoin block against headers from two explorers), each with the places where the author's text and kit were found to differ, reported to them; for the audit record, both earlier observations are taken into its -03, and three more were reported after the -03 rerun; and, from the same package, its approval-binding contract, whose eleven checks ask of one approval and one use what the action binding asks of a specification and its stages: a verifier written from the contract's text agrees with its 23 cases on decision and reason, and a table in the repository maps the eleven checks onto the extension's rules and cases, five met, three with a note, one partial (the validity window of a single approval), two with no analogue in the Standard (the principal who may use an approval; the window in which a policy was served), as the input to the shared profile that corpus's author proposed; and the SCITT-bridge Signed Statement of in its third construction, read and reproduced byte for byte from its task's text and the standards it names, at the author's invitation and within the boundary he set: both statements, the derived roots, the prefix-consistency proof from the statements' roots alone, the seven tamper expectations and the version rule, with the ambiguities logged.
• , the author's reading of the records as W3C PROV, version 0.1.0 (code Apache-2.0, context and vocabulary CC-BY 4.0), written against record schema 5.2.0, action binding 0.3.0 and signatures 0.2.0: a JSON-LD 1.1 context, an exporter and three SPARQL queries. On a worked example whose person approval the Standard's reference check verified, the queries find the stage chain from proposal to result, and for every attempt a verified approval of the attempted digest attributed to a person; a negative control with the attribution dropped finds no one. The graph proves nothing by itself: it repeats what the reference checks reported.
• The author's deployment, a runtime for insurance brokers: an action with external effect runs only after an approval that names the person and carries the digest of the exact payload shown, checked again before the effect, with a receipt kept for every effect; that approval is recorded today, not signed. A program that repeats is certified once, with bounds, a period, a count of executions and a revocation, as its code defines. An exporter writes approval and effect records in the form the action binding extension describes; one such export is the first interop case above. Its history, in the author's SmartOffice runtime (a private repository): schemas and examples committed in December 2025 describe a hierarchical execution envelope, the enclosing context and its operation records; workflows of January 2026 preserve that context across model calls, carry the authorization at the parent, distinguishing an approval of one instance (human_approved) from a preauthorised, registry-compiled process (preapproved, naming the use case and its version), refuse any other mode in the executor, and collect a result per step; the grammar of June 2026 requires an authority of one of those two modes for a runtime transition; from May 2026 the proposal shown to the person carries a hash of the plan's executable steps, the reply carries it back, and the resumed run refuses a plan whose hash changed before it is marked approved; guided actions of June 2026 allow that transition only with an approval identifier and that hash; prepared and revisable programs of October 2026 are approved on their exact content and executed through a preview token carrying the payload's digest, checked again before the effect. These are the background of the extension's approval and standing approval and of the compositions above; they implement neither the capsule profile nor the extensions' signatures, anchoring or portable verification, and none of it is public: the private documents are the author's declared implementation context.

Security Considerations Where the approver's signature is carried, the decision layer authenticates the approver's act and binds it to the executed specification; an authority reference stays the issuer's statement unless checked against an independent source; it does not establish the truth of the decision's inputs, nor that the artifact a specification names is safe: that stays with the build attestations and the reviews they record. A relying party that needs a signed approval requires one in its own configuration and does not accept an unsigned attachment: anyone holding a signed attachment can remove its signature and present it as unsigned, and only a seal beside it shows that. Keys and sources of trust come from the verifier's own trust policy, never from the artifacts. Every stage time in an attachment is the issuer's: a consistent set of them shows what the issuer recorded, not that the approval preceded the effect, since the issuer can date every stage as it likes. What bounds the order from outside is an independent timestamp over the approval signature's value, which the anchoring extension carries, and what the execution side observed itself, such as a request identifier under a receipt's own commitment (Section 11). A Receipt states no time; an OpenTimestamps proof shows only that bytes existed before a block was mined; only an RFC 3161 token from an authority the verifier trusts gives a time bound. A decision record and its attachment carry personal data, the names of the accountable owner, the approver and the attestor, and the rationale of a decision; only their digests are registered in a Transparency Service, and the documents themselves travel under the issuer's control, to the parties that hold the citing statement; this document defines no selective disclosure of their members. A member by which an execution receipt names a decision record, when it sits outside what the receipt's own digest or signature covers, is the producer's assertion and shows nothing by itself; a verifier reports it as such. The binding runs the other way: the decision layer's attempt and result cite values the receipt commits to, its identifier and its output digest, and where the executor sends the request identifier as the target's idempotency key, that key is under the receipt's own commitment as part of the recorded input. The same holds for a human-approval flag in a receipt: it is the producer's claim, and only an approval of that exact specification, signed, under the decision layer, makes it more. The anchoring extension's security considerations apply.

IANA Considerations This document registers no media type in this revision. A later revision may register, in the vendor tree, a media type for the checkpoint payload, with the Steward of the Decision Provenance Standard as change controller; the content type stays optional in the anchoring extension.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Action State Group, Inc. Tyche Institute Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. Informative References Fraunhofer Institute for Secure Information Technology ARM REA MITRE Microsoft This document includes a collection of representative Software Supply Chain Use Cases. These use cases aim to identify software supply chain problems that the industry faces today and act as a guideline for developing a comprehensive security architecture and solutions for these scenarios. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Glyphzero, Inc. The Agent Action Capsule (AAC) profile (draft-mih-scitt-agent-action- capsule) records what an autonomous agent actually did -- executed, blocked, denied, errored, or timed out -- with a structural binding that prevents an attempt from being presented as a completion. AAC deliberately does not define the authority that permitted an action; it carries that authority as an opaque reference. Two companion profiles supply what that reference can point to: a per-action authorization profile (draft-rampalli-aiagent-authz-hmac) records that an action was permitted (the "may"), and a memory-provenance profile (draft-rampalli-aiagent-memory-provenance) records the source and trust state of the belief on which the agent acted (the "why- believed"). This document specifies how the latter two are bound into an AAC Capsule. It defines (a) what the AAC "disposition.authority" reference MAY resolve to, (b) a namespaced, payload-only extension carrying an authorization-token reference, a memory chain root, and a quarantine attestation, and (c) an OPTIONAL divergence-class value, drawn from the per-action profile, that explains a non-executing AAC verdict. The binding uses only mechanisms AAC already provides -- the opaque authority reference and the payload-extension namespacing convention -- and changes neither AAC's closed protected-header claim set nor its Class 1 verification. The result is a single verifiable record that answers "may," "did," and "why-believed" together. Veridic Inc. Veridic Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS, and MiFID II. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. Aqta Technologies Limited This document specifies two compact JSON records, signed with Ed25519 and verifiable offline under a pinned public key. The first is an attestation receipt for an AI inference decision, binding an outcome to a request hash. The second, added in this revision, is an action record: the decision an enforcement point takes before an agent's proposed tool call or other state-changing action runs, whether that decision is to allow or to refuse. An action record is signed by the enforcement point, never by the agent, and binds the decision to a hash of the exact canonical arguments proposed. The document also describes how a human approval can be bound to exact action values with single use and expiry, how either record could be carried as a COSE_Sign1 Signed Statement and registered with a SCITT Transparency Service, and where the current format does not yet do so. Both formats are intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the decision. Veridom Ltd Veridom Ltd This document obsoletes draft-veridom-omp-00. The Operating Model Protocol (OMP) defines a deterministic routing and tamper-evident evidence architecture for consequential AI decisions. This document specifies OMP Core, which adds Invariant 3: Verifiable Delegation Binding. Every ASSISTED or ESCALATED routing state must bind the Named Accountable Officer to a verifiable DelegationInstrument at the time of decision. When valid binding cannot be established, the system records AUTHORITY_UNBOUND -- a sealed, positive evidentiary state. This update is additive and backward-compatible with OMP Core version 00. This document specifies records with which a third party can establish, later and without network access, what an automated agent, such as an artificial intelligence (AI) agent, was permitted to do and what it recorded doing. The person for whom the agent acts, the principal, signs a permission with a passkey; the permission carries limits that a verifier can check mechanically. The agent signs a receipt for each action with Ed25519 and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87). Receipts are chained and entered in a log whose signed tree heads are time-stamped. A verifier reports, separately, whether the records are sound and whether each recorded action stayed within its permission. The content of each record is specified independently of its encoding; one encoding, JSON Web Signature (JWS) over canonical JavaScript Object Notation (JSON), is defined. Alter Meridian Pty Ltd Independent This memo specifies the briefing-and-binding envelope: a delivery contract for the wire-level structure by which an artificial- intelligence agent surfaces a consequential decision to the human principal it acts for, and by which the principal commits, declines, amends, or rejects that decision. The envelope carries eight named slots (a synopsis, findings, recommendations, an offer of detail, a question stem, a set of options each marked with its own reasoning, a single recommended option, and a pair of escape hatches) and is emitted as a structured field of a Model Context Protocol tool result. The envelope is renderer-agnostic, so the briefing an agent delivers and the binding a principal commits back have one machine- checkable shape across every consuming surface. The memo also specifies a dual-veto handshake: one escape hatch lets the principal revise the answer space while accepting the question; the other lets the principal reject the question itself and reopen deliberation. Either party may veto. The memo defines a content digest over the envelope, canonicalized under JCS and hashed with SHA-256, so that a resolution names the exact envelope it resolves and an external receipt can reference that envelope by digest. The memo is Informational. No new transport is introduced; the envelope composes with the handle namespace of draft-morrison-identity-pronouns and the MCP tool surface of draft-morrison-org-alter-policy-provision. This document defines a record format for AI agent authorization decisions and the effects that followed them. The format is one in- toto predicate type, signed inside a DSSE envelope. A record carries the decision and the observed effect with a derived agreement between them, whether the decision point could evaluate the request and how fresh each input it relied on was, and a canonicalization contract under which a party that trusts neither the agent nor its operator recomputes the record's consistency from its bytes. The document also defines what a party that retains a record keeps beside it, so that the record can later be dated from anchors that party does not control. The format carries the seven minimum audit fields of the WIMSE AI Identity Management System framework, and it is offered as a data model for the audit records the proposed AUDIT working group would specify. It defines no policy. Vaara This document specifies vaara.receipt/v1, a signed and independently recomputable record that binds a decision about an autonomous action to the evidence the decision was made on, and optionally to one or more external timestamp anchors. The format is canonicalized with the JSON Canonicalization Scheme (JCS) so that a third party can recompute its digests, and, for a receipt signed with a public-key algorithm, verify its signature, without access to the issuer. A decision and the execution receipt that answers it form one recomputable pair through the envelope's back link. The receipt's trust is root-agnostic: the same record is verifiable with or without a hardware trusted execution environment and is re- expressible as an IETF RATS Entity Attestation Result. Downstream specifications (a payment rail, a compliance regime, a framework integration) define profiles that pin to a version of this document and add only their own evidence schema; they do not redefine the envelope. The format described here is deployed, and its receipts are independently recomputable from public conformance vectors that ship with standalone checkers importing no issuer code. The minimal profile is the engine decision: one receipt per decision an engine records on its own audit trail, bound to the trail record it decided, with no external rail. Zambo This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trust and equivocation limits in Section 13, and rewrites Section 15 to position the specification against adjacent work. It changes no receipt field, digest construction, or verification outcome for any receipt well-formed under the -17 rules. The -19 revision aligns the workflow tool and workflow view descriptions in Sections 8.5 and 8.7 with the normative Merkle construction in Section 8.1: both descriptions named step output hashes as the root's leaf input where Section 8.1 specifies step receipt identifiers. An implementer report identified the divergence. It changes no construction, receipt field, digest, or verification outcome. The -20 revision adopts three findings reported by an independent implementer who built a conformance verifier from the -19 text alone. It requires the published byte layout of a recorded input to state the member ordering rule it applies when the input is a JSON object (Section 3.3), and it bars control characters from provenance class labels, with rejection required (Section 5). The conformance kit's quickstart core tier also gains the provenance-label and schema-version metadata checks as a stated rule. It changes no receipt field or digest construction; a receipt well-formed under the -19 rules verifies identically, except that an input commitment whose published layout states no ordering rule is no longer reported as confirmed. The -21 revision states the receipt-id binding rule normatively (Section 6), describes the id- substitution case in Security Considerations (Section 13), and credits the independent control test that produced the finding (Section 18). It changes no receipt field, digest construction, or existing verification rule. The -22 revision pins the legacy (schema 0.3) member forms that satisfy the core requirements and requires verifiers to report a legacy acceptance explicitly rather than as a plain pass (Section 6), requires the canonical base64 spelling of canonical_bytes and the rejection of non-canonical spellings (Sections 3 and 4), states that the receipt object is the document and that no presentation envelope is part of the format (Section 3), enumerates the id verdict a verifier reports beside the structural verdict, binds the states to verifier behavior, and states the resolution order between the two layers (Section 6), requires the reason to be printed next to the rule for every check that does not pass (Section 6), and records an independent production validator in the Implementation Status. It changes no receipt field or digest construction; one verification outcome changes, for a receipt whose canonical_bytes spelling is not canonical, which earlier revisions did not address. The -23 revision states the per-anchor outcome report normatively (Section 6): a verifier's report carries each anchor's outcome in machine-visible form, and an anchor the verifier did not evaluate is reported as "not checked", never as an evaluated outcome, so that state cannot be conflated with an anchor that was evaluated and could not be resolved. It changes no receipt field, digest construction, or existing verification rule. Implementation Status This section records the implementation status of the AER-1 vocabulary at the time of this revision, following [RFC7942]. It will be removed before publication as an RFC. Reference implementation. Zambo (https://zambo.dev), operated by the document author, is a deployed implementation of Sections 3 through 10. Tool calls made over HTTPS as JSON-RPC to https://zambo.dev/api/ mcp receive a public receipt page at https://zambo.dev/run/<id>, retrievable without an account, wallet, or token. A machine-readable verifier is exposed as described in Section 6. Receipts are anchored to public Nostr relays with an envelope binding the receipt identifier, the output hash, and the evidence hash (envelope "zambo- receipt-anchor/1"). Workflow receipts (Section 8) are deployed in the reference implementation. Multi-step sessions receive a workflow receipt at https://zambo.dev/workflow/<workflow_id> binding the ordered step receipts with a Merkle root, and step receipt pages link to the parent workflow ("Part of workflow") while workflow pages link to each step receipt. Since 2026-10-22, the reference implementation closes workflows under the seq-output-v1 construction and declares merkle_version on every new workflow receipt; workflow receipts issued before that date carry no merkle_version member and remain verifiable under receipt-id-v0 exactly as issued. This revision defines both constructions and the selector. The conformance corpus described below now carries seq- output-v1 vectors as well, including multi-step closes, the odd-level duplication case, a single-step close, and mixed-version cases in which a single verifier checks closes under both constructions, each keyed on the close's declared merkle_version. Conformance kit. An open conformance suite for this vocabulary is maintained at https://gitlab.com/rambozambodotdev/zambo. It ships seven bundled kit runners (Rust, Go, TypeScript, Python, Java, C#, and Swift), each verified against the full vector corpus, which at this revision stands at 124 vectors (127 checks per runner) across the receipt-level, Merkle (Section 8.1), timeline (Section 7), hardened chain (Section 7.1), chain commitment (Section 7.3), Unicode, id-binding, and anchor-report suites. The kit repository publishes the corpus's current vector count, check count, and evaluated-set corpus digest alongside the corpus itself; that published record states the corpus's current counts, and if the corpus grows beyond the counts stated here, the published record governs. The -22 revision adds vectors pinning the canonical base64 spelling (Section 4), the nil-UUID rejection as a standalone case, the legacy schema 0.3 production shape (Section 6), the bare presentation form (Section 3), a current-schema (0.4) real receipt beside the two bundled 0.3 fixtures, and one vector per id_verdict state (Section 6). The -23 revision adds the anchor-report vectors pinning the per-anchor outcome report of Section 6, implemented in the kit runners (kit v1.5.6) and in the reference verifier (aer1-verify 0.2.13) ahead of this text. Each runner is zero- dependency within its language toolchain. Running the Python suite takes two steps and no dependencies beyond git and a Python 3 interpreter: git clone https://gitlab.com/rambozambodotdev/zambo.git python3 aer1- implementations/python/conformance.py Since the -23 revision, each conformance run also emits the evaluated vector set: one line per vector carrying its id and content digest, with a corpus digest over the set, so a claimed pass can be checked as a set difference against the full corpus. The cross-runner parity gate mints a receipt of each of its runs (schema 0.4; the committed payload carries the evaluated vector ids, the corpus digest, and the verdict, pass or fail) and pins it in the kit repository as parity- gate-receipt.json; the gate verifies that receipt with the kit conformance check and with aer1-verify, id bound, before it reports success. An implementation is conformant when it produces byte-identical verdicts to the reference runners across the full vector corpus. The corpus includes attack vectors for tampered provenance labels, schema version downgrades, and legacy (pre-0.4) receipts; conformance requires the Section 6 metadata checks to fail the first two and to report the third with a legacy notice rather than a failure. The kit is versioned; the v1.5.7 release is the frozen reference for the corpus described above. Independent verification. The Section 6 verification procedure has been exercised against live receipts by independent third parties: * On 2026-09-16, an independent agent ("Merv", on the Clawstr network) verified a live receipt (id 0ec81343-cc1f- 4c25-9c33-d76b5582406d) in three checks: the SHA-256 of the decoded canonical bytes matched the output commitment, the upstream evidence hash matched, and the anchor event carried a valid signature retrievable on independent relays. The same party reported that the anchor envelope did not then bind the evidence hash; the reference implementation has since shipped the binding envelope described above. * On 2026-09-16, an independent agent ("nilo_agent", on Nostr) ran adversarial verification challenges against live receipts, including a witness round and a strong-form Bitcoin-anchored challenge (anchor block 967351, receipt 88094e26), each answered with bytes the challenger could check independently. * On 2026-09-25 and 2026-09-26, an independent agent ("Devan", on Nostr) published timestamped probe receipts (v1 and v2) exercising independent verification of agent work in the same receipt model. Independent validators. An independent implementation exposes the Section 6 procedure as a public service: * WhiteMagic Labs (Lucas Bailey) operates a production validator for this specification at https://api.whitemagic.dev/aer1/verify, publicly accessible without a key, with the same procedure also exposed as an MCP tool (verify_aer1_receipt). On 2026-10-17 the operator exercised the validator against the reference implementation and the conformance corpus. The two implementations initially disagreed on cases in both directions (a decoding boundary in the validator; an id-binding reading and a nil-UUID acceptance in the reference tooling), each disagreement was resolved against the draft text the same day, and the implementations now agree across the exercised case matrix. The validator reports comparison outcomes in the shared states of Section 6 and attaches its provenance caution as advisory metadata beside the verdict, the arrangement the provenance note in Section 6 describes. Seven bundled kit runners for Sections 3 through 6 are maintained in the conformance kit repository (Rust, Go, TypeScript, Python, Java, C#, and Swift), each verified against the full vector corpus described above (124 vectors, 127 checks per runner). These runners are the kit's own test runners, not independent implementations. Independent third-party implementations, built from the draft text alone without access to kit internals, include ARION's Node.js and Java verifiers and ColonistOne's Perl verifier, each conformant against the same corpus. Since revision 12, contributors have reported two scoped interoperability exercises. On 2026-10-08, Tanilo and the AER-1 author published a cross-repository worked example linking an AER-1 receipt to a live Tanilo receipt by canonical hash, with the AER-1 commitment check and the Tanilo signature check run separately, each under its own rules. Also on 2026-10-08, the independent builder FlyThink published a four-case fixture binding AER-1 execution receipts to physical completion claims; all four cases replay cleanly, including the case where a valid AER-1 receipt coexists with invalid physical-evidence binding (see Section 10.2). Reports of additional implementations or independent verification results are solicited; implementers are encouraged to validate against the open conformance kit described above and to report their results. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. LedgerProof Foundation This document defines a Supply Chain Integrity, Transparency, and Trust (SCITT) profile for machine-readable cryptographic transparency receipts addressing all four sub-obligations of Article 50 of Regulation (EU) 2024/1689 (the "EU AI Act"): interactive AI system disclosure (50(1)), machine-readable marking of synthetic media (50(2)), emotion recognition notification (50(3), referenced for completeness), and AI-generated text disclosure with human editorial review exemption (50(4)). The profile defines three SCITT statement content types ("ai/article-50/v1", "ai/human-review/v1", and "ai/chatbot-session/v1") and specifies validation, verification, and chain-of-custody semantics suitable for presentation to European Union supervisory authorities, national competent authorities, and judicial proceedings. The profile is substrate-agnostic but presumes a SCITT Transparency Service backed by a publicly verifiable append-only log. A reference implementation using the Bitcoin blockchain as the SCITT log substrate, via RFC 6962 Merkle aggregation anchored in OP_RETURN transactions, is described in companion document draft-dawkins-scitt-lpr-00. VeritasChain Standards Organization This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, considerations arising from recordkeeping regimes such as the EU AI Act and MiFID II, and a crypto-shredding mechanism intended to support erasure obligations such as those under the GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto-shredding operations as append-only audit events. The profile makes trading records auditable and attributable after the fact; it does not prevent or block any trading activity, and it does not warrant the correctness of any recorded decision. Umarise This document describes the mechanism Umarise uses for temporal anchoring of digital artifacts: cryptographic hashes are committed to the Bitcoin blockchain via the OpenTimestamps protocol. The resulting proof is independently verifiable by any party with access to independently validated Bitcoin chain data, without contacting Umarise or any other anchoring service. The document is published so that other parties can produce and verify such proofs. The SCITT Architecture is used as the primary integration example; no changes to it are required. Action State Group, Inc. MyAuberge K.K. EMILIA Protocol, Inc. Independent Tyche Institute Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. Action State Group Many systems emit individually signed records — receipts, attestations, statements — and store them locally. Each record verifies on its own, but the collection proves nothing: records can be deleted, reordered, or created after the fact without detection. This document specifies the Checkpointed Local Log (CLL): a producer- operated append-only log that is a Merkle Mountain Range as defined by the COSE Receipts profile for Merkle Mountain Ranges, together with a small signed checkpoint that commits to the log's entire history. A checkpoint carries the content of that profile's Receipt of consistency — the accumulator and the consistency proof — inside a SCITT Signed Statement, so it can be registered with one or more independent Transparency Services without any change to them. A CLL upgrades a set of point receipts into a stream with provable order, contemporaneity, and completeness, and states precisely what it does not establish. It defines no new proof format, no change to SCITT Registration or Receipts, and no payload semantics. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. EMILIA Protocol, Inc. A human-authorization receipt proves an enrolled key produced a user- verified signature over a digest that commits to an exact action. It does not prove the signing surface DISPLAYED that action honestly. If a signing interface shows a benign summary while committing a different action, the resulting receipt is laundered authority: cryptographically valid and semantically false, which is worse than no receipt at all. This is the presentation attack, and it is the deepest unsolved problem in authorization evidence, because a signature cannot attest to pixels. This document narrows the gap with two additive, offline-checkable pieces that touch no existing receipt format: a DETERMINISTIC RENDERER, a pure function from the canonical action to a byte-identical human-readable rendering, so a verifier RE-DERIVES the rendering from the signed bytes and rejects a claimed rendering that does not match; and a DISPLAY ATTESTATION, a signed claim by the signing client binding the rendering it showed to the action it committed. Neither eliminates the presentation attack (nothing purely digital can), but together they let a verifier check the claimed rendering against the signed action under relying-party- selected client trust inputs. They make the residual risk explicit rather than hidden. EMILIA Protocol, Inc. Authorization proves what action was permitted; it does not prove what happened after execution. An executor-signed result improves attribution but remains a claim by the party that acted. This document specifies a source-routed Outcome Binding profile. Signed predicted effects identify the source role and source class required to evaluate each predicate. Executors, systems of record, and independent observers sign closed observation objects bound to the same authorization, action digest, Canonical Action Identifier, consumption nonce, operation, facility, and observation window. A deterministic verifier separates evidence availability from comparison: missing or unauthenticated required sources yield an indeterminate lifecycle state; authentic observations yield the closed comparison result in_bounds, divergent, or incomparable. The profile improves consequence reconciliation without claiming physical truth, sensor correctness, or legal finality. EMILIA Protocol, Inc. An authorization for one action does not by itself authorize an open- ended agent plan. This document defines an Experimental profile for a signed, finite, versioned directed acyclic graph of consequential action occurrences. The program binds a total retained-history ceiling. Each node binds an exact action or a pinned action-matching profile, an action- specific Trust Program, outcome-specific dependencies, an occurrence ceiling, and fixed charges against aggregate attempt budgets. A conforming program-aware admission store evaluates reachability and budgets in the same linearizable transaction domain as the ordinary one-time execution right. It uses store-owned authorizer trust roots, clock, authenticated profile-match verification, and current program status; seals a deterministic execution-program resource into the AdmissionSnapshot; and fences the program's independent authorization digest against ordinary-path admission. The profile does not establish that natural-language intent was understood, that a plan is safe or lawful, that provider or effect evidence is true, or that every mutation path was mediated. VolMax Studio Lab d.o.o. P10 defines a third-party-verifiable binding for NotDemonstrated(reason=underdetermined). A conforming P10 Adjudication Statement carries two canonical witness worlds that are compatible with the same closed evidence set and produce different values for the same frozen claim. The witness result is checked against committed profile semantics and bound into a SCITT Transparent Statement containing an in-toto Statement v1 predicate. The result establishes underdetermination only relative to the declared profile and does not identify the actual world or establish either claim value as true. Assault Consulting Assault Consulting This document describes PALA-1 -- version 1 of the Portable Append- only Log for Audit -- a compact binary record format for tamper- evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. n.d. n.d. n.d.

Acknowledgments Yohay Etsion, Founding Steward of the Decision Provenance Standard, for discussion. Steven Mih, for reading the demonstration and the two declarations and sending the corrections the -01 carries; Tora Toraman, for the correction on what the receipt profile commits to, and for stating the receipt's digest and signature constructions; Anya Chueayen, for the exchange on the approval record of section 8 of the Seal draft. Brennan Zambo, for confirming the readings of the AER-1 conformance kit and asking for the composed example. Sankalp Gilda, for the answers on the audit record's corpus that let its anchors be validated offline; Iman Schrock, for reading the WHO table against the composition draft's -02 candidate and the two corrections that followed; Andrii Sparysh, for stating the bridge task and its boundary; Ivan Nestorov, whose draft's adjudication shape the checkpoint case borrows, and whose own words for what it does not show the case keeps; Tolulope Adebayo, for reading the -00 against Invariant 3 and stating what a reference by instrument hash carries and what it does not. The authors of the capsule, payload binding, AI agent execution and action receipt drafts, whose care in stating what their records do not prove made the junction clear.

Appendix: the worked examples The files are kept with this document's source (https://github.com/Laurent-Lemonnier/dps-scitt-decision-layer, examples/release-decision/ and demo/); the digests below let a reader check them.

• Decision record DR-2026-0412 (record schema of the reference files 5.2.0, state closed): "Ship claims-intake 2.3.1 to production on 2026-10-23", three options considered, the first chosen; affirmed by the release manager on 2026-10-23T14:20:00Z. seal_hash: 34ba302a668e9200017a1083a92e88773dab1ca620faeaac8cd8bb7747596ba5.
• Action-binding attachment (0.3.0, unsigned in this example): seven stages, proposal by the release assistant, review and approval by the release manager under the release charter, without signature in this example, request, re-check, attempt, observed result; one specification, digest 19ade2a46319ac6622333cd6731ac400ed11daa7d6955b5daa5864da91c2b711, carried in full, naming build 2.3.1+git.5d1c9f0, the artifact digest, the SBOM digest, migration 0042 and the rollback. Attachment digest: 5086c7674db770c6d01592ba697722a2fb468c16d1d5ab9226a7b5217c4bc1a8.
• The action binding reference check on the attachment with the record: specification digests, record statements, action binding, stage order, authorisation re-check, observed results and rationale provenance verified; execution state attempted, result succeeded; issuer signature and time not checked, as the attachment is unsigned.
• A capsule (format 4, action_type decide, disposition accept by a human, effect confirmed) citing both by typed digest references in references[] with citation_purpose ran_under and acted_on: capsule_id 76481fc3bf5016ae51d7be821557f4bd7e40a0c0898ac7d8a6f425fbc135ab9d (the -00 quoted 8ffac39f..., before the effect's response digest was made the JSON digest of the observed response, as the capsule profile requires, and the effect type given a producer prefix); the capsule library (0.12.0) parses it strictly and its Class 1 verification passes with two informational findings (an effect type and a domain outside the seeded values); a verifier of the Standard resolves both references to the documents it holds.

The two references as the capsule carries them, wrapped as describes: