Rosetta Stone additions: cost-economics patterns from the genesis catalogue

[danielmeppiel]

Context

A companion change in the agent-side genesis catalogue
(genesis#9)
elevates token economics to a first-class design dimension —
alongside composition, threading, and attention. It introduces a
new substrate vocabulary (cacheable prefix / variable suffix /
output bucket / cache breakpoint / cache invalidator / per-harness
billing unit) and five new patterns: B11 MODEL ROUTER, B12
CACHE-AWARE PREFIX, B13 PROMPT THRIFT, B14 TOOL SUBSET, B15 EFFORT
GOVERNOR (TIER 2 design patterns); A10 GRADIENT WORKFLOW (TIER 3
architectural); and R7 COST PRUNE (refactor).

genesis is the agent-side reference; Ch18 (Architectural
Patterns: A Rosetta Stone) is the handbook-side canonical naming
surface. When the agent-side codification stabilises a pattern, the
Rosetta Stone is where it earns a human-readable name, a classical
analogue, and a place in the layered model — or where it is
explicitly declined because the bar in §8 ("every entry pays its
rent") is not met.

This issue proposes the minimum set of Rosetta Stone additions
that align the handbook with the new genesis vocabulary, without
inflating the catalogue with tactical patterns that the chapter's
inclusion bar deliberately filters out.

Inclusion bar (per Ch18 §8)

The chapter explicitly leaves out (a) harness-specific patterns,
(b) patterns with a useful lifetime shorter than the book, and (c)
patterns the field has not yet converged on. The bar is a name a
reader can use in a design review next week and still recognize in
five years. Each candidate below is judged against that bar.

How the proposed entries fit the layered model

The cost mechanics cut across three existing layers (Foundation,
Assembly, Dispatch) rather than constituting a new layer of their
own. The proposal is to annotate the existing layered model with
a cost-economics overlay and add four new catalogue entries — not
to add a fifth layer.

flowchart TB
    subgraph EXEC["Execution layer"]
        TH[Threading] --- PER[Persistence] --- TRG[Triggers]
    end
    subgraph DISP["Dispatch & orchestration<br/>(§4)"]
        PANEL[Panel] --- WAVE[Wave] --- SG[Scatter-Gather]
        ROUTER["<b>Model Router (NEW)</b>"]
        GRAD["<b>Gradient Workflow (NEW)</b>"]
    end
    subgraph BND["Boundary layer (§5)"]
        SUP[Supervised Execution] --- SCT[Schema-Checked Transformer]
        TSUB["<b>Tool Subset (NEW)</b>"]
    end
    subgraph COMP["Composition layer (§3)"]
        SK[Skill] --- BD[Bundle] --- DEP[Dependency]
    end
    subgraph ASM["Assembly layer<br/>(currently no §; proposed §3')"]
        FS[Agent source code] --- BIND[Binding modes]
        CAP["<b>Cache-Aware Prefix (NEW)</b>"]
    end
    subgraph FND["Foundation layer"]
        MOD[Model] --- HAR[Harness]
    end

    EXEC --> DISP --> COMP --> ASM --> FND
    DISP -.->|"selects per task"| FND
    BND -.->|"gates"| FND
    CAP -.->|"protects prefix from"| INV(["cache invalidators:<br/>timestamps, mid-session<br/>tool add, model switch"])

    style ROUTER fill:#fffbe6
    style GRAD fill:#fffbe6
    style TSUB fill:#fffbe6
    style CAP fill:#fffbe6

Loading

Note: the Assembly layer is named in §1 but currently has no
catalogue section. Cache-Aware Prefix is the first pattern that
demands one, so this proposal also recommends opening a short
§3' Assembly layer catalogue.

Proposed catalogue entries

1. Model Router — Dispatch layer (§4)

• Classical analogue: Strategy [GoF] — partial;
  Content-Based Router [Hohpe & Woolf, EIP] — precise.
• Intent: Classify a task's complexity in a cheap preliminary
  turn and dispatch the substantive work to a right-sized model
  rather than running every task on a single model class.
• When to apply: When the workload mixes tasks of materially
  different complexity (deep planning vs. lint vs. classification)
  and the foundation layer exposes more than one model class with
  a 5x+ cost spread.
• Consequences: The classification turn is itself a cost and a
  latency tax; routing must be cache-aware (a mid-trajectory model
  switch is a cache invalidator and pays full input on the entire
  prefix on the next turn); the router's classification rules are
  a public contract whose drift produces silent regressions.
• Cross-references: §4 (Dispatch); Ch10 (@sec-runtime-machine)
  for the model/harness seam; Gradient Workflow (below).

2. Cache-Aware Prefix — Assembly layer (proposed §3')

• Classical analogue: Cache-Aside [Kleppmann] — precise;
  Stable Storage / Append-Only Log — partial (the prefix is
  treated as append-only-from-the-head).
• Intent: Lay out what arrives in the context window so that
  stable content (system preamble, tool definitions, scope-loaded
  rules, agent source) sits at the prefix head and volatile content
  (current turn, in-flight diff, fresh tool results) at the suffix
  tail — making the prefix cacheable across turns at a fraction of
  full input cost.
• When to apply: Whenever the harness exposes prompt-prefix
  caching as a billing unit (every major foundation today), and
  whenever a session is expected to run more than one or two turns
  against the same primitive set.
• Consequences: Anything placed in the prefix that mutates per
  turn — timestamps, ephemeral IDs, "last updated" stamps, the
  conversation's own scrollback — is a cache invalidator that
  re-prices the entire prefix at full input on the next turn. The
  layout becomes a load-bearing architectural decision, not a
  cosmetic one. The discipline is shared with the U-curve attention
  argument in @sec-attention-economy: the position you place a rule
  at is taxed in two currencies (attention and dollars), and the
  optima coincide.
• Cross-references: Ch13 (@sec-load-lifecycle) for what the
  harness loads in what order; Ch14 (@sec-attention-economy) for
  the attention overlay on the same layout decision; Lockfile (§6)
  for the closure side.

3. Gradient Workflow — Dispatch layer (§4)

• Classical analogue: Tiered Architecture [POSA] — partial;
  Stratified Pipeline — partial. No clean GoF analogue;
  the closest distributed-systems shape is a topology in which the
  workflow's compute density is stratified across stages.
• Intent: Compose a workflow whose stages run on differently
  sized model classes — a heavy planner at the top, a mid-tier
  implementer in the fan-out, a lightweight reviewer/triage layer —
  rather than running every stage on one class.
• When to apply: When a workflow has a clear shape of small
  number of consequential decisions (suited to a heavy class) plus
  large number of mechanical edits (suited to a mid-tier class)
  plus high-volume filtering or classification (suited to a
  lightweight class), and the foundation layer offers all three.
• Consequences: Each tier boundary is a model switch and
  therefore a cache invalidator within a single trajectory; the
  topology must place the switches at thread boundaries (where a
  new context starts anyway) to avoid paying full input on a warm
  prefix. Composes naturally with Panel (mid-tier lenses, heavy
  synthesiser) and with Wave (heavy planner stage, mid-tier
  execution stages). Without this composition discipline, the
  pattern degrades into "use a cheaper model and hope".
• Cross-references: §4 (Panel, Wave, Threading); Model Router
  (above); Ch16 (@sec-multi-agent).

4. Tool Subset — Boundary layer (§5)

• Classical analogue: Facade [GoF] — partial; Interface
  Segregation Principle [SOLID, Martin] — precise.
• Intent: Expose to the model only the subset of tools the
  current phase or sub-task actually needs, rather than the full
  catalogue. The substrate equivalent is consolidating multiple
  narrow tools behind a single code-execution surface that composes
  them inline.
• When to apply: When the harness's tool catalogue grows past
  the point where the prefix is dominated by tool-definition tokens
  that the current task does not exercise (a common threshold is
  ~20 tools loaded every turn), or when the same tools are loaded
  identically across phases that need disjoint subsets.
• Consequences: The subset becomes a phase-scoped public
  contract; mid-session tool-catalogue mutation is a cache
  invalidator and must be avoided once a trajectory is warm.
  The substrate-side variant (a single code-execution tool) trades
  per-tool schema rigour for prefix compression; the boundary's
  Schema-Checked Transformer pattern moves inside the tool's
  execution rather than at the tool-call seam. This is a deliberate
  trade-off, not a free lunch.
• Cross-references: §5 (Supervised Execution, Schema-Checked
  Transformer); Ch14 (@sec-attention-economy) for the attention
  side of the same constraint.

Updates to the per-layer decision matrix (§7)

Three new rows; one decision-matrix annotation:

Layer	When you have…	Reach for	Trade-off you accept	Failure mode if you skip
Assembly	A session that will run more than a turn or two against the same primitives	Cache-Aware Prefix	Prefix layout becomes a public contract; no timestamps or mutable IDs in the head	Every turn pays full input on the entire prefix
Dispatch	Mixed-complexity workload with a 5x+ cost spread across available model classes	Model Router	Classification-turn cost; routing rules are a public contract	Single-class cost floor; either over-spending on trivial tasks or under-powering hard ones
Dispatch	A workflow with stratifiable stages (planning / execution / triage)	Gradient Workflow	Tier switches must land at thread boundaries to preserve cache	Flat model assignment; cost shape inverted (heavy model on cheap work)
Boundary	A tool catalogue large enough to dominate the prefix, with disjoint per-phase usage	Tool Subset	Subset is a phase-scoped contract; mid-session mutation is a cache invalidator	Tool-definition tax compounds with turn count; prefix size crowds out grounding

Patterns recommended against including

Three of the genesis additions are intentionally not proposed
as Rosetta entries. Each fails the §8 inclusion bar for a different
reason; recording the reason here is half the point.

• B13 PROMPT THRIFT — output-side compression. This is a coding
  discipline ("no preamble; structured output; explicit output
  budget"), not an architectural pattern. The Rosetta Stone is for
  patterns that recur at the layer level; a "be terse" rule is
  appropriately codified in the agent's instructions, not in the
  architectural catalogue. Recommendation: mention in passing
  as the discipline that operates Cache-Aware Prefix and Tool
  Subset together (the output bucket is the third cost lever); do
  not give it its own entry.
• B15 EFFORT GOVERNOR — per-primitive reasoning-effort knob.
  This is a configuration surface, not a pattern. The handbook's
  §8 explicitly excludes "patterns whose shape depends on a single
  vendor's runtime", and effort levels are exactly that today
  (different vendors expose different ladders). When the field
  converges on a portable effort vocabulary, this can be revisited.
  Recommendation: mention as a per-harness adapter concern (it
  belongs in runtime-affordances/per-harness/<harness>.md in
  genesis, which is the right home per §8); not a Rosetta entry.
• R7 COST PRUNE — a refactor pattern with a trigger list. The
  Rosetta Stone catalogues what to reach for, not when to
  refactor. Refactor patterns are a separate genre; including one
  would invite the catalogue to grow refactor entries for every
  existing pattern, which §8 (the inclusion bar) prevents.
  Recommendation: the trigger list belongs alongside the
  decision matrix as a "what to revisit on review" sidebar, not as
  a catalogue entry. The matrix's existing trade-off column already
  carries half of this signal; the rest is operational, not
  architectural.

Edits to existing chapter prose

Beyond the four new entries above, the chapter would benefit from
small annotations:

• §1 layered model: one paragraph noting that cost economics
  cuts across Foundation, Assembly, and Dispatch and is overlaid
  on the existing layers rather than constituting a fifth layer.
  Forward-references Cache-Aware Prefix, Model Router, Gradient
  Workflow.
• §2 reading guide: add cache invalidator and cacheable
  prefix to the vocabulary the catalogue assumes (with a
  footnote pointer to ch14 for the attention-side counterpart).
• §3 Composition layer: annotate the Skill entry to note that
  a skill's transitive closure has both an attention cost (ch14)
  and a prefix cost (Cache-Aware Prefix); the two are different
  ledgers tracking the same load decision.
• §4 note on Wave: add a sentence that the durability of
  inter-wave artifacts is what allows a Gradient Workflow to switch
  model classes at wave boundaries without paying a cache penalty
  mid-trajectory.

Reference footnote (proposed)

The existing [^genesis] footnote already names the agent-side
codification. It should be extended to mention that the cost-side
patterns (B11, B12, B14, A10) are codified there as agent-loadable
assets, with the Rosetta names above as the handbook-side canonical
names.

Definition of done for this issue

• §1 layered-model diagram annotated with the cost overlay
• §2 vocabulary updated (cacheable prefix; cache invalidator)
• New §3' Assembly layer catalogue opened, containing
  Cache-Aware Prefix
• §4 Dispatch layer catalogue gains Model Router and
  Gradient Workflow
• §5 Boundary layer catalogue gains Tool Subset
• §7 decision matrix gains four new rows
• §8 unchanged (the rejected patterns above belong in genesis,
  not here)
• [^genesis] footnote updated

---

Filed as part of cross-corpus alignment with
danielmeppiel/genesis#9.
Genesis is the agent-side reference; this chapter is the
handbook-side canonical-naming surface. The split is deliberate
and load-bearing: the agent loads codes, the architect speaks
names.