Plan: Engram placement as a fabric/materialization cost decision (RAM vs NVMe vs NFS routes)

[gunbai-bot]

Plan doc only, per DSV41-8 plan-first. docs/plans/engram-materialization-placement.md plus the one gunbc.doc_graph_roots bind that makes it reachable. No .dag implementation lands from this PR.

This body was recut after review. An earlier version presented a replica-count payoff (ax_independent_replicas) that the plan itself retracted, and claimed a closed count of three net-new concepts. Both are gone. A reviewer reading the old body would have approved a materially different plan from the file.

What it argues

Operator ruling (2026-09-11): model Engram access and cost and let the ordering fall out; do not declare it.

• One semantic component, several realizations. RAM / local NVMe / NFS / object origin are access realizations. But "every route serves the same digest" is too strong: different physical encodings give different realization digests, so §3 carries EngramComponentSubject / MaterializedEngramArtifact / FaithfulComponentRealization rather than one byte digest. The subject's digest does not exist yet — that is step 1 work.
• Logical demand and physical access are separate facts (§4). 48 hash IDs/token is implementation-plus-config derived (n_hash_cols = (max_ngram_size-1) * n_heads). The page-read chain — 48 pages, 196,608 B/token, 15.5×, the IOPS figures — is a scenario under named assumptions, not derivation, and is typed as such. Weight and scale are separate tensors, so 264 B is a summed logical payload; a contiguous record would be a route-specific materialization format.
• Routes are chains A/B/C/D, NFS declaring which of its three roles it plays. CasTier is keying semantics, not "remote".
• Selection returns RealizationSelectionResult<MaterializationRoute> unchanged — six arms, no second algebra, SelectionNeedsPolicy reachable here with full evidence.
• Placement and topology are coupled (§7.1). Route selection is parameterized by each exact serving candidate; the outer serving selection ranks composed candidates. There is no context-free route winner, and no invariance proof was available to justify one.

What it does not claim

The 5-vs-3 rank split is a lower-bound scenario over publisher-cited bytes, not a feasibility finding: weight_fit_of returns WeightFitUnderivable on FootprintReportedExternally, and its positive arm is WeightsNotRuledOutByLowerBound. No route is declared the winner. D is an expectation.

Census and integration

• §2 is the DFS, with four rows corrected in place rather than silently repaired — Placement has four arms (LocalAccelerator included), the route hop no longer restates what tier_axes derives, and ArtifactRequest is a closed coproduct over compiler artifacts that Engram cannot inhabit. The net-new count is open, not "exactly three".
• ArtifactFootprint is not forked. A non-resident route contributes its RouteResidentMemoryStanding, not zero — the earlier "zero resident bytes" was fail-open, since B and D depend on a retained page cache by construction.
• §11.1: a capability probe cannot discharge the runtime constraint. That module says of itself that presence is prerequisite inventory establishing nothing about serving; absence rules out, presence does not rule in, and only a RuntimeFeasibility launch receipt satisfies it. Digest grain is the observed local config digest, not the pull reference.
• §14.4 carries the fleet_fits defect this plan found — un-gated on this approval, owned by DSV41-9, anchored at DSV41-2: V4.1 native serving candidates, constraints against facts, derived topology #11013.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DiKZ27VVdsn6hn9V8fN9Kf

[gunbai-bot]

Both findings in review 64082 are correct, verified against the tree, and both are fixed in the head just pushed.

1. Wrong exclusion authority. llama_cpp_rpc_release_receipts carries a receipt for both srv7 and srv8, and spark_llama_cpp_rpc_witness pins length(llama_cpp_rpc_undischarged_peer_reservation_hosts()) == 0. The reservation is discharged. I had read the annotation in gunbc.spark.cell_role rather than the declarations the witness executes against — and that annotation's own sentence about a release receipt moving the count from four to six described something that had already happened, which the section then repeated as a future possibility.

The sharper half of the finding is the one I want to underline: applying my own stated formula yields six, not the four I claimed. The count was right by accident and the formula that produced it was wrong, which is the worse failure — a confirming number is exactly the kind that does not get audited.

What actually binds srv5–srv8 is spark_pair_serving_groups = [FabricGroupA] — srv6 head, srv5/srv7/srv8 workers, TP4, vLLM — pinned by group_a_is_four_ranks_headed_by_srv6_at_their_rail_addresses. §8.2 now names that as the exclusion authority, records the error and why it happened, and notes that cell-role assignment lags pair-serving desired state, which is why reading roles alone undercounts. Two of the three exclusion terms are currently empty, so the section now argues the host list must never be carried here as data — the binding derives it live. Route A's cost is restated accordingly: not "displacing two named subjects" but tearing down a running four-rank serving deployment.

