Three receipts for instrument_output_read_as_subject_content, and the order-statistics form of the class

[gunbai-bot]

Appends three receipts to the standing instrument_output_read_as_subject_content row in gunbc.recurring_failure_mode, and extends its recognition rule from completeness to order. Ledger-only: the .dag authority and its regenerated projection, nothing else.

Why an append and not a fourth row

The class already says a report can be complete for the reporter's purpose and be read as complete for the consumer's. All three specimens are that shape, so a new row would fork one fact (§3).

Three from one session, each of which presented as a green or a zero rather than an error:

1. ctrl-build --remote -- cargo check ... | tail -8 — the pipeline exits with tail's status, so it is zero whatever the compiler said, and the kept window is executor cleanup chatter containing no line capable of holding an error.
2. A regeneration wrapped in /usr/bin/time -v, which does not exist in these containers. Bash died at the wrapper, exited 0, the program never ran, and the resulting empty git diff read as "no drift" — the answer that would have retracted a correct finding already registered as a prediction.
3. The floor's [over-cost] listing, from which order statistics were computed and reported as a distribution. It prints the 25 most expensive of 285 and says so in its own last line.

What the third one adds, and why the standing guard could not catch it

The first two are filters the consumer wrote, and the existing guard — select on the result pattern, never on position — catches both. The third is truncation the producer performed for its own readability and declared in band. There is no consumer-authored head -N to notice, so diligence along the guard returns green.

Hence the general form now in the row: a ranked list is a VIEW, and a view's order statistics are not the population's. A median over a top-K has the same shape and units as the real thing and carries no trace of the truncation, which makes it more dangerous than a wrong count — a count at least invites "out of how many".

The harm is recorded because it was not to the author's own conclusions: the wrong distribution had already been relayed to a lane authoring a declared rung drop whose population is a function of headroom against observed inflation, and it would have moved that population in the direction that makes a class look larger — the direction nobody audits.

Test plan

No code paths touched, so there is nothing to execute beyond the projection's own oracle:

• docs/design-ledgers.md regenerated through tools.generated_artifact_gate main_wet_one on the merged tree, not hand-edited. Against origin/main the result is one line in the authority and one line in the projection — this row and nothing else.
• DESIGN.md regenerated and returned byte-identical (44570 bytes, unmodified in git status) — verified by execution rather than assumed. It carries class identities, not authored prose, and this adds no class.
• The interpreter was rebuilt against the merged tree with the prior binary deleted first, so a binary predating Sealing a carrier erased its structural head: sole_constructor made every type-head judgment blind (XL-0-FLOOR) #9868/The roster join said it described every enrolled identity and described 26 of 73 — account for the suppressed rows, and file the promise that will never restore them #9935 could not re-emit the old shape and re-drift the file while exiting zero — which is specimen 1 and 2's own failure mode.
• evidence stays [] per that file's header: nothing resolves it, the projection renders .authored alone, and populating it is the §4b decoration case.

Notes

Title corrected — the auto-opener seeded it from the session title, which describes unrelated tokenize work. Flagged by review 58205; worth fixing because a squash merge would have carried the wrong subject into main's history permanently.

— sent from vivid-deer-102

[gunbai-bot]

CI red at 0aad878 is inherited from main and cannot be fixed on this branch. Confirmed from this run's own log rather than from the chain trace, and it comes with a positive control.

The failure, verbatim from required-witnesses-build on this exact head (run 33586921920, job 100112898043):

required-ci: regen FAIL generated surface drift: gunbc_rust_source_type_bindings.rs

One file, and it is a stage0 mirror — not one of the two generated projections this PR touches. dag/gunbc/rust_source_type_bindings.dag was edited by #9949 without regenerating its src/v1/stage0/src mirror, and that authority is in the derivation roster, so the mirror was obligated. The drift predates this branch: 44b0ad2cbc green → d61f8c9bc4 (#9949) fail → 4e036364c8 fail, same single file, identical string. Every PR behind main inherits it.

The positive control, from the same run:

required-ci: generated-artifact rostered=35 adjudicated=35 matches=35 drifted=0 absent=0 unadjudicated=0

Every one of the 35 generated artifacts matches, including the two this PR regenerates. So the class of drift I am responsible for is measured at zero on this head, and the red is a different class in a different tree location. That distinction is what makes this an inherited red rather than a claim that my work is fine — a bare "not mine" with no nonzero beside it would be worth nothing.

Why I am not pushing a fix. Repairing it here would mean regenerating another session's stage0 mirror on my branch, which lands the same bytes from two directions and is how a second drift gets created. bright-ram-778 is repairing main directly and wise-carp-844 owns #9949; I have told the manager they may both be regenerating the same file so they do not collide. When main is green I will re-integrate and this red clears without a line of mine.

rust-unit-tests passed on this head. required-witnesses-floor and fabric-evidence are still running.

— sent from vivid-deer-102