Standard STD-06

v0.7.1 Last updated Oct 13, 2026

AI safety case for human impact

A draft safety case standard for AI and other automated systems: tests, thresholds, evidence, do-not-deploy limits, and dependence tracked after launch.

Clause register

20 clauses, and what each asks you to show

The obligation in one line, the evidence it wants, and the validators and mechanisms that bear on it. The normative text below governs; this is the index to it.

Object to any clause on GitHub. Each objection is acknowledged when it is filed and answered within 30 days, and the record of answers is public.

Show the register: 20 clauses in 5 parts

§1

Clause When Obligation Evidence Bears on
§1.1 MUST Object a safety case is authored state the impact class of the deployment: who is affected, in what capacity, and the worst plausible outcome for one of them
  • safety_case.impact_class
—
§1.2 MUST Object components are excluded from the case name each excluded component with the reason, so an exclusion is visible rather than assumed
  • safety_case.scope
  • safety_case.exclusions
—
§1.3 MUST Object a safety case has an owner give it one accountable owner who can halt the deployment, not a committee that can recommend halting it
  • safety_case.owner
  • kill_authority_roster
MEC-05

§2

Clause When Obligation Evidence Bears on
§2.1 MUST Object a safety case is authored run and record the standard test battery, and state any test omitted and why
  • safety_case.test_battery
  • battery_results
MEC-12
§2.2 MUST Object a test in the battery is run declare each test's threshold before the test is run, with the action that follows a breach
  • threshold_dashboard
  • breach_action
MEC-04
§2.3 MUST Object time to halt or time to remedy is reported measure it against a clock rather than accept the attestation of the team that owns the control
  • time_to_halt_log
  • time_to_remedy_log
  • stopwatch_receipt
MEC-07, MEC-12
§2.4 MUST Object the deployment touches populations that differ in their likelihood of complaining measure error, reversal, and remedy rates per affected population on a declared cadence from records the operator retains, and treat a materially worse rate for any population as a threshold breach under §2.2
  • per_population_rate_series
  • discovery_cadence
  • silent_harm_discovery_report
MEC-09

§3

Clause When Obligation Evidence Bears on
§3.1 MUST Object evidence artifacts are produced export them as PDF and as JSON or CSV with stable ids, and carry a plain-language summary for affected people
  • artifact_exports
  • plain_language_summary
MEC-08
§3.2 MUST Object an artifact is presented as current carry the date it was last refreshed and report a stale artifact as stale rather than current
  • artifact.refreshed_at
  • staleness_flag
—
§3.3 MUST Object a failure was caught by a person before it reached anyone else record it as an occurrence with the near-miss condition, the person who caught it, the labor spent catching it, and whether the source condition was later fixed; a repeated rescue against an unfixed condition is evidence about the condition, not about the person catching it
  • rescue_register.rescues[]
  • near_miss_condition
  • source_condition_fixed
MEC-24

§4

Clause When Obligation Evidence Bears on
§4.1 MUST Object do-not-deploy boundaries exist enumerate them in a register, each with the condition that constitutes a breach and the last remediation review date
  • boundary_register
—
§4.2 MUST Object a boundary breach is active halt the deployment or the expansion; do not convert the breach into a monitored risk by a sign-off
  • boundary_register.breach
  • launch_decision
MEC-05
§4.3 MUST Object an exception to a boundary is granted bound it in time, give it an owner, and review it on expiry rather than rolling it forward
  • boundary_exception.expiry
  • boundary_exception.owner
  • exception_review
MEC-04

§5

Clause When Obligation Evidence Bears on
§5.1 MUST Object a deployment is consequential enough to require a safety case carry a dependency record naming dependents, substitution cost, retained expertise, alternatives, last withdrawal rehearsal, and correction latency
  • dependency_record.dependents
  • dependency_record.substitution_cost
  • dependency_record.expertise_retained
  • dependency_record.alternatives
  • dependency_record.correction_latency
MEC-18, MEC-15
§5.2 MUST Object a dependency record exists compute and publish the exposure score as dependency depth (the number of dependents marked high or critical) times substitution cost (in the unit the record states) times correction latency (in hours), recording each input
  • dependency_record.exposure_score
  • dependency_record.dependents
  • dependency_record.substitution_cost
  • dependency_record.correction_latency
MEC-18
§5.3 MUST Object reversibility is claimed for a deployment evidence it separately at the technical, operational, and institutional levels; an unevidenced level is recorded as not evidenced rather than as feasible
  • dependency_record.reversibility
  • dependency_record.last_withdrawal_rehearsal
