DoWI 8430.01: what evidence should accompany AI-generated code?

01 / Definition, applicability and distinctions

Define the candidate and the decision before judging the package

An evidence package should let another person connect an identified software subject to its claims, original observations, review findings and unresolved decisions.

DoWI 8430.01, Accelerated Mission Software, directly addresses DoW Components and covers acquisition and non-acquisition software programs within its stated scope. A contractor should identify the applicable solicitation, contract, deliverables and adopted program requirements. The instruction does not by itself establish that every existing contract contains a universal new clause. §1.1, p.4; §3.3.d(1), p.16

Record the requested decision precisely: code integration, a release recommendation, contractual acceptance, safety approval, fielding or authorization to operate. Identify the responsible authority from the governing basis. A test result, package seal or completed review is an input to that decision; it does not confer the authority to make it. The instruction places evidence within risk management and assessment, with a separate exception process. §3.5.f–g, pp.20–21; §3.10, p.29

Keep three determinations separate

• Actual AI use is established: inspect the applicable generation or testing records. An unavailable model version remains a missing fact; it does not erase the known use.
• A record is not supplied: write NOT_PROVIDED and identify what it prevents you from concluding.
• Historical use is not established: write NOT_ESTABLISHED, describe the records examined and assign the inquiry. Absence of a receipt proves neither no AI use nor an AI-policy violation without the actual use and applicability basis.

AI-assisted development also differs from a delivered AI-enabled capability. Using an assistant to write code does not alone establish that the deployed software contains an AI capability. Runtime AI has additional evaluation and monitoring considerations under §3.6.e, p.24.

Inspect evidence beyond functional tests

The instruction states, “AI-generated code will be considered unverified input,” and keeps developers and the government responsible for the result. §3.6.a(2), p.23

For DoW proprietary software development, services must meet the specified AI cybersecurity requirements and be expressly authorized through formal DoW processes. Inspect contractual guarantees protecting government data and prompts against sharing or use in training public or DoW-external models, together with auditing and monitoring by designated authorities. §3.6.d, p.24

Keep sensitive originals within program-approved boundaries. Section 3.5.e(2) addresses controlled technical information for software and associated artifacts with specific military or space applications; it does not classify every SBOM identically. §3.5.e(2), p.20

02 / The free usable worksheet

Copy the complete human handoff record

Copy this record for one candidate. Start with the governing requirements, candidate identity and supplied records you can inspect. Mark missing material explicitly.

Use UNKNOWN for an unresolved determination and NOT_PROVIDED for an absent record. Separate archived observation, fresh observation, proposed work and unperformed check. A suggested role is not an assigned person. Repeat the evidence and gap entries as needed.

Copy CHANGE / RELEASE EVIDENCE HANDOFF
Purpose: give a human reviewer a bounded account of one candidate.
This is an editorial worksheet, not a government schema or AI prompt.

1. GOVERNING BASIS, CANDIDATE AND DECISION
Handoff identifier:
Prepared by / role / date:
Program / contract / governing documents and exact revisions:
Applicability determination, including lifecycle/BA transition if relevant:
Person responsible for confirming that applicability:
Decision requested:
Actual decision authority / source of that authority:
Repository or source location / change identifier:
Candidate source commit and tree / comparison baseline:
Delivered build or artifact identifier and digest:
Build environment, dependencies, configuration and relevant inputs:
Change purpose in ordinary language:
Current inspection disposition and reason:

2. INFORMATION BOUNDARY AND PREREQUISITES
Audience / markings / handling and retention basis:
Approved location of original evidence / permitted access:
Applicable evidence-format or CKS/program reference and verified edition:
AI service/environment residence, approval and authorization references:
Permitted inputs / contractual data and prompt protections:
Designated-authority auditing and monitoring references:
Tools, access, fixtures and environment needed to inspect or reproduce:
Constraints that prevent inspection or reproduction:
For nonpublic DoW input to generative AI, verify BOTH residence on DoW
information systems and the required approval (section 3.6.b). Inspect
applicable proprietary-development authorization, contractual safeguards
and authority auditing/monitoring (section 3.6.d). Keep nonpublic originals
within their approved boundary; do not submit them to an unapproved service.

3. CLAIM, DOMAIN, ORACLE AND IMPLEMENTATION
Requirement ID / exact behavior / source revision:
Owner and reason this requirement is authoritative:
Existing promises to preserve / authorized intentional behavior changes:
Input domain, units, preconditions and relevant failure conditions:
Expected reply AND stored or external effects:
Independent basis for those expected results (the test oracle):
Implementation entry point / relevant call path and configuration:
Harness/test revision and what it actually observes:
Source -> requirement -> test -> result links, including missing joins:

4. AI USED TO GENERATE OR TEST SOFTWARE
Actual use determination: ESTABLISHED / NOT_ESTABLISHED / UNKNOWN
Basis, records examined, time/change coverage and limitations:
Actual in-scope generating/testing use and governing basis:
For EACH established use, record:
  Activity: generation or testing; affected code, script, test or artifact:
  Actual provider / model identifier as exposed:
  Actual version / fact unavailable:
  Significant dataset identifiers and versions / significance and limits:
  Service approval / allowed input / protection references:
  Original record location and connection to this candidate:
Do not infer no historical use from absent receipts. Preserve known use
when its supporting records are incomplete. Do not invent model versions,
hidden training datasets or a full-transcript requirement.

5. EXECUTION, FAILURE, CORRECTION AND FRESHNESS
Evidence status: archived / fresh observation / proposed / unperformed
Actual executed command(s), working directory and settings:
Tool versions / runtime / platform / dependencies:
Execution time and original report location:
Observed reply AND stored/external effects:
Counting unit, selected cases, pass/fail results and unperformed checks:
Failure and consequence for the stated promise:
Correction revision / what changed / disposition of existing bad state:
Actual retest or replay evidence / remaining unperformed work:
Optional reproduction command, prerequisites and expected output:
Inputs to compare before reuse: requirement, source, build, configuration,
  oracle/harness, tools, dependencies, environment and relevant AI records.
Changed basis / stale records / required refresh and owner:

6. OTHER EVIDENCE LAYERS
For EACH layer below, record:
  Applicable basis and exact candidate subject:
  Original record location / observed result and scope:
  Missing, stale or unresolved matter:
  Actual owner / next check / required decision:
For actual in-scope AI use, include AI-suggested/generated code, scripts
and automated tests in the same or similar rigorous code review and
security testing. Review logic, safety, vulnerabilities, IP, licenses
and security controls before integration.
Layers:
  a. System SBOM, transitive components and applicable approved format.
  b. Build provenance/pedigree, trusted-builder basis and verification.
  c. Security analysis/testing, vulnerabilities and finding dispositions.
  d. Functionality, logic and safety review/testing.
  e. IP, license and security-control review before integration.
  f. Security/safety-critical functionality determination and rationale.
  g. Human review and approval where required for AI-generated changes
     to security- or safety-critical functionality.
  h. Applicable independent/government T&E and other program evidence.
  i. Evidence handling, residual risks and actual decision records.

7. GAP / OWNER / NEXT DECISION (repeat for every material gap)
Missing fact, record or check:
Status and evidence supporting that status:
Consequence / affected promise / proposed containment:
Specific next action and evidence it should produce:
Suggested owner role, if helpful:
Actual accountable person: UNASSIGNED until confirmed
Due date or review trigger agreed by that person:
Decision needed / actual deciding authority:
Decision reference, conditions and follow-up, if one exists:

8. REVIEW AND HANDOFF
Reviewer identity / review scope / date / actual findings:
What the supplied evidence supports:
What it does not establish:
Current disposition and unresolved risks:
Actual decision / authority / authentic decision reference:
Conditions, expiry or next review trigger:
Next action / accountable person:

A filled field, test pass, content hash, review receipt or package seal
alone grants no merge, release, deployment, fielding, safety, ATO/cATO
or contractual acceptance authority. Record the actual decision.

The free sample ZIP includes complete blank and filled handoffs, an evidence index, a gap/owner register, identity records and the unchanged original archive. The formats and filenames are editorial choices. No government material is needed to use them.

03 / Worked failure, correction status and reproducibility

Inspect a restored booking change without overstating the result

The candidate is a local teaching restoration of a booking component. The review question is whether the supplied records support the restored retry behavior and what still prevents a complete program handoff. No real DoW program or contract is identified in this example.

The rule comes first: retrying the same booking key at any supplied elapsed time from zero up to, but not including, 24 hours must return the original reservation and create no second reservation. The fixture author supplied this promise as SW-REQ-241, revision 1. It is teaching intent, not an approved customer or program requirement.

The original configuration, revision A, retains keys for 24 hours. Revision B reduces retention to 12 hours. At 12 and 23 hours, the component no longer finds an unexpired key and creates another reservation. Revision C restores 24-hour retention. The archived checks then observe the promised behavior again at those times.

