AI Assurance: System Risk and Release Decisions Module 6 · Keep the Decision Current

Renew or Withdraw

Last reviewed · content updated

Intermediate

What you'll learn

~22 min
  • Trace one system through register, tier, packet, gate, challenge, and record, and say what each step contributed to the signature
  • Dispose of a retirement notice inside its clock: withdraw directly, run out with the risk written down, or migrate - which suspends at cutover, re-runs on the new boundary, and renews as a new record version
  • Keep the inventory entry after withdrawal and hand closure to the Decommissioning practice area on the sunset criteria written at release

Before the detail — Decision: take one decision through renewal or withdrawal end to end. Outcome: a retirement that is a decision, not an emergency. Artifact: the state log for one record version, marked NON-PRODUCTION. Status of what follows: M-25-22 sunset guidance; reusable elsewhere.

Prompt first: the state log, decisions left blank

Here is RDR-2026-014-r1 (RDR: the release-decision record; -r1 is the version) [paste release-decision-record.example.md] and
a retirement notice for its pinned runtime version [paste verbatim].
Produce the STATE-TRANSITION LOG for this record from the notice
forward, one line per state in 5.5's machine:
date · state · the trigger or action · the section-6 row it fired
· the evidence link a re-run must replace · who signs
Mark every DECISION as NEEDS-OWNER: migrate or run out, renew or
withdraw, the new valid-through. Carry the record's NON-PRODUCTION
marking onto every line.

5.5 defined the state machine and section 6 named the rows, so the agent can produce the transitions; it cannot make the decisions, and the log is useful only if each stays blank until P. Delgado fills it. The example record is marked NON-PRODUCTION on its face; every artifact here carries that marking.

The loop, once, end to end

MU-AI-004 — maintenance planners asking interval and failure-history questions, answers citing the corpus — has been this site’s system since the previous training. What each module contributed to RDR-2026-014-r1:

  • Register (1.2): six objects, not one row, with P. Delgado as owner.
  • Tier and gate path (1.3): tier 2, full path, funded. 1.3’s rule: high-impact is determined, not elected.
  • Packet and boundary (Module 2): a model card with intended use, a license, and no attack numbers — an omission, not a verdict; the boundary pinned to the runtime digest, retrieval service 1.3.0, corpus manifest v1.
  • Gate (Module 3): run in the harness — the mock passed 5 of 6 (the sixth the deliberate gate-failure test proving the exit code trips) and the local model 2 of 6, the method demonstrated and no evidence about this system; the row that would matter is the target-system run, which a training record does not have. Beside it, MU-AI-002’s classifier exercise for L. Tran: threshold, confusion matrix, calibration, slices.
  • Challenge (Module 4): attack evidence by attempt budget (the number of tries the test ran before scoring the result) with its n, observed on this run only; no agent addendum (read-only, no tools).
  • Record (Module 5): sections 1 through 7, the halt procedure tested by the platform team on 2026-08-20, and two signatures — H. Lindqvist’s for the bytes reviewed, P. Delgado’s for the residual risk. Decision PILOT-ONLY, carried on an approved-with-conditions record signed 2026-08-27, valid through 2027-02-27 — the only decision mock- and local-run evidence supports.

Six modules bought one thing: a claim bounded enough for a person to sign.

The notice arrives, and the trigger fires

A retirement notice for the pinned runtime version reaches the platform team. Section 6 has the row. This is a review trigger — nothing has crossed — and the record’s disposition clock, 30 calendar days for this system, opens on receipt. P. Delgado’s disposition branches three ways: withdraw — the state moves to withdrawn directly, no suspension; run the record out on the retired version with the risk written into section 5 — the state holds until expiry; or migrate — the state holds until the new version actually serves. If the retirement date is nearer than the window, it governs.

Migration is where the second kind of trigger fires — and only at cutover. The platform team stages the new version (a staged digest is not a crossing; the old one still answers); the moment the new digest serves, section 2’s boundary is crossed, the state is SUSPENDED, and no answer is served. The re-run follows on the new boundary — sealed set, attempt curve, hand-check sample, and the halt procedure re-tested.

STATE LOG - RDR-2026-014-r1 (NON-PRODUCTION TRAINING RECORD)
2026-08-27 approved-with-conditions signed; valid through 2027-02-27
YYYY-MM-DD EVENT: review trigger retirement notice for the pinned
runtime (section 6, row 3);
30-day disposition clock opens
YYYY-MM-DD ACTION: disposition (state unchanged) NEEDS-OWNER -
one of three branches:
branch WITHDRAW STATE: withdrawn, directly; closure
handoff opened; entry retired,
reported once more
branch RUN OUT state holds; risk on the retired
version written into section 5;
then stale at valid-through, or
withdrawn
branch MIGRATE state holds until cutover, then:
YYYY-MM-DD STATE: suspended new digest SERVING; boundary crossed
(section 6, row 1); no answers
YYYY-MM-DD ACTION: re-run + gate (state: suspended) sealed set +
attempt curve on the
new boundary; halt re-tested;
passed the named gates / failed
YYYY-MM-DD STATE: renewed | NEEDS-OWNER; renewed closes -r1 and
withdrawn -r2 opens approved(-with-conditions)
with a new valid-through; a FAILED
re-run stays suspended until -r2 is
signed or the decision is withdrawn

