High-resolution morton location channel for ragged/CSR fields

[espg]

🤖 from Claude

Motivation

Ragged/CSR fields (#48 — e.g. the per-cell t-digest in the new atl03_tdigest_healpix.yaml) currently carry values per cell. A natural extension is a ragged field that also carries per-observation locations — a sketch that records where its contributions came from, not just their magnitudes.

The grid's cell_ids/morton coordinates are deliberately coarse (one value per cell at child_order), so they can't serve as a per-observation location channel. And storing per-obs (lat, lon) float pairs is wasteful and lossy-by-convention. A high-resolution morton index (order ~26/27, up to mortie's max of 29) encodes a position as a single integer to sub-meter precision and composes directly with mortie's geometric primitives for distance / containment / neighborhood queries — no decode-to-lat/lon round-trip.

What this needs

1. Retain the per-observation high-resolution morton. HealpixGrid.assign() now resolves points at order 29 before coarsening (PR Lift HEALPix assign reference order to 29 + order-19 t-digest / gain-bias templates #86 lifted the reference order 18 → 29), so the full-resolution index is computed — but it is discarded once cells_of groups observations by cell. A location-carrying ragged field needs that per-obs index retained as a column the reducer sees.
2. A reducer that packs locations into CSR. Alongside (or within) a value sketch, emit per-observation (or per-centroid) morton indices as part of the ragged payload, written via write_ragged_to_zarr.
3. Reader + geometric ops. A reader that exposes the location channel and operates on it via the mortie geometric primitives (espg/mortie MCP Server #59 and read_plan: select mortie linestring vs shapely by grid type (HEALPix -> mortie) #53). Exact signatures to be pinned once those land in a mortie release — they're outside this repo's scope to link here.

Open questions

• Resolution: fixed (26/27/29) or configurable per field? Precision vs. index width / storage.
• Granularity: one morton index per observation, or per t-digest centroid? (A centroid is a merged group, so its "location" would be an aggregate — a representative/centroid morton — which itself may want a mortie primitive to compute.)
• Schema surface: a new field attribute (e.g. location: morton on a ragged field) vs. a paired companion ragged field carrying the location channel.
• mortie primitives: which ops does the reader need (nearest-neighbor, within-radius, cell containment)? Confirm #59/#53 cover them.
• Layout: independent ragged field vs. an extended CSR payload interleaving value + location.

References

• PR Lift HEALPix assign reference order to 29 + order-19 t-digest / gain-bias templates #86 — lifts the HEALPix assign reference order to 29 (the enabler) + the t-digest / gain-bias order-19 test templates.
• Tier-2 vectors: CSR ragged (values/offsets/cell_ids) + t-digest as List<FixedSizeList<2>> #48 — ragged / CSR (t-digest) storage.
• src/zagg/stats/tdigest.py, src/zagg/csr.py, src/zagg/readers/tdigest_tensor.py.
• mortie geometric primitives: espg/mortie MCP Server #59, read_plan: select mortie linestring vs shapely by grid type (HEALPix -> mortie) #53.

Drafted for review — labelled plan; redirect scope/approach on the thread.

[espg]

so the full-resolution index is computed — but it is discarded once cells_of groups observations by cell. A location-carrying ragged field needs that per-obs index retained as a column the reducer sees.

not just a location-carrying ragged field -- there are other use cases where we want to pass the location information forward.

Resolution: fixed (26/27/29) or configurable per field?

configurable. We should set a default-- which would be done by checking and testing the encode/decode speed. I'm curious if order 26 or 27 is faster than 29 because of the suffix math at higher orders.

Granularity: one morton index per observation, or per t-digest centroid? (A centroid is a merged group, so its "location" would be an aggregate — a representative/centroid morton — which itself may want a mortie primitive to compute.)

yes, exactly. We'd want to run a morton function when collapsing the morton indices together, that would give a single morton index at the smallest coverage that contains both / all of the input observations (there are primitives to do this)

Schema surface: a new field attribute (e.g. location: morton on a ragged field) vs. a paired companion ragged field carrying the location channel.

I think new field attribute? What ever is most general-- again, more use cases for this than just t-digest and ragged arrays

Layout: independent ragged field vs. an extended CSR payload interleaving value + location.

What's the question here? I don't understand

[espg]

🤖 from Claude

Implementation plan — high-res morton location channel for ragged/CSR fields

I traced the full path from assign to the CSR on disk. Key finding up front, and a correction to this issue's framing: the per-observation order-29 morton is not discarded after grouping — it survives end-to-end as the leaf_id column, it just isn't exposed to a reducer under a usable name. So most of this is plumbing that can land now; only the reader's geometric ops are blocked on mortie.

What the code does today (grounded)

• HealpixGrid.assign(lats, lons) returns the order-29 morton (grids/healpix.py:30, :214-224); cells_of (:232-236) coarsens to child_order, shards_of (:226-230) to parent_order.
• Read stage: leaf_ids = grid.assign(...) (processing/read.py:401 planned, :605 full) and the order-29 morton is stored as the leaf_id column (read.py:480-482) — not discarded.
• _concat_and_group (processing/aggregate.py:91-140) computes cell_col = grid.cells_of(leaf_id) for grouping but passes the whole col_dict (incl. leaf_id) into _group_columns (:37-62), so leaf_id survives grouping, sorted into per-cell slices.
• _aggregate_chunk_cells (:569-647) slices each cell's columns into cell_data (:622-624) — which therefore already contains the per-obs order-29 morton for that cell — then calls calculate_cell_statistics.
• calculate_cell_statistics (:290-439) dispatches a kind: ragged reducer with values = cell_data[source] (a single source column, :403); _coerce_ragged_value (:479-510) shapes to (n_elements, *inner_shape); payloads collected per cell (:636-643) → ragged_out (worker.py:339,367-369) → write_ragged_to_zarr.
• write_ragged_to_zarr (processing/write.py:194-280) → csr.write_csr (csr.py:36-106): one CSR triple per field per shard; write_csr flattens any (n, *inner_shape) row-major (csr.py:99), so a wider inner shape needs no writer change.
• t-digest reducer (stats/tdigest.py:95-164) takes only values, returns (k, 2) (mean, weight); centroids are merged groups (:144-156), so a per-centroid location is an aggregate, not a passthrough.
• OUTPUT_KINDS = ("scalar","vector","ragged") (config.py:407); get_output_signature (:985+) emits {kind, trailing_shape, inner_shape, dtype, resolution}.

The one real gap: a reducer can only name one source column (aggregate.py:370,403), and leaf_id isn't a documented/declarable source. Everything downstream of "give the reducer the morton column too" already works — and params already resolves bare column names to arrays (aggregate.py:413-414), so params: {location: leaf_id} threads it to a reducer with zero core changes.

Phases

Phase 1 — expose the per-obs morton as a declarable reducer input (enabler; unblocked). Decide the surface (open Q3); recommended start: params: {location: leaf_id} (works today). Add a guard in calculate_cell_statistics raising a clear error if a field requests a location column the read stage didn't supply (non-HEALPix grids). Files: processing/aggregate.py (validation/guard), maybe config.py. Tests: stub reducer sees the order-29 morton via params; a config-validation test.

Phase 2 — a location-carrying ragged reducer. Two shapes (pick in review): (a) paired companion field — a standalone kind: ragged, inner_shape: [1], dtype: uint64 field returning the cell's leaf_id reshaped to (n_obs,1); no new math, reuses _coerce_ragged_value/write_csr; per-obs, exact. (b) per-centroid location — a build_tdigest_located variant (stats/tdigest.py) reducing each centroid's member mortons to one representative; the representative-morton step wants a mortie primitive (#59/#53) and is partially blocked (a stub "pick a member morton" is unblocked). Tests: per-obs round-trips exact mortons; per-centroid asserts representative + shape.

Phase 3 — CSR storage of the location channel. Path (a) needs no CSR change (a second uint64 ragged field, already supported). Interleaved (k,3) also needs none (row-major flatten). Caveat: interleaving float32 digest + uint64 morton forces a common dtype — the paired-companion path (separate dtype per field) avoids the clash and is the safer default. Add a byte-identity guard that value-only ragged output is unchanged.

Phase 4 — reader + geometric ops (PARTIALLY BLOCKED on mortie #59/#53). Extend readers/tdigest_tensor.py (_resolve_chunk_morton:206-228, read_csr) to surface the channel: yield (morton_index, cell_id, locations). Unblocked now: reading the channel back, decoding via existing mort2healpix/mort2polygon, a "raw locations" reader analogous to read_raw_values (:323-376). Blocked: the geometric queries (nearest-neighbor / within-radius / containment) — pin exact signatures once #59/#53 land in a mortie release.

Acceptance criteria

• A ragged field can declare a location channel and validates cleanly.
• The per-obs order-29 morton is retained from assign through grouping into the CSR payload (proven by it reaching the reducer + store).
• The location channel round-trips losslessly through write_csr/read_csr + reader (per-obs path).
• Byte-identical CSR output for existing value-only ragged fields (regression guard).
• Non-HEALPix / location-less configs raise a clear error rather than silently producing garbage.

Open questions

1. Resolution: store at 29 (what assign produces) and let the reader clip2order-coarsen to 26/27, vs a per-field knob. Rec: store at 29.
2. Granularity: per-observation (exact, larger; 2a) vs per-centroid (compact, aggregate; 2b, needs a mortie representative primitive)?
3. Schema surface: new location: morton attribute vs paired companion field vs params: {location: leaf_id} (works today, no core change). Rec: start with params/companion.
4. CSR layout: interleaved single array (shared-dtype clash) vs paired companion CSR (clean per-field dtype). Rec: paired companion.
5. mortie primitives: confirm MCP Server #59/read_plan: select mortie linestring vs shapely by grid type (HEALPix -> mortie) #53 cover NN / within-radius / containment; pin signatures on a release before Phase 4.
6. Grid coupling: leaf_id is HEALPix-morton-specific — HEALPix-only (guard others) or give rectilinear an analogous per-obs index?

Blocked vs proceed-now

• Proceed now (no mortie dep): Phases 1–3 — exposing leaf_id, the per-obs reducer/companion, CSR storage + round-trip + byte-identity guard. Pure plumbing on top of PR Lift HEALPix assign reference order to 29 + order-19 t-digest / gain-bias templates #86.
• Blocked on mortie MCP Server #59/read_plan: select mortie linestring vs shapely by grid type (HEALPix -> mortie) #53 release: the per-centroid representative-morton (2b) and the reader's geometric queries (Phase 4). The location reader (read-back/decode) is unblocked.

No code written, no branch opened. The plumbing is lighter than the issue body assumed — the order-29 morton already rides through as leaf_id.

---

Generated by Claude Code

[espg]

Resolution: store at 29 (what assign produces) and let the reader clip2order-coarsen to 26/27, vs a per-field knob. Rec: store at 29.

yeah, this does make sense-- make sure it's the right order 29. We have two; one is for 'unknown' resolution, ie., point type. we want that one. See mortie function / repo for more details.

Granularity: per-observation (exact, larger; 2a) vs per-centroid (compact, aggregate; 2b, needs a mortie representative primitive)?

Per centroid. When centroid has a mean from one obs, then this is just at the obs level. For aggregated means that are combined, we need to use a bmoc function to collapse the multiple order 29 obs down to the lowest order where all obs can be contained by that morton index. For later merges, we'd be merging < order 29 mean morton locations with order 29 obs that collapse into that mean vector. See bmoc options in mortie (including in process / in flight pr espg/mortie#59 ) for options, and report which function you select / how you plan to do this.

Schema surface: new location: morton attribute vs paired companion field vs params: {location: leaf_id} (works today, no core change). Rec: start with params/companion.

I don't understand this question-- isn't this just expanding the means column to be multivariable (i.e., hieghts means, morton location means)?

CSR layout: interleaved single array (shared-dtype clash) vs paired companion CSR (clean per-field dtype). Rec: paired companion.

Open to either. can you explain why you recommend paired companion?

mortie primitives: confirm #59 cover NN / within-radius / containment; pin signatures on a release before Phase 4.

Also don't understand this question-- what are you asking? What's the actionable decision that needs to be made here?

Grid coupling: leaf_id is HEALPix-morton-specific — HEALPix-only (guard others) or give rectilinear an analogous per-obs index?

Yeah, this doesn't make sense in rect, since we have no way of doing the observation spatial agg. Unless you can think of way-- i.e., can you update a mean value if you know the nobs that went into that mean, without knowing the original values? Can we weight the update perturbation via nobs in the mean?

[espg]

🤖 from Claude

Thanks — these answers converge the design. Taking your six points in order, leading with the decision each time.

(1) Resolution — store at order 29, the point/"unknown-resolution" encoding. Agreed on order 29. Today HealpixGrid.assign calls geo2mort(lats, lons, order=HEALPIX_REF_ORDER) with HEALPIX_REF_ORDER = 29 (src/zagg/grids/healpix.py:222-224, :30), and cells_of/shards_of coarsen via clip2order (:230, :236). I can't browse mortie from here (no egress), so I can't confirm which of the two order-29 encodings geo2mort emits. Action for you to confirm: which mortie call produces the point-type / unknown-resolution order-29 morton — is geo2mort(..., order=29) already that one, or is there a distinct point-type encoder we should swap assign to? Once you point at the function I'll verify the encoding and, if needed, change the one assign call.

(2) Granularity — per centroid, via a BMOC enclosing-cell collapse. Agreed: per centroid, which equals the obs level when a centroid holds one obs. The mechanism I need is a function with this shape:

• input: a set of mortons that may be mixed-order (order-29 raw obs plus already-collapsed < order-29 mean-mortons from prior merges);
• output: a single morton at the lowest order whose cell contains all inputs — i.e. the smallest enclosing cell / common ancestor in the nested HEALPix hierarchy (a 1-cell BMOC / bounded-coverage result).

This composes cleanly with the existing centroid merge: merge_tdigests already does a count-weighted mean fold over (mean, weight) centroids (src/zagg/stats/tdigest.py:226-227), and build_tdigest accumulates with a Welford one-pass (:149); the location channel would run the analogous fold, replacing "weighted mean of values" with "BMOC enclosing-cell of mortons." The mixed-order requirement is the important bit — later merges fold an existing low-order mean-morton with new order-29 obs, so the primitive must accept inputs at heterogeneous orders and still return their common enclosing cell. Action: please confirm the exact BMOC/common-ancestor primitive name + signature from espg/mortie#59 that does "lowest-order enclosing cell over a set of mixed-order mortons"; that's the one I'll wire in.

(3) Schema surface — yes, expand the means column to multivariable. Your framing is the right one and supersedes my earlier "new-attribute vs companion vs params:" question — drop that. Each centroid row widens from (mean, weight) to carry the location channel as well, i.e. (mean, weight, location_morton). This maps directly onto the existing CSR layout: a ragged field is stored as (n_centroids, *inner_shape) and write_csr row-major-flattens whatever inner shape it's given (src/zagg/csr.py:90, :99), so widening inner_shape from [2] to [3] needs no writer change — exactly your "multivariable means column" instinct. There's one dtype wrinkle that decides how the third sub-channel is typed, which is point (4).

(4) CSR layout — the multivariable concept is right, but the location sub-channel must be a uint64 integer array, not a third float column. This is the real reason I'd earlier leaned to a paired companion, and the math forces it:

• a t-digest centroid is (mean: float, weight: float), stored float32 today (tdigest.py:161-163);
• a morton is a large integer. An order-29 nested index over the 12 HEALPix base pixels reaches up to 12 · 4^29 = 12 · 2^58 ≈ 2^61.6 ≈ 3.46e18.
• float exact-integer ceilings: float32 → 2^24 ≈ 1.7e7 (far too small), float64 → 2^53 ≈ 9.0e15. The order-29 morton at ~2^61.6 exceeds even float64's 2^53 — so a full order-29 morton is not representable exactly in any float, float64 included.

So packing the morton into a single interleaved float column is lossy at order 29 regardless of float width. The location channel therefore has to live in an integer (uint64) array to be lossless. Concretely, the "multivariable" payload becomes value-array (float32 (k,2) mean/weight) plus a parallel location-array (uint64 (k,1) morton) — i.e. two CSR triples sharing the same offsets/cell_ids, because write_csr is single-dtype per triple (csr.py:90). It's still one logical multivariable field per your model; it just can't be one physical float array. The actionable choice for you: confirm storing the location sub-channel as a uint64 companion array (lossless at order 29). The only way to keep it a single interleaved column would be to cap the stored order to ~26 and go float64 — 4^26 · 12 ≈ 2^54.6, still above 2^53, so even order-26 doesn't fit a float exactly; you'd have to drop to ~order-25 to fit float64. Since you want order 29, uint64 it is.

(5) mortie primitives — replaced with one concrete actionable. Dropping my earlier vague NN/within-radius/containment question. The only mortie dependency that gates this design is two confirmations: (a) the point-type order-29 encoder from point (1), and (b) the BMOC lowest-order-enclosing-cell primitive from espg/mortie#59 in point (2). Reader-side geometric queries can be specced later against whatever lands in a mortie release; they don't block the storage design.

(6) Grid coupling (rect) — yes, count-weighted incremental mean works, but it's a separate capability from the location channel. Your instinct is correct: you can update a mean from nobs without the original values — new_mean = (old_mean·old_n + batch_sum)/(old_n + batch_n), weighting the perturbation by count. That's exactly the count-weighted fold merge_tdigests already runs over (mean, weight) (tdigest.py:226-227); a plain mean field would just store (mean, count) and merge the same way. So incremental count-weighted mean merge is grid-agnostic and worth having as its own small capability. But it updates the value mean — it does not give rect cells a location. Rect cells aren't morton-indexed (there's no per-obs leaf_id in the rect path), so the location channel is genuinely HEALPix-only, and I'll guard the rect/non-HEALPix path with a clear error rather than silently producing garbage. Confirming: location channel = HEALPix-only (guarded); count-weighted incremental-mean merge tracked separately as grid-agnostic.

---

Converging. The design is settling on: store order-29 point-type mortons, collapse per-centroid via a BMOC lowest-order-enclosing-cell over mixed-order inputs, surface it as a multivariable centroid payload whose location sub-channel is a uint64 companion array, HEALPix-only. Three things still need your confirmation before I'd move to a plan→implement handoff:

(1) the mortie point-type / unknown-resolution order-29 encoder (which function assign should call);
(2) the BMOC lowest-order-enclosing-cell primitive from espg/mortie#59 (mixed-order inputs → single enclosing morton);
(3) sign-off that the location sub-channel is stored as a uint64 companion array (lossless at order 29) rather than a single interleaved float column (the 2^53 vs ~2^61.6 ceiling rules out a lossless float).

---

Generated by Claude Code

[espg]

We can't do anything lossy on the morton index side -- so float for MOC is definitely out.

We could go the other direction -- use int data types for weights and elevations. There's some caveats:

1. We don't use floating point weights today-- these are always integer counts of number of obs per mean. But it sounds like there are (or could be) fancier tdigest variants that partial weights, and switching to int would foreclose on that.
2. Elevation / height is a floating point-- but it doesn't have to be. The unit is meters; the sensitivity of the height measurement is less than that. Using millimeters would put us back into the int space.
3. Two issues with (2) above: averaging losses precision, and we do have negative heights in places (morton uses unit, not int)

The other thing I'm unclear on is what sentinel we use for indicating an empty cell on read-- if it's zero, unit is possible, but if we use np.nan or similar, we're kinda out of luck on unifying to ints.

So, it may still make most sense to "stor[e] the location sub-channel as a uint64 companion array". What's your lean on this? How big of a benefit is storing interleaved vs as a companion array?

he BMOC lowest-order-enclosing-cell primitive from espg/mortie#59 (mixed-order inputs → single enclosing morton);

You should have read access to the mortie git repo now, and not be egress limited-- so please check there and resolve this question yourself (report back what you find).

[espg]

🤖 from Claude

Two asks: (a) my lean on uint64 companion vs interleaved now that float-on-the-MOC-side is out, and (b) the BMOC enclosing-cell finding from reading mortie source. Decision first, then reasoning.

(a) Lean: uint64 companion array. The interleave-into-int idea is real but the sentinel question kills it.

The reframed option you raised — don't float the morton, instead int-ify weights and heights so one interleaved integer array holds everything — is the only way interleaving stays lossless, and it's a clean idea. But three things make the companion array the safer default, in priority order:

1. Sentinel collision is the blocker. An interleaved single-dtype array forces one empty/missing sentinel across all sub-channels. The morton channel has no spare value: a packed mortie word legitimately spans the whole u64 range — order-29 reaches ~12·4^29 ≈ 2^61.6, and the only reserved value is 0, which mortie already uses as the empty/invalid morton (the kernel decode rejects 0 — mortie/tools.py:147-151). So 0 is taken as "no morton," and there is no in-band uint64 sentinel left for "no height" or "no weight" in those same cells. With a companion layout each channel keeps its own dtype and its own sentinel: morton uses 0, the value array keeps NaN/float32 exactly as the t-digest writes it today (stats/tdigest.py:159-162). You flagged this exact worry ("what sentinel… if we use np.nan… we're out of luck on unifying to ints") — companion sidesteps it entirely because the float channel never has to leave float.

2. Int-unifying weights/heights forecloses real things, per your own caveats. Weights are integer obs-counts today but partial-weight t-digest variants would need fractional weights — int closes that door (your point (1)). Heights→millimeter-ints work in principle but (i) averaging is lossy in fixed-point and t-digest centroid means are averages (tdigest.py:148-149, :225-227), and (ii) negative heights need signed ints, while morton is unsigned — so a single interleaved array can't be uint64 for both anyway (your points (2)/(3)). You'd be trading a lossless float channel you already have for a lossy int channel you'd have to build and migrate, purely to merge two arrays into one.

3. The merge mechanics differ per channel, so they don't want to share a cell. Value sub-channels fold by count-weighted mean (merge_tdigests, tdigest.py:223-227); the location sub-channel folds by smallest-enclosing-cell (set-union semantics, see (b)). Different reducers per column ⇒ keeping them in separate arrays is also cleaner in code, not just on disk.

How big is the benefit you'd give up by not interleaving? Small. write_csr already shares offsets + cell_ids across fields and writes one values blob per field (src/zagg/csr.py:104-106); a companion location field reuses the same per-cell offsets, so the only extra bytes are the morton payload itself (8·n_obs) plus one duplicated offsets/cell_ids triple per shard — offsets/cell_ids are O(n_cells), tiny next to O(n_obs) payload. Interleaving saves only that one small index triple while costing the lossy int migration above. Net: companion is ~free and lossless; interleave saves a rounding-error amount of metadata at the cost of precision and flexibility. If you later want a single logical multivariable field, the right move is a thin reader that zips the value triple and the uint64 location triple over the shared offsets — a presentation concern, not a storage one.

One caveat noted so it isn't a surprise: write_csr enforces a single dtype per CSR triple and a consistent inner shape (csr.py:90-104), so "companion" isn't optional polish — it's the only lossless layout unless heights/weights go int. That's consistent with your lean.

(b) BMOC enclosing-cell primitive — read mortie source: it does not exist yet as a single primitive. The pieces exist; the "find the minimal common-ancestor order" step does not.

I read the installed mortie (0.8.1; espg/mortie#59 is not merged into this tree — the registered Rust exports in src_rust/src/lib.rs:1054-1083 contain no enclosing/ancestor function). What exists:

• clip2order(order, midx) → Rust rust_mi_coarsen (mortie/tools.py:556-584, src_rust/src/lib.rs:862-883; core decimal_morton.rs:335 coarsen(word,k)). Coarsens words to a caller-supplied order; mixed-order-input safe (words already ≤ target pass through). It does not compute which order is needed.
• compress_moc(morton) → rust_moc_normalize (mortie/coverage.py:229-248). Merges complete 4-sibling groups into their parent and prunes any descendant already under a coarser ancestor (src_rust/src/moc.rs:262 test_normalize_ancestor_prune). This is a cover compactor, not a single-enclosing-cell reducer: 2-3 scattered order-29 points that don't form complete sibling quads stay separate — it won't collapse them to one ancestor.
• infer_order_from_morton (tools.py:125-143) and generate_morton_children (:587+) — order introspection / descent only.

So the primitive your per-centroid collapse needs — "given a set of mixed-order mortons, return the single morton at the lowest order whose cell contains all of them" (the common-ancestor / 1-cell BMOC) — has no direct implementation. It's expressible from the existing parts (decode each to nested+order via infer_order_from_morton; lift all to a common deep order; find the longest shared NESTED prefix; emit that prefix's cell — i.e. a coarsen to the agreed order), but that orchestration lives nowhere in mortie today and is exactly the kind of hot-loop op that wants to be one Rust call. espg/mortie#59 is the right home for it, but I'm not opening or commenting on a mortie issue — that's a cross-repo side-effecting action that needs your call (§6).

This means the per-centroid location reducer is blocked on that mortie primitive landing in a release: the per-observation / 1-obs-centroid case is unblocked (the morton is just the obs's leaf_id, no collapse), but multi-obs centroid merges and later mean-morton+obs folds need the enclosing-cell op.

Next steps

(1) Lock companion uint64 + proceed on the unblocked slice now. Adopt the companion layout, and let me move this issue to plan/implement for the parts that need no mortie change: retain per-obs order-29 leaf_id through grouping, store it as a uint64 companion CSR field (per-obs and 1-obs-centroid exact), reader read-back/decode, byte-identity guard on existing value-only output. The multi-obs-centroid collapse stays stubbed/guarded pending (2).

(2) You decide the mortie primitive's home. Since the enclosing-cell op is absent, it needs to be added in mortie (likely espg/mortie#59's scope). If you want, I can draft the precise spec here (signature: enclosing_cell(mortons: uint64[]) -> uint64; mixed-order in, single minimal-enclosing morton out; empty/dup handling) for you to carry over — but I won't open the mortie issue/PR myself.

(3) Confirm the height/weight int question is settled as "no". If you'd rather still pursue interleaving via int heights (mm) + int weights, say so and I'll spec the sentinel/sign/precision tradeoffs concretely instead — but my read of your own caveats (partial weights, lossy averaging, negative heights, sentinel) is that companion uint64 is the call.

---

Generated by Claude Code