Exhibit: each retry is checked against both the reply and stored state

Each row below is a separate case with a fresh in-memory database. The first reservation is created at injected hour zero. “Original” means its identifier; “new” means a different identifier. The reports retain identifier equality, not the numeric identifiers themselves.

Exactly 24 hours is outside the before-24-hour promise. That row documents the example's expiry convention, not a violation or an extension of the promised interval. A and C each pass five of five selected cases; B passes three and fails two. These are finite functional observations from one local process. They do not establish concurrency, restart durability, replica behavior or production-clock correctness.

Follow the implementation actually exercised

verify.py reads the configuration and fixed expected results from cases.json. For each case it creates a ReservationStore, calls reserve("client-key-1", 0), calls it again at the selected elapsed hour, then checks both count() and whether the returned identifier stayed the same.

In reservation.py, ReservationStore.reserve reuses a key only when its stored expiry is strictly greater than the supplied current hour. Otherwise it inserts a reservation and stores a new expiry using the configured retention. This explains why reducing retention alone changes the result. The expected counts and identifier comparisons are fixed independently of that setting. There is no HTTP or authentication layer in this exercised path. The original files and diffs are in the sample download.

The original Proof JSON packages preserve a separate conclusion: A and C have readiness not_assessed; B is blocked; all three have empty evidenceRecords arrays. Detailed behavior remains available in companion JSON and JUnit reports. The new index helps a person locate those records; it does not populate the missing native requirement links.

Filled handoff: the restored candidate and the unfinished work

The following record stands alone. Paths inside the original archive are relative to its retained-obligation/ directory.

Copy CHANGE / RELEASE EVIDENCE HANDOFF: BOOKING-RETRY-INSPECTION
Scope: inspection of archived public local teaching evidence.
Candidate: restored booking-key configuration; no real program basis supplied.
A client retries the same booking key. Before 24 elapsed hours, the
component must return the original reservation and create no second one.
Shortening retention to 12 hours produced duplicate reservations on
retries at 12 and 23 hours. Restoring 24-hour retention repaired those
selected cases; other handoff layers remain unresolved.
Result: selected duplicate-booking failures are observed; the selected
restoration passes; the handoff is INCOMPLETE FOR A REAL PROGRAM DECISION.

1. GOVERNING BASIS, CANDIDATE AND DECISION
Actual program/contract basis and approved requirement: NOT_PROVIDED.
Applicability and actual decision authority: UNKNOWN.
Prepared-by identity and actual program reviewer: NOT_PROVIDED.
Candidate: revision C, restoring booking-key retention to 24 hours.
C source commit: 08721dd7cda04dc5a52519d2c18ae5e8f45f0c26
C source tree: a8343572ff8961a87a2b543696720b5780379ff2
Comparison baseline B: 1cec89a6e69f7633e73a77e3dda945c332460f81
Original A: 33e282532163634bb0137fc66fa6fa3fab00c8fe
Source archive: originals/retained-obligation.zip in the sample download.
Delivered application build/artifact and digest: NOT_PROVIDED.
A and C have the same source tree but different commits.
Only config.json changes in the retained A-to-B and B-to-C diffs.
The runner compares a declared file list, not all possible dependencies.
Requested inspection: determine supported behavior and outstanding layers.
No actual integration, release, safety or authorization decision supplied.

2. INFORMATION BOUNDARY AND PREREQUISITES
Sample: public teaching material. Real-program markings, audience,
retention and approved evidence location: UNKNOWN.
Program/CKS evidence standard and verified edition: NOT_PROVIDED.
AI service residence, authorization, permitted input, contractual
  data/prompt protections and authority audit/monitoring references:
  NOT_PROVIDED.
Read-only inspection: unzip the sample, then separately unzip
  originals/retained-obligation.zip; use evidence-index.csv or .json.
Optional replay: Python 3 and Git; work from the extracted
  retained-obligation/ directory; use a new, empty output directory.
The runner creates a disposable local Git repository and executes the
  public fixture. It does not contact a real booking service.
No Proof binary is bundled. Its historical build instructions are in
  the original README. No new replay is reported in this inspection.

3. CLAIM, DOMAIN, ORACLE AND IMPLEMENTATION
Requirement: SW-REQ-241, revision 1, requirement.json.
Authoritative real-program validating owner: NOT_PROVIDED.
Teaching rule: same-key retry at 0 <= elapsed_hours < 24 returns the
  original reservation and leaves exactly one stored reservation.
