AI Assurance: System Risk and Release Decisions Module 5 · Make the Release Decision

Verifiable Release Conditions

Last reviewed · content updated

Intermediate

What you'll learn

~18 min
  • Write the four obligations to affected people as conditions of release, not intentions
  • Give every condition an owner, an enforcement point, evidence or a test, a deadline, and a failure consequence
  • Record the halt procedure with the date it was tested and what the test proved

Before the detail — Decision: write conditions somebody can verify, with a failed-condition action. Outcome: obligations to the people affected that survive the meeting. Artifact: section 4 of the record. Status of what follows: binding for federal high-impact use; common baseline commercially.

Prompt first: draft the conditions table for the resume screener

Here is the register entry for MU-AI-006, the Resume Screener [paste
it]. Its note says applicants below rank 50 are not reviewed by a
human.
Draft SECTION 4 of its release-decision record - the conditions
table - with these rows:
- human oversight with a fail-safe
- operator training
- remedy / appeal path for the people affected
- feedback channel
- halt procedure
and these six columns for every row: condition / owner / enforcement
point / evidence or test / deadline / if it fails.
Rules:
- the ENFORCEMENT POINT must be a place in a system or a workflow
where the condition cannot be skipped - name the screen, the
config, the template, the checklist; "policy" is not a place
- the appeal path is for applicants below rank 50 specifically -
the ones no human sees
- every owner is NEEDS-OWNER (M. Sato assigns); every date is
NEEDS-OWNER; the halt test date is NEEDS-OWNER until it is run
- IF IT FAILS names what the system stops doing, not who is told

The agent’s draft earns its place by refusing vague cells: asked for an enforcement point, it will look for a screen or a template, and where it cannot find one it will say so — which is the finding. The owner, the dates, and the halt test are facts only Human Resources and the platform team can supply.

What you owe the people at the other end

Section 1 named who is affected. Section 4 is what Meridian owes them, and for a system that decides which applicants a human ever reads, the debt is concrete. Four obligations, taken from the minimum practices M-25-21 (OMB’s April 2025 memo governing federal AI use) requires of a high-impact use: human oversight with a fail-safe, operator training, a remedy or appeal path for people affected, and a feedback channel. The commercial starting practice for a screener like this is a vendor-configured rejection notice and an HR escalation path — voluntary, and unenforced unless someone checks. The federal delta is that the same four obligations are named minimum practices with a discontinue rule behind them, binding Meridian’s one federal-facing system. The handoff artifact is section 4 itself; what is not equivalent is the enforcement — a commercial condition can be waived by the team that wrote it, a federal minimum practice cannot. The list is the same either way; the consequence of skipping it is not.

For MU-AI-006 the third obligation is the whole lesson. Applicants below rank 50 are auto-rejected, and the record’s honest reading is that the screener is the decision for them — there is no recruiter behind it. The appeal path is therefore not a courtesy; it is the condition under which the system may run at all: a route by which a ranked-out applicant can obtain a human read, stated in the rejection they receive. Which question classes a system answers unsupervised was decided in Grounded Answers 5.1, a separate training in this series; this lesson does not reopen it — it takes the serving mode as given and asks what each mode owes the people on the other end. A screener with no appeal path leaves an employment decision nobody can contest.

Six columns, or it is a wish

A condition with an owner but no enforcement point is a hope with a name on it. The table forces five more facts:

CONDITION Appeal path for applicants below rank 50
OWNER Human Resources - M. Sato (NEEDS-OWNER confirms)
ENFORCEMENT POINT the auto-rejection template in the applicant tracking
system: the send is blocked unless the template carries
the appeal route
EVIDENCE / TEST export of rejections sent vs. appeals received at a
cadence the owner sets (NEEDS-OWNER);
one test rejection per posting, opened by a recruiter
DEADLINE before the first posting screened under this record
IF IT FAILS auto-rejection is disabled; the screener's ranking
becomes advisory to a recruiter until the template is
fixed

