The Release-Decision Record

Before the detail — Artifact: the record, accepted when every link resolves and both signatures are present. Status of what follows: binding where M-25-21 applies; supports evidence for ISO/IEC 42001 elsewhere.

Prompt first: assemble the record shell

Here is the release-decision record TEMPLATE and the worked EXAMPLE
for RDR-2026-014 [paste both], plus the register entry for MU-AI-004
[paste it].

Build the record SHELL for MU-AI-004 from the template - every header
field, every section 1 through 7, every evidence row. Then:
  - copy the evidence artifact paths from the example; leave every
    sha256 as NEEDS-OWNER - I compute hashes, you do not
  - leave the Level column (mock / local run / target system) as
    NEEDS-OWNER on every row
  - leave the risk acceptor, reviewer, and both signature rows blank
  - mark the record NON-PRODUCTION in the banner unless every RUN
    row's Level reads "target system" (n/a and missing rows are
    not runs)
  - write "n/a - reason" on rows that do not apply; delete nothing
Draft section 1 from the register entry with every figure NEEDS-OWNER.

The agent is good at the shell — it will not skip a row, and it will not quietly delete the agent-addendum line because the system has no tools. What it must never supply is a hash, a level, or a name: the hash is a fact about bytes you hold, the level is a fact about which run produced them, and the names are the people who will answer for the record.

Sections 1 to 7, walked

The header block carries fourteen fields, and every one is walked here because a reviewer reads them first: the record id; the use case; the system id and name; the deployment; the version boundary (the immutable model or service version you could pin, or the alias you could not and what that means); the AI consequence tier from Lesson 1.3 and the gate path it selected; the lifecycle state; the decision and its date; a fixed valid-through date; the risk acceptor who signs; the independent reviewer who records findings; and where the record lands. Then the sections, in the order this module teaches them:

1  Impact, baseline, benefit     Lesson 5.1 - why, against what, at what cost
2  Evidence reviewed             every row: path + hash + LEVEL + result + reviewer
3  Gate results                  separate gates, thresholds set by the release
                                 owner; claim = "passed the named gates on the
                                 named set; no claim beyond it"
4  Conditions of release         Lesson 5.3 - each with owner, enforcement
                                 point, evidence, deadline, what happens on
                                 failure; halt procedure with its tested date
5  Determinations, exceptions,   Lesson 5.4 - the four documents, and what
   waivers                       of this becomes public
6  Triggers                      Lesson 6.1 - what suspends, what opens a clock
7  Signatures                    two rows, two meanings

One record per use case per decision. A row that does not apply reads “n/a - reason”; nothing is deleted, because a deleted row and a forgotten row look identical to an assessor. The example for MU-AI-004 shows the finished shape, and it carries a banner saying it is a non-production training record — the banner is part of the artifact, not decoration.

Every link resolves, and the level column

Section 2 is a table of claims, and each claim is a path plus a hash. The rule is simple: a link that does not resolve is a missing evidence row. If results/eval.junit.xml at the recorded hash cannot be opened from the evidence store — the append-only store the Federal Delivery training defends (3.2 of a separate training in this series: the evidence store you defend) — then the record has no evaluation evidence, whatever the prose says. The reviewer’s first act is to open every link; a row that opens to nothing is recorded as absent, not as “pending.”

The level column says which run produced the bytes: mock (the deterministic stand-in that proves the wiring), local run (a local model that proves the method), or target system (the deployed configuration behind its pinned version boundary). Module 3 introduced the three; here they decide something. Rows that are not runs — the evidence packet, an addendum — read n/a in the level column, and a bill of materials describing the deployed weights is target system evidence about lineage, not about behavior. Only the third supports a production decision, because only the third exercised the system that will answer real requests. A record whose eval row reads “mock + local run” — as RDR-2026-014’s does — is a complete, honest record of a rehearsal, and it says so on its face. A link that resolves at the wrong level is a subtler failure than one that does not resolve: a production claim resting on a rehearsal is a claim you cannot defend when the customer-facing system does something the local run never did.