Selected domain: retries at 0, 1, 12, 23 and 24 supplied elapsed hours.
Each case starts a fresh in-memory SQLite database and books at hour 0.
Exactly 24 hours is outside the promise; the example expects expiry,
  two stored reservations and a different returned identifier then.
Oracle: literal expected_count and expected_same_id in cases.json,
  fixed independently of retention configuration.
Call path: verify.py -> ReservationStore(config["retention_hours"])
  -> reserve("client-key-1", 0) -> reserve at the case's retry hour
  -> count() and comparison of the two returned identifiers.
Implementation: reservation.py; an existing key is reused only while
  expires > now_hours. Otherwise a reservation is inserted and the key
  expiry becomes now_hours + retention_hours.
Harness: verify.py; configuration: snapshots/A.json, snapshots/B.json,
  snapshots/C.json.
Source/claim/test/result connection: requirement.json, cases.json,
  implementation, harness, diffs and companion reports are retained.
Native requirement joins: missing; evidenceRecords is [] in A, B and C.

4. AI USED TO GENERATE OR TEST SOFTWARE
Actual historical AI use and model identities: NOT_ESTABLISHED.
Basis: supplied source and execution records include no recorded
  AI-generation/testing event establishing that history.
This does not establish human-only/non-AI authorship or a controlled
  AI-generation experiment. Editorial AI assistance is a separate matter.
Model/version/significant-dataset records for generation or testing:
  NOT_PROVIDED.
Actual in-scope AI use, program basis and environment approval: UNKNOWN.
Missing AI records alone are not a finding of a section 3.6 violation.
If actual in-scope use is established, obtain the applicable records;
  preserve unavailable facts rather than inventing versions or datasets.

5. EXECUTION, FAILURE, CORRECTION AND FRESHNESS
Status: ARCHIVED OBSERVATIONS from 3 October 2026.
Environment: Python 3.14.7; Darwin/arm64; in-memory SQLite;
  injected elapsed-hour clock. No SQLite version is supplied here.
Historical Proof: 0.1.0-teaching-b845ff313bac
Historical Proof source: b845ff313bacb887c4e9fb78145c681a15f6b3f0
C configured-check report time: 2026-10-03T09:32:07.304816+00:00
Git dates in the fixture are synthetic, not execution timestamps.

Actual direct command, inside each prepared snapshot with config.json:
python3 verify.py --config config.json --output .evidence/verification.json --junit .evidence/tests.xml

Actual historical Proof command:
proof audit --check tests_pass --no-cache --format json

The configuration explicitly sets tests_pass affected mode to full.
Only tests_pass ran. --no-cache alone does not guarantee a nonempty
  affected-test plan. The runner removes direct outputs before Proof's
  configured command produces its own reports.
Subsequent package assembly reads persisted runs; it does not rerun tests.

Observed selected cases: A 5/5 pass; B 3/5 pass, 2 fail; C 5/5 pass.
Direct verification exit / selected Proof-check exit:
  A 0/0; B 1/1; C 0/0.
Failure: B retains keys for 12 hours. Retries at 12 and 23 hours leave
  two reservations and return a different identifier, violating the
  before-24-hour promise of one reservation and the original identifier.
Correction: C restores 24-hour retention. Those cases return the original
  identifier and leave one reservation; the same five cases pass.
Existing duplicate-data repair: NOT_DEMONSTRATED. Cases use fresh stores.
Broader domain, concurrent/replica/restart/payload-conflict behavior and
  production-clock checks: UNPERFORMED in this supplied campaign.
Reports: results/{A,B,C}/audit-verification.json and
  results/{A,B,C}/tests.xml.
Direct reports: results/{A,B,C}/verification.json.
Native packages: results/{A,B,C}/package.stdout.json.
Native readiness: A not_assessed; B blocked; C not_assessed.
C persisted run: results/C/proof-run.json.
Summary/diffs/source history: results/summary.json, results/A-to-B.diff,
  results/B-to-C.diff and results/fixture.bundle.

Optional reader replay, PROPOSED / NOT PERFORMED here:
python3 run.py --output /tmp/retained-replay
Expected archived pattern for comparison: A passes, B fails, C passes.
The wrapper expects direct exits 0, 1, 0 and writes reports and a bundle.
It removes its temporary checkout. Save new output separately.

Optional replay with an available Proof binary, also UNPERFORMED here:
python3 run.py --output /tmp/retained-proof-replay --proof /absolute/path/to/proof
Supply an actual executable path. A different build or environment
  produces new evidence; it is not validation of the archived engine.