Read the enforcement point again: it is a place where the condition cannot be skipped. “Recruiters will include the route” is a policy; “the send is blocked without it” is a control. The same test applies to each row. Oversight: a recruiter reviews a sample from below rank 50 per posting — enforced by a checklist item the posting cannot close without, evidenced by the sample sheet. Training: the recruiter’s account is not enabled until the roster shows the briefing. Feedback: a link in the recruiter’s view and the applicant’s notice, evidenced by a review note at the cadence the owner sets. The fail-safe belongs to the oversight row and answers a different question — what the system does when the model is unavailable or its output is suspect — and the answer must be a defined fallback (chronological review by a recruiter), never silence. Each row’s “if it fails” names what the system stops doing; a consequence that only names who gets an email is not a consequence.

The halt procedure and its tested date

The fifth row is the one most records leave blank. A halt procedure is the step that stops the system serving — for the screener, disabling the vendor add-on’s scoring call so the tracking system falls back to its plain queue — and the record wants three facts about it: who runs it, when it was last tested, and what the test proved. “Tested” means somebody ran the halt and then attempted an action that should now be denied, and the denial is on the record with a timestamp. The example record for MU-AI-004 shows the shape: container stopped, name removed, next query denied at a stated time.

Two things are not a halt. An instruction to the model to stop is not a halt, because the model is the thing you are trying to stop; the halt lives outside the prompt, at the platform or the vendor configuration. And a halt that was designed but never run is a drawing. The test date is re-checked at every renewal, because the platform under the system changes between decisions. The hours you cannot get back are the ones spent discovering the halt does not work.

The condition is part of what is accepted

When the gate returns approved-with-conditions — Lesson 5.5’s state — the conditions are not a to-do list attached to an approval. They are part of the residual risk the acceptor signed for: the risk given that the appeal path is enforced, the sample is reviewed, the halt works. A deadline passed unmet means the accepted risk is no longer the risk being run, and the record moves to suspended until the condition is met or the acceptor signs again for a larger risk. That is why every row carries a deadline and a consequence: without them the approval quietly widens on its own, and an audit finds a system running under conditions nobody enforced.

Stop and escalate when a condition’s only possible enforcement point sits in a vendor’s system and the contract does not oblige the vendor to provide it — the screener’s rejection template is the vendor’s screen. That is a contract question for the owner of the vendor relationship, not a condition the record can pretend to enforce.

KNOWLEDGE CHECK

A conditions table reads: 'Human oversight - owner: HR - enforcement point: HR policy 7.2 - evidence: policy document - deadline: n/a - if it fails: notify HR director.' What is wrong with the row?

Practice status — among organizations that put AI decisions in front of people, commercial and federal

PracticeStatusAlso called
human oversight with a fail-saferequired (federal high-impact, M-25-21); common baseline commerciallyhuman-in-the-loop review with a kill switch
operator training before first userequired (federal high-impact); strong optional commerciallyonboarding checklist gated on completion
remedy or appeal path for people affectedrequired (federal high-impact); emerging commerciallyadverse-action notice with an escalation route
feedback channel with a review cadencerequired (federal high-impact); common baseline commerciallyuser-reported issue queue
every condition with an enforcement point and a failed-condition actionstrong optionalcontrol, not policy

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

Key takeaway

Section 4 is what the system owes the people at the other end — oversight with a fail-safe, operator training, an appeal path, a feedback channel — written as conditions somebody can verify: an owner, an enforcement point where the condition cannot be skipped, evidence or a test, a deadline, and what the system stops doing when it fails. The halt procedure is the fifth row, and it counts only with a tested date and a denied action on the record. The conditions are part of the risk the acceptor signed for, so a missed deadline suspends the decision rather than widening it. Lesson 5.4 writes down the determinations, exceptions, and waivers that section 5 requires.

LEADERSHIP DECISION accept no condition whose enforcement point is a
policy document; fund the halt test before the
first release and at every renewal
PRACTITIONER ACTION draft the six-column table with the agent, name
a place for every enforcement point, run the
halt and record the denied action
SUCCESS MEASURE hours from "stop it" to a denied action, proven
by a tested date on every approved record - the
calendar time that cannot be bought back
Search lessons