settled-reach/docs/workshops/body-map-viewer/tyre-round1.md

---
title: "Body Map Viewer — Tyre's Round 1 Position"
description: "Governance amendment ratification, gridunit↔D-243 reconciliation, determinism boundary, and cliff ruling — against the measured ①–⑤ appendix"
type: workshop
status: active
workshop: body-map-viewer
created: 2026-07-25
---

# Tyre — Round 1 Position

*cracks knuckles* — the measurements came back clean. All four of the things I
flagged as "could kill this" in the implications pass (hydrology cost, derive
throughput at scale, wire size, deep-step cost) landed as **GO**, not
**maybe**. That changes my tone here: I'm not hedging architecture around
unknowns anymore, I'm ratifying specific amendment text against specific
numbers. Four questions, in the brief's order.

---

## 1. Governance delta — ratified as concrete amendment texts

The implications pass named five amendment targets. I said "surface as a
workshop question, don't pre-decide" for the sharpest one (gridunit↔D-243) —
that's §2 below. The other four are ready to write as filing text now; the
measurements didn't change their *direction*, only confirmed their necessity
and gave me the numbers to cite.

### 1a. D-166 corollary — repoint, don't delete

**Current text (2026-07-21 amendment):** *"Display at every rung samples the
derivation at canvas resolution (the ladder is a continuous field, not a
stack of fixed display rasters)."*

**Amendment text (proposed):**

> **Amended 2026-07-25 (body-map-viewer workshop — stepped ladder).** The
> zoom mechanism is superseded from continuous to **stepped** (T-1143 ruling
> 3, itself superseded — see §1b). The corollary's intent — no magnified
> interpolation of a coarser composite; no undersampling below the source
> floor — is **preserved, re-expressed per-step**: each step's data canvas is
> a derivation sampled at that step's native gridunit spacing (never coarser
> than the step's own floor, never finer than the display's own tunable
> ratio, measurement ④'s 1×1-to-5×5 px/gridunit band). Display *within* a
> step holds that step's canvas at a fixed, texel-exact ratio (measurement ⑤:
> upload cost 0.03–4.6 ms across every canvas size tested, never a frame-budget
> risk) — the "continuous field" framing is retired as literally false (it never
> was continuous once server-side per-step canvases replaced client
> `_canvas.scale`), but the guarantee it protected is intact, just discretized.
> The one honest new gap this creates — magnification of the *held* canvas in
> the interval just before a step-cross — is a **named, bounded** exception,
> not a silent violation: see §1e below and Red Flag 1. The corollary's
> anti-oversample/anti-undersample clause now reads: *"a gridunit is never
> derived coarser than its step's floor and never displayed finer than the
> tunable ratio; between-step magnification is bounded by construction to one
> step interval and is the ladder's only sanctioned display-time scaling."*

### 1b. T-1143 ruling 3 — superseded for zoom transport

**Amendment text (proposed):**