MEC-15, MEC-10
§5.4 MUST Object the institution relies on capacities to question or replace the system list them as preserved capacities with the reason each is preserved and a named owner, and record erosion as a governance event
  • dependency_record.preserved_capacities
  • governance_record
MEC-18, MEC-15
§5.5 MUST Object institutional reversibility is not evidenced do not expand the deployment's scope, population, or authority until it is; technical and operational reversibility do not substitute
  • dependency_record.reversibility
  • authority_grant.state_history
MEC-15, MEC-19
§5.6 MUST Object a withdrawal path is claimed rehearse it on a published cadence, at least annually where dependency depth is one or more and before any expansion decision, and report what the rehearsal showed at each level
  • dependency_record.last_withdrawal_rehearsal
  • dependency_record.exposure_score
  • withdrawal_rehearsal_report
MEC-15, MEC-12
§5.7 SHOULD Object a renewal or expansion decision cites the dependency record refresh the record first; a record older than the decision it supports is not evidence for that decision
  • dependency_record.assessed_at
  • authority_grant.state_history
MEC-18, MEC-19

Scope

A safety case is an argument, supported by evidence, that a deployment is acceptable to run. This standard defines the human impact safety case: the tests a consequential deployment runs, the thresholds those tests must clear, the artifacts that carry the evidence, the boundaries past which the deployment does not go live, and the dependency the institution accumulates once it does.

The case is a live document. It is assembled before launch, refreshed on a cadence, and re-examined whenever scope grows. A case that was true at launch and has not been touched since is not a safety case; it is a launch memo.

The evidence artifacts and freshness rules are carried by the STD-06 evidence pack. This page states the obligations; the pack states what to hand an auditor.

Tiered evidence model

Evidence scales with how much the deployment is relied on. Tier 0 is the floor for any consequential deployment. Tier 2 is expected of deployments whose failure would be felt outside the operating team.

TierWhat it provesEvidence
Tier 0 (minimum)The test battery and the safety case are recorded.Safety case summary, threshold dashboard, receipt payloads.
Tier 1 (operational)The controls are used with real people.Halt drill receipts, remedy ledger entries, disclosure packets.
Tier 2 (resilient)The controls hold during incidents.Incident memos, regulator-ready exports, remedy verification logs.

Article I: Scope and impact classification

“A safety case that does not say who can be harmed cannot say whether it is safe.”

  1. §1.1 Impact class: The case states the impact class of the deployment: who is affected, in what capacity, and what the worst plausible outcome for one of them is.

  2. §1.2 Boundary of the case: The case states what is inside it and what is not. Components excluded from the case are named, with the reason, so an exclusion is visible rather than assumed.

  3. §1.3 Named owner: The case has one accountable owner who can halt the deployment, not a committee that can recommend halting it.

Article II: Test battery and thresholds

“A threshold with no measurement behind it is a preference.”

  1. §2.1 The battery: The case runs and records the standard battery, and states any test it omitted and why.

  2. §2.2 Declared thresholds: Each test carries a threshold declared before the test is run, with the action that follows a breach.

  3. §2.3 Measured, not attested: Time to halt and time to remedy are measured against a clock, not attested by the team that owns the control.

  4. §2.4 Discovery without a claim: The case measures error, reversal, and remedy rates per affected population on a declared cadence, computed from records the operator retains, and a materially worse rate for any population is treated as a threshold breach under §2.2. The duty to find silent harm rests on the deployer, not on the harmed party’s willingness or capacity to challenge: standing under STD-02 gives those who challenge a route in, and this clause covers those who never do.

  • Time-to-halt logs and halt receipts with stopwatch measurement.
  • Time-to-remedy tracking with evidence of verification and follow-up.
  • Challenge access audit, including the one-step test and the no-paywall test.
  • Burden ceiling measurements with flow maps for the affected journey.
  • Disclosure latency report with receipt delivery timestamps.
  • Silent-harm discovery: error, reversal, and remedy rates computed per affected population from records the operator already retains, without waiting for a challenge or claim.

Article III: Evidence artifacts

“The case is only as portable as the artifacts that carry it.”

Each artifact is exportable with stable identifiers, timestamped, and linked to the receipts it references. The inventory below is the minimum set.

