Spark serving route: the operator's site allocation, and a first-party self-use posture behind it

[gunbai-bot]

Two deliberate walls stood between a dashboard dispatch and a placed serving
turn, and either alone unblocks nothing, so they land together.

WALL 1 -- THE ROUTE HAD NO REGION. gunbc.spark.serving_offer refused every
offer because a ProviderRoute needs a region and nothing observes which region
a serving host sits in (withdrawn by operator ruling 2026-09-09). That refusal
was right for a rented route. For a unit the operator owns and physically
holds, no observer can ever exist -- the site is what the operator says it is
-- so the fix is not an observer but an ATTRIBUTABLE ALLOCATION, and
SparkServingRoute grows a third arm, ServingRouteOperatorAsserted, so the two
kinds of fact are told apart by matching rather than by prose. The allocation
is the operator's 2026-09-11 assertion that every Spark unit sits at his NYC
home, outside the rack, carried in the OperatorAllocation carrier
gunbc.spark.dgx_procurement already uses for the slot join. "Right now" is
carried by decided_on: a move into the rack is a NEW row, never an edit.

THE SITE IS NOT MINTED. gunbc.fleet_physical_inventory operator_site already
IS the operator's premises and gunbc.fleet_site_locale records that minting a
second SiteIdentity for this exact place was already done once and reverted as
the section 3 nickname failure. "Outside the rack" is a per-asset
RackResidence fact, not a site fact.

WALL 2 -- PROVIDER USE. gunbc.spark.first_party_serving declares the posture
the route is used under: gunbc serving gunbc, our own material, on
operator-owned hardware, with no third party and no border crossed. The
provider anchor is declared in OUR layer because for self-hosted serving the
provider is us; vLLM and the weights stay upstream facts in extdeps and are
what the service runs, not who provides it.

"FOR NOW" IS ENFORCED BY EXECUTION, NOT WRITTEN DOWN. The single sanction row
is bound to this posture revision, so another customer profile refuses as
CustomerScopeUnsupported and a superseded posture refuses as
PostureRevisionStale -- both are reds in the new witness.

NO FABRICATED LEGAL FINDINGS. The three use dispositions are required to be
DispositionCleared before a permit mints, and each one's evidence names a
declaration stating the program is NOT ENGAGED under first-party self-use --
no screening was run and no determination is claimed. A witness asserts the
permit carries exactly those references, so swapping one for a clearance goes
red.

WHAT STILL DOES NOT PLACE A TURN, stated rather than implied: a CandidateOffer
needs a demand and a work identity, a WorkKey comes only from
product.fabric.work derive_work_key, and gunbc.serving.turn_demand refuses to
bind a source manifest because nothing observes the weights, tokenizer and
runtime closure a launch loaded. harness_seat's refusal note is repointed from
"no provider-use admission producer exists" -- which stops being true here --
to that obligation, and the admission producer carries it as a declared
frontier (DESIGN 3c) with the receipt that retires it as its trigger.

The witness that asserted the standing refuses flips to a regression control
per DESIGN 4b(4) rather than being deleted.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WT6FDJa7Nyh9SJv25sM1Ui

[gunbai-bot]

Addressing review 63981.

Finding 1 — blocking, fixed at the root in 992fa06. The review is right and the argument is the one this module's own annotation made and then walked past. DispositionCleared meant both "a program resolved in our favour" and "a program has no subject", the honesty lived in NonEmptyStr fields nothing matches on, and the witness compared a DeclarationRef — so editing the cited row into a real clearance would have kept it green. That is a name check, not a wall.

The fix is upstream where the fork is, and it is the ProviderPathAbsent / ProviderPathUnread move the review names: product.fabric.provider_admission DispositionStanding grows a fourth arm, DispositionNotEngaged { basis }. It admits, like a clearance, and it is not one, so the two are separated by matching.

Two consequences beyond the arm:

• ProviderUseEvidence now records the standing rather than a projection of it (prohibited_use_standing / sanctions_standing / export_standing). With two admitting arms, a permit carrying only a DeclarationRef cannot say which one admitted it — exactly the "every consumer sees them as the same fact" half of the finding. disposition_evidence dissolves with the question it existed to answer (DESIGN 4b(4)); its zero-or-one list was the right answer to a question that stops existing once the value itself is carried.
• Both witnesses now match the arm. every_use_program_is_not_engaged_and_names_its_basis goes red if a not-engaged row is swapped for a clearance, and w_permit_records_its_clearances goes red in the other direction.

Corroborating finding — the nine identical paths, and one of them is worse than the review says. Agreed that one assertion answering for telemetry, logs and support access is not "each path answers for itself". Eight of the nine the operator's assertion does genuinely answer — the box is at his site and nobody else has access, so that is where execution, durable storage, backups, logs, spill, control plane, support and administrative access terminate.

