The Release Decision

Before the detail — Artifact: the record header with roles named. Status of what follows: binding where M-25-21 applies; reusable guidance elsewhere.

Prompt first: draft the header for MU-AI-004

Here is one register entry [paste the MU-AI-004 objects from
Lesson 1.2's YAML], its tier determination [paste Lesson 1.3's
record for MU-AI-004], and who built and bought it [from the
register's owner and provider fields; if absent, UNKNOWN -
NEEDS-OWNER]. Also here: the record template
[paste scripts/t7-substrate/data/release-decision-record.template.md].

Draft ONLY the header table of a release decision record:
  - fill use case, system id and name, deployment, tier, and gate
    path from the register, tagging each SOURCE: register
  - version boundary: write exactly what the register knows; if it
    holds a model family and no immutable version, write
    "alias, not pinned" and NEEDS-OWNER
  - lifecycle state: draft; decision, decision date, valid through:
    NEEDS-OWNER
  - risk acceptor, independent reviewer, release owner: NEEDS-OWNER,
    plus one line each on who the register DISQUALIFIES from the
    reviewer role (anyone who built it or bought it)
  - where this record lands: NEEDS-OWNER, both options named

Do NOT propose names for the roles, a date, or a decision. The
header is a scope statement; the decision comes at the end of
Module 5.

The header is the part of the record that can be written on day one, and the reason to write it on day one is the roles. An agent asked to fill in a reviewer will pick a plausible senior name; the register says who is disqualified, and that is the only thing it is allowed to say. Everything else — the version, the date, the decision — is a fact somebody will earn later.

The bridge: you already sign expiring authorizations

If you work in a federal environment you have signed, or watched someone sign, an ATO (the formal authorization for a system to operate), and the rule from Federal Delivery 1.1 (a separate training in this series) is already yours: authorization is a signed, expiring decision. If you work commercially, a change-approval record with an approver and a review date is the same shape. Neither is new.

What is new is that behavior moves without a code change. A provider moves the alias your deployment points at; a suite feature updates on the vendor’s schedule; a classifier is retrained on a quarter’s data. Your authorization described a system whose behavior is now different, and nothing in the change pipeline fired, because nothing in your repository changed. So the decision must name the version boundary it was made against and expire on its own, without waiting for a change request that will never come.

The thesis

An AI release decision is a bounded, signed, time-limited authorization claim about a named use case and deployable system configuration — including the model or service version boundary — supported by dated evidence, independent review, declared conditions, and a named risk acceptor. It is not, by itself, a certification or an ATO.

Each word does work. Bounded: one use case, one configuration, the version boundary included — not “the chatbot.” Signed: a named person who accepts the residual risk, not a committee. Time-limited: a valid-through date that holds regardless of whether any trigger fires. Dated evidence: runs that can be reopened. Independent review: findings recorded by someone who did not build or buy it. Declared conditions: what must remain true. And the negative is the most important clause: the record supports evidence for an authorization and for existing controls; it does not replace either. This is assurance (the evidence-backed decision that a system may run), stated so it can be checked.

Six corollaries follow, and each names a place where a claim quietly overreaches:

SIX COROLLARIES   where a release claim quietly overreaches
1  you cannot assure what you cannot list
2  consequence and reversibility decide the gates, not the vendor's
   confidence
3  the customer controls the test design and the sealed data;
   vendor-run results are declared as such and reproducible where
   practicable
4  a single-attempt attack number is insufficient when retries are
   plausible - report by attempt budget
5  a name alone does not prove an immutable version
6  a fired trigger starts a clock, and an unanswered clock expires
   the decision

The only honest pass statement is: “passed the named gates on the named set; no claim beyond it.” Each corollary is the exact sentence an assessor writes when the claim exceeded the evidence.

Roles assigned before testing

