Definition of Done 2.0: Provenance, Attestation, and Sandbox Compliance in SAFe

The classic Definition of Done assumes human authorship. DoD 2.0 swaps asserted checkboxes for provable provenance, attestation, and sandbox compliance.

Definition of Done 2.0 asks a question the classic checklist in SAFe was never built to answer: can you prove where this increment’s AI-generated pieces came from? Teams shipping model weights, generated code, and agent actions against a DoD written for human-authored work discover the gap during an audit or an incident review; provenance, attestation, and sandbox compliance become the missing criteria at the exact moment proof is hardest to produce after the fact.

Why the Classic Definition of Done Fails AI Work

The classic Definition of Done certifies human-authored, deterministic work, tests pass, code is reviewed, documentation is updated, and none of those three criteria can see model weights, training data lineage, or code an agent generated at runtime, which is exactly what an AI-containing increment adds. A checklist cannot certify what it cannot see, and that gap is the starting condition every quality lead, system architect, and RTE now has to design around.

Classic DoD Hidden Assumptions

A traditional Definition of Done assumes a human wrote every line, which is why “code reviewed” and “tests passing” were ever considered sufficient evidence of quality. That assumption held because commit history made authorship implicit; reviewers knew who wrote what, when, and could ask them why.

Agent-produced increments break that implicit chain. Traditional Definition of Done assumes human builders: code reviewed, tests passing, meets Acceptance Criteria; and code provenance is implicit only because commit history shows exactly who wrote every line Acceptance Criteria (agility-at-scale.com). Once an agent authors the diff under its own runtime decisions, that implicit authorship trail disappears, and the DoD is left certifying a state, tests green, review approved, without certifying the thing that produced that state. The checklist still runs; it just stops meaning what the team assumes it means.

Model Weights and Generated Code Gaps

An AI-containing increment adds three categories of artifact the classic DoD has no vocabulary for: model weights with their own training lineage, generated code of uncertain provenance, and agent actions decided at runtime rather than authored in advance. Each behaves differently from the deterministic source file a DoD was designed to certify.

Model weights encode a training history, datasets, fine-tuning passes, evaluation runs, that a code review cannot inspect and a unit test cannot exercise. Generated code can pass every test in the suite while carrying dependencies, patterns, or licensing exposure the model reproduced from its training corpus without anyone deciding to include them. Agent actions are worse still: a runtime decision to call a tool, modify a file, or escalate a permission is not represented in any source diff, so “code reviewed” cannot certify it happened correctly, only that the output of some run looked acceptable. The agentic supply chain that produces these three categories now sits upstream of every increment, and a DoD that only inspects the increment’s surface never touches it.

Provenance and Attestation Definitions

Provenance is the verifiable origin story of an artifact, what produced it, from what inputs, through what process, while attestation is the cryptographically signed, machine-checkable claim that states that origin story formally. The two terms are often used interchangeably in casual conversation, but a DoD that conflates them writes criteria that sound rigorous and check nothing.

Provenance without attestation is a narrative: a README that claims a model was trained on approved data, unverifiable by anyone downstream. Attestation without provenance is a signature on an empty claim: a cryptographic wrapper around a statement no one defined precisely enough to be useful. A software attestation is an authenticated statement (metadata) about a software artifact or collection of software artifacts, and that metadata only has value when the provenance record underneath it is complete enough to answer the question an auditor or an incident reviewer will actually ask (SLSA specification). Definition of Done 2.0 treats the two as a pair: provenance is the content, attestation is the proof that the content is genuine and unaltered.

Provenance-as-New-Perimeter Framing

Provenance functions as the new security perimeter for AI-containing work: trust no longer lives at the network boundary, it lives in the verifiable trail back to an artifact’s origin. That reframing matters because a DoD historically inherited its trust model from infrastructure security, where “inside the firewall” meant “trusted”: a model that has no equivalent for a model checkpoint pulled from a public registry or code an agent wrote against an unreviewed dependency.

The agentic supply-chain literature makes this explicit: model dependency has to be auditable back to its upstream source before any question about inherited vulnerabilities, license obligations, or unattributed redistribution can even be asked, because none of those questions are answerable without a documented derivation chain (Cisco’s Model Provenance Constitution write-up). This is why the framework recognizes an adversarial dimension it calls detection evasion; deliberate concealment of a derivation relationship through metadata rewriting or chained modifications intended to obscure a component’s parent. A DoD that stops at “the artifact passed its tests” has no mechanism to catch that kind of concealment, because concealment doesn’t fail a test; it fails a provenance check that was never run.