> **Superseded 2026-07-25 (body-map-viewer workshop).** T-1143 ruling 3
> ("continuous cursor-anchored zoom... wheel-zoom carries the view from the
> orbital frame down through regional granularities continuously") is
> superseded for the **transport mechanism**: zoom is **stepped** — scroll
> clicks through discrete gridunit-spacing levels, one server-canvas fetch
> per crossed step boundary. What SURVIVES from ruling 3, unchanged: (a)
> cursor-anchored centering, (b) edge-scroll pan, (c) the HARD condition that
> a full zoom-out resets to the canonical orbital frame and location. A
> client-side morph/tween between held step canvases is an *investigation
> item* — cosmetic interpolation of already-arrived data while the next
> step's canvas is in flight, never re-derivation, never a second source of
> positional truth (see §3, determinism boundary). Ruling 3's "progressive
> capped-density tiling riding the generalized `district_window` carrier, no
> forced tagged-envelope migration" clause is **also superseded** — see §1d,
> the tagged envelope is no longer avoidable and this workshop names it
> expected scope rather than something to keep dodging.

### 1c. `select_rung` / T-1143 §2–§5 rung model — replaced

**Amendment text (proposed):**

> **Superseded 2026-07-25.** The shipped `WindowGranularity` enum
> (Quarter/District/Region, coverage-ceiling-walked via `select_rung` keyed
> on `MAX_COVERAGE_M`) is replaced by the **stepped gridunit ladder**: a
> discrete step index (§3, the step ladder) selects gridunit spacing
> directly, not via a coverage-walk over a fixed rung enum. Rungs-as-
> derivation-granularity survive conceptually — every step still names an
> absolute-metre spacing — but the selector is gone, replaced by "which step
> is the viewport currently on." `resolve_window_granularity`'s whitelist
> discipline (T-1150: finer-than-district integer multiples only, unknown
> values fall back, never trusted from the wire) is the right *shape* for the
> step index's own validation and should be reused, not reinvented.

### 1d. D-226 T-1124 §2 windowed-family ceiling — tagged-envelope migration triggered

**This is the one measurement ④ makes unambiguous, not marginal.** The
brief's own framing ("likely triggers") undersells what T-1179 found: PNG
per-field, the *best* candidate encoding measured, is **21× the ~30 KB
ceiling at the smallest step canvas (330K gridunits) and 563× at the
largest (8.3M)**. Bit-packed and RLE are worse (55×–1,731×). There is no
encoding trick in the measured set that gets a step canvas anywhere near
"exactly one windowed field" territory — this isn't "the ceiling might need
raising," it's "the payload is two to three orders of magnitude past a
ceiling sized for a 4,096-cell window." T-1156's precedent (river skeletons
riding the whole-body family, explicitly *not* triggering the migration) and
T-1170's precedent (courses riding the windowed payload as *content*, not a
*new field*, also not triggering it) both worked because they stayed inside
the existing one-field shape. A step canvas cannot — its cell count alone
(330K–8.3M vs. the 4,096-cell design point) is off by two to three orders of
magnitude before encoding is even considered.

**Amendment text (proposed):**

