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

title, description, type, status, workshop, created

title	description	type	status	workshop	created
Body Map Viewer — Tyre's Round 1 Position	Governance amendment ratification, gridunit↔D-243 reconciliation, determinism boundary, and cliff ruling — against the measured ①–⑤ appendix	workshop	active	body-map-viewer	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.