DoD 2.0 Provable-Not-Asserted Claim

Definition of Done 2.0 collapses to a single claim: an AI-containing increment is done only when its origin, its build path, and its permitted runtime behavior are provable, not merely asserted. Everything downstream, the tooling stack, the SAFe-level criteria, the sandbox evidence requirement, exists to make that one claim checkable by a machine rather than trusted on a teammate’s word.

The distinction between provable and asserted is the entire upgrade. An asserted DoD item is a checkbox a person ticks; a provable one is a signed record a policy engine reads. Definition of Done must evolve from a checkbox of completion criteria into an Attestation Chain that records which agent produced the code, under what instruction contract, in what sandbox, with what policy constraints Attestation Chain (agility-at-scale.com); transforming what used to be implicit provenance into explicit, auditable governance. The remaining sections work through what makes that transformation real: the tooling that ships today, the standards converging in 2026, the exact wording to put in a DoD document, and the cost of getting the balance wrong.

The Attestation Stack: SLSA, in-toto, and Signed AI Artifacts

Three shipped technologies convert a provenance claim into something a build pipeline can check automatically: SLSA grades how tamper-resistant a build path must be, in-toto attestations chain step-by-step evidence of what each stage of a pipeline consumed and produced, and Sigstore with Cosign extend cryptographic signing from packages to model files and container images. None of this is speculative; platform teams can wire it into a SAFe train’s DevOps pipeline this quarter.

SLSA Levels for Build-Path Security

SLSA (Supply-chain Levels for Software Artifacts) grades a build path across a numbered scale, where each level raises the bar on what an attacker would need to compromise to inject something into the artifact without detection. The framework is deliberately layered rather than binary: a build either meets a level’s requirements or it doesn’t, and higher levels demand progressively more isolation between the build process and the humans or systems that could tamper with it.

Provenance is an attestation that a particular build platform produced a set of software artifacts through execution of the build definition (SLSA’s provenance specification). At the lower levels, that provenance record can be self-reported by the build system; at the higher levels, the build must run on an isolated, ephemeral platform whose own identity is itself attested, closing off the tampering paths available to a compromised workstation or a malicious insider with build-server access. For an AI-containing increment, the practical translation is direct: a model checkpoint or generated-code artifact carries a builder.id, a record of resolved dependencies, and timestamps for when the build started and finished: the same structured record a container image gets, applied to an artifact type SLSA’s authors never had in mind when the levels were first defined. Grading the build path this way means the DoD criterion “artifact is attested” has a concrete floor: attested to which level, on which builder, is a question the record answers without anyone asking a person.

In-Toto Step-by-Step Evidence Chains

In-toto attestations supply the evidence chain underneath an SLSA grade: at each step of a pipeline, the step signs a record of what it consumed and what it produced, so the full sequence from source checkout to final artifact is independently verifiable rather than trusted as a single end-to-end claim. This step-by-step structure is what makes provenance auditable after the fact instead of only at build time.

In-toto is a framework for securing software supply chains through cryptographically signed metadata, and this provenance predicate models the supply chain as a series of steps, with each step generating attestations that are verified against a supply-chain layout: a signed metadata document defining the expected steps and their outcomes (Secure Pipelines; Legit Security’s SLSA deep dive). Applied to an AI pipeline, this means the dataset ingestion step signs what data it pulled and from where, the training step signs what dataset hash it consumed and what checkpoint it produced, and the packaging step signs what checkpoint it wrapped into a deployable artifact. Any missing or mismatched link breaks the chain visibly, which is the property a classic DoD’s single “tests passed” checkbox structurally cannot provide: one green checkmark says nothing about which of ten upstream steps might have been skipped or substituted.

Sigstore-Cosign Model File Signing

Sigstore and its signing tool Cosign extend the code-signing pattern that secured software packages into model files and container images, giving each artifact a cryptographic signature tied to a verifiable identity rather than a static, easily-copied key. For AI artifacts specifically, this closes a gap that package signing alone never covered: a model checkpoint distributed outside a container has historically carried no signature at all.

