What are attributes and coordinates, really? A field/signature model (and maybe a unified store)

[d-chambers]

Posting this as a possible direction to kick around, not a plan. It came out of trying to sharpen what attributes and coordinates actually are, since a lot of recent work (#757, #983, #987, #988) has been legislating the boundary between them case by case.

The itch

An attribute looks a lot like a coordinate that happens to be constant. quality="good" says something about every sample in the patch, the same way the time coordinate says something about every sample in a row. Yet the two live in different containers with different rules, and every combination-policy question (kind, conflict, missing values, promotion) has needed its own debate.

A model

Take the single sample as the atomic unit. Then most patch metadata is a field over the sample set, classified by which dims its values vary along — call that its signature. time has signature ("time",), a per-channel depth has ("distance",), and quality="good" has signature (): constant, broadcasting over the whole array. In this reading an attribute is just the () corner of a lattice whose top is dims itself, and "attr" vs "coord" stops being a difference in kind.

Promotion and demotion are movement along the lattice: concatenate patches that disagree on an attr and it becomes a coordinate along the joined dim (#987); collapse a dim and a coordinate can become an attr. The round trip should be lossless.

But not everything in attrs is a field. Classify each item by how it responds to sample operations (select, chunk, concatenate — they change which samples you have) versus value operations (multiply, envelope — they change what the numbers are):

	invariant under value ops	transforms with value ops
invariant under sample ops	identity (acquisition_key, kind attrs)	data description (data_units, data_type)
acted on by sample ops	domain fields (coords, labels)	the data itself

• Data description is part of each sample's value, factored out of the array: 3.2 m/s is the value, and m/s isn't a label about the sample. That's why squaring a patch squares the units but touches no label, and why the only correct resolution for differing units is conversion — keep_first on units turned out to mean splicing m- and km-scaled samples into one unlabeled array (caught twice independently in the Make a missing attr value a value where patches are partitioned #988 review).
• Identity survives everything and changes only when populations mix, which is exactly why it partitions (Missing attr values should be values, not wildcards, for chunk/concatenate/stack #983).
• Provenance (history, the ids) is in neither cell: it isn't state at all but a record of the path. Two patches with different data and the same route share a processing_id; two with equal data and different routes don't. That's why provenance is (and should stay) exempt from every comparison rule.

A third layer: values vs references. Some attrs are plain values — nothing to know about "good" beyond its spelling. Others are references to entities that exist outside any patch: acquisition_key points at an Inventory node that owns its own facts (geometry, instrument, coupling). The model's placement rule: facts about an entity belong on the entity and get projected onto patches, never copied as per-patch truth. Disagreement between copies of gauge_length across one acquisition's patches is data corruption, not a "conflict" for a merge policy to arbitrate.

The tutorial-sized version of all of this: coordinates say where a sample is, attributes are coordinates that happen to be constant, units say what the numbers mean, the inventory says what the data is of, and history says what was done to it.

Recent work already points this way

• Treat patch attrs and coords as fully independent #757 fully decoupled attrs from coords and made "a name is either a coord or an attr" an invariant.
• Missing attr values should be values, not wildcards, for chunk/concatenate/stack #983/Make a missing attr value a value where patches are partitioned #988 made a missing value a value where patches are partitioned, and a wildcard for two-patch ops — in field terms, a missing attr is an undefined (partial) field, and both rules become statements about whether an entry exists.
• The inventory label formalism landed on membership = no value (State label membership by having no value #950), the same partial-function reading.
• Promote differing non-kind attrs to a coordinate when concatenating #987 proposes conflict="promote", which is the lattice's up-move.

Each of these was argued independently; the model above predicts all of them, which is some evidence it's the right one.

A possible direction for the data model

If we took the model seriously, the containers could follow it:

• One store on the patch: name → field (values, signature, units, role) — essentially a generalized CoordManager that allows signature (). coords and attrs become views: coords = entries with non-empty signature; attrs = the () entries plus data description and provenance, presenting exactly today's interface. One store means name collisions are unrepresentable and promotion is a signature change both views see instantly, rather than a hop between containers.
• PatchAttrs stops being state and keeps its three real jobs: schema declaration (per-name types/validators/roles, enforced when a field is written to the store), boundary DTO (FiberIO readers and the index keep their current contract), and the materialized attrs view (built without re-validation).
• Missingness becomes structural: the store holds only stated fields; defaults live in the schema. The None/NaN/"" sentinel conventions and the exclude_unset tracking disappear, because "not stated" is simply "no entry."
• patch.meta (name to bikeshed) as the uniform access point, and select working over any named field — selecting on a ()-field is the natural keep-all-or-none filter.

Backward compatibility looks surprisingly good: the constructor keeps accepting coords=/attrs= and decomposes them, readers and writers go through the views, and patch.attrs.data_units still works. The churn is internal (store, fingerprints, serialization) — large but mechanical.

What this would not change

• No pint-wrapping of the data array; data_units stays factored out (it's a compressed representation, not an annotation).
• No materialized provenance graph; the ids stay content-addresses.
• dims stays structural — it's the domain itself (signatures are subsets of it), not metadata in any container.

Questions

1. Is the field/signature framing right, or over-formal for what users need?
2. Is a unified store worth the internal churn, or is the better first step just documenting the model and landing Promote differing non-kind attrs to a coordinate when concatenating #987's promote/demote pair?
3. If we do unify: meta? fields? Something else?
4. Where should entity-level facts like gauge_length live long term — patch attrs (denormalized) or inventory-only with projection?

Curious what people think, especially about failure modes of the model — places where a real workflow doesn't fit it.