Evidence that an automated decision is wrong is settled one case at a time and never reaches the rule. The method puts it on the record, one workflow at a time.
Ethotechnics is the engineering discipline of keeping an automated decision system answerable as it grows. Six things have to stay tied together: what the system can do (capability), what it is permitted to do (authority), the evidence that justified the permission (evidence), how hard it would be to do without it (dependency), who can challenge its decisions and be answered (standing), and who can halt and reverse it (correction). When they come apart, a system that gains ability becomes power nobody can review. Where ethics asks what we should do, Ethotechnics specifies the mechanisms meant to make it happen and the records that show whether they did.
The claim
The primary object being engineered is not the model. It is the delegation of consequential agency. The question is not whether the model is capable, aligned, or safe. It is whether the delegation itself remains valid as the system acts, learns, scales, and becomes depended upon.
The unit of governance
The unit of governance is the consequential decision and the delegation that produced it. Models, agents, humans, APIs, rules engines, policies, and databases are components of the machinery. Nothing in the method depends on which component made the decision, so the same records and checks apply whether it was a model, a rules engine, or a person.
The positive form
Ethotechnics is the practice of building capable systems that remain answerable to the people and realities they can never fully represent.
No system may accumulate consequential agency faster than the institution accumulates the capacity to inspect, challenge, revise, and survive its decisions.
The invariant is the twelve laws in one sentence. Every standard clause,
mechanism, and eval on this site specifies or checks some part of it.
The object is the delegation. The failure is absorption: evidence that a delegation is wrong gets settled case by case and never reaches the rule. The instrument is the record. Read the stack from the top: each layer turns the one above it into something a running system can fail.
Vertical trace:
The complete stack from normative theory to public failure records.
Theory
23 essays
Why evidence that an institution is wrong rarely reaches anyone who can change the rule, and why that is a question of power, not only of accuracy.
Trace binding:
Axioms
5 axioms
What the constraints are owed to: finitude, consent, stewardship, reversibility, and legibility.
Trace binding:
Laws
12 laws and one invariant
The constraints. Each states a condition that must always hold; the invariant states all of them in one sentence.
Trace binding:
Safeguards
6 safeguards
What a delegation must keep in step: capability, authority, evidence, dependency, standing, correction. The casebook and the self-test score these.
Trace binding:
Standards
11 standards
Numbered clauses a running system can pass or fail, each with the evidence it needs.
Trace binding:
Mechanisms
Blueprints
Controls that meet a clause: decision logs, kill switches, appeal paths, authority grant registers, dependency ledgers.
Trace binding:
Evals and diagnostics
16 eval suites4 diagnostic toolsTests that check a system against the clauses, starting from a workflow, a decision log, or a set of numbers.
Trace binding:
Casebook
5 cases
Public failures scored on the six safeguards and on whether the institution changed the rule or absorbed the case.
The method is not adopted at the scale of an organization. It is adopted one workflow at a time, and a different workflow each week produces a cross-section of where burden lands.
Select a workflow. Choose a process where system decisions affect people: a benefit eligibility check, a prior authorization, a fraud hold. The six kinds of system on the use-cases page each name the standards to bind and the first check to run.
Map burden by role. Follow one decision from initiation to resolution. Document every point where a person compensates for or overrides the system.
Apply one lens. Choose the lens that fits where the workflow strains. One lens at a time; three at once produces a report nobody acts on.
Share the analysis. Present it to someone who can change the workflow. The pattern is sized to communicate in a single conversation.
Every consequential decision is one link in a governed chain: Evidence → Authority → Decision → Consequence → Challenge → Reconsideration → Correction. Each stage has a question the institution must be able to answer, and the standards, records, and tools on this site that address it.
The chain
Seven stages and two returns
Left to right is one decision. The arrows underneath are what make it
governed rather than merely logged: a challenge reopens the authority it
ran under, and a correction is evidence the next decision has to rest on.
The pipeline failure: Conventional automated decisions stop at
Consequence. Without challenge, reconsideration, or return loops, exceptions are
externalized as unpaid human compensation and the generating rule never adapts.
What propositions justify letting this system act at all?
What answers it today
Evidence packs for STD-01, STD-02, STD-06, STD-08, and STD-09
Links on each decision record to the evidence it relied on
STD-06 Human impact safety case
Burden Concealment evals
Institutional debris as an evidence class: workaround logs, override records, grievance files, exception codes, and shadow spreadsheets — the second process that grew around the intended one
STD-07 belief records, with what they rest on and what would invalidate them
STD-08 Part B: the policies a grant rests on are records with provenance, review triggers, and an expiry, and an expired policy stops justifying the grant
Record conformance checker: grades whether an exported record stream states what would invalidate its beliefs
STD-08 §2.6: a decision threshold is a policy record, pinned to the model version, question schema, and option order it was tuned against
Friction never disappears from a system that scales beyond what its operators can see. It transfers. Every deployment picks where it lands and whether it is recorded.
Circuit schematic: comparing absorption and correction
Schematic showing where an automated system's errors go. In the closed
circuit, the people around the system absorb them while its dashboard
stays green. In the open circuit, a person can challenge a decision, and
the challenge reaches the rule that produced it.
Absorption
The closed circuit
The system optimizes its own path and cuts off the feedback that would force it to change. Errors, waits, and exceptions are routed around whatever gets measured, so the figures improve because people quietly do the work the system no longer does.
What the dashboard showsAll greenNo faults recorded
Where errors landOn peopleUnpaid work to cope
The rule behind themNever hearsNo error reaches it
The hidden cost
The friction lands on whoever the system touches: unpaid work fixing its errors, exhausted operators, and claimants who carry the cost of being misjudged. The burden is real, unrecorded, and appears in no ledger.
The same scaled system, built so that the people it can misjudge can reach it: a challenge that has to be answered, deadlines that are kept, records that follow the case, halts sized to how much harm is at stake, and performance that does not depend on people quietly absorbing its errors.
What the dashboard showsChallengesEach one logged
Where errors landAn appealStaffed to a deadline
The rule behind themCan changeAn error reopens the permission
The deliberate cost
The friction is built back in on purpose: time spent answering challenges, the cost of halting, and the work of restoring what was lost. That cost is planned, funded, and recorded. The challenge load ledger counts it the way the burden ledger counts absorbed errors.
The same distinction underlies the
invariant: what a system does on
its own may not grow faster than the institution's capacity to inspect,
challenge, revise, and survive it.
A well-built system records each of the six safeguards explicitly. It becomes unsafe when they come apart: when it can do more than it is authorized to, or holds authority the evidence no longer supports. The laws treat the safeguards as state variables, quantities that move as the system runs; the casebook and the self-test score each one.
Dynamic equilibrium
The safeguards and their failure drifts
The twelve laws do not forbid delegation; they constrain drift. When any
one safeguard outruns its pair, the system degenerates into an
unreviewable power trap.
Workload modelerCalculates operational vulnerability when human coping capacity is removed.
Finite drillsRehearses manual takeover when an automated cluster must be halted.
Standing
Who could challenge a decision, and did the challenge have to be answered?
Failure drift: Exposure grows without standing when the people a system decides about bear the full burden of algorithmic errors with no procedural route to challenge them.
Which interventions were still possible, and how fast?
Failure drift: Observability grows without control when operators detect anomalies on dashboards but lack authority to halt throughput or issue refunds.
ToeslagenaffaireInstitutional inertia blocked administrative correction for over a decade.
Post Office HorizonDisputed balances could not be corrected without admitting a software defect.
Foundational theory
The sovereign override
When a hard rule fails staff in an emergency, how can the software stay strict while each emergency override is recorded as evidence against the rule, not as staff misconduct?
Exception learning
Why does resolving challenges one at a time leave the rule that caused them in place?
The chain says a consequential decision must account for who carries its burden. The lenses are how that accounting is done: each takes one workflow and asks one question about it. Apply one at a time. The examples are constructed to show the arithmetic; the figures are not from a real plan or agency.
Burden accounting
What hidden labor does this decision create — triage, rework, apology loops, policy exceptions — and does the staff's extra work hide the system's errors from whoever measures it?
A health plan's AI triage tool misroutes 12% of prior auths. Nurses spend 90 minutes per shift re-routing them. That is 7.5 hours of unpaid care-time per week per nurse. Because the nurses absorb the error silently, the green dashboard hides the tool's actual failure rate from management.
Infrastructure dignity
Does the system preserve operator agency and user recourse under pressure, or only when nothing is going wrong?
A clinical chatbot gives a wrong dosing recommendation. The nurse cannot override it without calling a supervisor who is in a meeting. The lens asks where the override is, and whether the operator can reach it in thirty seconds.
Care-time economics
What is being traded between shipping fast and the upkeep it pushes onto staff later, and was the trade visible to anyone before it was made?
Engineering ships a model update that cuts false positives by 3% and adds 45 minutes of daily review work for the care management team. The lens asks whether that second number existed before the deploy.
Optimization becomes predatory when an institution controls both the objective function and the accounting boundary, while people outside that boundary are required to supply whatever adaptation makes the objective achievable. The legitimate optimization problem is: "how much authority can be delegated without degrading the institution's ability to detect failure, account for human burden, and revise that delegation later?"
Many familiar projects make an institution better at deciding without
asking whether it should decide: fairer scores, better explanations,
faster appeals that still fix one case at a time.
Eleven of them, and what replaces each.