Repository navigation
Spark serving walls: operator's NYC-home site allocation + first-party self-use provider posture - #11287
Closed
gunbai-bot[bot] wants to merge 35 commits into
Closed
Spark serving walls: operator's NYC-home site allocation + first-party self-use provider posture#11287gunbai-bot[bot] wants to merge 35 commits into
gunbai-bot[bot] wants to merge 35 commits into
Conversation
THE DEFECT WAS MINE AND IT WAS LATENT RATHER THAN THEORETICAL. The telemetry fold read gunbc.spark.pair_serving_realization's container environment over the GLOBAL fabric lane roster, and the service reference named gunbc.spark.pair_serving_desired -- neither of which takes the launch being offered. A native GLM launch, whose actual environment nothing here models, would have inherited pair-serving's DESIRED answer and been admitted on route facts describing a different deployment. Nothing was wrong while one deployment existed; it fires the moment a second engine uses this path. THE SUBJECT IS NOW THE REALIZATION THAT ANSWERED. SparkServingRealization carries the endpoint and the hosts, which are the two things this module's questions actually turn on: the hosts decide whether the operator's site allocation covers the machines, and the endpoint decides whose container environment may be attributed. Both the route standing and the route facts take it, so the two answers can no longer come from different deployments. SCOPING BY HOST IS ONLY HALF, AND THE SECOND HALF IS WHY THIS IS NOT A ONE-LINE FILTER. spark_pair_container_env is keyed on a LANE, so scoping to the serving hosts still hands a native launch on those same machines the pair-serving container's environment. The environment this module can attribute is that container's, and the discriminator present at the offer is the port that answered. A deployment with no environment model is UNREAD -- and unread is an unresolved data path, so provider-use admission REFUSES rather than inheriting. Three REDs: a foreign deployment on the same hosts is unread and not inherited; that refusal reaches admission as route-facts-incomplete rather than stopping at the standing; and a pair realization with unreadable membership is unread for its own distinct reason. AND THE RECURRING FAILURE MODE ROW RIDES HERE. It was drafted to land with #11139, which edited the string it is about, but #11139 merged without it -- and a row parked behind a merged host is the quiet deferral the tripwire existed to prevent, so it lands on the next legitimately-running change rather than in a third PR. The class: an emitted diagnostic asserts a positive standing for a check that did not run on the path that emitted it. Three receipts, all one sentence: it misled its author, it misled a manager and a reviewer into reporting both spark walls down, and it misled its author again into arguing his own correction was pointless. Overlap checked against the three nearest rows before minting. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…verage refuses Both findings land on the same weakness: the first spelling of this repair moved the subject to the realization but kept deciding from things that are not evidence about the process that answered. 1. A PORT IS WHERE SOMETHING ANSWERED, NOT WHAT IT IS. Attribution keyed on the endpoint's port, so a replacement engine on the same port inherited the pair-serving container's environment with nothing observing it to have one -- the declaration-as-realization defect this change exists to remove, surviving inside the removal. The join is now LAUNCH-BOUND: the models-route readback carries the configured_model_path the running engine itself reported, and gunbc.spark.pair_serving_realization derives the path the pair-serving launch is declared to serve. Those agreeing is evidence about the process; a different engine serving a different checkpoint answers with a different path, and an unresolved readback identifies nothing at all. WHAT IT STILL DOES NOT ESTABLISH, in the annotation rather than left to a later reader: a configured path is strong evidence about intent and no evidence about bytes, so this identifies WHICH DECLARED LAUNCH the process is, not which weights it loaded. The incarnation join stays open. 2. PARTIAL COVERAGE IS MISSING EVIDENCE. The lane fold refused only an EMPTY result, so a realization with one observed and one unobserved host resolved from the observed one and silently dropped the other. Every host must now have an observed lane; the unobserved set is computed and refuses on its own obligation, distinct from the empty-membership one. Three new REDs: a partly observed realization is unread rather than answered from its observed half; an unresolved readback leaves the deployment unidentified; and the foreign-deployment red now differs from the pair fixture in WHAT THE ENGINE REPORTED rather than in where it answered, which is the discrimination the port-keyed version could not make. The harness threads the readback it already holds from HarnessBackendServing, so the identity join reads the same observation the candidate was admitted on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
… under prose saying it decides TWO FINDINGS, AND THE FIRST IS THIS PR'S OWN NEW ROW APPLIED TO THIS PR. 1. AN ENDPOINT FIELD NOTHING READ, UNDER AN ANNOTATION CLAIMING IT DECIDED ATTRIBUTION. Review 64424 moved attribution from the port to the readback; the field survived the move and so did the sentence justifying it. Nothing in the module read realization.endpoint -- the only field reads are hosts and readback -- so it was a declaration with no consumer, carried by three callers and three fixtures, under prose asserting an executing relation no operation performs. That is exactly diagnostic_asserts_standing_no_check_evaluated, which this same change files, found by that row's own review tell: name the producer the sentence asserts an outcome for, and grep the arm for it. There was none. The field is deleted rather than kept for later, the rationale in both modules now describes the two fields that exist, and the fixtures and imports that existed only to fill it go with it. 2. A REPURPOSED ARM KEPT THE OBLIGATION OF THE CONDITION IT NO LONGER TESTS. The empty arm used to fire on an empty LANE ROSTER and its text said so -- read the lanes. It now fires on unreadable HOST MEMBERSHIP, where reading every lane in the roster fixes nothing. The diagnostic named the wrong located fact and the wrong remedy, which is the same class again one arm over. It now names group membership as the located fact, and its witness asserts on that rather than on the stale sentence -- the witness whose own comment already said "what is missing is which hosts serve it" while asserting "no fabric lane", which is the mismatch made visible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…iling bright-boar-435 supplied a fourth reading of the same sentence, and it is worth more than the other three combined because it happened with the diagnosis already in hand: after the class had been named and the correction written, they told me the corrected string was unreachable, citing the dev end-to-end receipt as corroboration -- and that receipt was the sentence being emitted. So the cost line is four readers, not three: the author when he wrote it, a manager and a reviewer reporting both spark walls down, the author again arguing his own correction was pointless, and the person who caught it, after catching it. That settles what the row asks for. Four consecutive readings by three people who all knew about the class is the argument that a review habit does not fix this -- only the construction does, where a refusal note is built FROM the check's outcome value so a standing with no evaluated outcome cannot reach the text at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…t blocked everyone
gunbc#11137's transition-admission row admitted a TargetChanged binding on
extdeps.tools.sha256sum::extdeps_external_authority_anchor, created when a bare
import of extdeps.filesystem.filesystem_io became { Filesystem } and the
spelling's candidate set narrowed from three modules to two without changing
what it resolves to. Its stated trigger was "this row goes when #11137 merges".
#11137 merged at 06:35:25 today, so the base carries the named import, the delta
stopped being producible, and the deletion came due on this roster's next touch.
This is that touch. The roster is empty again, which the file already records as
its resting state.
DELETING A ROW WHOSE STATED TRIGGER HAS FIRED IS EXECUTING ITS DECLARATION, NOT
OVERRULING ITS OWNER. I asked rather than assumed, because it is another
program's roster; the ruling is bright-eagle-728's, on the measurement that four
unrelated lanes were each blocked by it and each reached the same deletion
independently.
AND IT DID NOT MERELY LINGER, which is the part worth leaving in the file. A
spent row matches no delta, so the wave phase reports it as an UnmatchedAdmission
refusal in stale_admissions -- correctly, since a row provable against neither
side is not evidence -- and that REFUSES the required floor for every pull
request whose base already carries the merge. Measured rather than inferred: PRs
based on 0c93af0 reported the stale row and a PR on an older base reported
none.
THE SHAPE TO FIX WHEN THIS ROSTER IS NEXT DESIGNED is recorded beside the empty
roster: a retirement condition written as a SENTENCE naming a merge does not
retire when that merge happens, because the trigger is readable by people and by
nothing else. The row outlives its own condition and the cost lands on whoever
opens the next pull request. Deriving retirement from the merge -- the positive
proof admission_consumed_at_base already performs for the consumed arm -- would
make the deletion structural rather than a debt passed between lanes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
Three corrections to the dissolution record, none to the deletion. THE FILE ALREADY RULES ON THIS AND I ARGUED IT FROM CONVENTION INSTEAD. Its own words: "the phase refused every unrelated change, so the shrink is the fix, not housekeeping", and "each transition adds its rows here and removes them when its subject lands". So the deletion is this roster's documented dissolution rather than unrelated cleanup riding a route-facts diff, and it is the same motion as the two shrinks already recorded here. STALE AND CONSUMED ARE TWO FRAMES FOR ONE ROW AND THEY BLOCK DIFFERENTLY. The dissolution records say consumed -- satisfied at the base, a typed receipt. The floor said stale -- an UnmatchedAdmission refusal, which fires whether or not anyone touched the roster. That is why this PR refused on a file byte-identical to main's, and why a record saying only "consumed" would not explain the red that forced the edit. Both are named now. AND SHRINKING EARLY CANNOT FAIL OPEN, which is the argument for not waiting on the row's owner: the file rules that empty does not mean permissive -- with no rows, a real delta refuses as UNADJUDICATED. The worst case of an eager deletion is a loud refusal naming the delta, never a silent admission. Also recorded: this is at least the fourth occurrence of the shape, not a novelty -- 53 rows once outlived their subject, a later state had 314 stale, #9689 measured six, tonight one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…aying it was
Verified in main's source before rewriting, because the correction goes against
what the row itself claimed. admission_consumed_at_base's Binding arm proves
consumption only on set.len() == 1 && set.contains(target) -- "a singleton set
equal to it, not merely containing it" in its own doc -- and the retired row's
documented head set is {extdeps.shell, extdeps.tools.sha256sum}, two members.
len() == 1 is false for it forever.
SO ITS TRIGGER PROMISED A DISPOSITION THE EVALUATOR CANNOT ASSIGN. "CONSUMED
comes due on the roster's next touch" was never reachable; the row could only
ever report STALE, which is the arm that refuses every unrelated pull request
rather than the polite one that waits. My record repeated that false prediction
by framing stale and consumed as two frames on one row, as though the polite
path had been available. It was not. The accurate history is that the subject
landed, the delta stopped being producible, and the row went stale, refusing
everyone until deleted.
AND THE GENERALISATION IS BIGGER THAN THIS ROW: any TargetChanged binding row
whose head candidate set has more than one member has an unreachable CONSUMED
condition, because only a narrowing ending at exactly the target can be proved.
Every other shape can only go stale, and stale is fleet-wide. That is a section
4b(3) defect -- a declared trigger naming a disposition the evaluator cannot
assign, so the row never retires and the cost lands on whoever opens the next
pull request.
This file already carries the opposite correction -- a record predicting stale
for rows that reported consumed -- so both directions of the confusion are now
recorded beside each other, which is the argument for deriving the retirement
rather than writing it.
Found by the effectful reviewer reading the consumption predicate rather than
the row's explanation, and relayed by bright-boar-435; I re-derived each step in
source rather than taking it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…sposition My dissolution record ended by proposing that retirement be derived from the merge rather than written in a sentence. That work already exists: gunbc#11165, "Derive admission consumption from exact candidate sets", checks Binding.expected_candidates by equality at head before admission is granted, derives consumption from the same proof at base, and removes the hand-written lifecycle prediction so the evaluator prints the computed disposition. So the paragraph would have been stale the moment that lands, and worse, it read as my proposal for something someone else had already built. It now states the defect as it stood today and NAMES the fix as a declared frontier with its trigger beside it: when #11165 lands, a row's retirement stops being a sentence anyone has to honour, stale means NEGLECT rather than structural impossibility, and the unreachable-CONSUMED shape becomes unwritable rather than documented. Verified the PR's subject and files before citing rather than relaying the description. The recurring_failure_mode row this PR carries is untouched and is not duplicated by #11165's: mine is a diagnostic asserting a standing nothing evaluated, theirs is a written row not being a firing mechanism. Neighbours, not one claim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…eleted The finding is this PR's own subject, in this PR, for the third time -- and the reviewer names that: a change whose entire point is prose asserting a standing nothing evaluated, shipping prose asserting a discriminator nothing performs. THREE SENTENCES SURVIVED THE MOVE. Commit 8c433e5 deleted the endpoint field because attribution had moved to the readback; three annotations in the two witness files went on describing attribution by port. The fixture header said the realizations "differ in the single field that decides attribution -- the port that answered", 27 lines above a sentence correctly saying they differ in what the engine reported; the headline RED said "one different port"; and the route witness said whose environment may be attributed is "the endpoint's question". SparkServingRealization has had no port since that commit. All three now describe the model path the running engine reported, which is what the fixtures actually vary. The route witness's note also now says why its readback is held UNRESOLVED: that standing never consults it, and a fixture supplying a resolvable one would invite a reader to think it did. AND THE IDENTITY PAYLOAD IS CONSUMED RATHER THAN DROPPED. RealizationIsPairServing carried configured_model_path and the only match discarded it -- structurally the same unconsumed-field finding as the endpoint. The standing's basis now names the path the join matched on, so an auditor reads WHICH launch was identified rather than that one was, and the witness asserts that path rather than only the arm. The expected value comes from the same producer the module compares against, so the assertion cannot drift into agreeing with itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
The ground I gave for deleting the spent row was that it came due on the roster's next touch and that this PR had to re-run anyway. Both are true and both are arguments from convenience -- the "ride it along" shape that widens a change's subject, which is the thing a reviewer should refuse whoever offers it. The correct ground is SCOPE. With that row in its tree, this pull request could not pass its OWN required gate: a spent row refuses the floor structurally for every PR whose base carries the subject's merge. Deleting it is this PR repairing its own blocker, which is inside any change's subject whatever file the blocker lives in -- and it carries no freight, because the evaluator is untouched and nothing about how admissions are judged rides along with the removal. That justification stands on its own terms rather than requiring anyone to accept an economics argument, which is the difference between a defensible bundle and a convenient one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…m-realization # Conflicts: # src/v1/stage0/src/namespace_wave_admission.rs
…he launch that answered TWO FINDINGS FROM ONE OPERATOR REVIEW AT 3bcf3d8, REPAIRED TOGETHER BECAUSE THEY ARE TWO HALVES OF THIS PR'S OWN CLAIM. The title says route facts come from the realization that answered rather than from a declaration. Both halves still came from a declaration. FINDING 1, THE TELEMETRY HALF. Matching the engine-reported configured_model_path against the pair-serving snapshot establishes path agreement, not which process is running -- yet the match authorised attributing spark_pair_container_env(lane), which RENDERS THE ENVIRONMENT A CONTAINER IS CREATED WITH and observes nothing. The counterexample needs no exotic input: same hosts, same configured path, a different effective environment or runtime, and every input to the join is identical. The standing fed ProviderPathLocated/Absent and then provider-use admission, so it was a deciding attribution rather than a label. THE REPAIR IS AT THE STANDING AND THE DEPENDENCY IS DELETED RATHER THAN POSTPONED. Missing launch-bound evidence yields UsageStatsLaunchUnread; neither an enabled nor a disabled standing is claimed. Keeping the declared-environment fold behind today's empty disable-term population would only postpone the same attribution, so spark_lane_disables_usage_stats and spark_realization_lanes are deleted and this module NO LONGER IMPORTS spark_pair_container_env AT ALL. FINDING 2, THE SERVICE HALF, WHICH NOBODY HAD LOOKED AT. spark_serving_route_standing read only the hosts, so whenever the site allocation covered them it returned a route unconditionally naming gunbc.spark.pair_serving_desired as its SERVICE -- an unreadable or foreign readback received the pair service by default. THE TWO HALVES OF A ROUTE REST ON DIFFERENT EVIDENCE, which is why this needs a fourth arm rather than a stricter guard. The REGION is the operator's dated allocation: a fact about where the machines sit, true whatever answered on them. The SERVICE is a claim about which deployment answered. ServingRouteServiceUnidentified carries the allocation and refuses the service, so the valid region assertion survives a refusal it has nothing to do with. The service is now derived from spark_realization_identity, and the binder does not bind without it. WHAT IS DELIBERATELY NOT HERE. A deployment-independent service would have to MEAN that rather than cite a particular desired deployment, and spark_first_party_service_ref names spark_pair_serving_desired -- making it honest is a redesign of what the first-party service is. And the positive control with launch-bound evidence is not authorable: no evidence-bearing path exists, and inventing one is what the review forbids. It lands with that path. THE OPERATOR'S 2026-09-11 JURISDICTION RULING IS NOT WITHDRAWN. It waives a located path's jurisdiction; it never established attributing a reporter to a launch. The Located arm is retained and currently unreachable, said out loud at the arm, and the drop row records its population as EMPTY PENDING attribution evidence rather than as a deleted subject. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…ntier the deleted fold left CI'S FLOOR REFUSED STRUCTURALLY AT ff6c853, blockers=1, on dag/test/claim/spark/spark_serving_offer_route_witness_test.dag:19: unresolved import, module 'std.token_count' not found. token_count is declared by std.measure, which the sibling witness added in the same push imports correctly. Review 64572 found it by reading; the floor then refused on exactly it. THE CONSEQUENCE IS WHY THIS IS A FLOOR DEFECT AND NOT A TYPO. Name resolution fails for the WHOLE module, so both service-half rows this PR's second claim rests on -- covered_hosts_with_an_unreadable_readback_refuse_the_service_and_keep_the_region and an_unidentified_service_does_not_bind_an_offer -- were not executing evidence for anything. A witness that cannot resolve is not a weak witness, it is an absent one. A SECOND UNRESOLVED SET, WHICH CI HAD NOT REACHED because resolution stops at the first failure: spark_first_party_serving_witness_test matched ProviderPathUnread / Located / Absent and called spark_usage_stats_telemetry_path without importing any of the four. That is the row asserting the central claim that no established telemetry path may be produced, so it too was asserting nothing. Both are now imported and every imported symbol in the files this change touches is verified to exist in the module it is taken from. AND THE FOLD'S DELETION LEFT AN UPSTREAM PREDICATE WITH NO CALL SITE. extdeps.vllm.usage_stats vllm_usage_stats_assignment_disables was consumed only by the deleted spark_lane_disables_usage_stats. It is kept as a DECLARED FRONTIER under DESIGN 3c with its consumer and trigger stated beside it: it is what an effective-configuration reading feeds once one exists, named at spark_serving_usage_stats_declared_environment_obligation. It is kept because it holds a CITED upstream reading -- the exact-equality semantics of envs.py, established by review 64043 after a first spelling erred in the admitting direction -- and re-deriving that is the redundant work DESIGN 2 prices. Not because deleting it would be inconvenient: if the reading never lands, this goes with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
REVIEW 64578 IS RIGHT AND THIS IS THE SEVENTH INSTANCE TODAY OF THE CLASS THIS PR MINTS,
the fourth of them in prose, and two of the paragraphs were added by this PR itself. They
described machinery that no longer exists: that the launch environment is "folded now"
against extdeps.vllm.usage_stats' disable terms; that "the fold still answers what the
LAUNCH IS DECLARED to do ... and the standing takes the WORST CASE for the process:
reporting is assessed as on"; and that "EVERY LANE MUST DISABLE IT, NOT ANY ... the
disabled arm is reached only when that set is empty".
NONE OF IT IS PERFORMED. spark_lane_disables_usage_stats is deleted, this module no longer
imports spark_pair_container_env or vllm_usage_stats_assignment_disables, and
spark_serving_usage_stats_standing returns UsageStatsLaunchUnread on EVERY arm -- verified
rather than asserted -- so there is no disabled arm to reach and nothing is assessed either
way. The text also contradicted this same function's own obligation ("no standing is
claimed for this launch either way") and this PR's own rung-drop correction.
A FOURTH PARAGRAPH THE REVIEW DID NOT NAME HAD THE SAME DEFECT, found by sweeping rather
than by fixing what I was shown: "THE REMEDY IF ZERO EGRESS IS EVER WANTED is one
environment variable on the launch". That is the stranded promise again -- setting
VLLM_NO_USAGE_STATS=1 edits what the launch is DECLARED to do, and this decision no longer
consults the declaration, so a reader would set it, see nothing change, and have no way to
learn why. An actionable false promise is worse than silence.
WHAT REPLACES THEM SAYS WHAT WAS REMOVED AND WHY, rather than vanishing: the paragraphs are
recorded as deleted, the direction of their error is named, and the reader is pointed at
what actually resolves the route -- evidence of the effective telemetry configuration of the
process that answered, bound to the offered launch, covering whether the reporter runs and
where it sends.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…igin 1 WHY A THIRD SPECIMEN RATHER THAN A TALLY MARK. Origin 1's two attested specimens both had the executor die in a DIFFERENT change from the prose describing it, which leaves open the reading that this class needs elapsed time, a hand-off, or a second author to fire. It does not. In this pull request the deletion of spark_lane_disables_usage_stats and the annotations describing that fold were the same diff, the same author, minutes apart -- and two of the stranded paragraphs had been written earlier in this same pull request. The minimum distance between removing an executor and stranding the claim that describes it is zero, and a reviewer who looks for this class only across changes will miss it where it is densest. WHAT IS DELIBERATELY NOT IN THE ROW. The count. Four instances in one afternoon is a fact about this author's afternoon rather than about the corpus; the corpus fact is the coupling, and the count is only the anecdote that surfaced it. AND THE ACTIONABLE ONE IS NOTED WITHOUT MINTING AN AXIS. One stranded paragraph told a reader that setting VLLM_NO_USAGE_STATS=1 would change the route's answer, when the decision no longer consults the declaration -- so the reader would set it, observe nothing, and have no way to learn why. That is a difference in KIND from a descriptive stranding, recorded as awaiting a second data point. Minting a severity axis on one case is the row-widening this same ledger refused earlier today. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
… in the field that projects THE FLOOR REFUSED STRUCTURALLY AT 7514dd4 WITH FOUR REAL FAILURES, counted as eight because each appears twice -- once as claim_failed and once as changed_witness_planned_without_terminal_verdict. Three of them are the hazard the review named in advance: an earlier, correctly located refusal masking a later obligation. MY OWN NEW RED FAILED ON A CASE MISMATCH. an_unidentified_service_does_not_bind_an_offer asserted "the SERVICE is not" against a refusal reading "The SERVICE is not:". The witness was right about the behaviour and wrong about the string, which is the cheapest possible way to assert nothing. THREE WITNESSES I DID NOT INTEND TO TOUCH WENT RED BECAUSE THIS PR MADE THE ROUTE REFUSE EARLIER. every_use_program_is_not_engaged_and_names_its_basis read its three standings off an ADMITTED permit; no realization admits any more, by design, so the permit arm is unreachable and the row asserted nothing. It now reads the dispositions from the producers that own them -- spark_sanctions_disposition, spark_export_disposition, spark_prohibited_use_disposition -- which is where the not-engaged claim actually lives. a_non_first_party_use_refuses_as_unsupported and a_superseded_posture_makes_the_first_party_sanction_stale both fed admit_provider_use the production route facts, whose telemetry path is now unread for every input. Route-facts refusal fires FIRST, so both rows would have gone green while proving nothing about customer scope or posture staleness. They now take facts whose paths all resolve and therefore reach the question they are about. THE ISOLATING FIXTURE INVENTS NOTHING, which is the only reason it is admissible. Every slot in its closure reuses this module's OWN on-site path -- the one the production producer already returns for execution, storage and logs on operator-owned hardware. It supposes the telemetry path is as established as those already are, which is a supposition about a FIXTURE INPUT and never a claim about a deployment. The row that would assert launch-bound evidence is still deliberately absent. AND THE LEDGER IS CORRECTED IN THE FIELD THAT PROJECTS, NOT BESIDE IT. The previous head fixed the rung drop's annotations and left the TYPED population asserting a live ProviderPathLocated return -- correcting the half no Accepted program reads while the half that gunbc.rung_drop folds and publishes to docs/design-rung-drops.md went on claiming the opposite. The field now states the population as gated and empty pending attribution evidence, and the projection is regenerated IN THIS COMMIT so heal has nothing to add: a separate auto-commit would move the head and cancel the run. THE CLASS ROW IS WIDENED TO COVER ITS OWN WORST INSTANCE. unbacked_execution_claim was drawn around prose stranding a claim about a deleted executor. A typed carrier is worse in kind, because it is folded and projected, so a claim withdrawn in the annotation beside it survives into a published artifact. The recognition rule now says to ask which TYPED rows in the same file assert the withdrawn thing, and whether any is projected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
REVIEW 64611 FOUND TWO TYPED ROWS IN THE MODULE STILL ASSERTING WHAT THIS PR WITHDREW, and the sweep it prompted found two more the review did not name. This is the sweep I said I owed and did not actually run: I swept deleted SYMBOLS corpus-wide and corrected the rung drop, and never swept the typed rows inside the module I was changing. spark_export_not_engaged.basis said spark_usage_stats_telemetry_path "carries that path as Located with an unread jurisdiction". It returns ProviderPathUnread for every input now. Worse, this PR made that row NEWLY LOAD-BEARING by re-pointing every_use_program_is_not_engaged_and_names_its_basis at these disposition producers -- so the false claim moved from decorative to asserted by a witness in the same change. The export CONCLUSION is unaffected and stands: an unestablished metadata path is still not an export of route material. spark_first_party_use_posture.data_subject cited spark_serving_usage_stats_standing "for this fleet's launch" and told a reader zero egress was one environment variable away. The standing establishes nothing for this launch, and this module no longer reads the declared launch environment at all, so that remedy edits a producer the decision does not consult. TWO MORE, FOUND BY SWEEPING RATHER THAN BY BEING TOLD, and both of the actionable kind. spark_serving_usage_stats_unread_obligation ended "establish which hosts serve this deployment before its telemetry path can be resolved", and spark_serving_usage_stats_unobserved_hosts_obligation ended "read those lanes before this route's telemetry path can be resolved". Both promise that satisfying them resolves the route. Neither does: a realization with every host known and every lane covered still refuses, because knowing which machines serve a deployment is not knowing what the process on them does. Both now say necessary-and-not-sufficient and name what remains. THE PATTERN, RECORDED WHERE IT BELONGS: the failure is not that prose rots. It is that a correction feels complete when the ANNOTATIONS read true, while the typed rows -- the ones folded, projected, and now asserted by witnesses -- keep the withdrawn claim. That is already the widened recognition rule in unbacked_execution_claim; this commit is its first application, and it took an external reviewer to start it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…the fixture evidence THE SERVICE SEAM STILL NAMED A SPECIFIC DEPLOYMENT ON A CONFIGURATION MATCH. Refusing the unreadable and different-path readbacks was never the fix -- those are the easy cases. The motivating case is two deployments that SHARE a configuration, which reports the same string, and gunbc.spark.first_party_serving spark_realization_identity says in its own annotation that the comparison establishes configuration agreement rather than identity, and that a consumer may not read RealizationIsPairServing as identity. spark_serving_route_standing was that consumer, reading it as identity, and naming gunbc.spark.pair_serving_desired on the strength of it. So the service is now unestablished for EVERY input and the refusing arm is unconditional. THE REGION IS UNTOUCHED, which is the reason this is a separate arm rather than a stricter guard: the operator's dated allocation is evidence of a different kind about a different question -- where the machines sit -- and it is true whatever answered on them. THE REFUSAL CARRIES ITS DIAGNOSIS. The refusal is identical for a matching configuration and an undecodable document; the reason is not, and a reader who cannot tell them apart goes looking for the wrong evidence. spark_realization_identity_cause carries which situation obtained into the obligation. MY WITNESS WAS PRESERVING THE DEFECT. the_standing_the_harness_passes_is_operator_asserted_with_its_allocation required the route-bearing arm and explicitly rejected ServingRouteServiceUnidentified, so a green there insisted on a complete route nothing establishes. It now proves what it was actually for -- that the operator's dated allocation survives a service refusal -- and two REDs drive the matching-configuration case at the standing and through the binder. AND I WITHDRAW THE "INVENTS NOTHING" DEFENCE OF THE ADMISSION FIXTURE. Copying a production value into a slot does not make it an observation of that slot's destination: assigning the execution path to the telemetry slot constructs a closure no producer returns, and the provenance of the copied value buys nothing. It is a HYPOTHETICAL RESOLVED-ROUTE FIXTURE, and what makes it admissible is the explicit hypothesis and the bounded question -- given a resolved route, the production evaluator still rejects an unsupported customer profile and a superseded posture for their own reasons. It is not production telemetry evidence and is not the deferred launch-bound positive control. TWO SCOPE STATEMENTS ADDED WHERE THEY WERE MISSING. t_not_engaged_naming checks the variant and the basis REFERENCE and does not evaluate the truth of the referenced prose, so re-pointing it did not turn those sentences into executed findings. And both route-bearing arms are now declared unreachable at the type, since an arm that quietly cannot occur is the decoration DESIGN 4b warns will be cited as coverage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…ptions as history REVIEW 64623: spark_sanctions_not_engaged.basis still said the usage-stats reporter "emits" metadata and that the path is "carried as this route's telemetry path". Both are withdrawn -- spark_usage_stats_telemetry_path returns ProviderPathUnread for every input. THE SIBLING ROW WAS FIXED AND THIS ONE WAS NOT: I corrected spark_export_not_engaged six lines above and never looked at the row beside it, in a file I was sweeping for exactly this. This diff also made it witness-load-bearing by re-pointing the disposition control at these producers. It is corrected the way export was: what upstream DOCUMENTS stays, whether it happens FOR THIS LAUNCH is marked unestablished with the reason, the superseded sentence is recorded as false rather than quietly replaced, and the sanctions CONCLUSION stands -- an emission of machine metadata to a recipient is not a supply of a good, service or route material to a counterparty whether or not it is occurring. AND THE SWEEP IS NOW MECHANICAL RATHER THAN BY EYE, which is what found nothing further: every typed string in the module was checked programmatically for the withdrawn vocabulary. The three remaining hits are correct -- each says the reporter's state is UNKNOWN or names the evidence that would settle it. THREE SUPERSEDED DESCRIPTIONS ARE MARKED AS HISTORY OR DELETED, not annotated around. The allocation witness carried two present-tense claims -- that the live path "carries a route" and that it "asserts the asserted arm specifically" -- above a correction that contradicted them, so a reader met the false claim first. They are now one past-tense history paragraph, and what survives from them is stated as still-asserted: a ServingRouteObserved return would mean an allocation relabelled as a measurement, and the region must cite the allocation rather than the bare site row. The first-party admission witness's "POSITIVE CONTROL. The first-party scope admits" is deleted. serving_offer's host-membership annotation no longer says the readback decides which declared launch the process is or whose container environment may be attributed -- it does neither. AND I SCOPED MY OWN OVERSTATEMENT while there: that witness said the dev end-to-end run does not pass the walls after this change. The harness takes SparkOfferBound directly to its missing-Work refusal and never calls spark_first_party_admission, so the run does not reach this refusal and its terminal is unchanged. The claim is about this producer, not about the run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
REVIEW 64649, TWO STRUCTURAL FINDINGS, BOTH CORRECT AND BOTH FIXED WHERE THEY BELONG. 1. THE ARM NAMED ITSELF AS IDENTITY AND THEN ASKED CONSUMERS NOT TO BELIEVE IT. RealizationIsPairServing carried an annotation saying a consumer may not read it as identity -- prose doing load-bearing work that the type should do, and DESIGN 4c is explicit that no Accepted program reads an annotation, so a consumer trusting the name never met the caveat. The consumer that did exactly that was in this same PR: spark_serving_route_standing named a specific deployment on the strength of this arm. It is now RealizationMatchesPairServingConfiguration -- what it establishes, in the constructor, per DESIGN 5's construction over validation. 2. SIX REFUSAL CAUSES WERE COLLAPSED INTO ONE ARM DISCRIMINATED BY PROSE. Every arm of the telemetry standing refuses, and extdeps.vllm.usage_stats gives the refusal one shape -- UsageStatsLaunchUnread carrying a String -- which is upstream's vocabulary and not ours to reshape. So this module was distinguishing a readback that did not resolve, a path that disagreed, an unpinned snapshot, absent host membership, unobserved lanes and a matched configuration ONLY by the sentence inside the string. The consequence was visible in this change's own witnesses: five of them separated causes with string_contains, which is validation standing exactly where construction was available -- and a case mismatch in that very pattern cost a floor run on this branch earlier today. SparkTelemetryUnreadCause now carries the cause as a value, spark_telemetry_unread_obligation RENDERS the sentence from it, and the standing is one line that composes them. The witnesses match variants; string_contains no longer discriminates any cause. Both identity failures are typed too, so RealizationReportedPathDiffers carries the reported and declared paths as fields rather than interpolating them into prose a test then greps. THIS IS THE CEILING MY OWN ROW NAMES, applied one layer out. diagnostic_asserts_standing_no_check_evaluated gives its class the ceiling "a note CONSTRUCTED FROM the check's outcome value rather than authored beside it". That is exactly this repair: the obligation is derived from the cause, so a sentence cannot drift from the arm that produced it, and a consumer asking WHY matches a variant instead of grepping. Verified before pushing: no stale RealizationIsPairServing/RealizationUnidentified references survive outside deliberate past-tense history; no new variant name collides corpus-wide, which matters because .dag variant names resolve across the corpus. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
THE BINDER POSITIVE NEVER COMPARED SERVICE, which is the worst possible field for it to omit here. an_observed_route_binds_and_the_offer_carries_it asserted region and provider -- two of the route's three -- while SERVICE is the exact field this whole change is about. So the binder's ACCEPTING branch was controlled by a row that was silent on the thing under review, and its name promised "the offer carries the route" while establishing something narrower. The conjunct is added; the name is now true. Adding it also enrols the identity, so the required lane will execute it rather than reporting declined_outside_required_gate as it did at b58b4a0. That is a consequence and not the motive: the assertion is one the row should always have made, which is what separates it from the contentless edit that would game the selector. ONE ANNOTATION MISSED THE RENAME and was a live claim rather than kept history: the t_realization fixture said "the identity join answers RealizationIsPairServing" in the present tense, naming a constructor that no longer exists -- two lines below a sentence deliberately marking the earlier spelling as history. AND THE ROUTE DIAGNOSES ARE TYPED NOW TOO, because the asymmetry was mine and would have been raised again. The telemetry causes were typed so witnesses match variants; the route rows were left grepping "configuration agreement and not identity" and "did not resolve" for the same distinctions. Both now assert the typed SparkTelemetryUnreadCause variant. What still uses a substring is the service-identity obligation, compared against the producer's own row rather than a literal, so it cannot drift into agreeing with a copy of itself -- and the remaining string checks are content assertions (a host name present, another absent), not cause discrimination. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
REVIEW 64662 IS RIGHT AND THE PLACEMENT IS THE POINT. The service withdrawal was propagated into first_party_serving.dag, serving_offer.dag and docs/design-rung-drops.md, and NOT into gunbc.harness.harness_seat -- the single consumer this diff actually rewired to call the new spark_serving_route_standing. Its annotation still said "two of the three obstacles are now gone: spark_serving_route_standing carries the operator's dated site allocation RATHER THAN REFUSING". The standing refuses on every input. It does carry the allocation, on the refusing arm, which is what that arm exists for. That is this PR's own rule, from the row this diff edits: after withdrawing a claim, ask which rows in the same file still assert it. I applied that sweep to the modules I was editing for content and not to the module I was editing for a CALL SITE -- where the withdrawal's whole consequence lands. AND THE SparkOfferBound ARM IS NOW UNREACHABLE AND SAYS SO, because this PR made exactly that demand of the two retained SparkServingRoute arms and owes it here: an arm that quietly cannot occur is the decoration DESIGN 4b warns will be cited as coverage. It is retained as the right handling once an offer can bind, and it becomes reachable when evidence identifies the deployment that answered. Worth recording where the note it carries came from: "The serving offer bound. Provider-use admission cannot yet be evaluated..." is the diagnostic that diagnostic_asserts_standing_no_check_evaluated was minted about. It is now unemittable, which retires the instance rather than the class. TWO DEFECTS IN spark_realization_identity_cause, one named by the review and one found reading it. Its note said "WHICH of the TWO situations obtained" -- there are six causes since they were typed, and the count was left behind by the change that typed them. And it called spark_serving_usage_stats_unread_cause in the scrutinee AND again in the fallback arm, running the whole identity join twice to answer one question: DESIGN 2's authored duplication, of the kind that hides because both calls return the same value. The cause is bound once now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
…mputed it MY TYPED-DIAGNOSIS CHANGE WAS A COVERAGE REGRESSION AND THE COUNTEREXAMPLE NEEDS NO EXECUTION. t_cause_is_configuration_matched and t_cause_is_readback_unresolved each called spark_serving_usage_stats_unread_cause directly, so both asked the UPSTREAM producer what the cause was. The witness separately called spark_serving_route_standing and checked the arm plus text common to every case. The two were joined by nothing but a shared realization argument. So: delete the case-specific suffix from the obligation spark_serving_route_standing builds -- "For this realization the identity join reports: " and the rendered cause -- and every assertion in both rows still passes. The route would have lost its diagnosis and no test would notice. THE PRINCIPLE IS THE ONE THIS PR HAS BEEN APPLYING FROM THE OTHER SIDE ALL DAY: a correct result from a NEIGHBOURING producer does not establish that the CONSUMER carried that result. I had been checking that upstream answers correctly and calling it evidence about the consumer. AND MY REPLACEMENT WAS BETTER IN FORM AND WORSE IN COVERAGE. The string assertions I removed were fragile with respect to wording, but they DID inspect the diagnosis the route standing actually returned. A robust check of the wrong object does not beat a fragile check of the right one. BOTH ROWS NOW CHECK BOTH THINGS: the typed cause pins WHICH case obtained without depending on wording, and a string join pins that the RETURNED refusal reported it. The expected text is spark_realization_identity_cause's own output for the same realization -- the renderer that is supposed to have populated the obligation -- so this compares two producers rather than a sentence against a copy of itself that any rewording would keep green. NOT DONE, AND DELIBERATELY: no carrier redesign. ServingRouteServiceUnidentified still transports its diagnosis as text, which is why the output boundary is where this is checkable at all. A typed diagnosis field on that arm would carry it structurally, and the annotation names that as the shape to reach for if this needs to get stronger. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AQGTwRrSBe8r3bmR3epQsL
THE IMPLEMENTATION REFUSES TO ATTRIBUTE AND FOUR COMMENTS STILL ASSERTED THE ATTRIBUTION. The reviewer named two sites; sweeping for the ARGUMENT rather than the quoted phrases found four. That search is the lesson from tonight's other repairs, and it paid here too. SITE 1, first_party_serving.dag above SparkServingRealization: said the hosts and readback "decide ... which declared launch the process is, which is what makes an environment attributable to it". The module establishes NEITHER. It now says the hosts answer site coverage, the readback answers configuration agreement only, and no container environment is attributed on the strength of either. The file previously carried this claim AND its own correction thirty lines apart, in the present tense, so a reader met the false one first. SITE 2, the same file's readback-unresolved obligation: "nothing the running process reported identifies which declared launch it is" is true about THIS cause and implies a resolved readback would identify the launch. It now states that a readback which does resolve establishes only configuration agreement, and that this cause is upstream of that limit rather than an exception to it. SITE 3, the witness fixture note: the model path was called "the single field that decides attribution". It decides nothing of the kind -- it separates these two fixtures by configuration agreement, which two deployments can share. SITE 4, the no-host-membership control: "the readback identifies the declared launch, so the environment WOULD be attributable, and what is missing is which hosts serve it." That is the claim in its most load-bearing form, because it tells a reader the attribution is one host roster away. It is not, and no host roster would make it so. A FIFTH SITE WAS ALREADY CORRECT and is left alone: serving_offer's paragraph carries the same sentence explicitly marked as an earlier spelling with the correction attached, which is the form the others now take. WORDING ONLY. No behaviour changes, and the reviewer was explicit that the four green check-runs do not remove a source finding of this kind -- a comment that publishes an attribution the code refuses is the claim a reader carries away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ol's name match its body AN UNUSED IMPORT IS WHAT MAKES A DELETED ATTRIBUTION ONE LINE FROM RETURNING. serving_offer.dag still imported spark_first_party_route with no call site: its only other occurrence in that module is inside the prose of spark_serving_route_service_identity_obligation, which is a string and not a reference. The caller WAS the defect -- spark_serving_route_standing returning that specific service for covered hosts -- and deleting it is finding 2's repair, so the import is residue of the exact thing this change removes. Two reasons rather than one. DESIGN 3c names this tell precisely: an imported name with no consumer in the closure. And DESIGN 3's attractor argument is the sharper one here -- while the import stands, restoring the unsupported service attribution is a one-line edit, which is the surviving-X residue the replacement-migration rule exists to remove. The function is still legitimately consumed twice inside first_party_serving.dag, at the sanction roster's route key and at spark_first_party_route_facts, so this is an unused import in ONE module and not a dead function. AND ONE CONTROL'S NAME CLAIMED ITS SIBLINGS' WORK. a_matching_readback_does_not_establish_the_effective_telemetry_configuration asserts over spark_serving_usage_stats_unread_cause -- the cause CLASSIFIER -- so it establishes that a matching readback is LABELLED matched-but-unread. It does not establish that anything downstream refuses to attribute; mutating the telemetry path to attribute leaves it green, and reds its two siblings instead. Both assertions are real and both discriminate, but a reader auditing by control name would credit this row with the property the operator actually demanded. Renamed to a_matching_readback_is_classified_as_configuration_matched_not_as_a_read, with the annotation naming which rows carry the downstream property. That is this PR's own subject applied to a test name: a name asserting more than the thing establishes, with the correction living in prose beside it instead of in the name. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A REGION REFUSAL AND A SERVICE REFUSAL ARE THE SAME SHAPE AT THE BINDER. SparkOfferBindingRefused carries cause as a NonEmptyStr and the binder forwards the standing's obligation verbatim, so only the text distinguishes them -- and both binder controls discriminated with string_contains "The SERVICE is not", a literal any rewording silently defeats. A case mismatch in exactly that pattern already cost a floor run on this branch. Both now compare the forwarded cause to the obligation the standing produced FOR THE SAME REALIZATION. That is a join between two producers: it fails if the binder forwards a different refusal, it distinguishes the service case from the region case by construction rather than by wording, and it cannot drift into agreeing with a copy of itself. The one remaining substring in the file names the old spelling inside the history annotation. Same repair as the telemetry causes earlier in this PR, at the seam that was still using prose to tell two refusals apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
THE POPULATION LIST HAD ONE MEMBER WHOSE CONTENT WAS THAT THE POPULATION IS EMPTY, so gunbc.rung_drop rung_drop_declaration_message published a one-member population and any consumer counting members got 1. That is DESIGN 5's fabricated plausible value: an uninformative answer would have been better than a confidently wrong one, and I produced the wrong one while fixing the row. It is also this PR's own widened rule -- ask which TYPED rows assert the withdrawn thing -- landing on the fix rather than on the prose. IT IS NOW [] AND THAT IS THE CORRECT VALUE RATHER THAN A COMPROMISE. gunbc.guarantee_stall's warning about population: [] is scoped to rows whose exposure is UNBOUNDED, where an empty list would falsely read as "nothing is affected" when the truth is that nothing could be enumerated -- which is what its UncountedNotEnumerable arm exists for. This row is the other case: nothing reaches the located arm because spark_serving_usage_stats_standing returns UsageStatsLaunchUnread on every arm, so the population is a COUNTED zero. In that carrier's vocabulary this is BoundedPopulation with no members, and "nothing is affected" is the true reading. WHAT THE EMPTY LIST COSTS IS DECLARED AT THE ROW rather than left to be discovered: the projection now renders "Population: ." and stops, and DESIGN 4c means the annotation carrying the reason cannot reach any consumer. Uninformative, not wrong -- nothing plausible is asserted. The projection is regenerated in this commit, so the typed row and its generated artifact move together. That is the same discipline this PR's unbacked_execution_claim specimen was minted over, and the distinction from the merge case is deliberate: heal derives the artifact from MERGED authorities, but an authored change to a typed row carries its own projection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
FLOOR REFUSED STRUCTURALLY, blockers=3, on five lines of dag/gunbc/rung_drop/provider_path_jurisdiction_unread_admits.dag: "source annotation sits inside a declaration body. Only module-item grain is modeled; move it above the declaration it describes." I wrote the explanation for the empty population INSIDE the RungDrop literal, beside the field it explains, which reads naturally and does not parse. The block is unchanged in content and now sits above the declaration. Swept every .dag this PR touches for the same shape: none left. WORTH RECORDING WHY THIS ONE GOT THROUGH. The constraint is not obscure -- it is the first thing DESIGN 4c says about the initial .dag realization, and I have hit it before. It got through because the annotation was written at the moment of deciding WHAT the field should say, where the natural place to put the reason is next to the field, and nothing about that moment prompts a question about grain. The check is mechanical and costs nothing: grep the file for an indented comment before pushing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…m-realization # Conflicts: # dag/gunbc/rung_drop/provider_path_jurisdiction_unread_admits.dag # docs/design-rung-drops.md
Ledger-Repair-Judged: docs/design-rung-drops.md Ledger-Rows-Repaired: docs/design-rung-drops.md provider_path_jurisdiction_unread_admits
BOTH ARE FALSE AS PRESENT-TENSE DESCRIPTIONS AT THIS HEAD, which is the bar for spending a head rather than leaving a note. "spark_serving_route_standing refuses today because nothing observes which region a serving host sits in" -- it does not. For covered hosts the REGION is established from the operator's dated allocation; it is the SERVICE that refuses. "The readback decides the SERVICE, because which deployment answered is not a fact about where the machines are" -- it does not decide the service. Establishing that even a matching readback cannot name the deployment is this change's whole subject; the readback contributes only to the diagnosis the service-identity refusal carries. The replacement is the reviewer's own wording, used rather than re-invented: the standing has two independently evidenced halves, host membership can establish the region, the readback bears on the service-identity diagnosis without establishing the service, so covered hosts produce ServingRouteServiceUnidentified while absent or out-of-allocation host evidence produces ServingRouteRegionUnobserved. WHERE THE SECOND ONE SAT IS THE FINDING WORTH KEEPING. It is inside a block that ALREADY narrates a correction -- "an earlier spelling of this block said the standing never consults the readback ... which was true and was the defect". So that block was rewritten once and this sentence survived the rewrite: the edit fixed what it was looking at and left a claim in the same paragraph that the same change had falsified. A one-directional sweep, at paragraph range. That is recorded at the site rather than only here. Comment-only: zero non-comment lines changed. No behaviour change, no witness body change, no new arm, no new observation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…g fork THE SERVICE REFUSAL RENDERED ITS REASON FROM THE WRONG AUTHORITY. spark_realization_identity_cause called spark_serving_usage_stats_unread_cause -- the TELEMETRY cause, which is the identity join PLUS two host checks that exist for the telemetry question. So a realization whose hosts are covered by the allocation but one of whose hosts has no OBSERVED FABRIC LANE would render, as the reason WHICH DEPLOYMENT ANSWERED is unestablished, an obligation about reading more lanes -- while this module's own spark_serving_route_service_identity_obligation says the discharging capability is evidence identifying the deployment, and lane observation is not it. DESIGN 3's meaning fork: one name, two materially different contracts. And it is the class this PR files, reached by that row's own tell -- name the producer the sentence points a reader at, then check the emitting arm. The service arm pointed at telemetry evidence no service check consults. IT CONSUMES THE IDENTITY JOIN NOW, with the service's own four sentences rather than the telemetry renderer's, so the two questions no longer share a renderer and neither can drift into answering for the other. LATENT, NOT FIRING, AND RECORDED AS SUCH. Every unit in spark_fleet_site_allocation currently has an observed lane, so the mis-rendered arm is unreachable with present data. It becomes reachable the moment a unit is allocated before its lane is observed -- which is what a hardware move produces, and this module exists because the operator moved hardware. THE TWO ROUTE CONTROLS HAD THE SAME DEFECT one layer out: helpers for a SERVICE refusal that interrogated the telemetry cause. They now match spark_realization_identity. And the annotation above the repaired function claimed "every other case renders through the telemetry obligation" and "there are six causes" -- both falsified by this change, in the paragraph being edited. That is the paragraph-range sweep failure recorded two commits ago, caught this time in the same edit rather than by a reviewer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
THE TELL AS WRITTEN ONLY FOUND HALF ITS OWN CLASS. It said: read the clause, name the producer it asserts an outcome for, grep the emitting arm. That catches a SENTENCE naming a producer no check consults -- and it caught two of those on this PR by reading prose. It does not catch an ARM naming an AUTHORITY no check on this question consults, and this PR carried one: spark_realization_identity_cause rendered the SERVICE refusal from the TELEMETRY cause, which is the identity join plus two host checks belonging to a different question. Every prose sweep passed over it, because no sentence was false -- the wiring was. Rewording would have left it intact. The row now carries both forms, and says which is the harder one and why: the arm form survives a wording sweep, so it has to be found by asking which producer answers this question rather than by reading what the text claims. AND IT RECORDS THE REACHABILITY HONESTLY, because the distinction decides how the next instance is filed: what kept the mis-rendered arm unreachable was a property of the DATA -- every allocated unit happening to have an observed lane -- not of the code. A defect that is merely not firing is not a defect that is fixed, and the condition that fires it is a unit allocated before its lane is observed, which is what a hardware move produces. That is the event this module exists for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rol the case it describes THE DIAGNOSTIC CLAIMED DEPLOYMENT IDENTITY FROM A CONFIGURATION COMPARISON, which is the exact inference this PR refuses everywhere else -- its own wall pointed the wrong way in one sentence. RealizationReportedPathDiffers rendered "so the process that answered is not the launch this route would name". The producer establishes only that the REPORTED CONFIGURATION DIFFERS from the pair-serving declaration. A process that IS the intended launch, running with drifted configuration, reports exactly that way and is not excluded by that evidence. It now says the readback does not establish the specific service, and says explicitly that it does NOT establish a different launch, naming the drifted-configuration case so the next reader cannot re-derive the overclaim. The service refuses either way: no behaviour change. AND THE FOREIGN CASE NOW HAS A CONTROL AT THE SERVICE ROUTE. It was exercised on the telemetry side only, so the route had controls for two of its three readback situations -- matching and undecodable -- and the third rested on a neighbouring producer. That is the defect this file already records against itself: a correct result from a neighbouring producer does not establish that the consumer carried it. The new rows pin the DIAGNOSIS rather than the arm: the refusal must report non-establishment, must NOT carry the configuration-agreement or unresolved-readback sentences, and must keep the dated allocation so the region survives. The binder twin joins the forwarded cause to the standing's own obligation rather than to a literal. THE TWO LAND TOGETHER DELIBERATELY. The control asserts the path-differs diagnosis, which is the sentence being repaired. Either one alone would have a row pinning text that is wrong or about to change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ence THE ARM TRANSPORTED ITS DIAGNOSIS AS PROSE, so consumers had to grep the sentence to learn WHICH situation obtained -- and the controls this PR added did exactly that. That is the defect this PR diagnoses and repairs one module over: SparkTelemetryUnreadCause exists precisely because "witnesses had to discriminate them with string_contains, which is validation standing where construction was available, and a case mismatch in exactly that pattern cost a floor run on this branch." The same argument applied to the arm I minted, and I did not apply it. ServingRouteServiceUnidentified now carries cause: SparkRealizationIdentity beside the rendered obligation, and the rows match the variant. It cost nothing: spark_realization_identity was already computed on that path by spark_realization_identity_cause, so the value was there to be carried rather than re-derived. AND THE FILE'S OWN ANNOTATION HAD ALREADY CONCEDED IT -- "a typed diagnosis field on that carrier would let the arm carry it structurally instead, and that is the shape to reach for if this needs to get stronger" -- while naming no trigger and no owner. Naming the right construction and then not building it, with nothing to retire the gap, is how a conceded shortfall becomes permanent. The annotation now describes what the code does. BOTH CHECKS SURVIVE AND THE ANNOTATION SAYS WHY NEITHER IS REDUNDANT: the variant match says which situation the standing FOUND; the obligation comparison says the refusal it RETURNED carries that situation's rendered diagnosis, joined against spark_realization_identity_cause's own output so it fails if renderer and arm disagree. Drop the first and you are grepping prose; drop the second and you are trusting a neighbouring producer. No behaviour change: the service refuses on every input before and after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
briansrls
marked this pull request as ready for review
September 13, 2026 16:39
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c1b9b945c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }, | ||
| serves: "gunbc itself. Every turn placed on this route originates inside this repository's own harness and control plane; no turn is served to any party outside gunbc and none crosses an organisational or national boundary.", | ||
| data_subject: "our own material. The prompts and responses on this route are gunbc's, held on operator-owned hardware at the operator's own site; no customer data and no third-party data is processed on it. ROUTE MATERIAL STAYS ON SITE AND EXACTLY ONE PATH LEAVES IT: vLLM reports host, build and engine-configuration metadata to https://stats.vllm.ai by upstream default, carrying no request content (extdeps.vllm.usage_stats, and gunbc.spark.first_party_serving spark_serving_usage_stats_standing for this fleet's launch). The remedy for zero egress is VLLM_NO_USAGE_STATS=1 or DO_NOT_TRACK=1 on the serving launch, which is the operator's to set on his own box.", | ||
| data_subject: "our own material. The prompts and responses on this route are gunbc's, held on operator-owned hardware at the operator's own site; no customer data and no third-party data is processed on it. ROUTE MATERIAL STAYS ON SITE AND EXACTLY ONE PATH LEAVES IT: vLLM reports host, build and engine-configuration metadata to https://stats.vllm.ai by upstream default, carrying no request content (extdeps.vllm.usage_stats). WHETHER THAT PATH IS ACTIVE FOR THIS FLEET'S LAUNCH IS UNESTABLISHED and this row does not assert it: gunbc.spark.first_party_serving spark_serving_usage_stats_standing returns UsageStatsLaunchUnread on every arm, so nothing here establishes that the reporter runs, or that it does not. AND THE REMEDY IS NOT A DECLARATION EDIT. An earlier spelling said zero egress was one environment variable away -- VLLM_NO_USAGE_STATS=1 or DO_NOT_TRACK=1 on the serving launch. This module no longer reads the declared launch environment at all, so setting either changes what the launch is DECLARED to do and changes nothing this decision consults; a reader following that advice would observe no change and have no way to learn why. What resolves the route is the evidence named at spark_serving_usage_stats_declared_environment_obligation.", |
There was a problem hiding this comment.
When this posture is read by an operator or auditor, data_subject still says that exactly one path leaves the site and that vLLM reports to stats.vllm.ai, before saying that whether this path is active is unestablished. The same contradiction appears in the sanctions and export bases. Because spark_serving_usage_stats_standing now returns UsageStatsLaunchUnread for every realization, describe this only as a documented potential/default path; otherwise the typed compliance evidence continues to assert the runtime egress that this change explicitly withdrew.
Useful? React with 👍 / 👎.
| backups: spark_first_party_path(), | ||
| logs: spark_first_party_path(), | ||
| telemetry: spark_usage_stats_telemetry_path(), | ||
| telemetry: spark_usage_stats_telemetry_path(realization: realization), |
There was a problem hiding this comment.
When an existing permit or grant is audited after this change, this function now derives a materially different, realization-dependent telemetry closure, but it still returns the old gunbc.spark.first-party-route-facts.2026-09-11 revision at line 722. ProviderUseEvidence.route_facts_revision is retained specifically so the admitting facts can be reconstructed from a grant, so reusing the revision makes the former admitting closure and the new always-unread closure indistinguishable and can attribute today's refusal semantics to an earlier decision. Give this implementation a new facts revision.
Useful? React with 👍 / 👎.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Auto-opened by session-dashboard for session
keen-owl-253.Pushing to
spark-route-facts-from-realizationadvances this PR.Worker attestation
Before flipping this PR to ready for review, confirm each item:
npm test,cargo test) and the result.Closes #Ndirective.Summary
TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.
Test plan