Two signatures that mean different things

Section 7 has two rows, and they are not two people agreeing. Artifact integrity says: this record and the evidence its links resolve to are the bytes I reviewed — a hash over the record and its linked artifacts, signed by the independent reviewer, H. Lindqvist for MU-AI-004. Risk acceptance says: the residual risk described in sections 1 through 6 is accepted for the valid-through period — signed by the person who owns that risk, P. Delgado. The first is a statement about bytes; the second is a statement about consequences. Swap them and you have a builder attesting to their own work and a reviewer accepting a risk they do not own.

Independence is the load-bearing word in the reviewer’s row. M-25-21 (OMB’s April 2025 memo governing federal AI use — OMB being the White House budget office that binds agencies) requires “an independent reviewer within the agency who has not been involved in the development”; the banking regulators’ SR 26-2 (April 2026) replaced “independent” with “sufficient independence” and dropped the annual-validation cadence — a looser standard, and one that explicitly leaves generative systems out of scope, which is why this training does not borrow it as a floor. The reviewer’s independence is what makes the integrity signature worth anything; without it the record is self-certification.

Where the record lands for an assessor

Commercial readers keep the record in the internal AI register, linked from the system’s entry; it supports evidence for ISO/IEC 42001 Annex A control A.6.2.4 (verification and validation) and clause A.5 (impact assessment).

Federal readers need it somewhere an assessor already looks: as an appendix to the SSP (the system’s security plan, the assessor’s map) or as a POA&M item (the tracked list of open weaknesses and fix dates) when a condition is still open. That is the handoff artifact — the same record, filed where the package is read.

Now the honest negative. No NIST AI control overlay is published — COSAiS (NIST’s planned AI overlays for its control catalog) is a concept paper and one annotated outline as of January 2026 — and FedRAMP’s 2026 rules (the federal cloud-authorization program’s current criteria) contain no AI-specific indicators.

So the record does not map to AI controls, because there are none to map to; it supports evidence for the existing controls the ISSO (the officer who answers for the system’s controls) already answers for — testing, configuration management, risk assessment — and says so. Two clarifications keep the seam honest. The AI consequence tier is not a FIPS impact level (the federal low/moderate/high rating of a system); the record carries both without confusing them. And whether crossing a version boundary is a “significant change” to an authorization is a question the corpus does not settle. The defensible position, stated as a position: treat it as one, tell the ISSO before the change rather than after, and let the authorizing side rule — because the Federal Delivery training’s first lesson (1.1: authorization is a signed decision) is the reason the ruling is theirs. Not equivalent: the commercial register is never read by an authorizing official, and a record that lands only there has been filed, not delivered.

Stop and escalate when no reviewer with sufficient independence exists — when everyone who could sign the integrity row helped build or buy the system. The record cannot be assembled around a signature that means nothing; naming a reviewer from outside the build is the release owner’s call to make before any more evidence is gathered.

Practice status — among organizations that gate AI releases, commercial and federal

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

The record is seven sections in a fixed order, and its section 2 is a table of claims where every claim is a path and a hash that open to the logged run — a link that does not resolve is a missing row, and a link that resolves at the mock or local level is a rehearsal, not a production decision. Two signatures close it, one about bytes by an independent reviewer and one about residual risk by its owner. For an assessor it lands as an SSP appendix or a POA&M item and supports evidence for existing controls, because no AI overlay yet exists to name. Lesson 5.3 fills section 4, the conditions somebody can verify.

LEADERSHIP DECISION   fund an independent reviewer per record and an
                      evidence store the links can resolve to; accept
                      no production decision on mock or local evidence
PRACTITIONER ACTION   build the shell with the agent, compute every
                      hash yourself, open every link before the gate,
                      and file the record where the assessor looks
SUCCESS MEASURE       zero records at the gate with an unresolved link
                      or a production claim above its evidence level -
                      the self-certification finding avoided