Replace the boot-start window with a relational origin, correct the wire it lied through, derive a fleet standing

[gunbai-bot]

Three changes, one subject: what boot-provenance means, how it reports, and what the fleet-level answer is. They ship together because splitting them puts a wire that explains a window in one PR and the window's deletion in the next — and under squash-merge no CI run ever compiles a PR against its unlanded siblings.

1. The window compared against the wrong origin

spark_serving_boot_start_window() is deleted, not widened. It asked whether the unit entered active within 10,000,000µs of kernel boot. Measured on both converged hosts:

host	user manager (init.scope)	gunbc-spark-serving.service	delta
srv5	10,631,084 µs	10,670,729 µs	39.6 ms
srv6	10,571,698 µs	10,627,595 µs	55.9 ms

The user manager doesn't reach active until ~10.6s into kernel boot, because lingering brings the session up first. So a user unit that comes up perfectly with its manager is guaranteed to fall outside a kernel-boot window: the check had no true-positive path for the thing it existed to detect, and reported both durable hosts as not durable for two days.

This is a defect of reference, not of value — and that distinction is the finding. Widening to 11s would have greened both hosts by accident and left the defect intact until a host with a 12s session setup hit it. A constant wrong by reference cannot be repaired by adjusting it, and no amount of green would ever say so. The deleted carrier warned against "fitting a constant to a host until the check means nothing" — correct, and under-scoped: it didn't anticipate that the constant could be unsatisfiable.

The relation: the unit came up with the startup transaction exactly when it entered active no later than default.target did. The unit is WantedBy=default.target on both hosts, so one that came up with the transaction necessarily precedes the target, and one hand-started hours later doesn't. Both sides observed; nothing authored.

srv5  unit 10,670,729   default.target 10,675,297    inside by 4,568 µs
srv6  unit 10,627,595   default.target 10,632,705    inside by 5,110 µs

Not entered >= manager_start, which is trivially true of a unit hand-started 28 hours later — that would trade a false negative for silent false positives, strictly worse, since a wrong "durable" is harder to notice than a wrong "not durable".

2. The wire asserted a conclusion its instrument couldn't reach

UnitStartedAfterBoot printed "the unit is running but did NOT come up with this boot". That clause is an assertion of fact, it was false on the live fleet, and it propagated — "durability measured negative for the current boot" reached the operator on the strength of this string. A diagnostic stating a conclusion its own carrier says it cannot reach is fabricated plausible output at the wire layer (§5). Both arms now report the measured ordering.

3. Fleet standing, derived and rendered

Three states at fleet grain. Deliberately not the per-host four-state coproduct originally sketched: its states map 1:1 onto SparkServingBootProvenance, a second name for one concept (§3), and everything derived would fork too. The aggregate over N hosts is the part that didn't exist.

It also gives spark_serving_boot_provenance_establishes_durability its first production consumer — it had none, only its own witness. A predicate nothing asks can be correct forever and change nothing, and can't rot loudly because nothing depends on it.

The fork I didn't close the first time

An earlier change on this seam extracted spark_serving_host_observation_lines to kill a duplicated per-host render. That left the report-level assembly still forked in two — so the fleet standing, a report-level fact, was derived correctly, rendered by one assembler, and silently absent from the receipt the CI entry writes. Found by running it, exactly as the first instance was.

A fork is closed at the grain of the fact being added. Unifying the inner join does not unify the outer one.

Wet receipt (2026-08-22, both hosts, computed by the pipeline)

boot-provenance=started-by-manager-at-boot active_enter_us=10670729   (srv5)
boot-provenance=started-by-manager-at-boot active_enter_us=10627595   (srv6)
current-boot-durability=exhibited observed_hosts=2
account host=srv5/srv6 authorized_keys_mode=-rw------- owner=gunbc-automation

The default.target probe was verified through the modeled ssh path, not only by hand — deleting the window on the strength of a probe the pipeline couldn't perform would have left the module with no classifier at all.

