Layout fingerprints and a cached coordinate store for placing channels from irregular coords

[d-chambers]

Problem

Spool-level selection on inventory-defined coordinates (spool.select(borehole=...)) works from the index, which stores only <dim>_min, <dim>_max and <dim>_step per patch. Channel membership is decided by rebuilding the sample grid arithmetically (_placed_rows, dascore/core/_spool_inventory.py). When a coordinate is not a CoordRange there is no step, so there is no grid, and the operation refuses:

N patch(es) are described by the inventory but cannot have their channels placed along the fiber: ... (states no channel spacing to place its channels on)

Refusing is right — guessing a step would silently trim the wrong channels — but the consequence is that a format storing an explicit, non-uniform coordinate array cannot use these operations at all. Ran into this on Febus BOTDR files whose distance axis is a 0.1 m grid quantized to float32 (steps 0.099853–0.100098), so it types as CoordMonotonicArray.

Idea

scan_payloads already returns full coordinate managers, and dc.scan reduces them to envelopes and discards the arrays. The exact values are in hand at scan time and thrown away.

1. At scan time, hash the coordinate array and store a layout fingerprint per row in the index.
2. Keep a process-global, content-addressed cache of fingerprint → array, bounded by bytes with LRU eviction.
3. When placement finds a null step, look up the fingerprint; on a miss, materialize that row via scan_payloads and populate. Place from the real values, so nothing is inferred and the objection above does not apply.

Because the key is content-addressed, patches sharing an instrument configuration share one entry — 48 files collapsed to a single array in my case. It is a memo, not meaning: it cannot change an answer, only the time to get one. So it should not live on the spool, take part in equality, or be propagated across derivations, unlike _inventory.

The fingerprint column is the piece that cannot be retrofitted lazily — at query time you hold a row, not an array — so it is worth landing first even if the cache follows later.

Notes and open questions

• Use a real digest over the raw bytes rather than hash(). A collision misplaces channels silently, which is the failure the current refusal exists to prevent.
• Cache the axis, not the derived placement: the latter also depends on the acquisition and distance map, and _placed_rows already caches that tier by (id(context), axis, low, high, step).
• Bound by bytes, not entry count; layouts vary by orders of magnitude. A single operation touches at most one entry per distinct layout.
• Worth a strict mode that refuses rather than faulting in. This makes an index-only API open files, and on a large archive an error may be preferable to a long wait. Hit/miss and bytes-held counters for visibility.
• Persisting the arrays into the index removes cross-session re-reads, but can wait until it is shown to matter.
• Is the fingerprint private to placement, or a queryable fact? "Which patches share an instrument configuration" is useful for chunking, merging, and checking that a setup did not drift mid-deployment — hard to reverse once people select on it.
• Adjacent but separate: FiberIO.scan(snap=True) already lets a format present a stored axis as an idealized uniform range, but appears aimed at time. Whether near-regular distance axes should snap there is a per-format question.

Against dev.