Telemetry is the one it does not. vLLM collects usage stats unless VLLM_NO_USAGE_STATS or DO_NOT_TRACK is set; nothing in our corpus sets either and gunbc.spark.pair_serving_realization's container env does not. I cannot observe the host (SSH needs the GCP-secret password and I hold no token), so the honest arm may be ProviderPathUnread — which refuses as ProviderRouteFactsIncomplete and re-blocks the dev run for a new, true reason. Whether that reporter is a path of this route's material is not my call to make silently, so it is escalated rather than papered over; the answer lands as a follow-up commit here.

observed_at: "2026-09-11T00:00:00Z" is the date of the assertion at date grain, matching the existing convention in gunbc.instruments.fabric_control_plane_live_probe. The time-of-day carries nothing and I will say so beside it in the telemetry commit rather than leave it reading as a moment someone measured.

— sent from keen-owl-253

[gunbai-bot]

Telemetry, following the operator ruling (2026-09-11) on the escalation — 98d3ce6.

The corroborating half of review 63981 turned out to be worse than a modelling smell. vLLM reports usage statistics to https://stats.vllm.ai unless a launch disables it, and gunbc.spark.pair_serving_realization's container environment sets neither VLLM_NO_USAGE_STATS nor DO_NOT_TRACK. The first spelling wrote the operator's site into that slot — false about the one path that demonstrably leaves it, and false in the direction that reads as clean.

So the path now carries its real destination, grounded rather than asserted. extdeps.vllm.usage_stats cites the docs page, usage_lib.py and envs.py, bound to source revision 1967a5627bc3 — which is the revision extdeps.vllm.server already reads and the one the running engine names in its own version string. It carries the documented field roster, the default server, the override and opt-out env vars, the marker file, and a typed content class: configuration and hardware metadata, no request content, prompts or completions. That class is what lets the path admit rather than refuse — the closure governs paths reaching the route's material, and this one carries none. The operator's condition for refusing instead was that the documented schema contain route material; it does not.

Two things I am not hiding:

• The jurisdiction slot cites a field, not a place. Upstream documents the server and nothing about who operates it or under which law, so the slot points at the field holding ServiceJurisdictionUndocumentedUpstream. ProviderPathLocated cannot express "located at a party whose jurisdiction is unread" — a consumer matching Located reads all three components as known. Next-rung trigger named in the module: a jurisdiction standing on ProviderPathStanding sufficient for a located path to say its jurisdiction is unread without the whole path becoming unread.
• The remedy is named, not blocked on. VLLM_NO_USAGE_STATS=1 on the serving launch, on a box the operator owns.

The posture row now states both halves — route material stays on site, one metadata-only path reaches vLLM upstream by default — so a reader of the posture is not told a stronger thing than the facts support. observed_at is annotated as the assertion's date at date grain rather than left reading as a measured moment.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 63995 — 618db79. All three findings are the same class as the first review's, and that is the useful part of them: a typed carrier is not evidence until something matches on it.

1. The roster gates the standing. Correct and the worst of the three. spark_serving_route_standing() took no argument, so the eight-unit allocation constrained nothing — a group on a machine the operator never placed at his home would have bound an offer whose region cites an assertion about other machines. It now takes the group's hosts and refuses unless every one is covered, returning the uncovered set rather than a Bool, because a predicate discards exactly the host the refusal has to name. The harness passes fabric_group_hosts(g: group).

One thing the finding did not ask for and the fix needs: the empty list refuses. Written the obvious way — all(hosts, covered) — a group whose membership could not be read would pass vacuously, which is the check reading cleanest exactly where it knows least. Folding the uncovered set makes the empty case a separate refusal with its own obligation. Both arms are REDs (a_host_outside_the_allocation_refuses_and_names_it, an_unreadable_group_membership_refuses).

2. The content class and the launch standing are folded. Correct, and it is the disposition defect re-landed one level over, as the review says. The telemetry path's arm is now derived from both carriers rather than chosen beside them: a launch that disables reporting → ProviderPathAbsent; a launch nobody read → ProviderPathUnread; a reporter that ever reports CarriesRequestMaterial → ProviderPathUnread against a declared obligation naming the remedy, because that is route material leaving the site and the posture rests on it not doing so. Only the metadata-only case is Located. The operator's ruling was made about a payload, and it is now conditional on that payload in code.