> **Amended 2026-07-25 (body-map-viewer workshop, superseding T-1143 ruling
> 2's "no forced tagged-envelope migration").** The windowed-family ceiling's
> **purpose** — prevent uncorrelated concurrent windowed queries needing
> per-field request correlation — survives untouched. Its **current
> mechanism** (exactly one windowed field, `district_window`, sized for a
> ≤4,096-cell served window) cannot carry a step canvas: measurement ④
> (T-1179) shows the best available encoding at 21×–563× the ~30 KB reference
> across the three measured canvas sizes (330K/2.07M/8.3M gridunits), with no
> encoding in the measured set closing that gap. The **tagged-envelope
> migration D-225 deferred** (`decode_inbound`'s shape-based demux → a
> required marker field / tagged envelope) is hereby the sanctioned path:
> the step-canvas payload becomes its own tagged message type on the existing
> IPC stream (not a second socket, not a `district_window` growth), landing
> D-225's 2026-06-12 constraint ("the next inbound message type must
> introduce a tagged envelope") on its intended target. Framed as **expected
> scope, executing a planned deferral** — tier: challenging but doable, not a
> risk. The ceiling's rule ("exactly one windowed-query field") is
> re-scoped: it now governs the *legacy* `district_window` carrier only (kept
> alive for whatever windowed traffic doesn't migrate — TBD in round 2's wire
> contract), while the tagged step-canvas envelope is a **new, separate**
> carrier the ceiling rule does not apply to by construction (it isn't a
> second windowed field on the old shape — it's the new shape).

### 1e. river-courses-t1170.md carrier rule — survives, terminology repointed only

No change to the rule's substance. I said in the implications pass this was
"robust to the pivot... cut on the axis the server relocation doesn't touch"
and the measurements don't disturb that: rule (iii) — "rung-indexed invented
detail rides the windowed payload" — still holds; "windowed payload" now
names the **tagged step-canvas envelope** (§1d) rather than the legacy
`district_window` field, but the *content* discipline (courses are payload
content, not a new query field) transfers unchanged. Ruling (i)/(ii) (skeleton
rides whole-body; continuous per-metre fields ride the window) are also
unaffected — Region-rung skeleton still needs the presentation-frame clip
T-1170 §3g describes until Region itself steps onto the ladder (§3, step
ladder — Region likely IS the global/step-0 rung, worth confirming in round
2's synthesis with Araminta).

**Amendment text (proposed):** none required beyond a terminology note —
"windowed payload" in `river-courses-t1170.md` is glossed as "the per-step
data canvas payload (formerly `district_window`, now the tagged step-canvas
envelope, §1d)" at the top of that document, so a future reader isn't
misled by the retired field name.

---

## 2. Gridunit ↔ D-243 reconciliation — the load-bearing call

Called this "the single most load-bearing vocabulary reconciliation" in the
implications pass and refused to pre-decide it. Now I have the numbers.
**Ruling: gridunit spacing snaps to D-243 rung spacings. It does not float
freely per viewport/step.**

### The argument

**Why free-floating breaks first:** if gridunit spacing were `viewport_px ÷
tunable`, two different monitor resolutions (or the same monitor at a
different step-transition moment) would derive **different absolute-metre
sample spacings at the same step**. That's not a cosmetic difference — the
derivation is `derive_at_metres(seed, body, position, spacing)`, and D-227's
whole determinism/cache-validity model rests on *the same inputs producing
the same output forever*. A gridunit spacing keyed to the requesting
client's viewport size means the server-side cache key must include viewport
dimensions (or the cache is wrong for the next client), which contaminates
D-227's "evictable cache, never source of truth, always valid on
recompute" cleanliness with a presentation-layer parameter. It also breaks
the client-side retention premise (premise 9): "a canvas for a fixed seed
never changes" stops being true if the canvas's own grid depends on the
window you happened to have open when you fetched it.

**Why snapping is free, not a compromise:** D-243's ladder already gives us
six absolute-metre rungs below the elastic seam (voxel 1 m, chunk 64 m,
block 128 m, quarter 512 m, district 2,048 m, region ~205 km) — measurement
③ (T-1154) independently confirms block and tile spacing cost the *same*
per-cell rate as District/Quarter (~1.8 µs/cell single-thread, no cutoff
discount below block). There's no derivation-cost reason to invent a
seventh, viewport-relative spacing value — the fixed rungs are already cheap
at every depth the ladder needs. **A step's gridunit spacing IS one of
D-243's absolute rungs** (or, at the very deepest step, the D-243 voxel/tile
itself, 1 m — already the ladder's own floor). Snapping doesn't cost
anything the ladder wasn't already going to pay.

**What DOES float, and this is where premise 5's "tunable" language was
doing real work:** the **px-per-gridunit display ratio** — 1×1 ideal down to
~5×5 acceptable — is the free parameter, and it's a client-side presentation
concern, not a derivation-side one. A 4K monitor and a 1080p monitor
requesting the *same step* get the *same absolute-metre canvas* (same
gridunit spacing, same derived content, same cache entry, shareable) — they
just display it at different px-per-gridunit ratios, which is a pure texture
scale-to-viewport operation, not a re-derivation. This is precisely the
canonical-vs-viewport question (red flag 3) wearing a different hat: the
canvas's *metre extent* should be sized to cover the largest viewport the
step needs to fill at that step's D-243 spacing (measurement ③'s "realistic
deep-step canvas," 216×384 m at 1 m spacing, 82,944 cells, 17 ms parallel —
already computed as a fixed metre-extent shape, not a viewport-px-shape),
and any monitor smaller than that extent just doesn't need all of it.

### Concrete ruling

- **Step → D-243 rung mapping is 1:1 or a documented fixed multiple**,
  chosen in round 2's step-ladder synthesis (question 3 below feeds it). No
  step invents a spacing D-243 doesn't already name.
- **Gridunit = "the per-step data cell," and its metric size is always a
  D-243 absolute-metre value** — the vocabulary clarification I flagged in
  the implications pass resolves cleanly: gridunit is not a *new* spatial
  unit, it's a *role* ("the cell a given step's canvas is sampled at")
  played by whichever D-243 rung that step is pinned to. At the deepest step,
  gridunit and tile (D-243's voxel) coincide exactly — which is exactly what
  "10 px per tile" in the outline already assumes.
- **The px-per-gridunit ratio (1×1 to 5×5) is a display-side tunable**,
  decoupled from spacing. It governs texture-to-viewport scale and canvas
  *extent* sizing, never canvas *spacing*.
- **D-243 gridunit vocabulary entry (filing text):**

  > **gridunit (D-243 amendment, additive).** The per-step data-canvas cell.
  > Not a new spatial rung — a *role* name for whichever D-243 absolute-metre
  > rung (voxel through region) a given zoom step is pinned to. Gridunit
  > spacing is always one of the ladder's fixed metre values; it never floats
  > with viewport size or display resolution. The **display ratio**
  > (screen-px per gridunit, 1×1 ideal, ≥5×5 acceptable per the body-map-viewer
  > workshop) is the free, client-side, viewport-dependent parameter — kept
  > terminologically and architecturally separate from gridunit spacing
  > itself.

This is the "that's actually easier than it sounds" moment I was hoping for
going in: the reconciliation isn't a compromise between two systems, it's
recognizing gridunit was never a competing unit — it's D-243 wearing a
per-step hat, with exactly one genuinely free parameter (display ratio) that
was never a spatial-ladder concern in the first place.

---

## 3. The determinism boundary — where the client may interpolate without creating a second truth

D-010 principle 4 (server owns simulation/derivation state) and D-227
(derive-don't-store, pure function of seed+position) together draw this line
sharply, and the T-1170 course-invention ruling already demonstrates the
right shape in miniature — I want to generalize it rather than invent a new
rule.

### The rule

**The client may interpolate/tween *only* values that are already fully
resolved server-side and arrived on the wire as concrete endpoints or
control geometry.** It may never invent a sample the server hasn't computed,
and it may never smooth/blend *across* a boundary the server treats as
discontinuous (a step boundary, a rung's own truncation floor, a cliff edge).

Concretely, three buckets:

**(A) Legal client interpolation — presentation-only, zero determinism risk.**
- **Step-cross morph/tween** (premise 3, explicitly an investigation item):
  animating from the held (arrived, resolved) coarser-or-adjacent canvas
  texture toward the newly-arrived finer canvas texture. Both endpoints are
  server truth; the client is blending two *already-true* images for visual
  continuity during the fetch window. This is a pure `Tween`/shader
  cross-fade — no new sample is invented, and the final resting state is
  always the server's canvas, never a lerped hybrid held as "the" data.
- **River/road tweening between wire-carried control points**: T-1170's
  Stage A/B course points ship as `Vec<(i32,i32)>` world-metre polyline
  stations. The client draws a smooth curve *through* those points (spline
  interpolation between server-given anchors) — this is cosmetic curve
  fitting of a fully-specified polyline, not invention of new geometry. The
  server has already decided where the river bends; the client is just not
  drawing it as a jagged polyline of straight segments between stations.
  This is exactly what T-1175 (per-vertex tapering, Polygon2D strips) is
  scoped to do, and it's legal by this rule as written today.
- **Texture-to-viewport scaling** (the display ratio from §2): resampling a
  fixed-spacing canvas to fit a monitor's px-per-gridunit ratio is a GPU
  presentation resize, not a derivation. NEAREST/LINEAR filter choice
  (already precedented per-rung in `_filter_for_granularity_v2`) lives
  entirely in this bucket.

**(B) Illegal client interpolation — would create a second source of truth.**
- **Inventing a sample the server never computed** — e.g., a client-side
  guess at what lies between two arrived gridunits at a *finer* spacing than
  the server sent (upsampling terrain detail client-side). This is exactly
  the T-1143 error class (magnified interpolation of a coarser composite)
  the whole workshop exists to kill. The corollary amendment (§1a) forbids
  it structurally — there is no client code path that samples "between"
  gridunits at invented resolution, because the render baseline draws the
  canvas 1:1 (or at the tunable ratio) via RTT, texel-exact by construction.
- **Smoothing across a step boundary**: blending step-N's canvas with
  step-N+1's canvas as if they were one continuous field (rather than
  cross-fading two discrete textures per bucket A) would reintroduce exactly
  the composite-magnification problem — the boundary between two
  differently-sampled canvases is real (different gridunit spacing on each
  side), and pretending otherwise fabricates data.
- **Client-side course/terrain re-derivation** — the T-1170 ruling already
  rejected this explicitly (1a: "Client-side GDScript invention is rejected
  on the determinism surface... a byte-exact two-language mirror... is a
  standing liability"). This generalizes to every invented-detail field:
  hydrology (channel_depth/cliff_edge, §4 below), coast crinkle, vegetation
  massifs — all CPU/Rust server-side only, per the workshop's own locked
  premise 2. GPU is presentation only (the c2 pre-empt from the implications
  pass, unchanged).

**(C) The one genuinely gray case — flagged, not resolved here.** Named-
feature *label placement* (settlement name text, POI glyphs) when two
adjacent gridunits at a coarse step both nominally "contain" the same named
feature — is a small client-side de-duplication/placement heuristic (avoid
drawing the same city name twice at a seam) legal presentation logic, or does
it risk client and server disagreeing about "which gridunit owns this
feature's label"? My read: legal, IF the server always ships feature
*identity* (a stable id) rather than the client inferring identity from
proximity — then client-side de-dup is deciding *where to draw one already-
identified thing*, not deciding *what things exist*. This is Araminta's
named-feature-encoding call (question 1) to confirm in round 2; I flag it
here because it's adjacent to the determinism boundary but is really a wire-
schema question (does the id ship) more than an interpolation question.

### Why this generalizes cleanly

Every "legal" case in bucket A shares one property: **the interpolation
input set is closed and server-supplied** (two full textures, a finite list
of wire-carried points). Every "illegal" case in bucket B shares the mirror
property: **the interpolation would need to invent a new sample outside
that closed set**. That's the same test D-227 already applies to
derive-don't-store generally ("cache is a bonus, never truth") — I'm not
proposing a new principle, I'm stating the existing one precisely enough
that "tween rivers/roads" (Jeroen's outline phrase) has an unambiguous
yes/no per case instead of being a vibe.

---

## 4. Cliff/multi-height ruling — building on Dudley's measurement

T-1177's finding changes the shape of this decision more than I expected
going in. Two things I flagged as open in the implications pass are now
answered by data, not architecture judgment:

1. **The representation question** (min/max height pair vs. dominant height +
   channel-depth + cliff-edge flag) is **settled by what the solver actually
   emits** — `HydrologyResult` already produces `channel_depth_scaled` and
   `cliff_edge` per cell, directly, no re-derivation needed. Dudley's own
   argument against min/max (loses the transition *shape* — is the drop a
   point or does it span the gridunit — and requires synthesizing two heights
   from one number the solver never computed) is correct and I'm not
   relitigating it. **Ruling: dominant-height + channel_depth + cliff_edge is
   the adopted representation.** This was "the first option red flag 4
   named" and it wins because it's the one that requires zero invented
   derivation downstream — the wire field is a direct carry of solver output.

2. **The frequency question changes the stakes.** I framed red flag 4 as "the
   data model needs to represent gorges because hydrology produces them."
   T-1177's honest finding — **zero carved cells across all three
   production-scale benches (512×256, 768×432, 8.3M)**, with a clearly
   articulated structural reason (priority-flood's true-minimum-rim property
   makes single-basin carving mathematically impossible; genuine carving
   needs a rare two-independently-sealed-basins-plus-single-cell-corridor
   geometry) — means gorge cells are a **rare, not routine**, occurrence at
   the scales this system actually runs at. That doesn't remove the need for
   the field (the model must be able to represent what the algorithm
   produces when it does fire, and "structurally rare" isn't "never" — real
   planetary heightmaps beyond the one body sampled may differ), but it
   substantially weakens the wire-cost argument for worrying about it: this
   is a mostly-zero, sparse, `#[serde(default)]`-safe optional field, not a
   dense per-cell cost driver.

### Ruling, stated for filing

**Phase-4 Atlas scope, not deferred to Phase-5.** Two reasons this call
goes *into* scope rather than out:

- **It's nearly free once carved.** The representation is a direct carry of
  existing solver fields — no new derivation, no new invented-detail
  category, and (per the rarity finding) usually a no-op (`channel_depth:
  0`, `cliff_edge: false` for the overwhelming majority of gridunits). This
  isn't "cliffs are hard, defer them" — it's "cliffs are already computed,
  carrying them costs approximately nothing."
- **Deferring it to Phase-5 in-world geometry with only a "steep"
  classification would silently violate D-227's determinism-critical
  framing** of hydrology as a *settled equilibrium*: if the Atlas map shows
  a lake with a smooth shoreline where the settled hydrology solver actually
  computed a carved overflow channel, the map is showing something other
  than what "settled hydrology" means. The whole point of red flag 4 in the
  implications pass was "hydrology can't be settled as producing gorges
  while the data model can't represent one" — now that the solver
  demonstrably does produce them (even if rarely), showing a flattened
  version on the map is exactly that contradiction, just less frequently
  triggered.

**Wire shape (for Araminta's round-1 payload schema, ④):**

```
elevation: existing dominant-height field, unchanged for the non-gorge case
channel_depth: u16 (quantized), 0 for the overwhelming majority of gridunits
cliff_edge: bool (or a bit folded into an existing classification byte)
```

**What this does NOT resolve, staying honest about scope:**
- Whether `channel_depth`/`cliff_edge` ride the *tagged step-canvas envelope*
  (§1d) as two more per-cell array fields, or get folded into a bit of an
  existing field — Araminta's wire-schema call, not mine, but I'd steer
  toward "new arrays" over "steal a bit" given how sparse the data is (a
  sparse-friendly encoding, e.g. PNG-per-field per measurement ④'s own
  finding that DEFLATE handles near-constant fields exceptionally well —
  `morphology`/`vegetation` at 0.0% run density in the RLE table are the
  same shape channel_depth's near-all-zero distribution would have —
  actually *helps* this field cost less than its raw byte width suggests).
- The client-side render treatment (cliff-face style transition vs. gradient)
  — Stig's call, not architecture's; I note only that `cliff_edge` gives the
  map-art function exactly the signal it needs to make that choice without
  inventing anything (bucket A interpolation, §3: the client is styling a
  server-supplied boolean, not deciding where a cliff is).
- Whether Block/Tile rungs (where gorge-scale features would actually be
  visible at all, per T-1154's spacing) are the step ladder's floor or an
  intermediate step — that's the step-count/step-ladder synthesis, §3 of the
  brief's expected outputs, round 2 territory.

**One honest caveat to carry into round 2 (Troblum's adversarial pass should
stress this):** T-1177 sampled hydrology on exactly one real body (GJ1c) plus
two synthetic gradients. "Structurally rare at production scale" is a
strong, well-argued finding, not a survey across the ~273-body population.
If a body with genuinely different terrain character (e.g., heavily
tectonic, high-relief, many small nested basins) produces carving far more
often than GJ1c did, the "usually a no-op" cost argument softens — still
correct architecturally (the field costs nothing when zero, something
reasonable when nonzero), but the "rare" framing shouldn't be read as
"provably rare across the whole body population." Doesn't change my ruling;
does mean I wouldn't cite "rare" as load-bearing for anything beyond the
wire-cost argument above.

---

## Summary — my four calls, plainly

1. **Governance delta**: five amendment texts drafted and ready to file
   (§1a–1e) — the D-166 corollary repoint, T-1143 ruling-3 supersession, the
   `select_rung` replacement, the tagged-envelope migration as **triggered,
   not merely likely** (measurement ④ makes this unambiguous — 21×–563× over
   the ceiling), and the T-1170 carrier rule surviving with a terminology
   gloss only.
2. **Gridunit ↔ D-243**: **snaps, does not float.** Gridunit is a per-step
   *role* played by a D-243 absolute-metre rung, never a viewport-derived
   spacing. The only genuinely free parameter is the display ratio
   (px-per-gridunit), which is a client-side presentation concern cleanly
   separated from spacing.
3. **Determinism boundary**: client may interpolate only within a closed,
   server-supplied input set (two arrived textures, wire-carried control
   points) — never invent a sample outside it, never smooth across a step or
   rung-truncation boundary. Three concrete legal cases, two illegal, one
   gray case flagged for Araminta.
4. **Cliff ruling**: dominant-height + `channel_depth` + `cliff_edge`,
   **in Phase-4 Atlas scope** (not deferred to Phase-5) — nearly free given
   T-1177's direct-carry representation and rarity finding, and deferring it
   would contradict "settled hydrology" itself. Caveat: rarity is measured
   on one real body, not the population — don't over-lean on it for anything
   beyond wire cost.

Feasible across the board. The measurements did their job — nothing here is
extrapolated, and nothing surfaced a reason to walk back the "architecturally
cleaner than what ships today" read from the implications pass. The tagged-
envelope migration is the one genuine chunk of new work or this list, and
it's exactly the size we already knew it would be.