Decision Provenance for SCITT: binding software releases and agent actions to the decisions behind them
draft-lemonnier-scitt-decision-provenance-00

SCITT                                                       L. Lemonnier
Internet-Draft                                                   iSoluce
Intended status: Informational                           26 October 2026
Expires: 29 April 2027

   Decision Provenance for SCITT: binding software releases and agent
                  actions to the decisions behind them
              draft-lemonnier-scitt-decision-provenance-00

Abstract

   Build attestations, bills of materials and Signed Statements in a
   Transparency Service record what was built and by whom.  None records
   the decision to ship: who approved it, on what authority, what they
   were shown, and why.  The statement profiles for AI agent actions
   have the same gap, and say so: their human-approval fields are the
   producer's claim.  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.

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 29 April 2027.

Lemonnier                 Expires 29 April 2027                 [Page 1]
Internet-Draft          SCITT Decision Provenance           October 2026

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Relation to the Decision Provenance Standard  . . . . . .   4
     1.2.  Versions and commit . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  What the decision layer adds  . . . . . . . . . . . . . . . .   5
   4.  Where it attaches in the software supply chain  . . . . . . .   5
   5.  Artifact types for typed digest references  . . . . . . . . .   6
     5.1.  decision_record . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  action_binding_attachment . . . . . . . . . . . . . . . .   7
     5.3.  What a verified reference shows . . . . . . . . . . . . .   7
     5.4.  Carrying the references . . . . . . . . . . . . . . . . .   7
   6.  Verification  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Checkpoints in a Transparency Service . . . . . . . . . . . .   8
   8.  Worked examples . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  A software release decision . . . . . . . . . . . . . . .   9
     8.2.  An agent action capsule citing a decision . . . . . . . .   9
   9.  Open questions  . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     12.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Appendix: the worked examples . . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

Lemonnier                 Expires 29 April 2027                 [Page 2]
Internet-Draft          SCITT Decision Provenance           October 2026

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 [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, and that the reasoning behind
   the action stays private or reduced to a hash.

   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.

   This document does three things.  It declares two artifact types 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,

Lemonnier                 Expires 29 April 2027                 [Page 3]
Internet-Draft          SCITT Decision Provenance           October 2026

   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.

1.1.  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.

   "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.

1.2.  Versions and commit

   This document is written against the extensions as they stand on the
   repository's main branch at commit 5b0534d: 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 Section 5 are those the
   extensions index declares at the same commit [DPS-NAMES].  Each
   extension states its version in every document it defines; this
   document names them so that a reader can check the same tree.

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.

Lemonnier                 Expires 29 April 2027                 [Page 4]
Internet-Draft          SCITT Decision Provenance           October 2026

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.

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:

Lemonnier                 Expires 29 April 2027                 [Page 5]
Internet-Draft          SCITT Decision Provenance           October 2026

   *  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; the
   Agent Action Capsule profile [I-D.mih-scitt-agent-action-capsule]
   (section 9.1) asks that a declared type name carry a URI or reverse-
   DNS prefix.  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 it uses; this document does not restate the digest
   rules and only says how the references are carried.  A name never
   changes meaning; a different digest rule would get a new name.

Lemonnier                 Expires 29 April 2027                 [Page 6]
Internet-Draft          SCITT Decision Provenance           October 2026

5.1.  decision_record

   *  type: org.decisionprovenancestandard.decision_record

   *  digest: as [DPS-NAMES] declares it for this name, by reference to
      portable verification [DPS-PV]; the same value as the entry's
      seal_hash.

5.2.  action_binding_attachment

   *  type: org.decisionprovenancestandard.action_binding_attachment

   *  digest: as [DPS-NAMES] 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 [DPS-SIGNATURES].

5.3.  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.

5.4.  Carrying the references

   In a capsule, the references are carried in references[] as the
   capsule profile allows, in the style of
   [I-D.rampalli-scitt-capsule-provenance-binding]; in an
   AgentInteractionRecord, in external_refs; in a receipt that keeps its
   object closed, as a separately signed claim linked by digest; in a
   release statement, in the cpb-refs protected header or in the
   statement's own 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.

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;

Lemonnier                 Expires 29 April 2027                 [Page 7]
Internet-Draft          SCITT Decision Provenance           October 2026

   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.  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;

   5.  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.

   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 5b0534d.  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; a Transparent
      Statement is carried with its receipts taken out;

   *  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

Lemonnier                 Expires 29 April 2027                 [Page 8]
Internet-Draft          SCITT Decision Provenance           October 2026

8.1.  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.

8.2.  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.

9.  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 two artifact type names of Section 5 belong in a
      registry, if the Canonical Payload Binding establishes one, and
      under which policy; today the Standard's repository declares them
      under its own namespace.

   *  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 11).

   *  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.

Lemonnier                 Expires 29 April 2027                 [Page 9]
Internet-Draft          SCITT Decision Provenance           October 2026

10.  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.  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.  The anchoring extension's security
   considerations apply.

11.  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.

12.  References

12.1.  Normative References

   [DPS-ACTION-BINDING]
              Lemonnier, L., "Action binding extension 0.3.0 of the
              Decision Provenance Standard", October 2026,
              <https://github.com/decision-provenance-
              standard/standard/tree/5b0534d/extensions/action-binding>.

   [DPS-ANCHORING]
              Lemonnier, L., "Anchoring extension 0.2.0 of the Decision
              Provenance Standard", October 2026, <https://github.com/
              decision-provenance-
              standard/standard/tree/5b0534d/extensions/anchoring>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