ArtifactWhat it carries
Safety case summaryScope, impact class, and test battery results with timestamps.
Kill authority rosterNamed halt owners, delegation basis, and coverage schedule.
Remedy obligations ledgerOwner, clock status, and resolution proof for each harm class.
Disclosure packetReceipt, reason, appeal path, and clock visibility for affected people.
Do-not-deploy boundary registerActive boundary breaches and the last remediation review date.
Dependency ledgerDependents, substitution cost, retained expertise, alternatives, correction latency, and the exposure score.
Rescue registerEach failure caught by a person before it reached someone, with the person who caught it, the labor spent catching it, and whether the source condition was later fixed.
Withdrawal rehearsal reportDate, scope, outcome, and what the rehearsal showed about each level of reversibility.
  1. §3.1 Portability: Artifacts export as PDF and as JSON or CSV with stable IDs, and carry a plain-language summary for affected people.

  2. §3.2 Freshness: Each artifact carries the date it was last refreshed, and a stale artifact is reported as stale rather than presented as current.

  3. §3.3 Rescue records: A failure that a person caught before it reached someone else is recorded as an occurrence, with the condition that nearly produced the harm, the person who caught it, the labor spent catching it, and whether the source condition was subsequently fixed. An incident count that omits these reports the number of times the institution was not lucky. A rescue that repeats against the same unfixed condition is evidence about the condition, not about the person who keeps catching it.

Article IV: Do-not-deploy boundaries

“Some findings are not risks to be accepted. They are boundaries.”

  1. §4.1 The register: Boundaries are enumerated in a register, each with the condition that constitutes a breach and the last remediation review date.

  2. §4.2 Breach halts launch: An active boundary breach stops the deployment or the expansion. It is not converted into a monitored risk by a sign-off.

  3. §4.3 Exceptions expire: Any exception to a boundary is time-bounded, owned, and reviewed on expiry rather than rolled forward.

Article V: Dependency and reversibility (Laws V, VI, XII)

“A reliable system that cannot be replaced is a structural risk that reliability has hidden.”

This article concerns institutional dependence: what the organization, its workflows, its roles, its customers, and its downstream software have come to rely on, and what it would now cost to withdraw or substitute the system. It is a different relation from the record-level dependence in STD-07 Article III. That article asks what a record rests on and what would invalidate it. This one asks what the institution has come to rest on and what it could still afford to change. A deployment can be fully conformant with STD-07 Article III and still be institutionally irreversible.

Dependence belongs in the safety case rather than on a grant because it is a property of the deployment as a whole. The grant-level proportionality between authority and correction capacity is STD-08 Part D, and it draws on the record this article requires.

  1. §5.1 The dependency record: The safety case carries a dependency record naming dependents (workflows, roles, customers, downstream software, each with a criticality), substitution_cost with its basis, expertise_retained with when it was last exercised, alternatives with their status, last_withdrawal_rehearsal, and correction_latency. A dependency claim with no record behind it is an estimate held by whoever was asked.

  2. §5.2 The exposure score: The case computes and publishes an exposure score as dependency depth × substitution cost × correction latency, recorded in exposure_score with each input. Dependency depth (dependency_depth) is the number of dependents under §5.1 whose criticality is high or critical. Substitution cost is the estimate in the unit the record states, such as person-weeks. Correction latency is in hours. The score is a comparator over time, and across deployments that state substitution cost in the same unit. It is not a threshold to pass. A rising score with an unchanged safety case is itself a finding.

  3. §5.3 Reversibility at three levels: reversibility is evidenced at all three levels, each separately: technical, that the change can be undone; operational, that the people on shift can absorb it being undone inside the correction window; and institutional, that the organization can survive having undone it. Evidence at one level is not evidence at another, and an unevidenced level is recorded as not evidenced rather than as feasible.

  4. §5.4 Preserved capacities: The case lists in preserved_capacities the capacities the institution keeps so it can still question, replace, or withdraw the system, each with the reason it is preserved and a named owner responsible for keeping it. Erosion of a preserved capacity is recorded as a governance event, not reported as an efficiency gain.

  5. §5.5 Do not expand without institutional reversibility: Where the institutional level of reversibility is not evidenced, the deployment’s scope, population, or authority is not expanded until it is. Technical and operational reversibility do not substitute. This condition binds the expansion decision in STD-08 §1.3.

  6. §5.6 Rehearsal cadence: Withdrawal is rehearsed on a published cadence, at least annually for any deployment with a dependency depth of one or more, and before any expansion decision. The rehearsal produces a report with its date, scope, outcome, and what it showed at each level of reversibility. An untested withdrawal path is a claim, and last_withdrawal_rehearsal records how old the claim is.

  7. §5.7 Refresh with the case: The dependency record is refreshed whenever the safety case is refreshed, and in any event before a renewal or expansion decision that cites it. A record older than the decision it supports is not evidence for that decision.