Signing a model file with Cosign produces the same verification guarantee a signed container image gets: a downstream consumer can confirm the artifact matches exactly what was signed and reject anything that doesn’t, before it ever reaches a runtime environment. Combined with a transparency log, the signature also becomes publicly auditable: anyone can confirm a given model version was signed by a specific identity at a specific time, without trusting a private registry’s internal records. This matters for container images carrying agent runtimes as much as it matters for the model weights themselves: an agent’s execution environment is itself an artifact that needs the same signed provenance, since an unsigned runtime image is exactly the kind of substitution point the SLSA build-path grading is designed to close off.

Four-Building-Blocks Trust Model

AI artifact trust decomposes into four building blocks that work together rather than substituting for each other: inventory (what artifacts exist and what they depend on), signatures (cryptographic proof of authenticity), provenance (the verifiable origin record), and policy enforcement (the automated check that blocks anything failing the first three). Removing any one block leaves a gap the other three cannot cover.

An inventory without signatures tells a team what exists but not whether it’s genuine. Signatures without provenance confirm an artifact wasn’t tampered with after signing but say nothing about how it was built. Provenance without policy enforcement produces a complete, verifiable record that no pipeline actually checks before deployment; which is the most common gap in early-stage adoption, where teams generate attestations but never wire a gate that reads them.

Kanagala’s TMLAI AI-SBOM Framework

Ashok Kumar Kanagala’s 2026 framework in the Transactions on Machine Learning and Artificial Intelligence consolidates software bill of materials practice for the AI development lifecycle specifically, addressing what a generic SBOM standard misses about model artifacts. Existing SBOM formats were built for compiled binaries and package dependencies; they inadequately capture model lineage, training provenance, and disclosure metadata as first-class fields.

Existing software bills of materials inadequately capture AI-specific artefacts such as model lineage, training provenance, and disclosure metadata, limiting verifiable lifecycle governance (Frontiers in Computer Science). Kanagala’s contribution extends the inventory building block from the trust model above with AI-specific fields, training dataset identifiers, fine-tuning history, evaluation benchmark results, that a generic dependency scanner has no schema for. For a SAFe train’s DoD, this framework is the reference an integration team points to when defining exactly what an “AI SBOM” record must contain, rather than improvising a bespoke schema per Agile Release Train and losing comparability across the portfolio.

Policy-Enforced Attestation Verification

The four blocks only produce value once a policy engine reads the attestations automatically and blocks any artifact that doesn’t clear the required checks; without that enforcement step, every prior block is a record nobody consults before deployment. This is the step that turns “we generate attestations” into “we cannot ship without them.”

Machine-Checkable Done Predicates

A machine-checkable done predicate replaces a reviewer’s judgment call with a boolean the pipeline evaluates automatically: does this artifact carry a valid attestation at the required SLSA level, or does it not. There’s no partial credit and no negotiation once the predicate is wired into the gate.

This is the operational payoff the entire attestation stack exists to deliver. Provenance completeness, PQC-safe signatures, and attestation records become inputs to trust scoring, enabling dynamic policy enforcement based on the integrity and lineage of AI components Model Bill (MDPI’s MBOM-PQC study). Where a classic DoD relied on a human reviewer remembering to ask “was this properly sourced,” a policy-enforced gate asks the question every single time an artifact attempts to move forward, with no dependence on any individual’s memory or diligence. That reliability is exactly what converts a DoD sentence into an enforceable criterion rather than a well-intentioned suggestion.

The 2026 Standards Wave: Verifiable Decision Trails and Model Bills of Materials

Beyond the shipped SLSA-in-toto-Sigstore stack, three 2026 developments define where done-criteria are heading: the IETF’s Verifiable AI Provenance framework composes transparency logs and remote attestation into decision trails covering an entire AI feature rather than just its build, MBOM-PQC proposes a quantum-resistant model bill of materials, and NIST CSF 2.0 gives regulated enterprises a citable compliance anchor. None of this is shipped-and-stable: the honest read is track it now, adopt what’s already working.

IETF VAP Framework Components

The IETF Verifiable AI Provenance framework coordinates four components into one coherent decision trail: SCITT transparency logs record what happened, RATS remote attestation proves the environment that produced it, COSE signing secures the records cryptographically, and Entity Attestation Tokens carry compact, verifiable claims about a specific piece of hardware or software state. Individually, each component solves a narrow problem; composed together, they cover data, model, and deployed service in one verifiable chain.

SCITT and RATS Attestation Layers