Lemonnier                 Expires 29 April 2027                [Page 10]
Internet-Draft          SCITT Decision Provenance           October 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

   [RFC9942]  Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
              Fournet, "CBOR Object Signing and Encryption (COSE)
              Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
              <https://www.rfc-editor.org/rfc/rfc9942>.

   [RFC9943]  Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
              Y., and S. Lasker, "An Architecture for Trustworthy and
              Transparent Digital Supply Chains", RFC 9943,
              DOI 10.17487/RFC9943, June 2026,
              <https://www.rfc-editor.org/rfc/rfc9943>.

12.2.  Informative References

   [DPS-CORE] Etsion, Y., "The Decision Provenance Standard, Core v1.3
              (reading edition rev. 11)", 2026,
              <https://decisionprovenancestandard.org>.

   [DPS-NAMES]
              "Extensions of the Decision Provenance Standard, Names for
              typed references", n.d., <https://github.com/decision-
              provenance-standard/standard/blob/5b0534d/extensions/
              README.md#names-for-typed-references>.

   [DPS-PV]   "Portable verification extension 0.3.0 of the Decision
              Provenance Standard", n.d., <https://github.com/decision-
              provenance-standard/standard/tree/5b0534d/extensions/
              portable-verification>.

   [DPS-SIGNATURES]
              "Signatures extension 0.2.0 of the Decision Provenance
              Standard", n.d., <https://github.com/decision-provenance-
              standard/standard/tree/5b0534d/extensions/signatures>.

   [I-D.emirdag-scitt-ai-agent-execution]
              Emirdag, P. and D. Feichtinger, "AI Agent Execution
              Profile of SCITT", Work in Progress, Internet-Draft,
              draft-emirdag-scitt-ai-agent-execution-01, 12 October
              2026, <https://datatracker.ietf.org/doc/html/draft-
              emirdag-scitt-ai-agent-execution-01>.

Lemonnier                 Expires 29 April 2027                [Page 11]
Internet-Draft          SCITT Decision Provenance           October 2026

   [I-D.ietf-scitt-software-use-cases]
              Birkholz, H., Deshpande, Y., Brooks, D., Martin, B., and
              B. Knight, "Detailed Software Supply Chain Uses Cases for
              SCITT", Work in Progress, Internet-Draft, draft-ietf-
              scitt-software-use-cases-03, 18 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
              software-use-cases-03>.

   [I-D.mih-scitt-agent-action-capsule]
              Mih, S., "An Agent Action Capsule Profile for SCITT", Work
              in Progress, Internet-Draft, draft-mih-scitt-agent-action-
              capsule-05, 26 September 2026,
              <https://datatracker.ietf.org/doc/html/draft-mih-scitt-
              agent-action-capsule-05>.

   [I-D.mih-sokolov-scitt-payload-binding]
              Mih, S. and A. Sokolov, "Canonicalization Declaration for
              SCITT Signed Statements", Work in Progress, Internet-
              Draft, draft-mih-sokolov-scitt-payload-binding-06, 25
              October 2026, <https://datatracker.ietf.org/doc/html/
              draft-mih-sokolov-scitt-payload-binding-06>.

   [I-D.noa-scitt-ai-agent-receipt]
              Toraman, T., "A SCITT Profile for AI-Agent Action
              Receipts", Work in Progress, Internet-Draft, draft-noa-
              scitt-ai-agent-receipt-01, 14 August 2026,
              <https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
              agent-receipt-01>.

   [I-D.rampalli-scitt-capsule-provenance-binding]
              Karthik, R., "Binding Per-Action Authorization and Memory
              Provenance into Agent Action Capsules", Work in Progress,
              Internet-Draft, draft-rampalli-scitt-capsule-provenance-
              binding-00, 4 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-rampalli-
              scitt-capsule-provenance-binding-00>.

   [IN-TOTO]  "in-toto Attestation Framework", n.d.,
              <https://github.com/in-toto/attestation>.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
              2001, <https://www.rfc-editor.org/rfc/rfc3161>.

Lemonnier                 Expires 29 April 2027                [Page 12]
Internet-Draft          SCITT Decision Provenance           October 2026

   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
              "Handling Long Lines in Content of Internet-Drafts and
              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8792>.

   [RFC9597]  Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
              COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
              <https://www.rfc-editor.org/rfc/rfc9597>.

   [SLSA]     "SLSA: Supply-chain Levels for Software Artifacts,
              provenance predicate", n.d., <https://slsa.dev/spec/>.

   [SPDX]     "SPDX Specification", n.d.,
              <https://spdx.dev/specifications/>.

Acknowledgments

   Yohay Etsion, Founding Steward of the Decision Provenance Standard,
   for discussion.  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-star/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

Lemonnier                 Expires 29 April 2027                [Page 13]
Internet-Draft          SCITT Decision Provenance           October 2026

      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
      8ffac39fe42e5d1b9dcbff838ec5c3aad749a3e8a32e3157791297f5f325b6e7;
      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

   Laurent Lemonnier
   iSoluce
   France
   Email: laurent@isoluce.net

Lemonnier                 Expires 29 April 2027                [Page 14]