2. DSV41-9 does not resolve. Correct — it is a dashboard work item created by the DSV41 manager session today, not a repository artifact, so git grep finds only the plan. §14.4 now says that explicitly and gives #11013 as the anchor a reader can check, in the same shape the corpus already cites DSV41-2 beside it.

— sent from nimble-ferret-574

[gunbai-bot]

Both findings in review 64096 are correct and fixed in the head just pushed. The first is the more serious of the two and I had the fact wrong, not just the wording.

1. RealizationSelectionResult has six arms, not three. SelectedWithin, CandidateFieldUnestablished, NoFeasibleRealization, SelectionNeedsEvidence, SelectionNeedsPolicy, RealizationSelectionRefused. I wrote a three-arm spelling and called it "the three arms of RealizationSelectionResult", which is a second algebra with fewer distinctions — the §3d fork the plan claims elsewhere to avoid, committed in the plan that claims it.

SelectionNeedsPolicy is the arm this subject is most likely to reach, and the reviewer is right that more evidence does not resolve it: B and D can both be fully measured and still non-dominated — D wins on fill since the site cache is already near the hosts, B wins on network bytes and failure-domain breadth. My vocabulary would have forced that field to either report NeedsEvidence for evidence that exists, or pick a winner off a front of two. The subject now adds no result type at all; it supplies candidates, axes, constraints and a policy authority and returns whatever select_realization returns.

2. "the answer is A regardless of cost" contradicted §8.2. A is subject to the same screen, and §8.2 establishes A fails it today — TP8 × 1 needs eight Sparks, four are admissible. If the runtime refuses the non-resident routes and A fails host feasibility, every candidate has violated a hard constraint and the result is NoFeasibleRealization naming both causes. A surviving candidate is one that passed every constraint, never the last one standing after the others were excluded.

That state is also the most useful thing the subject can say: it means the deployment does not fit this fleet under any placement, and the reply is to change a constraint — release Group A, patch the runtime, add hosts — rather than to pick a route.

I also reconciled the downstream claims this exposed, since fixing §7 and §11 alone would have left four places asserting NeedsEvidence as today's output. With §11's constraint axis unfunded, today's output is RealizationSelectionRefused — std.decision treats a selection run against a constraint nobody can read as defective rather than under-evidenced, which is one of the six arms earning its keep.

— sent from nimble-ferret-574

[gunbai-bot]

Correct, and fixed in the head just pushed. §14 step 4 was still telling the worker to build "roster minus role assignments minus undischarged reservations" — the exact two-term formula §8.2 spends three paragraphs rejecting, and which yields six hosts rather than four.

This is worse than an inconsistency, and the reviewer named why: the landing order is what a worker actually implements against. I corrected the argument and left the recipe, so the dead formula was the one that would have been built. That is the surviving-attractor shape DESIGN §3 describes — while the old structure stands, the nearby question keeps getting answered in its vocabulary, including by the person who just replaced it.

§14.4 now carries the three-term formula with the desired-serving-deployment term first, since that is the term a worker reading the role roster would omit, and omitting it is not a near miss: it admits six hosts and hands four of them to a new shape while Group A is serving on them. It also states which terms are live — pair-serving non-empty, role assignment a strict subset of it because cell_role lags the desired state, reservations discharged — so the next reader cannot repeat my mistake of treating an empty term as the load-bearing one.

The one remaining instance of the rejected formula is at :130, where §8.2 quotes it in order to reject it. That one is deliberate.

— sent from nimble-ferret-574

[gunbai-bot]

No action needed from review 64126 (APPROVE, no findings) — but approvals are hygiene, so I re-read the document against the brief rather than stopping on the tally, and my own sweep found one more instance of the propagation failure the last two reviews caught.

§8.2 still said a shape needing more admissible hosts than exist is Refused. After §7's six-arm correction that arm means the selection itself was defective. A full fleet is NoFeasibleRealization — a well-formed selection with no surviving candidate — which is precisely the distinction the six arms exist to keep, and I had just finished arguing for it two sections earlier. Fixed in the head just pushed.

Against the brief, the one deliberate divergence is worth stating rather than leaving for a reader to find: the brief specified a three-arm result (EngramPlacementSelected / NeedsEvidence / Refused), and the plan returns RealizationSelectionResult unchanged instead. That is a §3b "diverges with a stated reason" — review 64096 showed the concrete reason (SelectionNeedsPolicy is reachable here with full evidence), and §7 records it in the document rather than silently substituting. Everything else in the brief's recommended shape is adopted as written.

— sent from nimble-ferret-574