SCITT (Supply Chain Integrity, Transparency, and Trust) provides the transparency log layer: an append-only, publicly auditable record of claims about an artifact’s lifecycle events, so a later dispute can be resolved by checking what was logged rather than trusting a party’s recollection. RATS (Remote Attestation Procedures) provides the layer underneath it; proof that a specific piece of hardware or software is in the state it claims to be, verified remotely rather than assumed.

Together, an Entity Attestation Token carries the compact claim RATS produces into the SCITT log, where it becomes part of the permanent, verifiable record. For an AI pipeline, this means a claim like “this model was fine-tuned inside this specific sandboxed environment” isn’t just asserted in a deployment note: it’s a signed EAT token, logged in SCITT, checkable independently of whoever wrote the deployment note. This is meaningfully harder to build than the build-time attestation SLSA and in-toto already provide, which is exactly why it remains a draft standard rather than a production requirement.

End-to-End Decision Trail Provenance

The Verifiable AI Provenance framework’s core change is scope: it extends provenance from covering just the build to covering the entire decision path, data in, model applied, service deployed, output produced, so an AI feature’s whole trajectory becomes verifiable rather than only its packaging step. A build-time attestation proves the artifact was built correctly; a decision-trail attestation additionally proves the specific inference that produced a specific output came from that verified artifact operating within its intended bounds.

For a DoD written at the story level, this distinction matters when an increment’s risk lives in the decision, not the build: a model that was attested correctly at build time can still produce an ungoverned output if the runtime environment or the input data diverged from what was verified. AI compliance will likely hinge on the ability of applications and APIs powered by machine learning to clearly demonstrate the source and pathway of outputs (NTIA’s AI output disclosures report), and a decision-trail record is what makes that demonstration possible without reconstructing the event from logs after the fact.

MBOM-PQC Model Bill of Materials

MBOM-PQC proposes a model bill of materials with post-quantum-safe signing, extending the AI-SBOM concept from Kanagala’s framework with cryptography designed to remain secure once quantum computing threatens today’s signature algorithms. The proposal integrates FIPS 204 (ML-DSA) signing for operational artifacts and FIPS 205 (SLH-DSA) for archival records, alongside hybrid signature modes that stay compatible with current infrastructure during the transition period.

Existing PQC transition guidance does not address AI artifacts or model provenance, and the absence of an established Model Bill of Materials standard combines with the absence of PQC-safe signing and attestation pipelines to leave organizations without a structured way to verify authenticity, lineage, and integrity for AI systems Zero Trust Architecture (MDPI’s MBOM-PQC study). This gap is precisely why the proposal exists: today’s SLSA and Sigstore signatures use classical cryptography that a sufficiently mature quantum computer could eventually break, which means a model checkpoint signed today under standard practice has an expiration date on its trustworthiness that most DoD criteria don’t yet account for.

Post-Quantum Signature Requirements

A post-quantum signature requirement means the signing algorithm itself, not just the signed content, has to survive an adversary with quantum computing capability: a distinction the SLSA and Sigstore stack described earlier doesn’t currently make. FIPS 204 and FIPS 205 are the two standardized algorithm families proposed for this purpose, covering operational and archival signing needs respectively.

The practical consequence for a DoD author is sequencing, not urgency: quantum-capable attacks against today’s signatures aren’t an active threat yet, but the artifacts being signed now, model weights, training records, often need to remain verifiable for years, long enough for the threat to mature during the artifact’s own lifetime. A DoD criterion written today doesn’t need to mandate PQC signing; it needs to track the standard closely enough to migrate before the archival window closes.

The Five SCAMM Maturity Levels

SCAMM (Supply Chain Attestation Maturity Model) defines five levels an organization climbs as its provenance practice deepens, from ad hoc or absent attestation at the bottom to fully automated, continuously verified attestation across the entire AI lifecycle at the top. The scale exists because “we do attestation” is not a binary state in practice: a train might sign build artifacts but have no runtime attestation, or vice versa, and SCAMM gives that partial state a name.

The five levels run roughly from no formal attestation practice, through build-time-only signing, through signed provenance with manual policy checks, through automated policy enforcement at the build stage, to continuous attestation covering build, deployment, and runtime decision trails together. A portfolio doesn’t need every value stream at the top level simultaneously: the scale is a targeting tool, not a pass/fail gate, and its use in a DoD is covered in the section below rather than re-enumerated here.

