Story 2071: CE-13 — the ONE bundle builder (folding five stores into one pack a brain can read)

🛰️ Satellite — the one sentence

A pure assembler folds cards → chronology → evidence → assertions → contradictions into a context_bundle.v1, spends each section its slice of a named budget tier's token ceiling (recipes live in settings, eval-tuned, not doctrine), stamps a version_hash over exactly what it serves, and caches it in context.bundles; an I/O orchestrator fetches the five sections from the real stores around it, and a quiet-window rebuild consumer drains ops.context_bundle_jobs so a burst of triggers coalesces onto one rebuild.

✈️ Airplane — the sandwich chef with a fixed-size plate

Think of a chef plating one dish the diner (a brain) eats in a single sitting. The frame is the placemat — it sits outside the plate (and outside the hash): the prompt is system + charter → frame@frame_version → bundle@version_hash, so the frame is carried once, beside the bundle, never baked in (collision #6). The plate is a fixed size — the budget tier (S/M/L → a token ceiling). The recipe decides how much of the plate each of the five courses gets (a strategy diner gets more assertions+contradictions; a drafting diner more evidence). If a course won't fit its slice, the chef serves fewer items and says so (truncated=True) — never overfills the plate.

Two facts make the dish honest. First, the ticket: the chef writes a version_hash over exactly the food on the plate, so two identical orders get the identical ticket and cache to one entry — and the four roles of a command panel all quote the same ticket, so the critic judges what the proposer ate. Second, the freshness sticker: the plate records the watermarks it was built from, so when the pantry restocks (a card updates) the diner is told the dish is stale — served anyway, flagged, never silently.

Restocking is the last trick. Fifty documents landing in a minute would have the chef re-plate fifty times, each throwing away the last. Instead each restock drops one sticky note per matter in a bin (the partial-unique index enforces one), and each new note slides the "cook after" time forward. A runner drains the bin only for notes whose time has passed — so the dish is re-plated once, after the burst quiets (target ≤ 2 min).

  request(profile, budget, role_hint, focus?)
        │
        ▼   build_bundle  (I/O)
   ┌──────────────────────────────────────────────────────────┐
   │ cards       ← context.document_cards        (spans inline)│
   │ chronology  ← Neptune Event traversal        (resolver)   │
   │ evidence    ← CE-5 hybrid+rerank  IFF focus   (else empty) │
   │ assertions  ← context.assertions            (spans inline)│
   │ contradictions ← Neptune CONTRADICTS edges    (resolver)   │
   └───────────────┬──────────────────────────────────────────┘
                   ▼   assemble_bundle  (PURE)
        recipe × budget → per-section token allocation
        truncate to fit  →  truncated: bool
        sha256(firm,matter,axes,layout,served items) → version_hash
                   ▼
        upsert context.bundles   (one per firm×matter×profile×budget×role_hint)

  frame  ──stays OUTSIDE──▶  cache key = (prompt_version, frame_version, version_hash)

  card/assertion/graph change ─▶ enqueue_rebuild ─┐  (not_before = now + debounce)
                                                   ▼
     50 triggers ─▶ ONE pending job (partial-unique) ─▶ drain when not_before ≤ now
  

🔬 Microscopic — the four decisions that carry the story

1. The pure/I-O split — so the invariants test without infrastructure

assemble_bundle is a pure function: it takes already-fetched section inputs and produces the bundle — no DB, no graph, no clock. That is where the two merge gates live and where they test with zero infrastructure: byte-identical hash (same items in → same version_hash) and token ceiling + truncated (a small budget cuts items, the total never exceeds the ceiling, a cut section says so). build_bundle is the thin I/O shell that fetches the five sections and calls the pure core. A green pure test is necessary; the integration test against a real, empty-first-run matter is what proves the door is not welded shut.

2. version_hash is over what is SERVED, and the frame is not in it

The hash is computed after truncation, over (firm, matter, profile, budget, role_hint, layout_version) plus each section's kind and the JSON of the exact items served — spans carry the verbatim quote, so "item refs AND texts" are both in it. built_at and the watermarks are deliberately excluded (they are staleness metadata, not content), which is why two builds seconds apart still hash identically. The frame lives outside the bundle and outside the hash; a section-order or recipe change bumps layout_version (a hash input) to invalidate caches without forking the schema.

3. Recipes in settings, budgets as config — tuned, not doctrine

The S/M/L tiers survive as named tiers, but every number behind them — the ceiling and the per-profile section weights — is an eval-tuned config default in settings.py (context_bundle_budget_tokens, context_bundle_recipes), per the RFD's supplement 7A: token cost and latency are forces the golden-corpus eval balances, and lost-in-the-middle means the eval may tune a budget down. Consuming code never hardcodes a weight; it reads the recipe. The builder proves the ceiling regardless of what the eval picks — token_estimate and truncated enforce it.

4. Staleness is decidable, and rebuild is debounced — never silent, never a stampede

A bundle records the watermarks it was built_from. Read-time staleness is the cheap comparison — has a card/assertion updated_at advanced past the stored watermark? — because recomputing the graph watermark on every read would defeat the cache; the event-debounced consumer is what re-derives the expensive ones. A stale bundle is still served, flagged. Rebuild triggers coalesce: the ops.context_bundle_jobs partial-unique index guarantees one undispatched job per matter, each trigger slides not_before forward, and the drain claims only due jobs with FOR UPDATE SKIP LOCKED so parallel workers partition the ledger instead of double-firing.