[gunbai-bot]

Both findings in review 64146 are correct and fixed. The first is the most substantive defect any review has found here, because the fix changes what §8 is allowed to claim.

1. False rung on the byte partitions. The partitions are CitedToAuthority publisher figures summed from the safetensors index — deepseek_v4_1_flash_payload_footprint_standing, whose annotation says "PUBLISHER-REPORTED, NOT FLEET-READ" in capitals and whose dissolution names FootprintObservedOnFleet as something that does not yet exist for this revision. The only FootprintObservedOnFleet nearby is a different artifact — artifact_deepseek_v4_flash_native, 168 GB, V4 not V4.1. I claimed the stronger arm in the paragraph whose entire job is rung honesty.

The correction has teeth, which is why I did not just swap the label. weight_fit_of returns WeightFitUnderivable on FootprintReportedExternally — deliberately, so a figure from someone else's deployment cannot support a feasibility verdict here. So §8's rank arithmetic, run through the screen that actually exists today, does not yield 5 ranks and 3 ranks. It yields underivable, for every route. §8.3 now says that outright: the 5-vs-3 split is motivation for the decomposition, not a feasibility finding, until someone reads the byte spans on a Spark. §14 step 1 takes that read together with the 264 B row-size read, since one pass discharges both.

2. EngramPlacement was a nickname. §9 admits three new concepts and that is not one of them; it was a second name for the selected route, in a plan whose thesis is that placement is a property of the route and never of the component. That is precisely the sentence a #11013 worker could mint the forbidden location type from. It now names the MaterializationRoute inside the SelectedWithin arm, and EngramPlacement appears nowhere in the document.

Standing back: five reviews, five real defects, and this document argues for not asserting beyond your evidence. Four of the five were my own corrections failing to propagate or my own standard applied everywhere except the sentence I was writing. That is worth recording in the plan's own terms rather than treating each as a one-off.

— sent from nimble-ferret-574

[gunbai-bot]

Investigated; there is no fix to push from this branch, and pushing one would be worse than leaving it red. Evidence rather than assertion:

The "2 failing" is one lane failure counted twice. required-witnesses-floor fails and witnesses is the aggregating job that reads it. required-witnesses-build is green, which is the discriminating fact — the diff compiles and the corpus is fine.

The same red is on main's own head, so it is not about this PR. Run 34660770145, witnesses on f5830871d:

required-witnesses-build   success
required-witnesses-floor   failure   signature=MemoryStallRefusedPageThrash

Identical signature on all three of my heads (c49821d1a, 8cb561f30, 3bdba8a26), build green on every one. The floor refuses because the runner is re-reading its own evicted pages instead of computing — 284k–327k major faults/minute at ~4% CPU share, with swap disabled so the treadmill holds indefinitely. This diff is two files, neither under src/v2/workflow.

Why I am not pushing a no-op to re-roll it. For this class the outcome tracks whatever page cache the runner cgroup happens to get under co-tenancy, so a retry samples a distribution rather than re-tests anything. A green obtained that way is a draw reported as a pass — a fabricated plausible output with a check mark on it, which is precisely what DESIGN §5 forbids. A real red is more useful than a manufactured green.

One correction to my own earlier report on this: I first cited run 34660763884 as evidence that main was red. That run is the fleet-desired workflow, not witnesses — the right receipt is 34660770145 above. The conclusion held; the citation did not.

The land-or-hold call is with the operator, and the manager has this branch on hold at 3bdba8a2. Review floor is otherwise met: 1 approval, no open REQUEST_CHANGES, no active reviews.

— sent from nimble-ferret-574

[gunbai-bot]

Correcting an overstatement in my comment above. I wrote "the trunk cannot pass this lane." That is stronger than the evidence supports.

What I had was four observations, all red. What I now know: #11013, #11096 and #11088 have since gone fully green on all four checks. So the condition is intermittent, not total — the lane can pass, and my four reds were a sample rather than a demonstration of impossibility.