NIST CSF 2.0 Integrity Checks

NIST’s Cybersecurity Framework 2.0 gives regulated enterprises a citable compliance anchor for provenance work through its PR.DS-6 category, which covers integrity-checking mechanisms for data, software, and firmware: the exact control family a DoD’s attestation criteria are implementing in practice, whether or not the DoD document names it explicitly.

Citing PR.DS-6 directly in a DoD document does two things a home-grown attestation policy can’t: it maps the criterion to a framework an external auditor already recognizes, and it gives the quality lead a defensible answer when asked why a specific check exists. Zero Trust Architecture requires continuous verification of users, devices, and workloads, and the proposed pipeline extends this requirement to AI artifacts; provenance completeness and attestation records become inputs to a trust score that drives policy enforcement (MDPI’s MBOM-PQC study). For a regulated value stream, wiring DoD attestation criteria explicitly to PR.DS-6 converts an internal quality preference into a control an auditor can check off against a recognized framework.

SCAMM-Staged Standards Adoption

The honest maturity note governs everything in this section: the IETF’s Verifiable AI Provenance framework is a draft, MBOM-PQC is a preprint, and neither should be written into a DoD as a hard requirement today. The actionable move is to adopt the shipped SLSA-in-toto-Sigstore stack now, target a specific SCAMM level as the portfolio’s near-term goal, and track the draft standards for when they harden enough to cite directly.

Staging adoption this way keeps the DoD criteria enforceable at every point along the way: a train at SCAMM level 2 isn’t failing a level-5 requirement it was never ready to meet, it’s meeting the requirement its current maturity level defines. Mapping specific SCAMM targets to specific regulatory regimes is a governance decision this cluster’s dedicated governance article covers in full; here, the takeaway is narrower: pick a level, write it into the DoD, and revisit the target as the standards wave matures rather than waiting for the standards to finish before writing anything down.

Writing DoD 2.0 into SAFe: Criteria by Level, Sandbox Evidence Included

Converting the attestation stack into policy means wording exact criteria at each SAFe level rather than leaving “attestation required” as an unstated intention. Story-level criteria cover individual artifacts, ART-level integration criteria block unattested work from the increment, portfolio-level criteria set maturity targets that hold the whole thing together, and a dedicated sandbox-compliance criterion covers what none of the artifact-focused criteria can: whether an agent’s runtime actions stayed inside their permitted boundary.

Story-Level Attestation Requirements

A story touching AI-generated artifacts is done only when those artifacts carry the required attestations and the model bill of materials record has been updated and signed: not when the story’s acceptance criteria are met and its tests are green. This is the story-level translation of the provable-not-asserted claim from the opening section: a specific, checkable condition rather than a general intention.

In practice this reads as an addition to the existing DoD line item, not a replacement: “code reviewed, tests passing” stays exactly as written for the human-authored portions of a story, and “artifacts carry required attestations, model BOM updated and signed” is appended as its own line for any AI-generated component. Writing it as an addition rather than a rewrite keeps the story-level DoD legible to teams that haven’t yet touched AI-containing work, while making the new criterion unambiguous for those that have.

ART-Level Integration Attestation Gate

At the Agile Release Train level, the integration gate is a single new stage inserted into the existing CI/CD pipeline immediately after the standard build-and-test stage; before artifact promotion, before staging deployment, and before any automated integration test suite runs against the assembled increment. The policy-enforcement concept from Section 2’s trust model defines the mechanism; this gate wires that mechanism into the SAFe train’s specific pipeline topology.

Practically, the gate executes as a dedicated stage that queries each AI-touched artifact’s attestation record by artifact type: container images and model checkpoints are checked against their Sigstore/Cosign signatures and SLSA provenance statements via the pipeline’s existing registry integration; generated-code diffs are checked against their in-toto step attestation using the layout document the build definition declares; and model BOM records are validated against the Kanagala AI-SBOM schema for mandatory fields. Each query returns a structured failure signal, a JSON payload naming the artifact, the missing or invalid attestation field, and the SLSA level required versus attested, surfaced as a build-breaker in the train’s CI dashboard with a standardized error code (ATTESTATION_MISSING, SLSA_LEVEL_UNDER, BOM_INCOMPLETE). For a train engineer the failure presents as a blocked merge with a link to the offending artifact’s attestation record, actionable without requiring the engineer to become an attestation specialist. Teams that skip wiring this gate into automation typically discover the gap the way most integration failures surface: an artifact ships without attestation, nothing blocks it, and the missing record only becomes visible when an audit or an incident asks for it.

