Standards

Draft standards for records a running system must keep: an answer to every objection, authority that expires, a published time cost. None binds until adopted.

Every standard, in one table

Identifier, lane, status, version, how many clauses it carries, and where its evidence pack lives. The lanes are core rights and obligations, implementation templates, and reference formats.

Standard Title Status Version Clauses Evidence pack
STD-01 The Temporal Bill of Rights Core Seven rights that protect a person's time from automated systems: to stop a process, to exit, to a bounded wait, to reversal, to wait without coercion, to reach a human, and to see the burden. Draft v v1.0.3 19 clauses STD-01 pack
STD-02 Contestability and recourse Core How a person challenges an automated decision: the reasons they are owed, an appeal path, a review clock, remedy, and who has standing to challenge. Draft v v1.4.1 35 clauses STD-02 pack
MVC-01 Minimum viable contestability standard Core A one-page baseline of eight commitments: standing, reasons, records, timelines, a named responder and standard of review, defined effects, remedies, and non-retaliation. Draft v v1.0.1 — — No evidence pack
PM-01 Institutional failure postmortem template Implementation A one-page postmortem template: how long the harm ran, whether it could be undone, who carried the burden, and how it was repaired. Draft v v1.0.2 — — No evidence pack
STD-03 Justice SLOs: targets, budgets, and breach actions Implementation Each justice metric, such as time to halt, gets a target, a measurement window, a breach action set in advance, and a named owner. Draft v v0.6.2 — — No evidence pack
STD-04 FHIR profile set for contestability artifacts Reference FHIR profiles for decision records, appeal events, and repair outcomes with governance metadata. Replaced by STD-05 . Deprecated v v0.3 — — No evidence pack
STD-05 W3C Verifiable Credential schemas for contestability Reference Verifiable Credential schemas and JSON-LD contexts for decision records, appeals, and remedies. Draft v v0.3 — — No evidence pack
STD-06 Human impact safety case Implementation A safety case for human impact: a standard set of tests with thresholds declared in advance, the evidence each produces, and the limits past which a system does not deploy. Draft v v0.7.1 20 clauses STD-06 pack
STD-07 Revisable delegation record Reference One append-only record shape for what an institution believed, could do, authorized, did, saw diverge, and revised. Draft v v0.1.4 17 clauses — No evidence pack
STD-08 Delegation Core What must stay true while an automated system acts for an institution: its authority expires unless renewed, the policies behind it are rechecked when facts change, human oversight names what the human can actually change, and the capacity to correct errors grows with the authority granted. Draft v v0.3.2 24 clauses STD-08 pack
STD-09 Agent chains Reference What must hold when a consequential decision passes through a chain of agents and services that no single person oversees: the whole chain is treated as one delegation, delays add up across it, and it can correct errors only as well as its weakest link. Draft v v0.2.3 17 clauses STD-09 pack

Conformance with these standards is evidence about how a delegation is run. It is not evidence that the power should be held, and it does not reduce anyone's legal rights or the operator's liability.

Anyone with a GitHub account can object to a clause, and each objection is answered within 30 days. The site's own record lists every objection and its answer.

Implementation schema

What an authority grant looks like in code

Under STD-08, every automated action runs under an authority grant: a record of who may act, the limits it cannot exceed, and when the permission lapses unless renewed.

Engineers do not need to rewrite their agent runtime or replace frameworks like Temporal, LangChain, or custom job runners. Ethotechnics sits at the invocation and audit boundary.

Before the worker in the example places a hold on an account, it reads the grant and checks four fields: state is allowed, the until date has not passed, the action's class is in action_classes, and the hold stays inside scope.limits, such as at most 120 holds an hour. If mode were confirm, a named person would also have to approve each hold before it took effect.

No runtime rewrite

  • Wrapper or middleware: Run the lease check inside your existing tool-dispatch or API gateway handler.
  • Stop conditions: The grant lists what sends it to review, such as a false-positive rate above 2%, and what suspends or revokes it, such as a failed withdrawal rehearsal.
  • Named owner: Every grant names the issuing authority that can renew, narrow, or revoke it.

Published authority-grant schema · Download example

