Decision Provenance for SCITT: binding software releases and agent actions to the decisions behind them

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 May 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The SCITT use cases [I-D.ietf-scitt-software-use-cases] and the formats a software supply chain already carries, build provenance [SLSA], attestations [IN-TOTO] and bills of materials [SPDX], answer the question "what is this artifact, and how was it built". Registered as Signed Statements in a Transparency Service [RFC9943], with Receipts [RFC9942], 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 [I-D.mih-scitt-agent-action-capsule]; an AgentInteractionRecord its inputs and outcomes [I-D.emirdag-scitt-ai-agent-execution]; a receipt its risk class and verdict, and may record a permission, a refusal or a deferral as well as an execution outcome [I-D.noa-scitt-ai-agent-receipt]. 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 [I-D.schrock-ep-authorization-receipts] 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 [DPS-CORE] 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 [DPS-ACTION-BINDING], 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 [DPS-ANCHORING], 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 [I-D.mih-sokolov-scitt-payload-binding], 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 [RFC9943], 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.¶

2. 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 [RFC2119] [RFC8174] 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 [RFC9943] and [RFC9942] define them. Build attestation, provenance predicate and bill of materials are used as [IN-TOTO], [SLSA] and [SPDX] define them.¶

3. 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 [RFC3161] 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.¶

4. 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 Section 5. 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 (Section 7) 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.¶

5. Artifact types for typed digest references

The Canonical Payload Binding [I-D.mih-sokolov-scitt-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 [DPS-NAMES]. 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.¶

6. 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 ([I-D.mih-sokolov-scitt-payload-binding] says so of its references); [INTEROP] 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.¶

7. 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 [RFC9052]: alg -19, kid the witness key's reference, CWT claims [RFC9597] iss the key's holder and sub the chain;¶

• the leaf: the statement's bytes as registered, under the [RFC9162] 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 (Section 9);¶

• 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 [RFC9943]. 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.¶

8. Worked examples

9. 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 [I-D.mih-sato-agent-accountability-composition] 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 [I-D.schrock-ep-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 [I-D.schrock-ep-presentation-binding] and the observed effect [I-D.schrock-ep-outcome-binding], and declare bounded execution programs [I-D.schrock-ep-bounded-execution-program]. 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 [I-D.mih-scitt-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 [I-D.munoz-scitt-permit-profile], 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 [I-D.chueayen-attestation-receipts] 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 (Section 10); [INTEROP] carries a worked example of its section 8.3 in that form, verified by both sides, with the failing cases.¶

• The Operating Model Protocol [I-D.veridom-omp-core] 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 Section 10.¶

• Signed permissions and action receipts [I-D.izmaylov-agent-permission-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 [I-D.morrison-binding-moment-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 [I-D.gilda-audit-agent-audit-record], [I-D.zambo-aer1], [I-D.sirkkavaara-vaara-receipt] 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 [I-D.kuehlewind-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 [I-D.ietf-wimse-aims] 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, [I-D.dawkins-scitt-ai-article50] 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. [I-D.kamimura-scitt-vcp] applies SCITT to the audit trail of algorithmic trading decisions under MiFID II.¶

• For time, [I-D.fassbender-scitt-time-anchor] 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 [I-D.sparysh-pala-audit] 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 [I-D.nestorov-scitt-p10-underdetermination] 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 [PROV-O] 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 [DECISION-PROV] does with a JSON-LD context, an exporter and queries, under a vocabulary of its own and without changing a member of the records.¶

10. 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 Section 5, 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 (Section 9) 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. [INTEROP] 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 [RFC9162] 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 (Section 13).¶

• 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.¶

11. 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 [RFC7942]; 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.¶

• [INTEROP], 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 [I-D.zambo-aer1] 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 [I-D.noa-scitt-ai-agent-receipt], 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 [I-D.nestorov-scitt-p10-underdetermination] 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 [I-D.fassbender-scitt-time-anchor] (its four vectors, against a header set the verifier checks for proof of work and linkage from a checkpoint it holds), AER-1 [I-D.zambo-aer1] (119 of 119 across its kit's seven suites) and the agent audit record [I-D.gilda-audit-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 [I-D.sparysh-pala-audit] 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.¶

• [DECISION-PROV], 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.¶

12. 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.¶

13. 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.¶

14. References

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 [RFC8792] describes:¶

NOTE: '\' line wrapping per RFC 8792

[
 {
  "type": "org.decisionprovenancestandard.decision_record",
  "digest_alg": "SHA-256",
  "digest": "34ba302a668e9200017a1083a92e88773dab1ca620faeaac8cd8\
bb7747596ba5",
  "citation_purpose": "ran_under"
 },
 {
  "type": "org.decisionprovenancestandard.action_binding_attachment",
  "digest_alg": "SHA-256",
  "digest": "5086c7674db770c6d01592ba697722a2fb468c16d1d5ab9226a7\
b5217c4bc1a8",
  "citation_purpose": "acted_on"
 }
]

Author's Address