Everything the earlier comment establishes still stands: the red is not about this diff (build green on every head, same signature on main's own head at run 34660770145), and the "2 failing" is one lane plus its aggregator. What does not stand is "cannot", and the difference matters — "cannot pass" invites someone to go looking for a structural defect that is not there, while "does not always pass under memory pressure" points at capacity, which is where the actual cause is.

This does not change the hold or the method. Sampling for a green is still the wrong way to clear a check, and I am still not pushing to re-roll. It does mean a green run may simply arrive on its own, which would resolve this without anyone deciding anything.

— sent from nimble-ferret-574

[gunbai-bot]

All three findings in review 64308 verified and fixed. Origin sha after push: fc2d38223b0369b0c3d195ad285dd2a2545a160b.

1. The citation — the reviewer is right, and the diagnosis is more interesting than "stale name". The symbols are real, but they were not in this branch's tree:

origin/main : dag/test/claim/spark/serving_runtime_capability_probe_witness_test.dag  ✓
my HEAD     : not found

My branch predates that merge. I verified the witness against origin/main, read its body, and then cited it as though the PR corpus carried it — so a whole-tree grep of the PR finds nothing, and the citation was unresolvable exactly where it needed to hold. Merging main was the fix, not rewording: the symbols now resolve in the tree this PR presents.

2 and 3 are the same defect twice, and it now has a structural repair. Step 3 keyed the probe on "the observed local config digest, not the pull reference" — the precise inversion §11.1 says manufactures a false negative — and the closing line said "a refusal naming the unfunded runtime constraint" where §8.3 now says SelectionNeedsEvidence with the axis declared and funded.

Both are in §14, which is the brief a worker executes, so a stale restatement there outranks corrected prose everywhere else. Three separate reviews have now found this same shape in §14: the argument gets corrected and the landing order keeps the abandoned reading.

So the repair is not another patch. §14 now states no semantics of its own — every step names the section that owns its meaning and defers to it, and the section says so explicitly: where a step and a section disagree, the section wins and the step is the defect. That removes the class rather than the third instance of it.

— sent from nimble-ferret-574

[gunbai-bot]

Both findings in review 64320 are correct — verified against this tree — and I am holding rather than pushing, because this head is frozen pending a review the manager has in flight. Not a disagreement; a sequencing constraint. I pushed over a reported head once already tonight and it cost a reviewer a re-read of a superseded corpus.

Finding 2 is self-inflicted, and the causal chain is the interesting part. constraint_no_redundancy resolves in this tree right now:

HEAD:dag/gunbc/spark/serving_deployment_selection.dag:1093
  data constraint_no_redundancy: DeclarationRef = ...

It resolves because I merged main — the merge that was needed for the #11088 citation in finding 1 of the previous review. So fixing one citation falsified a different status claim three sections away. The generalisation I had not seen: merging main does not only make citations resolve, it invalidates every "in flight / not on main" claim in the same document, and those are precisely the claims that read as settled and get skipped on a re-read. I will therefore re-check all four — constraint_no_redundancy, #11013, #11088, host_commitment — rather than the one named here.

Finding 1 is the surviving-attractor shape, in a document that names it. §11 says "only four are admissible" while §8.2, three sections earlier, says the host list must not be carried here as data and records that "four" went stale when srv9 took the GLM canary. Group A still explains why TP8 needs displacement; the cardinality does not follow. The fix is to drop the count and let host_commitment decide it, not to write three.

Both edits are narrow and ready. They go in on one push when the manager authorises it, and I will report the origin sha read back after pushing.

— sent from nimble-ferret-574

[gunbai-bot]

Disposition on review 64320: both findings accepted, edits authorised and written, deliberately not yet pushed. The published head is still fc2d38223b — a side-chat review is reading it, so pushing now would land a verdict on a stale head for the second time tonight. The edits go in on a single push when that verdict returns.

Finding 1 is worse than the review states, and the extra fact is worth having. Dropping "and only four are admissible" is right, but four is not merely forbidden-as-data — it is now wrong: host_commitment derives three uncommitted units, because srv9 took the GLM canary. §11 now states no count at all and defers to §8.2, and §8.2 records that the value moved explicitly as a demonstration rather than as a figure to consume — replacing four with three would repeat the mistake in a fresher costume. That the number changed twice while this document was being written is the argument for not carrying it.

Finding 2 is right, and the fix is not the sweep it looks like. The four symbols do not resolve alike, checked against live PR state at edit time rather than memory:

#11013  MERGED   -> status clause deleted, constraint_no_redundancy cited plainly
#11088  MERGED   -> same treatment
#11107  OPEN     -> host_commitment's "in flight" wording is STILL TRUE and stays

Sweeping them uniformly would have traded one false status claim for another, which is the actual content of the finding: the defect is not the in-flight phrasing, it is a status claim that nothing re-derives.

And the cause generalises, so it is now a standing instruction in the document rather than a fix to two lines. Merging main — which this plan did, correctly, so a cited witness would resolve here — does not only make citations resolve. It silently falsifies every "not yet on main" claim in the same file, three sections away, with no conflict and no diagnostic, because the merge touches none of its lines. Those claims read as settled, so a re-read skips them exactly when they have gone wrong. That note now sits beside the §14 rule, because they are the same class: a restatement that nothing re-derives.

— sent from nimble-ferret-574