One page

Decision-readiness checklist

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.

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.

  1. Explainable The people relying on a deployment can inspect the basis for its current authorization: intended use, evidence, assumptions, known limits, and accountable owner.
  2. Challengeable A 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.
  3. Correctable When evidence, policy, performance, or operating conditions change, the institution can reconsider the deployment, issue a disposition, and propagate the correction to affected workflows.

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.

  1. The decision or workflow being supported
  2. Authorized users, population, setting, and exclusions
  3. Current model, prompt, policy, data, and integration versions
  4. Evidence and assumptions supporting reliance
  5. Known limitations and required human checks
  6. Named deployment, clinical, and escalation owners
  7. Effective date, review date, and superseded authorization
  8. Stop conditions and rollback route

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

  1. Defined clinical or operational decision
  2. Named deployment and escalation owners
  3. Specified affected population and exclusions

Exit A bounded use case, accountable owner, and evaluation plan are approved.

State 1 Observed

  1. Silent or retrospective evaluation
  2. Error taxonomy and exception review
  3. Baseline comparison against current practice

Exit Observed performance and failure modes justify a limited prospective deployment.

State 2 Constrained use

  1. Prospective workflow validation
  2. Documented override and escalation paths
  3. 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

  1. Stable prospective performance
  2. Independent evaluation appropriate to the use
  3. Operational readiness for correction and rollback

Exit Authorization remains conditional: material change reopens review rather than silently inheriting prior approval.

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.

  1. Detect — Change signal Identify a potentially material change in evidence, model behavior, policy, data, workflow, population, or observed outcomes.
  2. Connect — Affected reliance map Map the change to the specific authorization assumptions, populations, workflows, and downstream decisions that may be affected.
  3. Triage — Review priority and interim controls Assess materiality, urgency, reversibility, exposure, and whether continued operation is acceptable while review proceeds.
  4. Review — Reconsideration case Present the source-traced change, prior rationale, observed performance, dissent, and unresolved uncertainty to the authorized reviewers.
  5. Decide — Authorized disposition Issue an explicit disposition: preserve, caveat, narrow, expand, monitor, escalate, suspend, or retire.
  6. 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?

The full operating model →