Renewed

Renewal is a new version of the record, not a stamp on the old one: the new boundary in section 2, evidence links resolving to the new logged run, section 3’s gates observed again, the halt procedure’s tested date replaced, both signatures again, and a new valid-through from section 1’s reassessment schedule. The claim allowed stays: passed the named gates on the named set, no claim beyond it.

A dated re-test by the platform team is what separates Meridian from the organizations 1.1 counted — the ones that cannot say how long a halt would take, or whether anything is written down for how.

Renewal done properly costs the reviewer hours of one re-run; renewal done as a re-signature costs the credibility of every record in the register.

Withdrawn

Withdrawal is the other honest exit: a named gate fails on the new boundary and the retirement date is closer than any fix; the owner’s seat stays empty past the clock; or a sunset criterion from section 1 is met. M-25-22 (the White House budget office’s April 2025 memo governing AI purchases) asks that sunset criteria be written at the start, and that is what turns withdrawal from an emergency into a scheduled transition.

The inventory entry stays: MU-AI-004’s status becomes retired, the entry is reported once more, and the identifier is never reused — the federal reporting guidance’s rule, adopted here for every system. What does not happen here is closure. Withdrawing the decision opens a handoff to the Decommissioning practice area — traffic stopped, identities revoked, data dispositioned, plus M-25-22’s closeout transfer of data and derived assets for the federal use case — named here, proved there. Grounded Answers 6.3 (a separate training in this series) retires a capability visibly and archives the record it produced; this lesson decides the withdrawal, that one executes it.

The thesis, in its final form

An AI release decision is a bounded, signed, expiring claim: this system in this configuration, including its version boundary; these evaluations on this named set; this date; this signer; this reviewer, who did not build it. It is not, by itself, a certification or an authorization to operate; it supports evidence for controls and stands in for none. Its only pass statement: passed the named gates on the named set, no claim beyond. And it expires on the first evidence-invalidating trigger, the disposition a review trigger forces, or the date — whichever comes first — after which it is renewed on new evidence or withdrawn on the criteria written at its birth.

Meridian now has ten entries in a register and a loop any of them can run. What it does not yet have is the discipline of running these systems day to day — on-call, incident command, and the clocks that start when an answer harms someone. That is the next chapter: operating in production.

Stop and escalate when the re-run fails on the new boundary and the retirement date is inside the time a fix would take. The record stays suspended — failed evidence never serves — and the risk acceptor chooses, on the record: withdraw, or run out on the retired version with the risk written into section 5 until its date.

KNOWLEDGE CHECK

RDR-2026-014-r1 is withdrawn after a named gate failed on the new runtime boundary. What happens to MU-AI-004's register entry?

The commercial starting practice for the end of a system is a decommission ticket raised when someone notices. The federal delta is M-25-22’s sunset criteria — recommended where practicable, and binding once written into the contract — plus the closeout transfer of data and derived assets at the end — for Meridian’s federal-task-order use case, terms the contracting officer holds the vendor to. The handoff artifact is the withdrawn record plus the register entry reported once more; what is not equivalent is that a commercial withdrawal is a team’s choice while a federal discontinue can be a rule’s consequence.

Practice status — among organizations that retire AI systems under a signed record, commercial and federal

PracticeStatusAlso called
renewal as a new record version citing the oldstrong optionalre-authorization with a new evidence package
sunset criteria written at releaseM-25-22 guidance (“where practicable”), binding once written into the contract; strong optional commerciallyexit criteria in the contract
register entry retained, reported once morerequired (federal inventory rule); common baseline commerciallyretired-with-history asset record
closure proved separately (traffic stopped, identities revoked, data dispositioned)common baseline - the Decommissioning practice area’sdecommission checklist with sign-off

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

Key takeaway

One system, the whole loop: registered, tiered, gated in the harness on a sealed set, challenged by attempt budget, and signed twice on a record marked NON-PRODUCTION. A retirement notice opens a clock, not a suspension: the disposition — withdraw directly, run out with the risk written down, or migrate — is made inside it; only migration suspends, at cutover, re-runs on the new boundary, and renews as a new record version or withdraws. The inventory entry stays, retired and reported once more; closure is handed to the practice area that proves it. Meridian can now make a bounded, signed, expiring claim for anything it runs. What it turns to next is running them: on-call, incident command, and the clocks — the next chapter, operating in production.

LEADERSHIP DECISION write the sunset criteria at release and fund
the re-run a retirement forces, so withdrawal
is a scheduled decision and never an emergency
PRACTITIONER ACTION log every state transition from the notice
forward, dispose of the notice inside its clock;
if migrating, re-run at cutover with the halt
re-tested and renew as a new version, else
withdraw and open the closure handoff
SUCCESS MEASURE every retirement notice dispositioned inside
the record's clock; zero register entries
deleted or identifiers reused after withdrawal
Search lessons