Stage 1 of the serving extraction: what the observer may read from vLLM, and when it must refuse

[briansrls]

What this PR actually contains — read this first

It carries two lanes, and only one is mine:

	commits	files	lines
serving-observer-contract (not my work, unreviewed, no PR of its own)	26	29	+4462
Stage 1 of the serving extraction (mine)	3	3	+628

My branch was auto-pushed and auto-opened as this PR before a base could be chosen, so it
inherited the base branch.

This PR is the verdict's PR A. serving-metric-semantics and serving-prefill-scaling are
both ancestors of serving-observer-contract, so this branch already carries their terminal
state with the refuted intermediate statements corrected downstream — the consolidation the
verdict asks for is this branch's history, not something to reconstruct. serving-placement-authority
is a descendant of this branch, so landing PR A unblocks the restack PR B needs.

Fabric placement is deliberately not here. An earlier revision of this PR declared a
FabricConsumption type and a placement-standing row. Since PR B owns that question and is built
on top of this branch, those would have landed underneath the lane that owns them and become a
second authority to reconcile. They were carved out (commit 7e348f2). The observation survives as
a finding for that lane, not as a declaration here: dag/gunbc/spark imports nothing from
gunbc.fabric and picks its head host from a constant.

My three files: dag/extdeps/vllm/scheduler_extension.dag,
dag/gunbc/spark/serving_observer_compatibility.dag,
dag/test/claim/spark/serving_observer_compatibility_witness_test.dag.

Stage 1 — the observer's binding surface and its compatibility manifest

FIRST-PARTY SERVING EXTRACTION sequences ten cuts; this is the first. It answers what a
first-party step observer must read from vLLM, at which exact revision, and when it must
refuse. It builds no observer. gunbc.spark.serving_step_receipt authored the receipt
before its producer so the producer could not become the authority by accident; this applies
the same move one layer out, to the join between that receipt and upstream — which belonged
to neither side, and which the wheel would otherwise have defined by being the only thing that
knew it.

Three findings, each read from the pinned source (1967a5627b) rather than recalled:

Read the output, never the request. Scheduler.schedule constructs its SchedulerOutput
and then, as its last act, calls _update_after_schedule, which does
request.num_computed_tokens += num_scheduled_token. One step therefore has two values of
num_computed_tokens, and which an observer sees depends purely on where it reads. A wrapper
that calls the delegate and then reads the live Request objects — the obvious way to write
it, since it is holding the scheduler — records a cached_tokens that already contains the
step's own computed_tokens. Both numbers are plausible, the arithmetic succeeds, and nothing
downstream can catch it.

The default delegate is conditional. With scheduler_cls unset, get_scheduler_cls
returns AsyncScheduler when async_scheduling is truthy and Scheduler otherwise; setting
scheduler_cls removes that branch entirely. A wrapper hardcoding Scheduler does not observe
an async-scheduled engine — it silently converts it to a synchronous one and reports the result
as behaviour-preserving. Async is refused outright until its num_output_placeholders
semantics are modelled, rather than admitted and averaged into one population.

Upstream disclaims the interface, in its own words: "This scheduler interface is not
public and compatibility may not be maintained." That is why the binding is admitted against
one exact revision and refuses every other — no version range is an admissible compatibility
statement for a surface whose shape may change without anything a range could observe.

Evidence

Ten witnesses green by execution under gunbc run (not a typecheck). The load-bearing
one carries a discriminating red: injecting the defect it guards — admitting the
live-request read site — flips it true → false; the module was restored byte-identical.

Full-corpus compile (--source-root dag --source-root src/v2, the CI argv): zero
diagnostics name any of my three files. Other diagnostics in that run are in files this
change does not touch; I did not compile main alone to baseline them, and my merge resolution
touched only a markdown projection, so it cannot have produced .dag diagnostics.

The merge of main hit one real conflict — docs/design-failure-modes.md, a generated
projection — resolved by its declared repair route: incoming side taken verbatim, and
verified by set difference (not count) that no row went dark, with roster.dag confirmed to
carry both sides' rows so the healer can regenerate.

What this does NOT do

• It does not generate the receipt wire schema — the other half of stage 1's brief. That
  projection depends on this manifest and lands next.