Three roles, assigned before any test runs. The risk acceptor signs — the person whose function absorbs the loss if the system is wrong, senior enough that the signature is theirs to give. The independent reviewer records findings and was not involved in building the system — M-25-21’s bar is “an independent reviewer within the agency who has not been involved in the development”; this training adds “or buying it,” a stricter house rule, because the person who chose the vendor has a stake in the verdict. The release owner runs the gates and assembles the record. For MU-AI-004, P. Delgado built it, so he can be the release owner and cannot be the reviewer; the risk acceptor sits above Asset Management.

Before testing, because a reviewer chosen after the results is chosen for the results. The sponsor who picks the reviewer once the evaluation looks good has already decided, and the record will read as if the decision were reviewed.

Naming the roles first costs a single agenda item; naming them after costs the credibility of every signature that follows.

The seam: where the record lands

Declare the frame first. Meridian operates one specified AI use case on behalf of a covered agency, and the contract expressly incorporates the applicable federal requirements — the contracting officer wrote M-25-22’s terms (OMB’s April 2025 memo on buying AI; OMB being the White House budget office that binds agencies) into the task order. The agency determines applicability, and AI risk acceptance is separate from an ATO. The European Union’s AI law does not reach a US utility serving US customers, and this training does not teach it.

The commercial starting practice is an approval record in a governance platform or an internal register — a signer, an approval date, a review-due date. The federal delta is that M-25-21 (OMB’s April 2025 memo on agency AI use) names the practices the record must evidence for high-impact use — an impact assessment, an independent reviewer, a signed risk acceptance — with a documented-by date that has passed.

The ISSO (the system’s security officer) needs the record where an assessor reads, not in a separate tool. The handoff artifact is the record itself, filed as an appendix to the system’s SSP (the system security plan — the package an assessor reads).

Where a condition is still open and it amounts to a control deficiency, a linked POA&M item (the tracked list of open weaknesses with dates) points at the record; the record itself is evidence, not a weakness.

What is not equivalent is the honest negative. No NIST AI control overlay is published — COSAiS (NIST’s planned AI overlays for its security-control catalog) is a concept paper and an outline — so the record supports evidence for existing controls rather than mapping to AI-specific ones. And the record is not an ATO, and an ATO is not an AI risk acceptance; a system can hold one and lack the other.

The record, by its sections

The template at scripts/t7-substrate/data/release-decision-record.template.md opens with the header table you drafted above, then runs: impact, baseline, and benefit; evidence reviewed, every link resolving to a logged run; gate results as separate gates, never a blended score; conditions of release, each verifiable, including a halt procedure with a tested date; determinations, exceptions, and waivers; the triggers that suspend or expire the decision; and two signatures that mean different things — artifact integrity says these are the bytes reviewed, risk acceptance says the residual risk is accepted. Every field stays; “n/a - reason” replaces deletion.

Stop and escalate when the proposed independent reviewer built or bought the system, or when nobody with the authority to accept residual risk will sign — the acceptor’s test is authority, the reviewer’s is independence. A system with no signer gets no record and does not ship, and finding a signer is a decision for the governance board, not for the release owner.

Practice status — among organizations that put AI systems into production under a named approver, commercial and federal

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

Key takeaway

A release decision is a bounded, signed, time-limited claim about one named use case and one deployable configuration, version boundary included, supported by dated evidence, independent review, and declared conditions, with a named risk acceptor — and not, by itself, a certification or an ATO. Six corollaries mark where claims overreach, and the only honest pass statement is “passed the named gates on the named set.” The three roles are assigned before testing so the reviewer is not chosen for the results, and the record lands where the assessor already reads, supporting evidence for existing controls because no AI overlay yet exists. Module 2 turns to the evidence packet: what the model and its provider say about themselves, read from the risk acceptor’s seat.

LEADERSHIP DECISION   name the risk acceptor and the independent
                      reviewer for every high-impact system before
                      its first test - and accept that a system with
                      no signer does not ship
PRACTITIONER ACTION   draft the record header from the register with
                      the agent; leave the version, date, decision,
                      and names NEEDS-OWNER; file the record where
                      the assessor already reads
SUCCESS MEASURE       zero approved AI systems whose record lacks a
                      named acceptor, a version boundary, and a
                      valid-through date - the finding avoided at
                      the first assessment