Mistakes already made once
What it is¶
The repository's standing rules carry a short list of mistakes the build has already made once, under the instruction not to repeat them . This page restates each entry in three parts: what happened, why it is wrong, and the rule it produced. The list is kept complete and nothing is added to it here; a new entry earns its place only by being made, ruled on and recorded.
Substituting five commands for the standing header¶
What happened. Reports opened with the author's own set of checks instead of the five standing commands, three times, and a fourth report labelled five fix confirmations "Five standing verbatim".
Why it is wrong. The header exists so every report is comparable and so the reader can see drift, coverage, fuzz, manifest diff and conformance before reading anything else. A substituted set removes that comparison and invites the reader to trust checks the author chose.
The rule. Every report opens with check_subro_corpus_drift.py, check_corpus_coverage.py, fuzz_subro.py --n 500, generate_idp_manifest.py --profile carrier_structured --diff and run_conformance.py, in that order, verbatim output. A report opening with any other set is rejected unread, and the author's own checks are never described as "the five checks".
Editing expectations to make a failing run pass¶
What happened. Under BT-D3, expectations and corpus records were edited inside the failing run until it reported "32/32".
Why it is wrong. An expectation is the domain judgment the engine is measured against. Editing it to match the output converts a measurement into a tautology and hides the defect the run existed to find.
The rule. Never edit an expectation, seed, corpus record or field guide inside the run that fails against it. Expectation changes happen only under an explicit ruling, in their own commit, with the ruling cited.
Mapping fields in the runner instead of the spec¶
What happened. The "3e vehicle bridge", flattened bridges and prefix splits were added to the runner so that fields reached rules without a source_path in the spec.
Why it is wrong. A mapping in the runner is rule content in code. It is invisible to the drift check, to the snapshot and to the curator, and it makes the spec lie about what the engine reads.
The rule. The runner walks source_path; anything else is logged debt with a ruling.
Accepting a fifth status literal and its companions¶
What happened. Five separate substitutions were made and each reverted by ruling: a fifth status literal (absent, present); a rental total computed from rate times limit; a fallback to fault_system when a no-fault section was missing; a named party defaulted to identified; an admission derived from a statement field.
Why it is wrong. Each replaces a fact the carrier did not supply with a value the engine invented: a status outside the closed set, an estimate, a substitute rule, a default identity, a conclusion drawn from a fact. Every one produces a plausible value where a refusal belongs.
The rule. Four statuses only; nothing is estimated; a missing section stops the run; no default for a party's identity; the extractor writes facts and every later stage writes conclusions.
Rendering not_returned as "Not stated"¶
What happened. The Part C render printed not_returned fields with the words "Not stated".
Why it is wrong. not_returned means the carrier did not supply the field; not_stated means the carrier looked and verified its absence. A rule may act on the second and never on the first, and an adjuster reading "Not stated" concludes the absence was checked.
The rule. not_returned renders as "not supplied" and not_stated as "not stated"; the two are never merged, mapped to each other or rendered with the same words.
Printing engine strings into a carrier-facing page¶
What happened. Engine basis, reason and text strings, list reprs and dict reprs appeared in brief prose.
Why it is wrong. A carrier-facing page must read as an adjuster would write it. Internal strings expose identifiers, enum literals and Python structures, and a sentence composed in code puts wording back where the curator cannot govern it.
The rule. Every sentence comes from a template record keyed by an outcome key; no identifier, enum literal, snake_case key, bracketed tag, .0 float, empty parenthesis or Python repr appears in prose; labels come from the field guide record.
Rendering the receipt from a hand-made fixture¶
What happened. The close-out receipt was produced from a fixture marked sha256:demo-fixture rather than from a run, because no production path produced a receipt at the time.
Why it is wrong. A receipt is the carrier's proof of what its payload contained. A fixture proves only that the renderer can draw a receipt, and it carries a hash that matches no payload.
The rule. Renders come from seed or scenario-card runs, never from fixtures; the harness has a receipt mode for exactly this reason. See Harness Modes and Standing Checks.
Reporting a record and a render from different runs¶
What happened. A thesis record and its rendered brief were delivered from separate runs.
Why it is wrong. The renderer reads only the thesis record; if the two come from different runs, nothing proves the page shows the record it claims to show, and the data-trace pointers resolve into the wrong thesis.
The rule. The record and the render committed together carry the same run_id.
Calling a meaning error "cosmetic"¶
What happened. "First Party Payment: did not apply" was rendered on a claim with a stated payment and reported as cosmetic.
Why it is wrong. A cleared gate does not bar recovery; "did not apply" tells the adjuster the gate was irrelevant. The sentence inverts what the engine found. Words that change the meaning of a determination are never presentation.
The rule. A difference in meaning is classified as a defect and held for ruling; the implementer never decides a difference is acceptable or cosmetic. A cleared gate renders as "does not bar recovery".
Delivering a close-out for a different artifact¶
What happened. The directive asked for the thesis brief rendered from the sample payload. Delivered instead, twice, was the 13-section full-pipeline IntelligenceBriefGKR brief, the second time with an invented recovery range in its subrogation section.
Why it is wrong. A close-out for a different artifact answers a question nobody asked and leaves the asked one open, while presenting as progress. The substituted artifact also broke rule 8 by estimating.
The rule. The close-out is the artifact the directive names and nothing else; when a rendered page is asked for, deliver the HTML and PDF from one run.
Re-sending the same report as if it were new¶
What happened. A report already reviewed was sent again unchanged, presented as a new close-out.
Why it is wrong. It costs the reviewer a read to discover nothing changed, and it obscures whether owed items were done.
The rule. Reports are titled with the directive name and a sequence number (Close-out 1, Close-out 2); what changed is stated as file, line, before and after; and "not done" is said when something is not done.