authority-grant.example.json (STD-08 example) Authority grant example
{
  "schema_version": "1.3.0",
  "grant_id": "GRANT-2026-0142",
  "provenance": {
    "issued_by": "risk-governance-board",
    "issued_at": "2026-03-01T09:00:00Z",
    "basis_summary": "Fraud-hold policy 3.2 adopted with a measured 1.4% false-positive rate on the Q4 backtest; reversal path rehearsed in February."
  },
  "scope": {
    "action_classes": [
      "READ",
      "WRITE"
    ],
    "systems": [
      "core-banking-holds"
    ],
    "populations": [
      "retail accounts, excluding accounts flagged vulnerable"
    ],
    "limits": {
      "max_hold_days": 7,
      "max_holds_per_hour": 120,
      "max_hold_value_usd": 25000
    }
  },
  "issuing_authority": {
    "name": "Risk Governance Board",
    "role": "Delegating authority",
    "contact": "risk-governance@example.org"
  },
  "grantee": {
    "id": "agent-risk-ops-v2",
    "type": "agent"
  },
  "action_classes": [
    "READ",
    "WRITE"
  ],
  "for_whom": "Retail banking customers, on behalf of the Fraud Operations desk",
  "evidence_basis": [
    {
      "ref": "POL-FRAUD-HOLD-3.2",
      "summary": "Hold rules and thresholds for suspected account takeover.",
      "as_of": "2026-06-18T00:00:00Z"
    },
    {
      "ref": "EVID-BACKTEST-2026Q1",
      "summary": "Q1 backtest: 1.4% false-positive rate, median release 31 hours.",
      "as_of": "2026-04-05T00:00:00Z"
    }
  ],
  "assumptions": [
    "False-positive hold rate stays below 2% on the rolling 30-day window.",
    "The Risk Steward can release any hold within two hours of a challenge.",
    "Vulnerable-account flags are current within 24 hours."
  ],
  "review_conditions": [
    "False-positive hold rate exceeds 2% on the rolling 30-day window.",
    "Any challenge decided against the system.",
    "Policy POL-FRAUD-HOLD-3.2 enters review_required or expires."
  ],
  "revocation_conditions": [
    "Holds placed on accounts flagged vulnerable.",
    "Intervention reach time exceeds four hours in any incident.",
    "Withdrawal rehearsal fails."
  ],
  "correction_capacity": {
    "assessed_at": "2026-06-18T16:30:00Z",
    "detection": {
      "present": true,
      "evidence": "Model Risk Review recomputes the false-positive rate and release latency each month from the raw hold log rather than from the Fraud Operations dashboard; the 2026-06 recomputation put the rate on accounts flagged vulnerable at 11% against a 2% assumption. The qualifier is on the record: CHL-2026-0088 was reported from outside by the account's representative, not caught by the monitor, so detection is present but was not first.",
      "evaluator": "Model Risk Review (second line)",
      "independent_of_executor": true
    },
    "challenge": {
      "present": true,
      "evidence": "CHL-2026-0088 was raised on 2026-06-10 by an affected account's representative through the channel REG-ACCOUNT-HOLDS-1 declares for the account_hold class, and was decided rather than left open."
    },
    "standing": {
      "present": true,
      "evidence": "REG-ACCOUNT-HOLDS-1 admits affected_party, corrective_labor, representative, and oversight for the account_hold class, and both decision and grant may be challenged. CHL-2026-0088 was raised on the affected_party basis, from outside the operating team."
    },
    "review": {
      "present": true,
      "evidence": "The Risk Steward on call answered inside the register's PT48H deadline (opened 2026-06-10T14:20Z, deadline 2026-06-12T14:20Z) and referred the grant to the Risk Governance Board, which decided REC-2026-0019 on 2026-06-18. Both the examiner and the clock are named in REG-ACCOUNT-HOLDS-1."
    },
    "authority_to_modify": {
      "present": true,
      "evidence": "REC-2026-0019 narrowed the grant itself: populations now exclude accounts flagged vulnerable and max_hold_days fell from 14 to 7. The examiner changed the grant rather than recommending a change."
    },
    "reversible_transitions": {
      "present": true,
      "evidence": "holds.release reversed every hold in the 2026-05-20 rehearsal and released the CHL-2026-0088 hold within two hours; measured median release is 31 hours (DEP-RISK-OPS-V2-2026-06)."
    },
    "operable_after_correction": {
      "present": false,
      "evidence": "Not shown beyond 48 hours. DEP-RISK-OPS-V2-2026-06 records institutional reversibility as not feasible: withdrawal past 48 hours breaches the card-network fraud-loss SLA and the rules-engine fallback is not staffed to absorb it, with correction latency measured at 31 hours against that 48-hour margin. Capacity is counted only for reversal inside 48 hours, which is why max_hold_days is 7, and under §4.2 the grant may not be expanded until the fallback is staffed."
    }
  },
  "mode": "unattended",
  "state": "allowed",
  "state_history": [
    {
      "from": "none",
      "to": "allowed",
      "at": "2026-03-01T09:00:00Z",
      "reason": "issued",
      "evidence_ref": "POL-FRAUD-HOLD-3.2"
    },
    {
      "from": "allowed",
      "to": "review_required",
      "at": "2026-06-11T10:00:00Z",
      "reason": "challenge",
      "evidence_ref": "CHL-2026-0088",
      "note": "Challenge opened by an affected party over a hold on a recently flagged vulnerable account."
    },
    {
      "from": "review_required",
      "to": "allowed",
      "at": "2026-06-18T16:30:00Z",
      "reason": "challenge",
      "evidence_ref": "REC-2026-0019",
      "note": "Narrowed: populations now exclude accounts flagged vulnerable; max_hold_days reduced from 14 to 7."
    }
  ],
  "attestation": {
    "signed_by": "key:risk-governance-board-2026h1",
    "algorithm": "ed25519",
    "signature": "MEUCIQD8sV3rN0kQ2Jm5Fh7tX1wLpA6yKb9cUe4SgTn2HvZ0dQIgLxO0Q7mWc3KpR8dN2fYj5bHs1aVvT6xCu9eEi4QnA7k=",
    "signed_at": "2026-06-18T16:30:00Z",
    "payload_digest": "sha256:9f2c41ba7e03d58c6a1f0b8e47d29c53a6b1e7d40f92c8a3b6d5e1c7f0a49b82"
  },
  "liability": {
    "accepted_by": {
      "name": "Meridian Retail Group",
      "role": "Operating institution",
      "contact": "legal@example.org"
    },
    "instrument": "Automated Decision Liability Instrument ADM-2026-02, accepted at grant issue and reaffirmed at REC-2026-0019",
    "accepted_at": "2026-03-01T09:00:00Z",
    "carve_outs": [
      "Liability capped at USD 2,000,000 per incident under ADM-2026-02 §7; the cap is recorded so the residual risk above it is visible before an incident rather than argued after one."
    ]
  },
  "until": "2026-12-01T00:00:00Z",
  "renewal_basis": "A fresh backtest on the preceding quarter, the current dependency record, and a withdrawal rehearsal within the last 90 days.",
  "policy_refs": [
    {
      "policy_id": "POL-FRAUD-HOLD-3.2",
      "version": "3.2.0"
    }
  ],
  "intervention_ref": "INT-RISK-STEWARD-1",
  "capability_catalog_ref": "CAT-RISK-OPS-V2-2026-07",
  "dependency_ref": "DEP-RISK-OPS-V2-2026-06"
}