Stale-evidence triggers: changes to requirement, source/configuration,
  delivered build, oracle/harness, tools/runtime, dependencies/environment,
  AI-use or authorization basis, handling rules or decision authority.
Applicability of these reports to any later candidate: UNKNOWN.

6. OTHER EVIDENCE LAYERS
System SBOM/transitive components/approved format: NOT_PROVIDED.
Trusted-build provenance, pedigree and trust verification: NOT_PROVIDED.
Security campaign and vulnerability dispositions: NOT_PROVIDED.
Logic/safety/IP/license/control review before integration: NOT_PROVIDED.
Applicable same or similar code review/security testing of AI-suggested
  or generated code, scripts and automated tests: scope UNKNOWN;
  supporting records NOT_PROVIDED. No AI-specific violation is inferred.
Security/safety-criticality determination: UNKNOWN.
Any required critical-function human review and approval: NOT_PROVIDED.
Independent/government T&E and other program-specific evidence:
  applicability UNKNOWN; supporting records NOT_PROVIDED.
Broader coverage, compatibility and change effects: unmeasured or
  unavailable as recorded in the native package.
Residual-risk acceptance, real reviewer and release/fielding/ATO/cATO
  decision: NOT_PROVIDED.
The editorial evidence index does not repair native trace gaps.

7. GAP / OWNER / NEXT DECISION
Actual accountable assignees and accepted assignments: NOT_PROVIDED.
Roles below are proposals, not confirmed assignments.
All actual deadlines and decision references: NOT_PROVIDED.
Proposed review trigger: resolve or route each applicable gap before
  treating the handoff as sufficient for the requested program decision.

Governing basis, evidence standard, handling and authority:
  Suggested role: program/release lead.
  Next action: identify applicable documents, allowed evidence location
  and actual decision authority; retain the applicability determination.
AI history, generation/testing records and approved environment:
  Suggested roles: development lead and AI service owner.
  Next action: establish actual use and scope; obtain applicable model,
  version, significant-dataset and service/handling records.
Delivered subject, SBOM and trusted-build evidence:
  Suggested role: build/release owner.
  Next action: bind the real artifact to its inventory and provenance;
  record trust verification and coverage limits.
Review, security findings, criticality and any required human approval:
  Suggested roles: code reviewer, security lead and safety lead as needed.
  Next action: determine applicable review scope and obtain original
  pre-integration reviews, testing and finding dispositions.
Missing trace links and broader behavior:
  Suggested role: verification lead.
  Next action: explain the actual claim/test/result connection and select
  justified additional checks. Preserve the archived native packages.
Freshness for a later candidate:
  Suggested role: release evidence owner.
  Next action: compare relevant inputs and decide what must be refreshed.
Residual risk and final decision:
  Suggested role: program assurance lead to route the request.
  Next action: obtain the actual authority's decision, conditions and
  follow-up. No risk acceptance or exception is supplied.

8. REVIEW AND HANDOFF
Supported: selected original failure and restored behavior in the
  archived local setup, with exact source and report locations.
Not established: complete program evidence, historical AI provenance,
  delivered-system correctness, compliance, certification or approval.
Disposition: INCOMPLETE FOR A REAL PROGRAM DECISION.
Actual human reviewer, accountable program owner and decision: NOT_PROVIDED.
Next action: assign real owners to the gaps and obtain applicable evidence.

Inspect or reproduce the evidence: follow the sample package index to the original failure and restoration reports. For optional reproduction, use the prerequisites in the filled record. The archive root has no ready config.json; the runner prepares each snapshot. Retain any new replay separately.

04 / Ordered practical procedure

Inspect the package in decision order

1. Fix the governing basis and subject. Record program/contract revisions, applicability, candidate source and delivered artifact, comparison baseline and requested decision. Resolve a missing candidate identity before attributing reports to it.
2. Confirm access and handling. Establish where originals may be inspected, who may see them and which evidence standard applies. Check the actual AI environment authorization before using it with program information.
3. Inventory original records by claim. For each report, identify its producer, subject, command or review scope, environment, time, observed result and limits. A link to a test definition is not an execution record.
4. Read failures and corrections together. Check the applicable requirement and expected result, the original failure, the correction identity and actual retest. Ask separately whether existing bad state needs repair. If the intended behavior or oracle is unresolved, use the deeper AI4SDLC one-change method.
5. Inspect AI and other assurance layers. Preserve known generating/testing use even when details are unavailable. Apply the review, criticality, security, SBOM, build, handling and program-specific evidence requirements identified in the governing basis.
6. Assess reuse and assign the gaps. Compare relevant inputs before carrying evidence forward. Give each unsupported claim a concrete next check, actual owner and review trigger. A proposed check remains unperformed until its result exists.
7. Route the decision. Give the responsible authority a bounded supported conclusion, material gaps, residual risks and proposed next actions. Retain the actual decision and its conditions separately from the package's technical status.