3. The jurisdiction departure is a rostered drop. Correct — a next-rung trigger in a comment is invisible to 4b(2) and to the roster that exists to count exactly this. gunbc.rung_drop.provider_path_jurisdiction_unread_admits declares it: population, previous and temporary rungs, and a trigger naming the capability — a jurisdiction standing on ProviderPathStanding sufficient for a located path to declare its jurisdiction unread without the whole path becoming unread. It states explicitly that looking up who operates stats.vllm.ai does not discharge it, since that fills one slot on one route and leaves every other located path in the same unexpressible position.

I did not take the other offered remedy (widening ProviderPathStanding now) in this PR: it is a change to a generic fabric authority that admits for every route, and it deserves its own change rather than riding in on a spark serving PR. The drop is the mechanism DESIGN provides for exactly that gap, and it is now countable.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 64033 — eb94bf9. Both findings are this PR's own lesson applied to the two lines that did not get it.

1. The usage-stats launch standing was transcribed from a module that models it. Correct, and it is the same defect the diff fixes one function below for the content class — spark_pair_container_env owns that environment, so a sentence about it is a second authority that rots the moment someone edits the first (DESIGN §6, name the instrument). It is folded now: every observed fabric lane's container environment against extdeps.vllm.usage_stats' own disable_env_vars. The consequence the review named is now closed in both directions — adding VLLM_NO_USAGE_STATS=1 to the launch flips the standing, flips the telemetry path to ProviderPathAbsent, and takes the rung drop's population out from under it with no edit here.

Three properties of the fold that a bare predicate would have lost:

• Every lane must disable it, not any. A group serves from several hosts, so a reporter on one of them is an egress for the route. The fold is over the lanes that do not disable it, and the disabled arm needs that set empty.
• An empty lane roster is UsageStatsLaunchUnread, not disabled — the same vacuous-all() trap the host-coverage fold avoids two functions up, which would otherwise read cleanest exactly where it knows least.
• A name set to "0" is not a disable, since upstream parses these as booleans; matching on the name alone would have read a present-but-false assignment as off.

A witness asserts the arm the fold selects, so the day the launch disables reporting, the rostered drop stops describing a path that exists and the witness says so rather than the roster quietly going stale.

2. staleness_condition claimed to be machine-read and was not. Also correct, and the sharper version of the review's point is that this is worse than an annotation: an annotation does not claim to be read, and mine did — "every consumer of this row reads this", with nothing folding it. Deleted. What enforces "for now" is what always enforced it: spark_first_party_posture's revision, the single roster row bound to it, and the RED that drives a superseded revision through admit_provider_use and requires PostureRevisionStale. The annotation now says that instead of claiming a fold that does not exist.

I kept serves / data_subject / hardware_custody, and the review agrees: those are the evidence an auditor reaches by following a DeclarationRef out of the permit, which is a cited row's job. The line between them and the deleted field is whether the module claims a machine reads it.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 64043 — ae905c8. One finding, and it is the sharpest one this PR has had: the predicate failed in the admitting direction.

spark_lane_disables_usage_stats asked whether a disable variable's value was anything other than "0". Upstream asks whether it equals "1" — os.environ.get("VLLM_NO_USAGE_STATS", "0") == "1", and DO_NOT_TRACK the same way. Those disagree on =false, =no, =0.0 and every other spelling a person would expect to mean off, and the disagreement runs the wrong way: the launch keeps reporting, the standing reads UsageStatsDisabledByLaunch, the telemetry path becomes ProviderPathAbsent, and the rostered rung drop's population evaporates under a route that is still sending. A machine claim authored in our layer instead of cited, reading clean while the engine talks.

The reading now lives in extdeps.vllm.usage_stats, cited to envs.py, and the names moved with it: a VllmUsageStatsDisableTerm is a variable and the exact value that disables it. That pairing is the actual repair — keeping a bare name list beside a separately-authored value test is what allowed the two halves to be recombined wrongly in the first place. vllm_usage_stats_assignment_disables performs exact equality on both components; no truthiness, no case folding, no "anything non-empty", each of which is a consumer's guess about a reading the upstream module can simply state. gunbc now supplies the launch's assignments and reads nothing into them.

On the corroborating point — upstream's third term, the marker file — I named it where it is not folded rather than folding it: a container environment cannot answer whether a path exists inside the image or the home directory, and guessing would re-import the same defect one term over. Its absence errs conservatively (a fleet disabling reporting only by marker file reads as EnabledByDefault, which over-declares the egress rather than hiding it), and the honest closure is a filesystem observation, not a bolder predicate. That is stated in both modules so the gap is readable from either end.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 64068 — 122e36c.

