What I work through to decide whether an automated decision is ready to be relied on — or
what still needs systems work before it is. Nothing here is proprietary: it is the
operating model stated as questions.
Take it, print it, put it in your own review template. If you want the reasoning behind a
particular line, or a second pair of eyes on a live deployment,
email me — but the checklist itself
is not the thing you have to ask for.
1 · Three tests
If a deployment fails any of these, the answer is not a better model. Every later section is
a way of making one of these three true.
ExplainableThe people relying on a deployment can inspect the basis for its current authorization: intended use, evidence, assumptions, known limits, and accountable owner.
ChallengeableA clinician, operator, patient advocate, or reviewer can contest a result or deployment condition through a defined route that does not depend on informal access or personal discretion.
CorrectableWhen evidence, policy, performance, or operating conditions change, the institution can reconsider the deployment, issue a disposition, and propagate the correction to affected workflows.
2 · The authorization record
Eight things a reviewer should be able to read off one record. If any line is unanswerable,
the deployment is at State 0 regardless of how well the model performs.
The decision or workflow being supported
Authorized users, population, setting, and exclusions
Current model, prompt, policy, data, and integration versions
Evidence and assumptions supporting reliance
Known limitations and required human checks
Named deployment, clinical, and escalation owners
Effective date, review date, and superseded authorization
Stop conditions and rollback route
3 · Evidence the current state requires
Find the state the deployment is actually in, then check the evidence that state requires.
Authority does not advance because the last state went well; it advances when the exit
condition is met.
State 0 Not authorized
Defined clinical or operational decision
Named deployment and escalation owners
Specified affected population and exclusions
Exit A bounded use case, accountable owner, and evaluation plan are approved.
State 1 Observed
Silent or retrospective evaluation
Error taxonomy and exception review
Baseline comparison against current practice
Exit Observed performance and failure modes justify a limited prospective deployment.
State 2 Constrained use
Prospective workflow validation
Documented override and escalation paths
Monitored safety, equity, and operational indicators
Exit The deployment performs acceptably inside its stated scope and the institution can pause, correct, or roll it back.
State 3 Routine reliance
Stable prospective performance
Independent evaluation appropriate to the use
Operational readiness for correction and rollback
Exit Authorization remains conditional: material change reopens review rather than silently inheriting prior approval.
4 · When the facts change
The part most reviews never specify. Before authorizing, confirm each of these has a named
owner and a route — not that someone would probably notice.
Detect — Change signal Identify a potentially material change in evidence, model behavior, policy, data, workflow, population, or observed outcomes.
Connect — Affected reliance map Map the change to the specific authorization assumptions, populations, workflows, and downstream decisions that may be affected.
Triage — Review priority and interim controls Assess materiality, urgency, reversibility, exposure, and whether continued operation is acceptable while review proceeds.
Review — Reconsideration case Present the source-traced change, prior rationale, observed performance, dissent, and unresolved uncertainty to the authorized reviewers.
Decide — Authorized disposition Issue an explicit disposition: preserve, caveat, narrow, expand, monitor, escalate, suspend, or retire.
Propagate — Corrected operating state Update the authorization record and each connected workflow, instruction, interface, monitoring rule, and affected stakeholder.
The checklist is a way of asking one question in eleven places: when this is wrong, who finds
out, who can stop it, and what reaches the people who already relied on it?