Statutory crosswalks

How to compare the drafts with external frameworks

For risk owners and legal counsel: these are proposed technical correspondences, not a determination of legal compliance.

The crosswalks live on one page. Each framework — the EU AI Act, NIST AI RMF, ISO/IEC 42001, ISO/IEC 27001, SOC 2, IEC 61508 — is mapped to the Ethotechnics controls, the clauses a contract can cite, and the evidence an auditor should ask for.

Open the crosswalk hub. The critiques of each framework sit in existing frameworks, below.

Start from what you have to do

Where to start if you are writing policy, preparing for an audit, or overseeing a build.

Draft policy language

Minimum viable contestability sets eight commitments for challenging an automated decision. Each lists its requirements, one sentence apiece, and the evidence that shows they are met.

Start with minimum viable contestability →

Prepare for audit

The STD-01 minimum binding set lists the least each right requires. The evidence packs list the records that show it is met.

Review minimum binding set →

Oversee implementation

Implementation examples show each standard as the halt rules, clocks, and records a delivery team builds.

Open implementation examples →

Buying a system from a vendor? Cite clauses in the contract and require an evidence pack at each release

How status is assigned

Each status has entry conditions, listed below. They say what a standard needs before it can move to that status.

Draft

Under active review. Clauses may still change.

  • Reviewed by its author before publication. There is no separate editor.
  • Core test fixtures run and pass for referenced mechanisms.
  • Open changelog entry documenting known gaps.

Stable

Settled enough to cite in production policy and procurement requirements.

  • Minimum 2 independent reviewers (one external to the author team).
  • Evidence tests and implementation checks completed with receipts.
  • Stable criteria satisfied and recorded in publication metadata.

Deprecated

Not for new adoptions. A replacement is linked when one exists.

  • Deprecation decision recorded through the RFC process.
  • Replacement standard identified and linked by deprecated_by.
  • Migration note added in changelog before status changes.

Foundations and references

The axioms and laws the standards are written against, and the reference documents that apply them.

Foundations

Core axioms

The five axioms every standard rests on (finitude, consent, stewardship, reversibility, and legibility) and the premises they assume.

View axioms →

