Work with me

Framework · Ethotechnics

Before an AI system may influence care

Name the decision it may inform, the person responsible for it, and the route for challenging and correcting it.

I wrote this framework for the institution deciding whether to approve a system. A team building one can use the same list to reach that review with the answers already written down. It exists for the failure modes documented in Research: decisions made under depleted attention, systems where a wait works as a denial, and harms that are fast to cause and slow to undo.

Stages of approval

  1. State 0 Not approved

    Can’t affect care or workflow. Needs a specific use and a named owner.
  2. State 1 Observed

    Runs silently or on past cases, to see how it fails compared with current practice.
  3. State 2 Limited use

    A person reviews each recommendation, in one narrow workflow.
  4. State 3 Routine use

    In regular use. People can still challenge results, and reviews run on a schedule.

Worked example

A model recommends a treatment change. At every state, the approval is a dated record that can be superseded.

State 0

Not approved

To leave this stage
Has the institution approved a bounded use case, an accountable owner, and an evaluation plan?
Who acts
Named deployment and escalation owners

The proposed use cannot yet influence care or workflow because the institution hasn’t decided what it’s for, named who owns it, or defined the evidence needed before anyone may rely on it.

Evidence required

  • Defined clinical or operational decision
  • Named owners for the rollout and for escalations
  • Who it applies to, and who it doesn’t
  • A written list of assumptions, with a plan to test them
State 1

Observed

To leave this stage
Does how it performed, and how it failed, justify a limited live trial?

The system runs without affecting care or workflow. It saves its outputs so you can test whether they’re relevant, how it fails, and whether the proposed checks hold up in real use.

Evidence required

  • A silent run, or a run on past cases
  • A list of error types, and a review of exceptions
  • A comparison with current practice
State 2

Limited use

To leave this stage
Does it work well enough inside its stated scope, and can the institution pause, correct, or roll it back?
Who acts
A person reviews each recommendation

The system may inform one narrow workflow for a limited group of people, with a person reviewing it, someone watching for exceptions, and stop conditions set in advance.

Evidence required

  • A live test in the workflow
  • Written routes for overriding it and for escalating
  • Tracking of safety, equity, and operations
State 3

Routine use

To leave this stage
Has a change to the model, data, users or evidence reopened review, or has the approval expired?
Who acts
Independent review, and people can still challenge results

The institution lets people use it routinely within a defined scope, while keeping independent review, the right to challenge a result, checks for anything that has changed, and a review on a fixed schedule.

Evidence required

  • Steady performance in live use
  • Independent review, sized to the risk, that can assess cases without relying on the tool’s recommendation
  • Ready to correct it or roll it back

A new safety signal reopens the approval from whichever state it had reached, and triage decides whether to suspend it while the review runs. The clinical safety lead opens the review and makes the decision. The review follows the six steps below.

Checklist

Use this before limited use, and keep the review route open afterward.

The four tests assume a view of progress in which capability and influence grow together.

1 · Four tests a system must pass

01 Explainable
The people relying on a system must be able to see why it’s approved: what it’s for, the evidence, the assumptions, its known limits, and who owns it.
02 Challengeable
A clinician, operator, patient advocate, or reviewer must be able to challenge a result, or how people are using the system, through a set route, without needing to know someone.
03 Correctable
When evidence, policy, performance, or operating conditions change, the institution must be able to review the system, make a new decision, and carry the correction to every workflow it affects.
04 Refusable
People must be able to decline or withdraw without penalty or permission from the buyer or operator. Before approval, name who will provide care if a patient declines the tool and how the patient can reach them. The institution must staff that route and cover the work it adds. Record when someone declines.

2 · The approval record

Eight lines a reviewer should be able to read off one record before a system enters State 2 (Limited use), the first state in which it can affect care. If you can’t answer a line, it goes no further than State 1 (Observed), however well the model performs. Observing needs less: the decision, the population, the owners, and a plan for testing the assumptions.

  1. 01 The decision or workflow it supports
  2. 02 Who may use it, on whom, where, and who it leaves out
  3. 03 Current model, prompt, policy, data, and integration versions
  4. 04 Evidence and assumptions that justify using it
  5. 05 Known limitations and required human checks
  6. 06 Named owners for the rollout, clinical use, and escalations
  7. 07 Start date, review date, and the approval it replaces
  8. 08 Stop conditions and rollback route

3 · When the facts change

Before approving, name who owns each review step and how its result reaches the people affected.

  1. 01 Detect Change signal
  2. 02 Connect Map of everything that depends on it
  3. 03 Triage Review priority and interim controls
  4. 04 Review Case for review
  5. 05 Decide Recorded decision
  6. 06 Propagate Corrections to everything that relied on it
Return to Detect for the next change. Select a step for details.
01 Detect — Change signal
Notice a change that could matter — in the evidence, the model’s behavior, policy, the data, the workflow, the people it affects, or the outcomes you’re watching.
02 Connect — Map of everything that depends on it
Trace which of the approval’s assumptions, which people, which workflows, and which later decisions the change could affect.
03 Triage — Review priority and interim controls
Judge how much it matters, how urgent it is, whether it can be undone, how many people it reaches, and whether the system can keep running while the review happens.
04 Review — Case for review
Put five things in front of whoever may decide: the change, traced to its source; the original reasoning; how the system has performed; any objections; and what is still unknown.
05 Decide — Recorded decision
Make the decision and write it down: keep, caveat, narrow, expand, monitor, escalate, suspend, or retire.
06 Propagate — Corrections to everything that relied on it
Update the approval record, and every workflow, instruction, screen, monitoring rule, and person that relied on the old decision.

4 · What the purchase contract must carry

The contract should let you keep checking the system after you’ve paid the vendor.

  1. 01 A screen that stops a task names the person who owns it and the clock it must move on — a status that only says “pending” is a defect, not an answer.
  2. 02 Every output that changes a record links to its source, so correcting that source can find everything that relied on it.
  3. 03 Log the workaround a nurse or clerk builds to route around the product as a product failure, and count it the way you count an outage.
  4. 04 The system has to prove itself on the buyer’s own messy data, not on a demo prepared for the sale.

5 · How deep correction reaches

Most reviews should change a decision and leave the rule alone; reopening the rule every time would make it unusable. When the same error keeps coming back, the path has to be able to reach the rule, the governing arrangement, the membership, and the material conditions.

Shallow corrigibility Decisions can be challenged. The deeper structure stays fixed. Recursive corrigibility Every level can be contested and revised. Decisions Rules Governance Membership Material conditions correction path stops here Decisions Rules Governance Membership Material conditions correction path reaches every level Shallow corrigibility Decisions can be challenged. The deeper structure stays fixed. Decisions Rules Governance Membership Material conditions Recursive corrigibility Every level can be contested and revised. Decisions Rules Governance Membership Material conditions
A system can look corrigible while protecting the structure that decides what correction can mean. On the left, a decision can be appealed but the rule, the governing arrangement, the membership, and the material conditions are sealed. On the right, the correction path reaches every level, including the institution’s own necessity.

Full standards

Ethotechnics publishes proposed standards, each numbered and versioned, with control crosswalks aligned to NIST AI RMF, ISO/IEC 42001, and the EU AI Act.

The shared record format is the Revisable Delegation Record, paired with a conformance checker that verifies record structure, provenance schemas, and state transitions across the decision lifecycle.

Revised