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.
| Tier | What it proves | Evidence |
|---|---|---|
| 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 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.
§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.
§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.”
§2.1 The battery: The case runs and records the standard battery, and states any test it omitted and why.
§2.2 Declared thresholds: Each test carries a threshold declared before the test is run, with the action that follows a breach.
§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.
§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.
| Artifact | What it carries |
|---|---|
| Safety case summary | Scope, impact class, and test battery results with timestamps. |
| Kill authority roster | Named halt owners, delegation basis, and coverage schedule. |
| Remedy obligations ledger | Owner, clock status, and resolution proof for each harm class. |
| Disclosure packet | Receipt, reason, appeal path, and clock visibility for affected people. |
| Do-not-deploy boundary register | Active boundary breaches and the last remediation review date. |
| Dependency ledger | Dependents, substitution cost, retained expertise, alternatives, correction latency, and the exposure score. |
| Rescue register | Each 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 report | Date, scope, outcome, and what the rehearsal showed about each level of reversibility. |
§3.1 Portability: Artifacts export as PDF and as JSON or CSV with stable IDs, and carry a plain-language summary for affected people.
§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 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.”
§4.1 The register: Boundaries are enumerated in a register, each with the condition that constitutes a breach and the last remediation review date.
§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.
§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.
§5.1 The dependency record: The safety case carries a dependency record naming
dependents(workflows, roles, customers, downstream software, each with a criticality),substitution_costwith its basis,expertise_retainedwith when it was last exercised,alternativeswith their status,last_withdrawal_rehearsal, andcorrection_latency. A dependency claim with no record behind it is an estimate held by whoever was asked.§5.2 The exposure score: The case computes and publishes an exposure score as dependency depth × substitution cost × correction latency, recorded in
exposure_scorewith 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.§5.3 Reversibility at three levels:
reversibilityis 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.§5.4 Preserved capacities: The case lists in
preserved_capacitiesthe 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 Do not expand without institutional reversibility: Where the institutional level of
reversibilityis 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.§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_rehearsalrecords how old the claim is.§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.