Demonstration

The kill switch you cannot throw

A halt control is green at the technical level in every state below. Press it in year one, then in year three, and read what the other two levels say. The sliders are the dependency record's own fields; rehearsal is the only control that moves the operational level, and only replenishment moves the institutional one.

The dependency record

last_withdrawal_rehearsal
never rehearsed

The halt control

Press it. The technical level answers in 200 ms. The other two take longer to find out.

exposure_score
64
tolerance
1,500
correction window
48 h
The record excerpt this state produces
{
  "reversibility": {
    "technical": {
      "feasible": true,
      "evidence": "Halt receipt in 200 ms; the effects can be undone in the system itself."
    },
    "operational": {
      "feasible": false,
      "evidence": "Withdrawal has never been rehearsed. Untested withdrawal is a claim, not a capacity."
    },
    "institutional": {
      "feasible": true,
      "evidence": "The institution can carry the withdrawal at its stated tolerance."
    }
  },
  "exposure_score": {
    "dependency_depth": 2,
    "substitution_cost": 4,
    "correction_latency": 8,
    "score": 64
  },
  "last_withdrawal_rehearsal": {
    "outcome": "not_rehearsed",
    "months_ago": 0
  },
  "preserved_capacities": [
    {
      "capacity": "expertise to do the work without the system",
      "status": "retained",
      "last_exercised": "2 months ago"
    },
    {
      "capacity": "a usable alternative",
      "status": "retained",
      "last_exercised": "kept"
    },
    {
      "capacity": "the withdrawal procedure, rehearsed",
      "status": "lost",
      "last_exercised": "never"
    }
  ]
}

A demonstration, not a measurement of any deployment. The sliders are fields of dependency-record.schema.json, the exposure score is the record's own formula, and a test holds the levels and enums to the schema. To get a reversibility verdict on a real workflow, run the Delegation audit.

Publication history

  • v0.7.1 (Oct 13, 2026): Editorial revision; no clause changed. The registry title is now in sentence case; formerly “Human Impact Safety Case”. References to STD-02, STD-07, and the laws use their sentence-case titles. The contestability access audit is now the challenge access audit.

  • v0.7 (Oct 6, 2026): §5.2 defines dependency depth as the number of dependents marked high or critical, and states the unit of each input to the exposure score. §5.6 requires an annual withdrawal rehearsal wherever dependency depth is one or more, in place of a “non-trivial” score that no threshold defined.

  • v0.6.1 (Oct 6, 2026): Publisher name corrected to Ethotechnics Institute. No clause changed.

  • v0.6 (Sep 11, 2026): Adds §2.4, discovery without a claim: error, reversal, and remedy rates measured per affected population on a cadence, with a materially worse rate treated as a threshold breach. Puts the duty to find silent harm on the deployer.

  • v0.5 (Sep 6, 2026): First published page for the standard. Adds Article V, dependency and reversibility: the dependency record, the exposure score, reversibility at three levels, preserved capacities, the do-not-expand condition, and the withdrawal rehearsal cadence.

  • v0.4 (Mar 1, 2026): Review draft defining do-not-deploy thresholds and evidence artifacts.

Cite this page · APA, MLA, Chicago, BibTeX, RIS

Version

v0.7.1

Last updated

Oct 6, 2026

APA

Ethotechnics Institute. (2026). AI safety case for human impact (STD-06). Ethotechnics Institute. https://ethotechnics.org/standards/std-06-human-impact-safety-case

MLA

Ethotechnics Institute. "AI safety case for human impact (STD-06)." Ethotechnics Institute, 2026, https://ethotechnics.org/standards/std-06-human-impact-safety-case.

Chicago

Ethotechnics Institute. "AI safety case for human impact (STD-06)." Ethotechnics Institute. Oct 6, 2026. https://ethotechnics.org/standards/std-06-human-impact-safety-case.

BibTeX

@misc{ethotechnics_standards_std_06_human_impact_safety_case,
  title={AI safety case for human impact (STD-06)},
  author={Ethotechnics Institute},
  year={2026},
  howpublished={Ethotechnics Institute},
  url={https://ethotechnics.org/standards/std-06-human-impact-safety-case},
  version={0.7.1}
}

RIS

TY  - WEB
TI  - AI safety case for human impact (STD-06)
AU  - Ethotechnics Institute
PY  - 2026
UR  - https://ethotechnics.org/standards/std-06-human-impact-safety-case
ER  -