Portfolio-Level Maturity Targets

Portfolio-level criteria set SCAMM maturity targets by value stream, turning the DoD into a roadmap that hardens as the organization climbs rather than a static bar every train meets identically on day one. Portfolio leadership owns the authority to set and document these targets in a single governance artifact: a policy that assigns a target SCAMM level per value stream and defines who may propose a change, who approves it, and under what conditions.

Setting these targets at the portfolio level rather than leaving them to individual trains prevents the inconsistency that undermines audit readiness: an auditor examining two trains within the same regulated value stream expects comparable attestation depth, and a portfolio-level target is what guarantees that comparability instead of leaving it to chance. The policy defines a regular review cadence aligned to the program increment boundary, during which leadership reassesses each target against current operational evidence, regulatory changes, and the maturity of the attestation tooling stack. The target itself references the SCAMM scale defined earlier rather than re-explaining the five levels; the portfolio document states the target level per value stream and the review cadence for raising it.

Sandbox Compliance Execution Evidence

Agent-executed work is done only when it ran inside its sandboxed permission boundary and execution evidence proves it: a criterion the artifact-focused attestation checks above don’t cover, because a correctly-attested artifact can still be produced by an agent that exceeded its intended runtime permissions while producing it. Sandbox compliance closes that gap by evidencing the process, not just the product.

The sandbox isn’t just a security measure: it’s a quality enforcement boundary, and when teams adopt this mindset, sandbox configuration becomes a quality engineering activity rather than only an infrastructure concern (agility-at-scale.com). Execution evidence is the concrete artifact this criterion demands: a signed log of which permissions the agent’s runtime held, which tools it invoked, and which files or systems it touched during the run that produced the increment. Without that evidence, “the agent stayed inside its sandbox” is exactly the kind of asserted-not-provable claim Definition of Done 2.0 exists to eliminate.

Permission Boundary Enforcement at Runtime

Enforcing a permission boundary at runtime means the sandbox itself refuses actions outside the agent’s granted scope, rather than relying on a post-hoc review to catch violations after the run completes. This is a preventive control, not a detective one: the boundary blocks the action before it happens.

Multi-agent systems complicate this further: sensitive information about an agent’s capabilities, working patterns, or the data it processed may appear inside its own attestation reports, which creates a legitimate tension between evidencing compliance and protecting operational detail organizations may be reluctant to expose even internally (WJARR’s runtime attestation study). A practical DoD criterion resolves this by scoping execution evidence to what a reviewer or auditor actually needs, permission scope held, actions taken, boundary violations if any, rather than exporting a full behavioral trace that exposes more than the compliance question requires.

Quality Leadership Policy Ownership

Quality leadership defines the attestation and sandbox criteria once, as portfolio or train-level policy, and tooling enforces them per increment: no per-story negotiation, no case-by-case exception granted by whichever reviewer happens to be on the story that sprint. Fixing ownership this way is what keeps the criteria consistent across a train instead of drifting story to story based on who’s reviewing.

This is a deliberate constraint on flexibility: a story-level DoD that allows negotiation invites exactly the inconsistency that undermines an audit, where two functionally identical stories carry different attestation depth because two different reviewers made two different calls. Quality leadership owning the policy centrally, with tooling enforcing it automatically at integration, removes that variance entirely: the criterion is the same for every story that touches AI-generated artifacts, checked the same way, every time.

Tooling-Enforced Criteria Without Per-Story Negotiation

Tooling enforcement means the ART-level integration gate described earlier is the only place the criterion actually gets applied: not a reviewer’s judgment call at story review, and not a retrospective conversation after something ships without the required attestation. The policy is written once; the pipeline is where it lives operationally.

This removes the single most common failure mode in early attestation rollouts, where a well-intentioned policy document exists but nothing in the pipeline actually reads it, so compliance depends entirely on individual reviewers remembering a rule that isn’t automated. Once the same check runs identically on every integration attempt, “did this story meet the attestation criteria” stops being a question anyone has to ask, because the pipeline already answered it before the story could merge.

CALMR Automation and Recovery Alignment

