Verifiable Release Conditions
Last reviewed · content updated
IntermediateWhat 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 [pasteit]. Its note says applicants below rank 50 are not reviewed by ahuman.
Draft SECTION 4 of its release-decision record - the conditionstable - with these rows: - human oversight with a fail-safe - operator training - remedy / appeal path for the people affected - feedback channel - halt procedureand these six columns for every row: condition / owner / enforcementpoint / 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 toldThe 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 50OWNER 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 routeEVIDENCE / TEST export of rejections sent vs. appeals received at a cadence the owner sets (NEEDS-OWNER); one test rejection per posting, opened by a recruiterDEADLINE before the first posting screened under this recordIF IT FAILS auto-rejection is disabled; the screener's ranking becomes advisory to a recruiter until the template is fixedRead 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.
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
| Practice | Status | Also called |
|---|---|---|
| human oversight with a fail-safe | required (federal high-impact, M-25-21); common baseline commercially | human-in-the-loop review with a kill switch |
| operator training before first use | required (federal high-impact); strong optional commercially | onboarding checklist gated on completion |
| remedy or appeal path for people affected | required (federal high-impact); emerging commercially | adverse-action notice with an escalation route |
| feedback channel with a review cadence | required (federal high-impact); common baseline commercially | user-reported issue queue |
| every condition with an enforcement point and a failed-condition action | strong optional | control, 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 renewalPRACTITIONER ACTION draft the six-column table with the agent, name a place for every enforcement point, run the halt and record the denied actionSUCCESS 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