• It discharges no part of spark_step_receipt_producer, which stays ProducerUnbuilt.
• Stages 2–10 need a wheel build and live Spark hardware, neither reachable from this session.

🤖 Generated with Claude Code

https://claude.ai/code/session_01963UR9Y5pU2x11dCcgwJ8t

[gunbai-bot]

Re: review 62094 — verified; one row fixed, the rest blocked on a missing carrier capability

I verified every row against the tree rather than taking the pre-scan on trust. The findings are factually correct: those fields are flat scalars, and the carriers exist exactly where cited — std.measure.dag:354 Watt, :1183 Microsecond, :1193 Millisecond.

Fixed: serving_critical_path.dag:38 watts: Nat → Watt (95c0da4)

PowerEnvelope.watts is arithmetic-free — one type field, four data rows, and no reader anywhere in the module. Consuming std.measure.watt is mechanical and total there, so I did it. The module's witness still returns true by execution.

Not fixed: the micros rows — the named remedy has no constructor in this tree

This is not a scope objection. std.measure publishes exactly six operations on Measure:

measure_count   measure_add   measure_le
measure_scale_fraction_floor   measure_scale_fraction_ceil   measure_fit_count_floor

There is no measure_mul, no measure_div, and no dimensional product — I grepped for all three and for any Q1/Q2 composition on the Quantity type; none exists.

The flagged fields are not inert unit-carrying data like watts. They are the inputs and outputs of a least-squares affine fit (arm_fit, ~line 317), whose terms are:

• sxy = Σ (computed_tokens × wall_micros) — a product of two different dimensions (Amount · Time). Not typeable without dimension algebra.
• denom = n·sxx − sx² — the square of a measure.
• slope_milli = ((n·sxy − sx·sy) × 1000) / denom — a quotient whose unit is Microsecond/TokenCount.

That last one is precisely what the review asks for on line 309 ("a rate over Microsecond/TokenCount, not a bare Int") — and it is the one thing Measure cannot currently express, because a rate is a dimensional quotient and there is no such constructor.

The only way to land these today is to wrap at the field and unwrap at every arithmetic site. DESIGN §4b rules that out by name: "a brand, wrapper, or Validated<T> is cosmetic until construction and acceptance enforce the distinction." A wrapper immediately unwrapped enforces nothing and would let the row be cited as coverage it does not provide.

Disposition

The correct fix is dimensional product and quotient on Measure, plus multiplication and division, in std/ — a substrate modeling change, model-before-implement, landing before its consumers migrate. That is a separate PR in std.measure, not something to smuggle into an observation contract; and the fits themselves come from live Spark measurements this session cannot reach, so I could not validate a semantic change to them.

I've left the rows unfixed rather than marking them feature:/dissolve-on: debt, because a debt marker on another lane's in-flight calibration module asserts a disposition I don't own.

Worth noting for the record: none of these rows are in my change. My three files (extdeps/vllm/scheduler_extension.dag, gunbc/spark/serving_observer_compatibility.dag, and its witness) carry zero flat-scalar unit fields — I checked. The findings are all in base-branch content this PR inherited because the branch was auto-opened on its base. I fixed the one that was cleanly fixable anyway.

— sent from loyal-wren-455

[gunbai-bot]

Re: review 62106 — you were right and my earlier reply was too broad. Migrated (11f52b0)

Two reviewers now name this class, and 62106 stated the sharper version of it: serving_step_cost.dag already imports std.measure for TokenCount and re-mints bare scalars for time in the same record. The fork is internal to one file, and that file's own handling — token_count at the field, token_count_value at the arithmetic — is the pattern to follow.

I over-generalized in my reply to review 62094. I reasoned from the affine fit, which genuinely cannot be expressed, out to the whole class. That was wrong: most of these fields aren't in the fit. They're inert data, or they're summed and compared — and measure_add and measure_le both exist.

Migrated

module	fields	carrier
serving_step_receipt	started_micros, elapsed_micros	Microsecond
serving_step_cost	elapsed_millis ×2, inter_iteration_{min,median,max}_millis	Millisecond
serving_critical_path	wall_micros ×2 (24 sample rows)	Microsecond
serving_critical_path	median_watts, max_watts	Watt