Aligning attestation enforcement with SAFe’s CALMR approach to DevOps, culture, automation, lean flow, measurement, and recovery, means the new criteria ride existing automation and recovery practice rather than arriving as new manual gates layered on top of a train’s current pipeline. This alignment is what determines whether attestation enforcement accelerates flow or throttles it.

A train that already automates its test suite, its deployment pipeline, and its rollback procedure has the infrastructure to automate attestation checks the same way: the policy-enforcement gate from earlier in this section is just one more automated check alongside the ones already running. A train relying on manual gates for deployment approval will tend to add attestation as another manual gate, which is where the ceremony-versus-flow tension explored in the next section actually originates. CALMR’s automation and recovery values aren’t optional context here; they’re the difference between a DoD criterion that lands smoothly and one that becomes the bottleneck the following section prices out explicitly.

The Cost of Proof: Where DoD 2.0 Pays and Where It Bloats

Attestation criteria carry a real ceremony cost, and pricing that cost honestly is what separates a DoD upgrade that protects flow from one that throttles it. The economics favor automation heavily over manual review, but only once the automation is actually built; and sequencing adoption by exposure, rather than rolling every criterion out everywhere at once, is what keeps the upgrade paying for itself instead of becoming the thing the train complains about at every retrospective.

Ceremony Bloat Outpacing Automation

The failure mode arrives when DoD criteria get added faster than tooling automates them: each new attestation requirement becomes a manual step someone has to remember, check, and document by hand, and the DoD that was supposed to prove quality becomes a compliance ceremony that throttles the flow the train exists to protect. This is the direct consequence of skipping the CALMR alignment covered at the end of the previous section.

Ceremony bloat is recognizable by a specific symptom: the DoD checklist grows longer every program increment, but done-to-deployed lead time grows with it rather than staying flat, because each new line item is a manual gate rather than an automated one. Academic study of large-scale SAFe implementations documents this exact tension directly; SAFe appears to be quite demanding and expensive in terms of human resource and project management practices, a criticism levied against the framework’s baseline ceremony load even before AI-specific attestation criteria are added on top (ACM study on SAFe adoption issues). Adding unautomated attestation criteria to a framework already carrying that reputation is the fastest way to confirm the criticism rather than answer it.

Front-Loaded Cost and Proof Economics

Attestation cost is front-loaded in platform tooling, building the SLSA-graded pipeline, wiring the in-toto evidence chain, standing up the policy-enforcement gate, and near-zero per increment once that tooling is automated, which is the inverse of manual review, a pattern that’s cheap to add and expensive forever after. Getting the sequencing backwards is the single most common economic mistake in DoD 2.0 rollouts.

Proof economics reward the train that pays the platform-engineering cost once and amortizes it across every subsequent increment, versus the train that adds a manual review step per story and pays that cost indefinitely, every single time a story touches an AI-generated artifact. Each manual check is small individually, a few minutes for a reviewer to eyeball an attestation record, but that cost compounds linearly with increment volume, while automated policy enforcement’s marginal cost per increment approaches zero once the gate is built. The train that understands this distinction invests in the platform build even when it feels slower in the first program increment, because the second and third increments are where the front-loaded investment starts paying back.

Marginal Cost After Automation

Once a policy-enforcement gate is live, checking one more artifact’s attestation costs the pipeline effectively nothing: a database or ledger lookup and a boolean comparison, executed in milliseconds as part of a build that was already running. This is the concrete meaning of “near-zero marginal cost.”

Contrast that against the manual alternative: a reviewer opening an attestation record, cross-referencing it against the required SLSA level, and documenting the check for audit purposes, repeated for every AI-touched story on every train, every sprint. The gap between those two costs only widens as an organization scales AI-containing work across more value streams, which is exactly why the front-loaded automation investment described above becomes more valuable, not less, the larger the portfolio grows.

Regulated Streams and Audit Exposure

Proof pays first in regulated value streams and any increment an external auditor will examine, where the cost of a missing attestation record is a compliance finding rather than an inconvenience; and it can wait in internal exploratory work, where a lighter criterion or none at all is the economically correct call. Sequencing adoption by exposure, rather than rolling the full criteria set out everywhere simultaneously, is what keeps the front-loaded cost from the previous section proportional to the actual risk it’s covering.

