Framework
Before any team relies on an algorithmic decision — a clinical recommendation, a content moderation call, a model output — I apply three questions. The same questions recur wherever model output becomes an operational decision.
A guideline changes. A drug is recalled. An allergy gets updated. The people who rely on the old decision often never hear about it — and the systems that automated the decision keep running.
Every consequential AI decision should be explainable, challengeable, and correctable. Authority increases only as evidence, monitoring, and correction capacity mature.
Evaluation, review, escalation, and correction systems — including frozen evidence states, dispute records, dependency tracking, hold/rollback tools, and audit trails.
A person — clinician, compliance officer, or patient — can see what the system considered and what it recommended. Not a full model explanation; enough to understand the basis for action.
The recommendation can be overridden, escalated, or sent back for review without halting care or creating a compliance incident.
When the evidence, policy, or model changes, the decision can be updated and the record corrected. Someone owns that correction.
U.S. healthcare has spent 15 years moving decisions into software. My work is about making sure responsibility moves with them.
The framework can be used alongside NIST AI RMF, the EU AI Act's requirements for high-risk systems, and existing compliance programs — but it starts with the people who have to trust or challenge the recommendation in practice.
Ethotechnics is the product method behind this framework — making AI decisions explainable, challengeable, and correctable in production, with explicit ownership, escalation, and correction paths.
Operating model
Deploying AI is not a one-time review. It is an operating system for deciding when a system may influence decisions, what conditions limit that authority, how people can challenge it, and what happens when evidence or behavior changes.
Authorization states
The proposed use cannot yet influence care or workflow because the institution has not bounded the decision, named the accountable owners, or defined the evidence needed for reliance.
Transition condition: A bounded use case, accountable owner, and evaluation plan are approved.
The system operates without influencing care or workflow. Outputs are captured to test relevance, failure modes, and whether the proposed controls fit real operating conditions.
Transition condition: Observed performance and failure modes justify a limited prospective deployment.
The system may inform a narrow workflow under explicit human review, limited population scope, active exception monitoring, and predefined stop conditions.
Transition condition: The deployment performs acceptably inside its stated scope and the institution can pause, correct, or roll it back.
The institution permits routine reliance within a defined scope while preserving independent review, challenge rights, change detection, and periodic reconsideration.
Transition condition: Authorization remains conditional: material change reopens review rather than silently inheriting prior approval.
Reconsideration loop
Identify a potentially material change in evidence, model behavior, policy, data, workflow, population, or observed outcomes.
Output · Change signalMap the change to the specific authorization assumptions, populations, workflows, and downstream decisions that may be affected.
Output · Affected reliance mapAssess materiality, urgency, reversibility, exposure, and whether continued operation is acceptable while review proceeds.
Output · Review priority and interim controlsPresent the source-traced change, prior rationale, observed performance, dissent, and unresolved uncertainty to the authorized reviewers.
Output · Reconsideration caseIssue an explicit disposition: preserve, caveat, narrow, expand, monitor, escalate, suspend, or retire.
Output · Authorized dispositionUpdate the authorization record and each connected workflow, instruction, interface, monitoring rule, and affected stakeholder.
Output · Corrected operating stateEscalation matrix
| Trigger | Default action | Decision owner | Required record |
|---|---|---|---|
| Immediate patient-safety signal or prohibited use | Suspend affected use; preserve records; initiate urgent review | Clinical safety owner | Incident, scope, interim control, and restart authority |
| Material performance degradation or distribution shift | Constrain scope or return to observed mode | Deployment owner with clinical sign-off | Metric change, affected population, and evaluation plan |
| New evidence changes benefit, risk, or required qualification | Open a reconsideration case; assess continued reliance | Evidence or policy owner | Source change, affected scope, rationale, and disposition |
| Repeated overrides, complaints, or workflow workarounds | Investigate usability, fit, incentives, and hidden failure modes | Product and operations owner | Pattern analysis, user accounts, and corrective action |
| Model, prompt, data, vendor, or integration change | Reassess inherited authorization before release | Change approver | Version change, test evidence, and authorization linkage |
Independent validation
A sample of cases receives independent review rather than automatically accepting the system-supported path.
Reviewers compare outcomes, overrides, delays, and subgroup effects against current practice where the deployment permits a valid comparison.
Independent review continues after initial approval so gradual drift and workflow adaptation can remain visible.
Material discrepancies trigger reconsideration; they are not absorbed as routine monitoring noise.
Implementation boundary
The practical objective is bounded institutional reliance: the system may move work faster inside an authorized scope, while human authority, challenge rights, and correction obligations remain explicit.
Vocabulary for reasoning about AI deployment, institutional decision-making, and the boundary between human judgment and automated systems.
A condition that automatically reopens evaluation of a previously approved decision. Instead of relying on someone to remember to check, the system fires when evidence shifts, time elapses, or context changes.
A record of who depended on a decision, when, and under what assumptions. When the underlying evidence changes, reliance memory tells you which downstream decisions are now stale.
The discipline of keeping decisions current after they are made. Most organizations treat decisions as events. Decision maintenance treats them as ongoing obligations.
A map of which conclusions depend on which sources. When a trial is retracted, a guideline updated, or a safety signal issued, the graph shows exactly which downstream positions are affected.
Ethics is real only when it exists as a hard constraint on what actions remain available. Not defined by what a system claims to value, but by the profitable actions it has rendered impossible.
The extraction of unpaid diligence from conscientious employees to bridge the gap between resource allocation and safety requirements. A system that depends on heroism to function safely is under-designed.
When a system manages scarcity not by saying no, but by waiting for the applicant to give up. The delay itself is the denial.
Modern institutions have automated the power to suspect, but not the power to exonerate. A fraud filter freezes an account in milliseconds; exoneration takes weeks of manual appeal.
The degree to which a person can absorb or reverse a wrong decision before their life comes apart. In high-speed administrative systems, this is the real class divide.
A temporary drop in mental bandwidth caused by stress, fatigue, or distraction. Interfaces designed for an idealized hero user break when the actual user is operating at a fraction of capacity.
A one-page checklist I use to assess whether an AI/system decision is ready to rely on — or what still needs systems work.
Request the checklist →