Arithmetic sites unwrap through the published accessors rather than reaching into the record. All 28 witnesses across the three modules return true by execution.

Still not migrated — three rows, for a narrower reason than I gave before

• intercept_micros: Int and intercept_difference_micros: Int — these are signed, and Microsecond is Measure<Time, Micro, Nat>. There is no Measure<Time, Micro, Int> alias in std.measure. A difference of two times is legitimately negative, so this needs a signed time alias, which is a std/ change.
• micros_per_thousand_tokens: Int — a dimensional quotient (Microsecond/TokenCount). Measure has no product or quotient, so this rate has no carrier at all. This is the row review 62094 line 309 asked for by name, and it's the one genuinely blocked on substrate capability.

A finding from doing the migration, worth recording

The witnesses compared these fields to integer literals. After the migration, Record == Nat did not refuse — it evaluated to false, silently. The witness went red for the right reason by luck rather than by a located type error. Only < raised, as cannot apply Lt to Record and Record.

An equality that silently answers across two different types is DESIGN §5's silent wrongness sitting in the comparison operator itself. It's a substrate fact rather than this change's, but it is exactly what made this migration risky: a wrap-the-field change that misses an unwrap site produces a quietly false witness, not a failing one. Flagging it rather than leaving it in a commit message.

— sent from loyal-wren-455

[gunbai-bot]

Re: review 62139 — both findings actioned (b90e5b2)

The constant-false predicate — deleted, and it was the more serious finding

Verified exactly as reported. extdeps.vllm.kv_layout.allocator_usage_is_occupancy(usage) -> Bool { false } ignored its argument, and its only consumer asserted !allocator_usage_is_occupancy(...) — !false, for every input, forever. Green by construction, unable to go red.

There's a second thing wrong with it that makes deletion the right fix rather than strengthening it: it was the weaker of two statements of one fact. The module's own comment already rules that there is deliberately no function from AllocatorUsage to a request or token count — and that absence is enforced by construction: a caller wanting an occupancy ratio finds nothing to call and stops at resolve. A function that exists and answers false invites the ask and hands back something that reads as a measurement. That's validation standing where construction was already in place.

Deleted, along with the green-by-construction conjunct; the ruling stays as the absence it always was. All 8 kv_layout witnesses green by execution.

The three Int fields — declared, not silently dropped

You're right, and the distinction you drew is the one that matters: "that is an argument for a signed duration carrier or a declared 🟡, not for dropping to Int silently." The objection is the silence. DESIGN §4b(2) requires a class below its ceiling to name its next-rung trigger, and an undeclared Int sitting beside a migrated Microsecond in the same record is an unstated divergence.

gunbc.guarantee_stall.signed_and_ratio_measure_carrier_stall now carries it, rostered in all_guarantee_stalls — current: Mitigatable, ceiling: StructurallyGuaranteed, blocker: AwaitsOneGrounding { grounding: "std.measure" }, with a capability-shaped trigger.

I used the repo's existing GuaranteeStall carrier rather than a feature:/dissolve-on: comment marker, because that carrier is the modeled authority for exactly this ("no untracked stall") and a comment marker would be a second spelling of it.

On why not just wrap: Microsecond is Measure<Time, Micro, Nat> — Nat-backed, so it can hold neither a fit intercept nor a difference of two intercepts, both legitimately signed. And micros_per_thousand_tokens is a dimensional quotient, which std.measure cannot spell at all — it publishes measure_add, measure_le, measure_count and two scale-fraction folds; no product, no quotient, no composition on Quantity. Unlike the fields migrated in 11f52b0 (inert data, or summed and compared), every consuming site for these three is arithmetic — a division producing the intercept, a multiply-and-divide predicting from the slope, a subtraction contrasting two fits. Wrapping would construct a carrier and unwrap it on the next line at every site.

The trigger names the capability that ends the stall: a signed duration magnitude and a dimensional quotient in std.measure, with arithmetic to inhabit them, sufficient to express all three without any consumer unwrapping to a bare Int.

— sent from loyal-wren-455

[gunbai-bot]

Re: review 62159 — right on both counts, both fixed (5694fc9)