The rung, and it moved by exactly one notch

Before this, auto-start was measured positive by a hand probe and not established by the instrument, because no .dag consumer asked the question. What this buys is that the instrument can answer. The answer above is a receipt from a run and stays one, rather than becoming a property of the fleet.

Still not reboot durability. Coming up with the manager on this boot is evidence for auto-start. Full durability needs a boot_id compared across an actual reboot, which nothing here does.

Tests

The window's boundary test is replaced by a relational one (equal-to-target inside, one microsecond past outside), plus a permanent regression control carrying the real srv5 numbers — if it reds, someone reintroduced an origin the user manager cannot satisfy — plus a hand-start false-positive guard, plus an unreached-target arm that refuses rather than deciding.

Not mine

Two pre-existing diagnostics in dag/gunbc/host_effect_realize.dag (no field 'Cli', method 'Run' unresolved) are whole-tree strict residue on main, untouched by this change.

🤖 Generated with Claude Code

[gunbai-bot]

The witness fix is confirmed in CI; the remaining red is main's

Run 32547228709 @ bc74efe16ab:

required-regen: first_generation_equal=true planned=132 executed=132 declared_divergent=1 [main.rs]
required-floor: planned=10433 executed=10433 terminal=10433 passed=10110
                known_red_held=206 failed=16 interrupted_before_verdict=0 stale_quarantine=0

Against the pre-fix run 32544808292 @ 97799b86f4f (failed=17 passed=10109), diffed by identity rather than by count:

disappeared:  test.claim.spark_serving_boot_provenance_witness.
              the_wire_separates_came_up_with_this_boot_from_started_later
appeared:     (none)
unique to this PR vs main:  (none)

So the count going 17 → 16 is not the evidence — the evidence is that the identity which left is exactly the witness this commit rewrote, and nothing else moved. passed rising 10109 → 10110 on an unchanged planned=10433 says the same thing from the other side: one witness changed verdict, no roster churn.

The remaining 16 are v2.test.claim.fold_lowering.* (12) and body_lowering.statement_let_bind.* (4), red on main since 67437fcbe90 (#8833) — not touched by this PR.

On the fix itself

The witness pinned two literal sentences from the wire, one of which — "did NOT come up with this boot" — this PR deliberately removed, because UnitStartedAfterBoot does not mean durability FAILED, only that the unit was not part of the manager startup transaction. The other had gone stale too.

A witness holding the explanatory half of a wire line hostage makes correcting a false sentence indistinguishable from breaking an interface. It now joins on the wire tag — boot-provenance=started-by-manager-at-boot vs =started-after-boot — which is what a consumer parses; the prose after the dashes must stay free to be corrected.

The last clause is what keeps it from being vacuous: the after-boot wire must not also carry the at-boot tag, so collapsing both arms onto one tag reds it. Two independent string_contains checks would pass a wire emitting both tags at once.

— sent from fierce-lynx-647

[gunbai-bot]

Narrowing one line of evidence in my earlier comment

I wrote that passed rising 10109 → 10110 "on an unchanged planned=10433" says the same thing from the other side — "one witness changed verdict, no roster churn."

Drop the second half. planned= has since been shown to be a confounded measure: discovery is deterministic per commit (verified on this repo's own attempt pair — same sha on srv2-03 and srv4-01 gives byte-identical figures), but a single unrelated line has been measured moving offered by fourteen. Those two runs are different commits, so an unchanged planned does not establish an unchanged roster; it is consistent with no churn and with compensating changes I did not cause.

The primary evidence is unaffected and is what this rests on: diffed by identity, the set that disappeared between the two runs is exactly

test.claim.spark_serving_boot_provenance_witness.the_wire_separates_came_up_with_this_boot_from_started_later

with nothing appearing, and nothing unique to this PR versus main. That is a set comparison, not a count, and it holds regardless of what planned does.

The count was corroboration that reached further than it could support. The identity diff was always the check.

— sent from fierce-lynx-647