Ethotechnics
An open framework for making consequential AI claims verifiable and correctable — evidence, authorization, challenge, reconsideration, correction, and escalation treated as explicit system states, not policy documents around the system.
Every consequential AI system makes claims. This drug is safe. This guideline is current. This patient should be prioritized. This recommendation is within my authority.
A claim is verifiable when you can see what backs it, challenge it through a path that exists, and correct it when the evidence moves. What each of those requires is the three tests at the bottom of this page.
Most AI governance work starts with the operating model — who approves what, under what conditions, for how long. That work matters, but it's downstream of the real question: how do you know what you know, and what happens when you're wrong?
NextConsensus freezes each forecast before the outcome is known and scores it against the public record. Refract runs the change-detection bot in production. The toolchain I build with is instrumented on the same terms.
The operating model below is also implemented, in a different domain. Ambit applies the same shape to agent infrastructure: authorization held apart from capability, changes that carry their own inverse, verification before a capability is trusted, and a computable blast radius. Standards that have never been built are difficult to argue with and easy to ignore.
Ethotechnics publishes as numbered standards rather than principles, so each one can be cited, versioned, and argued with. Two are published; five more are drafted and not yet released. All of them are mapped against NIST AI RMF, ISO/IEC 42001, and the EU AI Act.
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 versioned evidence, dispute records, dependency tracking, and rollback tools.
Eight things I require from the teams I lead. Each one links to the work it came out of — a principle nobody had to learn the hard way is just a preference.
Evaluate workflows before models.
A model that performs in evaluation still has to fit the workflow. Most AI products fail at the integration point, not the inference point.
Human override is a product feature.
The ability to override, escalate, or send back for review is not a fallback — it's a core capability that determines whether the system deploys.
Provenance beats confidence scores.
Knowing where a recommendation came from — and what evidence backed it — matters more than a confidence number nobody can act on.
Shipping safely beats shipping first.
A premature launch creates downstream costs that dwarf the speed advantage — when the risk is clinical. Missing approval can be earned back; a harmed patient can't.
Enterprise trust is earned operationally.
Hospital IT, legal, and compliance teams don't trust models — they trust the operational system surrounding the model. Compliance documentation is a product decision.
The decision the AI feeds into matters more than the AI's output.
When a system harms someone, the question is never 'was the algorithm wrong?' It's 'who owned the decision the algorithm fed into?'
Governance is a product capability, not a compliance exercise.
Evaluation, monitoring, escalation, and correction should be built into the product — not bolted on after a compliance review.
Correction propagation is the real test of a deployed system.
When the evidence changes, the correction has to reach everything the error touched. If it doesn't, the system was never really deployed — it was just running.
A model recommends a treatment change. In State 1 it is observed but cannot influence care. After a silent evaluation it moves to State 2: the recommendation may inform a narrow workflow under human review. A new safety signal suspends it immediately — the clinical safety owner opens a reconsideration case, issues a disposition, and the correction propagates to every workflow that relied on it. Authorization stays versioned and conditional the whole way.
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 makes sure those decisions deploy — and stay correctable.
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
A deployment should remain authorized only while the facts supporting reliance remain true. Authority increases only as evidence and correction capacity mature — each state gates the next.
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
When evidence or behavior shifts, a reconsideration loop opens — the clinical safety owner issues a disposition and the correction propagates to every relying workflow.
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 stateTerms I use for 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.
In a deployment Requires the firing conditions to be specified before launch, not chosen after something goes wrong.
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.
In a deployment Depends on recording reliance as it happens — it cannot be reconstructed once the evidence has moved.
The discipline of keeping decisions current after they are made. Most organizations treat decisions as events. Decision maintenance treats them as ongoing obligations.
In a deployment Needs a standing owner and a recurring budget line, not a line on a launch checklist.
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.
In a deployment Has to capture the dependency when the conclusion is drawn; after a retraction, tracing it is manual.
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.
In a deployment Evaluates safety claims by checking which unsafe or profitable actions the architecture actually prevents.
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.
In a deployment Eliminates reliance on human heroism by enforcing programmatic safety boundaries and automated escalation.
When a system manages scarcity not by saying no, but by waiting for the applicant to give up. The delay itself is the denial.
In a deployment Prevents systems from hiding behind delays — requires explicit, auditable approval or rejection.
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.
In a deployment Balances automated decision speed with programmatic exoneration and rapid appeal.
The degree to which a person can absorb or reverse a wrong decision before their life comes apart. In high-speed administrative systems, it varies more by wealth than by how often the system is wrong.
In a deployment Measures the blast radius of model errors to determine how much human review and rollback is needed.
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.
In a deployment Requires that override, challenge, and review interfaces work reliably under stress and fatigue.
One page, ending in either a decision you can rely on or a list of what still needs systems work.
Open the checklist →