I migrated one arm of a coproduct and left its siblings bare. GpuReportedPowerDraw took Watt while GpuKernelBusyFraction, GpuClockObservation, RoceByteRate and RankCoarseSymmetry stayed on Nat directly beside it. That's precisely the silence the stall row itself objects to.

Migrated — exact carrier, exact conversion

field	carrier
GpuKernelBusyFraction.busy	Percent
GpuClockObservation.median_clock	Hertz — 2408 MHz as 2408000000
RankCoarseSymmetry.power_spread	Milliwatt — 17 deciwatts as 1700
RankCoarseSymmetry.util_spread	Percent

Hertz rather than MegatransfersPerSecond, which has the right shape and the wrong meaning: std.measure's own comment beside it says MT/s is semantically distinct from a clock because DDR moves two transfers per clock. Taking it here would be a meaning fork, not a migration. There is no Megahertz alias, so the Mega scaling is carried in the literal.

(busy was not on your list — same class, swept with the rest.)

The stall was too narrow — you're right, and it was worse than one field

DecodeRatePredicted.milli_tokens_per_second carried no declaration at all. The row now covers both modules and separates three genuinely different blockers instead of presenting one:

• signed — Microsecond is Nat-backed; no signed duration alias
• quotient — no product, quotient, or Quantity composition, so a per-token rate cannot be spelled
• scale — milli_tokens_per_second needs Measure<Frequency, Milli, Nat>; the One-scaled TokensPerSecond would round a sub-unit rate to zero, which is what that field exists to avoid

And one is blocked by a fork rather than an absence

The two RoCE fields would take Bandwidth = Measure<DataRate, One, Nat>. std.measure declares DataRate to be bits/s — and its live consumers disagree with that and with each other:

• extdeps.systems.nvidia records the GB10's 273 GB/s memory bandwidth as bandwidth(count: 273000000000) — that's bytes per second
• extdeps.colo.natcoweb records colo transit ports as bandwidth(count: 1000000) and 10000000 — neither reading

Three consumers, at least two mutually inconsistent readings of one carrier's base unit, ~1000× apart. Migrating into it would make these rows a third reading and cement the fork. They stay declared until DataRate has one adjudicated answer, which the trigger now names — including migrating every existing Bandwidth consumer onto it.

That fork is pre-existing and outside this PR; flagging it rather than fixing it here, since it touches extdeps.systems.nvidia and extdeps.colo.natcoweb.

Sixteen serving_critical_path witnesses green by execution.

— sent from loyal-wren-455

[gunbai-bot]

review 62185 — the pre-scan rows are settled, and the new finding stands. Disposition in 75c6a4dc5.

On the three unit-modeling rows you refuted: agreed, and thank you for checking the stall rather than re-reporting the fields. signed_and_ratio_measure_carrier_stall is the §4b(2)/(3) record for intercept_micros, micros_per_thousand_tokens, intercept_difference_micros and milli_tokens_per_second — three distinct blockers (signed, quotient, scale) plus the Bandwidth base-unit fork that blocks RoceByteRate. Nothing further owed there.

On capacity_probe_script: the finding is factually correct. gunbc.instruments.fabric_capacity_standing capacity_probe_script join([...])s an eleven-field bash program out of String literals — command substitutions, pipelines, sed, grep -oE, a per-field default — and group_report ships it to ssh … "bash","-s" as stdin_payload. No part of the substrate can read that program. I did not author this module and my branch does not touch it; I am enrolling it rather than deferring it because the class is otherwise silent.

The distinction that decides the disposition — and it is not "is this shell":

docs/plans/shell-to-dag-residual-census-and-arc-completion.md splits the remaining arc in two. A probe executed on a foreign host over SSH is in its legitimate shell bucket; foreign executors stay shell. But the same census requires legitimate shell to be "emitted through the v2 bash rows (grammar-owned), and bounded" — and this is neither. ROADMAP's translator row names this exact population as what it deletes: "the scripts assembled by gluing strings together."

So the honest gap is not that the probe is shell. It is that this instance is untracked: the census is dated 2026-07-12 against #6507, predates this module, and names no member here. §4b(2) is explicit that a class below its ceiling must name its next-rung trigger. It now does — gunbc/guarantee_stall/probe_program_assembled_from_string_literals_stall.dag, rostered, with the trigger naming the translator capability rather than the plan document (§4b(3): a trigger naming an artifact is satisfiable while the capability stays dead).

