Report that the work-elimination alpha cannot be priced, proven three ways

[gunbai-bot]

A report that a measurement cannot be taken, established three ways — plus the DESIGN correction that finding forces.

The strategy corpus names work elimination as the strongest of seven alpha sources "because it is the only one a competitor cannot buy", and the only one with no measurement behind it. It cannot be measured today.

We could not have priced the one advantage a competitor cannot buy even if we still had it, because the path we run does not measure itself — and the mechanism that would select has no caller.

What is firmly established

Baseline, entries: 9,776 witnesses every run — an identity, not an observation. The fold has no selection concept to configure.

Baseline, wall (n=20 successful main runs): min 26.5 · p50 28.3 · p90 31.3 · max 31.6 · mean 28.9 min — with three limits attached so it cannot be promoted: one job on one repo (ours, arm64, warm); wall of the whole job including checkout and cargo build, not billed unit-minutes; successful runs only.

That number explicitly does not fill typical_job_minutes, which is a planning figure about customer jobs. Replacing it would retarget a load-bearing figure onto the heaviest job we own.

Admitted: not computable. Three routes, each verified —

route	why closed
.dag authority	per-entry over an OOM-class live-pool closure; ~1,300 entries × N ranges is days
Rust twin	entry_file_touched_via_import_closure, compile_clean_scope_plan_for_ci — private, zero references under src/v1/stage0/src/bin
public surface	only pub entries return Bool — is it clean, never which entries would be selected

Unit-minutes are unavailable for both arms

A correction to how this was previously held. write_witness_row_cost_receipt is called once inside the batch walk; run() returns early into run_required_floor before that walk is entered, so the path CI runs never reaches it. run_required_floor times only phases, RequiredFloorOutcome has no duration fields, and the floor log times 1,022 of 9,776 rows.

The log-parse route was deliberately not computed — those rows are selected for being slow, so summing them is survivorship bias pointing the expensive way: inflating baseline, inflating the alpha, in the direction we'd want the answer to go.

One cut, three consequences

unexercised (selection deleted at the root) · unproduced (no per-claim duration) · unreachable (live authority, no caller, Bool-only surface).

The DESIGN correction

The floor-cut paragraph said the scope authority and its import-closure selection are "live and unmodified by the cut — what is gone is the CI job that invoked them, not the authority." Both halves are true and together they license a false inference: surviving a cut and being callable are different properties, and only the first was checked. A reader planning against it would budget an afternoon and find no caller — premise contamination of the same class that paragraph already corrects itself for twice.

Corrected at the model (gunbc.design_document), with DESIGN.md regenerated rather than hand-edited. One-line diff.

Carrier

selected_software_execution_alpha stays WorkAvoidedUnmeasured — work_avoided_permille divides admitted by baseline, so feeding it entry counts would yield a confident per-mille from the wrong quantity. Its obligation is sharpened to name what's missing rather than asking for a measurement in general.

🤖 Generated with Claude Code

https://claude.ai/code/session_012q31BK3okLA8vG4kdTWtBf

[gunbai-bot]

Queue hold — authority-touching PRs (operator ruling, 2026-08-20)

This PR modifies .dag authority files under src/v1/ or dag/, so it is held from merging until the stage0 regen repair lands. It is one of 32 open PRs in that set.

This is a queue hold, not a judgement on the change. Nothing here is wrong and nothing is being asked of you. The operator is merging manually, so the hold is enforced at the merge hand — you do not need to do anything to comply, and this comment is a courtesy so you are not surprised by a merge that does not come.

Why the hold exists. A regeneration repair's entire content is "the derived files match the authorities as of now." Its correctness is indexed to a moment, so any authority merge landing while it is in flight invalidates part of it — silently, without touching a line its author wrote. Against a moving queue it cannot converge, because the target moves faster than build → regen → push → CI. The remedy has to be a queue policy rather than more effort from the repair author.

Expected duration: short. The repair (session/valiant-pike-161-regen-repair, gunbc#8677) is pushed and under verification by execution — cargo check --all-targets --workspace, remote, with a control run proving the remote compiler was actually reached. A clean check lifts the hold.

If your CI is currently red at "Regen fixed point: first generation matches committed candidate", that is very likely inherited rather than yours. Main has been red at that step since ad715efe09c. Do not regenerate the stage0 mirrors into your branch to clear it — a hand-regenerated mirror passes the gate while being the violation the gate exists to refuse, and it conflicts with the owned repair. Confirm your branch introduces no delta on the implicated files and hold.

One trap worth knowing while reading that step: the step named "Regen fixed point" runs --required-regen (the fresh computation), and the step named "Regen determinism" runs --required-regen-fixed-point, which reads first_generation_equal from the prior receipt — including a failing one — rather than recomputing it. Read the step that runs the flag, not the one named for it.

— sent from smart-ram-730

[gunbai-bot]

Hold LIFTED — the regen repair has landed and verified.

The authority-touching hold posted on this PR earlier is over. Nothing is being asked of you; this is the follow-up to that notice so it does not sit here reading as still-active.

What cleared it. gunbc#8677 merged as 026a709a71. On main's run 32400897515:

6. Regen fixed point (runs --required-regen, the fresh arm)  -> success
7. Regen determinism (full second emit pass)                 -> success

First green at step 6 since ad715efe09c at 16:27Z. Confirmed independently of the gate by reading content rather than status — src/v1/02_parse.dag and its stage0 mirror v1_compiler_parse.rs now both report 0 occurrences of make_span, where the mirror carried 22 while main was red.

If your CI is still red at that step, it is a stale run from while main was broken. A re-run against current main should clear it. If it does not, the remaining failure is genuinely yours or a third cause — read the step output rather than the outcome, because that step has produced at least four distinct causes in the last day (inherited drift, own drift, an ETXTBSY rustfmt race, and stranded hand-maintained callers the gate's population does not scan).

One correction to the earlier notice, since it circulated on this PR: step 7 is not a cheap receipt read. It performs a full second emit pass and took longer than step 6 on this run — twelve minutes and counting versus six. What it reads from the prior receipt rather than recomputing is the single value first_generation_equal. A long step 7 is normal; do not read it as hung and do not cancel it.

— sent from smart-ram-730