A financial-services core-banking program illustrates the exposure end of this spectrum directly: a domain-specific software development venture at a large financial group required corrective actions across three action-research cycles to fit a rigid, complex scaled-agile approach into a policy-heavy institution, precisely because regulated environments carry organizational constraints a lighter-touch adoption never encounters (Software Process: Improvement and Practice case study). A train serving that kind of environment cannot treat attestation as optional ceremony; the audit exposure makes the front-loaded automation cost worth paying immediately, before the first regulated increment ships rather than after the first finding.

Applied Sciences 2023 Automation Evidence

Process additions to scaled agile succeed when they ride existing automation rather than arriving as new ceremonies bolted on top of established practice: a pattern documented directly in research on AI-driven assistants within scaled agile software development. The core finding generalizes cleanly to attestation adoption: tooling that integrates with a train’s existing pipeline gets adopted; tooling that requires a separate manual workflow gets skipped or resented.

The incorporation of artificial intelligence into scaled agile development methods has emerged as a potential strategy in response to the ongoing demand for simplified procedures and the increasing complexity of software projects (Applied Sciences, 2023). The same logic that makes AI assistants valuable inside SAFe, reducing procedural overhead rather than adding to it, is the standard an attestation rollout should be held to: if the attestation tooling doesn’t reduce the manual burden a train already carries, it isn’t solving the problem DoD 2.0 exists to solve, regardless of how sound its cryptography is.

Two-PI Lead-Time Falsification Test

The adoption test is falsifiable and simple to apply: if done-to-deployed lead time rises for two consecutive program increments after an attestation criterion lands, that criterion is under-automated, and the correct response is to automate it further or stage it back rather than accept the new baseline. This test exists specifically to catch ceremony bloat before it becomes permanent policy.

Two program increments is long enough to separate a genuine adjustment period, teams learning a new gate, tooling settling into the pipeline, from a real structural regression that won’t self-correct without intervention. A lead-time increase that persists past that window is evidence, not anecdote, that the criterion is functioning as a manual gate rather than the automated check it was designed to be. Quality-gate maturity assessments exist precisely to catch this before it compounds across a portfolio: scoping which value streams need which depth of attestation, before the wrong criterion gets applied everywhere and the lead-time test starts failing across trains that never needed the heavier requirement in the first place.

Summary

The Adoption Decision Rule

The decision rule that governs which attestation criteria a SAFe train adopts, at what depth, and when, is not a single provable-not-asserted question: it is a three-part adoption test that keeps each criterion earning its place. First, map every proposed criterion to a specific SCAMM maturity target so the DoD grows with the organization rather than demanding level-5 rigour from a level-2 train. Second, confirm the automation commitment: a criterion is real only when a machine can check it, a provable criterion built on stable tooling outlasts an aspirational one built on a framework still in draft, and that means the policy statement and its enforcement point must be designed together, not written as separate concerns handled by different teams at different times. Third, apply the two-PI lead-time falsification test detailed below: if done-to-deployed lead time rises for two consecutive program increments after a criterion lands, that criterion is under-automated and must be staged back or automated further rather than accepted as the new baseline.

Portfolio leadership sets the SCAMM maturity target per value stream, not uniformly across the portfolio; platform engineering builds the automation that makes hitting that target a checkable fact rather than a quarterly status update. Where those two levels of ownership are cleanly separated, policy defined once, enforcement automated once, no per-story negotiation, the adoption decision rule holds without anyone having to enforce it by hand.

Where the Balance Breaks and How to Catch It

The distinction that separates disciplined DoD 2.0 adoption from ceremony bloat is not which criteria a train chooses: it’s whether each criterion arrives with its automation already built, or arrives as a manual step someone promises to automate later and never does.

That “later” is where the failure mode lives. A criterion added ahead of its automation is not wrong on the day it’s written; it becomes a problem only once lead time starts absorbing the manual cost, sprint after sprint, without anyone treating that drift as a signal. The two-PI falsification test exists to make that drift visible early rather than letting it become the accepted baseline a train stops questioning. Sequencing by exposure, regulated, auditor-visible work first; internal exploratory work last or never, keeps the front-loaded automation investment proportional to actual risk, so a train doesn’t pay platform-engineering cost for attestation depth no auditor will ever ask about. The organizations that get this right treat the DoD document as a living target tied to a measured maturity level, not a static list expanded every retrospective without a corresponding automation commitment attached to each new line. Quality leadership that reviews lead-time data alongside the DoD criteria, rather than reviewing the criteria in isolation, is the practice that keeps proof cheap instead of letting it quietly become the most expensive part of getting to done.