Why enrolled and not rebuilt here. The two routes available inside this PR are (a) hand-author v2 bash grammar rows for an eleven-command probe inside another lane's instrument, or (b) wait for the translator that lane exists to build. (a) is the larger risk of the two and would stand up a second hand-authored shell writer beside the one the translator is meant to delete — adding a member to the population in the act of objecting to it. That is §6's forked-logic trap, and §3's replacement-migration rule says the cut happens at the root, in the owning lane.

Rung, stated honestly: mitigatable, not lower. The failure mode is not silent-wrong — every field defaults to - and the instrument reports an unestablished standing rather than a fabricated number, so §5's floor holds. What is invisible is the class of defect: a quoting error, an empty pipeline, a sed expression that stops matching after an upstream format change. That stays invisible until the program has a grammar, which is precisely the stall.

— sent from loyal-wren-455

[gunbai-bot]

Correction to my reply on review 62185. I wrote there: "I did not author this module and my branch does not touch it." The second half is false, and I should not have said it without checking the diff.

dag/gunbc/instruments/fabric_capacity_standing.dag does not exist at this PR's merge base. It is new in this PR, +331 lines, arriving on the base branch (6963aa9ed, 8aa21c315, 2126f0225, b6f03e9ad). It is not my commit, but it is my diff, and "someone else committed it" is not a disposition — this PR is where it enters main.

That matters for the disposition I argued, so I am revising it rather than letting it stand: I claimed the string-assembled probe was a pre-existing instance that my PR merely surfaced, and enrolled it as a stall. review 62194 is right that a stall row records how debt ends and does not authorize creating it — and since the module is created here, that is the applicable rule. I'll come back to that finding separately; the two mechanical defects below are fixed first.

— sent from loyal-wren-455

[gunbai-bot]

review 62194 — all three findings verified against the code. Two fixed in ed1914fbf, one escalated to the operator. Also note the correction I posted separately: this module is new in this PR, not pre-existing as I claimed on review 62185.

Finding 1 — the re-stamped revision. Confirmed, and it is worse than a decoration.

You are exactly right about the mechanism, and the consequence is larger than "permanently green". pool_from_fields was the first and only production caller of the constructor this branch had just fixed, and the pool it builds is not inert — it flows into admit_kv_layout, whose refusal on reported.observed_at_revision (extdeps.vllm.kv_layout) is the wall, and that verdict reaches admitting: Bool. So a receipt captured from a mismatched vLLM build was being admitted by a check that could not fail.

The revision is now a parameter and its absence is a typed PoolUnobserved refusal that names the missing observation.

On your claim that "the real revision is observable there and is not being captured" — I tried to verify that and could not: 192.168.110.225 times out from this session and from srv2, and my srv1 docker context is gone. So I did not add a twelfth probe field. The probe reads systemd and two localhost endpoints, none of which answer which vLLM source the engine was built from; writing a shell command I cannot execute against a live host would be specification-without-execution (§5), which is the trap this instrument is already in. The absence refuses loudly and one call site changes when the field lands.

Finding 2 — Absent => 0. Confirmed. The module header three screens above states the opposite as its own design: "A field the far side cannot produce is a literal -, which fails to parse here and refuses — it never arrives as a zero." Both arms now refuse like the other nine.

Finding 3 — you are right, and I withdraw my earlier disposition. I argued on review 62185 that the string-assembled probe was pre-existing and enrolling it as a stall was sufficient. Both halves were wrong: the module does not exist at this PR's merge base, and as you say, a stall records how debt ends and does not authorize creating it. Escalated to the operator, because the two clean options — drop 331 lines of their live-wet instrument, or rebuild the probe through v2 bash grammar rows while the hosts are unreachable — are theirs to choose, and §5 puts scaffold approval outside the diff.

One thing neither review raised, found while fixing these: the module has no witness at all. Its only entry is fabric_capacity_standing() -> ProcessExit, an actuator that probes live hosts. So both arms I just corrected have no discriminating red, and neither did the defects — which is why a stamped constant and two fabricated zeros survived four commits. That is a §3c consumption gap, and it is the reason this module's real rung is lower than its prose suggests.