The unresolved DeclarationRef is real and the review is right about why it is worse than an ordinary broken reference. spark_usage_stats_carrying_request_material_obligation was declared, then lost when I rewrote the launch standing into a fold for review 64033, and the decl_ref to it survived the deletion. That arm is the one the rung drop's operator condition is declared to execute against — the admission was granted on the condition that the payload stay metadata-only — so the single path where that condition discharges was the single path whose reference pointed at nothing, and an auditor following the refusal out to the remedy would have landed nowhere on the day it fired.

The row is restored beside spark_serving_usage_stats_unread_obligation, naming both remedies: disable on the launch (which the standing folds, turning the path Absent), or re-assess the posture with the operator. I then swept every decl_ref in the three touched modules and both witnesses against its target — no other unresolved citation.

Also in this commit: the generated projection. docs/design-rung-drops.md has been stale since the drop row landed, and that — not anything in the .dag — is what both completed CI runs refused on (generated-artifact drift, population=docs-projections), while required-witnesses-floor itself passed. Regenerated through docs_projection_gate regen; the diff is +4 lines, exactly this row.

One thing worth recording for whoever owns that lane: heal-generated-artifacts failed on both heads rather than repairing the drift, which is precisely what that job exists to do. Doing it by hand cost two CI cycles here, and the next author to add a rung-drop row will pay the same unless the heal path is looked at.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 64100 — 5bf3568. The finding is correct and it is the one I should have caught myself: I wrote the export and sanctions bases before modelling the telemetry egress and never went back to them.

They said "nothing leaves gunbc", "no transfer", "no recipient", "nothing is supplied or made available to any party outside gunbc" — while three functions later the same module admits a ProviderPathLocated to a third-party service with a jurisdiction upstream does not document. A permit's own evidence contradicting the route facts it was minted against is exactly the class this PR exists to close, sitting inside the rows written to close it.

Both are narrowed to what is true, and the egress is named in each rather than omitted — a basis that stayed silent about it would be contradicted by this module's own ProviderRouteFacts:

• Export. No route material leaves and none crosses a border: prompts, responses and the weights they run against begin and end inside gunbc at one site. What does leave is host, build and engine-configuration metadata from vLLM's usage-stats reporter, cited to extdeps.vllm.usage_stats, to spark_usage_stats_telemetry_path, and to the declared drop that admits its unread jurisdiction. That egress carries no request content, so it is not route material, and the row does not claim it was classified.
• Sanctions. No good, service or route material is supplied to any party outside gunbc, so there is no counterparty to screen. The reporter is an emission to a recipient, not a supply to a counterparty, and it is named as such rather than left out of the sentence.
• Prohibited use is unchanged and needs no carve-out: a telemetry recipient is not a user whose use could be governed.

Each row states the condition that would give it a subject, and both conditions are executed elsewhere in the module rather than promised — a turn served to anyone else refuses as CustomerScopeUnsupported, and a reporter that ever reports CarriesRequestMaterial refuses through the telemetry fold.

— sent from keen-owl-253

[gunbai-bot]

Correction to something I wrote in the 122e36c commit message and in an earlier comment here: I was wrong that heal-generated-artifacts failed rather than repairing the drift.

Heal did regenerate docs/design-rung-drops.md correctly — commit c1f349c20e, 1 file, 4 insertions, which is byte-identical to what I later produced by hand. It then lost the push race against my next head and reported that as an untyped red with a bare git hint, which is what I read as a failure to heal.

So the two cycles cost here were a push race, not a defect in the heal path. The practical rule, which I should have inferred from the shape rather than blaming the job: do not push while a heal run is in flight on your head, or you reject its push and inherit its red. I am leaving the original sentence in the commit message rather than rewriting history, and correcting it here where it is visible beside it.

The underlying observation still stands for whoever wants it: an untyped red with a git hint is an unhelpful way for that race to surface, since it is indistinguishable from heal refusing. But that is a diagnostic-shape issue, not the broken-job claim I made.

— sent from keen-owl-253

[gunbai-bot]

Addressing review 64115 — 0754941. Correct: extdeps.docker does not declare DockerEnvAssignment; extdeps.docker.cli does. And the import was unused besides — the fold reads e.name and e.value off the values spark_pair_container_env returns and never names the type — so it is deleted rather than repointed.

That is the ordinary compiler floor (names resolve), which DESIGN §4b puts beneath every differentiating claim, so it earns its own push under the rule I am otherwise applying: correctness defects get a commit, style and wording get a reply.

I swept every import in all seven touched files against its defining module while I was in there, to avoid spending another cycle on a second instance. Two flags came back and both are artifacts of the sweep rather than defects: String is a kernel type declared in a map rather than a type row, and FabricGroupA is an arm of a single-line coproduct. No other unresolved import.

— sent from keen-owl-253