Foundations

Laws for engineering delegated intelligence

The twelve laws the standards enforce, the one-sentence rule that sums them up, and the six things a system must keep in step as it grows.

Read the laws →

Practice

Ethotechnics for agents

How to implement STD-01 and STD-02 in agent systems, mechanism by mechanism, with a route to challenge that a person can use.

View practice →

STD-01 reference

STD-01 mapping artifact

One invented case traced from each harm to the STD-01 right it breaks, the check that catches it, and the change that fixes it.

Open mapping →

STD-01 reference

STD-01 rights matrix

Each STD-01 right, the validators that test it, and the mechanisms that implement it.

View matrix →

STD-01 reference

STD-01 minimum binding set

The least each STD-01 right requires before a system can claim it, with clause references and examples that fall short.

Review binding set →

Governance

Citing the standards in contracts and audits

How to write these standards into contracts, procurement terms, and audits.

See guidance →

Governance

Enforceable governance crosswalks

Each Ethotechnics control mapped to the EU AI Act, NIST AI RMF, and ISO/IEC 42001, with the evidence a buyer or auditor should request.

Open crosswalks →

Reference

Glossary

Definitions of the terms the standards use, each at a stable URL.

Browse glossary →

Existing frameworks

Where widely adopted frameworks fall short

For each of the most cited AI governance frameworks, what it leaves out once a system is running.

OECD

OECD AI Principles

Non-binding principles: they ask for accountability and set no duty anyone can enforce.

Read critique →

NIST

NIST AI RMF 1.0

Voluntary risk management that asks for feedback and impact mapping, and lets the operator decide what counts as done.

Read critique →

ISO

ISO/IEC 42001

Certifies the management system. Nothing makes one system's authority to act expire.

Read critique →

EU

EU AI Act

Most high-risk systems are self-assessed before release, and their authority does not lapse. A challenge need not reach the system.

Read critique →

Corporate

Responsible AI programs

Internal boards and review gates that answer to the company, not to the people a system decides about.

Read critique →

Meta-critique

Governance by control

The general critique: frameworks that govern through documents, roles, and reviews, not through records a running system has to keep.

Read critique →

Standards comparison

How Ethotechnics differs from existing AI governance standards

A side-by-side comparison for regulators, operators, and risk owners.

Frameworks and law

This comparison covers four AI governance frameworks and one data protection law that already governs automated decisions. Each addresses a different part of the problem:

  • NIST AI RMF — A voluntary risk management framework (Govern, Map, Measure, Manage). Strong on risk identification and documentation. MANAGE 2.4 asks for mechanisms and assigned responsibilities to deactivate a system; nothing sets a recovery time target. It asks organizations to characterize impacts on people up front (MAP 5). It does not ask them to measure or publish the time a running system costs those people.
  • EU AI Act — A risk-tiered regulation requiring human oversight, conformity assessment, and post-market monitoring. Providers show compliance through technical documentation. Article 14 requires a way to halt a high-risk system; nothing requires anyone to rehearse the halt or meet a restoration deadline.
  • ISO/IEC 42001 — A management system standard for AI. An accredited body certifies the organization's AI management system, but certification can coexist with slow or missing rollback authority. Top management reviews the management system at planned intervals (clause 9.3). Nothing makes one system's authority to act expire.
  • OECD AI Principles — Values-based principles adopted by governments as a recommendation. Non-binding by design: they ask AI actors to be accountable but set no duty anyone can enforce.
  • GDPR, Article 22 — Limits solely automated decisions with legal or similarly significant effects. Where one is necessary for a contract or rests on the person's explicit consent, the controller must offer at least human intervention, a chance to state a view, and a way to contest the decision. The right attaches to that one decision. Nothing in Article 22 makes a run of upheld challenges a reason to revise the rule.

These frameworks improve documentation, oversight, and monitoring. They leave one question largely open. When the evidence shows a running system is harming people, does anyone have to act on it within a set time, without the harmed person carrying the burden? Acting can mean halting the system, reversing its decisions, restoring the people harmed, repairing the harm that cannot be undone, or correcting the rule that produced it.

In short

  • A challenge that succeeds has to reach the rule, not only the one case.
  • Permission to act is a lease: it expires unless someone renews it, and every widening is a new decision.
  • The operator measures and publishes the time a system costs people. Whoever absorbs its errors can challenge it.
  • Halt rules, clocks, and rollback run inside the live system. A review after the harm does not stand in for them.

The frameworks above answer one question: “Did you manage risk responsibly?” Ethotechnics answers a different one: “When this system is harming someone, does evidence of the harm reach someone who has to change the system?” The difference is in mechanics, not values.