Verified compile-clean: whole-tree compile over the three compile_clean_source_roots reports 0 blocking errors in this module.

— sent from loyal-wren-455

[gunbai-bot]

review 62211 — the second finding is the valuable one, and following it to the root found something neither of us expected. ac95284bd8a.

Finding 1 (the string-assembled probe) — agreed, and already withdrawn on my side before this review landed. My earlier "pre-existing, not my branch" framing was factually wrong: the module does not exist at this PR's merge base. You and review 62194 are both right that §5's "a dissolution condition describes how admitted debt ends; it does not authorize creating the debt" is the applicable rule when the instance is created in the same diff. It is escalated to the operator — drop the module, accept the debt explicitly, or rebuild the probe — because §5 puts scaffold approval outside the diff and I cannot sign my own.

Finding 2 (the "NO BRACE" comment) — you are right that it is a workaround, and §5 says a workaround is the line-stop signal: root-cause it or flag for help. I root-caused it. The deficit does not exist.

The comment claimed the heads-only pass "counts braces without knowing it is inside a string literal, so a --format template … ends the enclosing declaration early and the module refuses to parse." That is not what the reader does:

• v1_compiler_parse::heads_skip_block_tokens walks tokens, branching on is_lbrace_shape(t.shape) / is_rbrace_shape(t.shape). A brace inside a string literal belongs to a String token whose shape is neither, so it is never counted. The heads reading is token-grain by construction — parse_module_heads_for_pool_census says so at its definition.
• And by execution rather than by reading: 691 .dag files in the corpus carry a brace inside a string literal, dag/std/types.dag:236 among them (TextFile { path: \"<none>\" inside a module-scope data initializer). That module is in every closure, so the heads census parses it on every run.

So the constraint the script was contorted around is imaginary, and the annotation asserted a false fact about the compiler for four commits — which §4c forbids specifically, because no Accepted program can read an annotation and nothing can therefore contradict it. The claim is corrected in place. I deliberately did not restore the --format templates: whether this probe survives at all is the open escalation, and reshaping its shell while that is undecided is investment in something that may be deleted.

Unprompted, and the reason both of your findings were possible: the module had no witness at all. Its only entry is a live-host ssh actuator, so nothing could go red without a fleet. That is why a stamped revision constant, two fabricated zeros, and a false claim about the lexer all survived four commits. §4b distinguishes unwritable-in-the-corpus from unwritable-as-a-fixture and only the second is a ceiling — decode_probe and pool_from_fields are total functions over captured text, so the REDs were authorable all along. Six tests now enrolled, each refusal paired with a positive control so a function that always refuses cannot satisfy them; all six green by execution.

— sent from loyal-wren-455

[gunbai-bot]

review 62225 — the blocking finding is correct, is the same one raised by review 62194 and review 62211, and I am not going to resolve it in the diff. It is escalated to the operator and has been since 22:24Z, unanswered. No commit accompanies this reply.

You name the two acceptable resolutions precisely — "operator sign-off recorded outside the diff, or the probe emitted through the v2 bash rows" — and both are the operator's to pick, which is exactly why it is escalated rather than argued. The options put to them are: drop the module from this PR and reland when the translator exists; land it with their explicit acceptance; or have me rebuild the probe through the v2 bash grammar rows now. I recommended the second and gave my reasons for not taking the first or third unilaterally: dropping 372 lines of someone else's live-wet instrument on a doctrine reading is not my call, and the Sparks are unreachable from this session (192.168.110.225 times out from here and from srv2), so a rebuilt probe would be unexecuted shell — §5's specification-without-execution, which is the same failure in a new place rather than a fix.

On the stall row being "its own cover" — that is fair and I have already withdrawn the argument it was covering. I originally enrolled it on the belief that the module was pre-existing and this PR merely surfaced it. That was wrong: the module does not exist at this PR's merge base. §5 and §6 both say what follows — a dissolution condition does not authorize creating the debt, and adding a trigger after the fact only makes the proposal eligible for a decision. The row stays because the class is real and should be tracked whichever way the decision goes; it is not offered as the answer.

On the :181-183 annotation being the "for now" tell — you are right that it reads as one, and I want to be precise about what it is. It says the script's shape is left alone because whether the probe survives is undecided. That is not a deferred refactor with no owner; it is a live escalation with a recommendation attached. But the distinction only holds while the escalation is open — if it goes unanswered it decays into exactly the "for now" you are describing, and the annotation would then be a lie by omission. If the operator picks the first option the module and the annotation both go.

Two things in that module that were more than shell debt, and are fixed (ed1914fbf, ac95284bd): pool_from_fields re-stamped vllm_source_revision_read into the reading it built, which made admit_kv_layout's revision refusal — the wall that decides admitting — permanently green; and running/waiting decoded as Absent => 0, so an engine whose metrics could not be read reported as idle. Both now refuse. The module also had no witness at all, which is why those survived four commits; six are now enrolled, each refusal paired with a positive control, and I verified by restoring both defects in a scratch worktree that all three refusal tests go red — they discriminate rather than being green by construction.

Pre-scan rows — agreed and nothing owed; signed_and_ratio_measure_carrier_stall is the §4b record for those fields.

— sent from loyal-wren-455

[gunbai-bot]

Closed on the operator's verdict at ac95284bd8a54f077b92352fa0e47dbe417cb158. The branch spark/serving-receipt-schema is preserved as investigation history and is not deleted. The open escalation is retracted as answered: A — drop fabric_capacity_standing.dag.

Not merging, and not attempting another rescue round. The decisive point is that this PR's terminal state is not merely old, it is false again: the later MFU evidence establishes that the honest per-step counter follows ceil(tokens / 2048) while iteration_tokens_total_count is an output/accounting event — and serving_critical_path.dag still constructs BehaviouralPerIterationCapacityAtLeast { computed_tokens: 20082 }, serving_step_cost.dag still reasons from that interpretation, and metrics.dag still answers that the histogram count measures engine steps. A green CI run does not repair a false authority, and this one is green.

On the finding I want to own, because it is a defect I introduced. The verdict is right that the production entry calls pool_from_fields(f: f, observed_revision: none) unconditionally — I verified it: one production call site, :327, always none. So the production path always returns PoolUnobserved, and admit_kv_layout, the capacity floor and any Admitting result are unreachable. My earlier fix removed a stamped constant that made a refusal wall permanently green, and I described the result as the instrument "refusing where it used to silently agree with itself." That was true and incomplete: it also left the instrument unable to answer its own question at all. And my positive control a_pool_built_with_an_observed_revision_is_admitted supplies a revision the real probe never acquires — so it proves a hypothetical caller can get further than the production entry, not that the instrument can. A fixture that reaches past the live path is not coverage of the live path.

That makes A the right call for a stronger reason than the shell debt the three reviews raised: B would take on maintenance for no operational capability, and C would generate a probe whose live path still cannot establish its prerequisite.

Also accepted without argument: surface_binding_for_revision compares only full_revision and ignores VllmSourceRevision.repository, returns SurfaceBound on a string match without observing whether any required attribute exists, and therefore leaves SurfaceRefusedForMissingField unreachable through that function — so the scratch wheel's Python tests, not the .dag manifest, currently own field-presence compatibility, which is the second authority the generated artifact was meant to remove. And ServingStepReceipt promises one engine step while the wheel overrides only schedule(), which times the allocation decision, not schedule → execute → collectives → output. That is the observer reproducing the exact wrong-grain failure class it exists to delete, and it needs schedule_decision_elapsed and engine_iteration_elapsed as separate facts.

Carried forward into one consumed observer PR from current main: exact VllmServingLaunch and its same-launch join; reading SchedulerOutput rather than the already-advanced live Request; resolving the delegate through async policy and executor support (the Ray-vs-MP divergence); exact-revision refusal for an unstable seam, once complete identity and live shape are actually checked; metric-paired-with-question with unsupported pairings refusing; and the generated NotCommitted Python package.

Not carried forward: the DeepSeek critical-path data and fitted conclusions, the step-cost module, the 20,082 standing, the co-tenant receipt, the current iteration_tokens_total_count interpretation, fabric_capacity_standing with its witness and stall row and roster entry, the approximate KV-layout/capacity-floor chain, and the power prose. The NVIDIA 120 W / 240 W platform facts belong in the external hardware authority, not here.

— sent from loyal-wren-455