05 / Checklist

Check whether the handoff is reviewable

• Governing program/contract basis, applicability owner and requested decision are identified.
• Source, delivered artifact, configuration and report subjects agree, or discrepancies are open gaps.
• Each important claim has a valid expected result and original observations of relevant replies and effects.
• Selected scope, failures, correction status and unperformed checks are visible.
• AI generation and testing use are distinguished from unavailable records and unknown history.
• Applicable AI approval, input-handling and model/version/significant-dataset records are inspectable or explicitly missing.
• Review, security, SBOM, build and applicable independent evidence layers have findings or named gaps.
• Criticality and any required human approval are supported by actual records.
• Freshness has been assessed for this candidate, with triggers for another review.
• Every material gap has an actual owner or remains visibly unassigned; the actual authority's decision is separate.

06 / Mistakes

Repair the inference that caused the gap

07 / Proof workflow and limits

Use Proof to connect supported records, then inspect what is actually present

Proof can connect supported requirement, test and reported-result records and assemble sealed JSON evidence from persisted runs. Assembly does not execute verification, validate an oracle or supply missing evidence.

The native-package walkthrough shows that distinction concretely: detailed selected behavior exists in companion reports while native requirement evidence is empty and passing readiness remains not_assessed. Those observations belong to the identified historical teaching build. They do not validate the current product.

Use the worksheet with or without Proof. It does not assume automatic AI lineage, authenticated generation records, SBOM generation, DoW-approved hosting or universal package completeness. Keep original review and authority records alongside any supported software evidence; neither a sealed package nor an accepted software record grants release or authorization authority.

08 / Tool, method and workflow choices

Choose the method that closes the actual gap

Other suppliers offer useful approaches. Anchore's explanation describes SBOM and supply-chain workflows and explicitly retains separate testing, provenance-generation and authorizing-official responsibilities. Fusion Cyber's guide offers a downloadable alignment CSV. These are useful starting points for their stated tasks; compare the original outputs and scope with your candidate's needs.

NIST's SSDF also supports protecting release archives and maintaining component provenance. Its implementation examples are not individually mandatory, and the cited v1.1 is final while v1.2 is listed as a draft. Use these as engineering references alongside the actual program basis. PS.3.1–3.2; implementation-example scope; publication status.

10 / Two useful extra examples

Apply the worksheet to different evidence gaps

Example 1: AI generated the tests, but its version is unavailable

Illustrative decision, unperformed. A program establishes that an assistant generated automated tests for a change. The supplied service record exposes a model name but no immutable version.

Record the established use to generate tests, the affected tests and the available model identifier. Mark the version unavailable and assign its resolution or disposition. Inspect the tests' expected results and applicable review/security-testing evidence; do not relabel this as unknown AI use simply because a receipt is incomplete. The review must address both generated automated tests, §3.6.c, and AI used for generation or testing, §3.6.f. Any acceptance of the remaining gap belongs to the actual program authority.

Example 2: the source commit matches, but the delivered build changed

Illustrative decision, unperformed. A release reuses a source commit and its passing report, but changes a dependency or build image.

Treat the new artifact as a distinct delivered subject. Ask the build owner for the corresponding inventory and provenance, then assess which behavioral and security results remain applicable and which need refreshing. A matching source commit cannot by itself establish that the changed artifact has the same composition or behavior. Preserve the old result's scope and route the remaining checks through the build-evidence basis in §3.5.c.

12 / Related guides

Go deeper where your inspection finds a gap

• AI4SDLC: requirements and testing: develop one change's intent, independent expected results and implementation evidence when those foundations are unresolved.
• Software verification plan: specify the verification work, environment, responsibilities and completion criteria before execution.
• Software verification report: turn actual results, deviations and unresolved findings into a bounded verification conclusion.
• Requirements traceability matrix: inspect the links from requirements to tests and results without treating a populated table as execution.
• When verification evidence goes stale: decide what changed and which existing records still apply.