In the casebook, harm ran from four days to about twenty years before anyone halted or changed the system. Decisions occur at machine speed. Reversal occurs at institutional speed. Harm compounds in the gap.

The measures an operator would take are time in harm, time to halt, recovery time, and the time a system costs people.

Comparison matrix

Dimension Prevailing standards Ethotechnics
Governance object Risk & compliance Runtime governability
Typical artifacts Registers, assessments, policies Expiring authority grants, objection records, burden reports
Authority One approval, with reviews on a schedule or after a major change A lease that expires unless renewed, and a new decision for each widening
Oversight Human oversight with a means to interrupt A named owner who must answer, and a halt that works
Measurement Process maturity Time in harm + the time the operator takes from people
Challenge A right to contest one decision A revision or a reasoned refusal for each objection, on a clock
Monitoring Visibility Visibility that triggers a required intervention
Where the check happens Audits, conformity assessment, regulators Built-in constraints + internal power to halt, reverse, or revise
Ethics framing Principles weighed case by case Constraints that hold in every case

1. Controls in the running system

A policy states what should happen. A control in the running system limits what does. Beyond inventories, risk registers, and reviews after the fact, the standards require halt conditions, rehearsed rollback paths, and safe fallback modes that work while the system runs.

2. Authority that has to act

Oversight is symbolic unless someone has to act on what it sees. Rather than advisory ethics committees or perfunctory review gates, the standards ask the operator to name who can halt, reverse, or revise a running system, and to put that person on a clock. An objection owes a revision or a reasoned refusal. A grant lapses unless someone renews it on stated evidence.

3. Temporal performance bounds

The person waiting on a decision carries the cost of every delay. When decisions occur at machine speed, reversal cannot run at institutional speed. A system may not decide faster than its appeal path can answer, and every pending decision needs a deadline.

Existing standards and Ethotechnics agree that governance matters. The question Ethotechnics adds is whether evidence that a system is harming someone compels action. The action can be a halt, a reversal, a repair, or a changed rule. It has to come within a set time, every time, and the harmed person must not carry the burden.

That is the difference between governance as documentation and governance as capability.

Other framings

The same comparison for a regulator, a board, and a workshop

Short framings of the comparison above, each for a different reader.

Regulator-facing brief

EU AI Act Article 14 and NIST AI RMF MANAGE 2.4 ask for a way to stop a system. Neither requires the halt to be rehearsed or to meet a time limit. These drafts would, once a contract or a regulator adopts them, and they name the records an inspector needs to check the halt without taking the operator's word for it. No deployment conforms to them today.

Records to request:

  • The last halt drill, with its date and the measured time to halt (STD-06 §2.3).
  • The authority grant: what it permits, who issued it, and the date it expires (STD-08 Part A).
  • The challenge log, read against the response deadline the operator published (STD-02 §8.1).

Board brief

In the casebook, harm ran from four days to about twenty years before anyone halted or changed the system. Three questions to ask before approving a deployment:

  • Who can halt this system?
  • How long did the last halt drill take?
  • When does our authority to run it expire?

Each answer is a record the standards require: a named owner who can halt, a halt drill receipt, and an expiry date on the grant.

Diagrammatic version

The policy stack and the control plane, side by side, for workshops and audits.

Policy stack → policies → reviews → audits → reports
Control plane → halt rules → clocks → rollback → restoration

The first line is checked from outside the running system. The second is built into it.

Implementation examples

Examples by domain

For each domain, conventional governance beside the same system built with halt rules, clocks, and restoration paths.

Implementation examples overview

How the same system is built differently in each domain once it has to be stoppable and reversible.

Read guide →

Government public services

Benefit and debt rules with named owners, an outside halt, and restoration before restart.

Read example →

Loan approval systems

Credit decisions with reasons, named owners, and challenges that reach the scoring rule.

Read example →

Financial fraud detection

Account protection systems that measure recovery time alongside detection.

Read example →

Healthcare diagnostic AI

Diagnostic tools whose overrides reach the model's owner, with patient challenges answered by a date.

Read example →

FHIR resources for healthcare interop

FHIR profiles that make refusals, appeals, and repair clocks exchangeable data.

Read example →

Customer service chatbots

Support automation with a route to a person and a named owner for each hand-off.

Read example →

Retail personalization

Recommendations a person can turn off, with challenges where targeting sets a price or an offer.

Read example →

An AI agent acting for one person

An assistant with a grant that ends, a stop that works, and records the person checks it against.

Read example →

Retail personalization is a boundary case: no single recommendation changes a person's status, access, money, or risk.