A column named for a money amount holds text, and two rows carry the same row label - what did those names guarantee?

## A name is a string beside the values A field name is metadata: a short string recorded next to a run of values. Nothing in the holding reads the word in it. There is no step at which a design compares the string "amount" against the values under it and forms an opinion, so a field named for a money amount holding text is not a failure of the holding - it is the holding behaving exactly as designed. The name told a human something. It told the machine nothing. This is why the failure mode here is always silence. A wrong name does not raise anything; it just misleads every person and every review that comes afterwards, until a downstream step that actually depends on the content fails somewhere unrelated. ## A row label is a key nothing checks A row label is the per-row key a design stores beside the values, in designs that have the concept at all. Like the field name, it is stored rather than validated. Nothing checks the set of labels for uniqueness at the moment they are set, and nothing rechecks them after an operation produces new rows. Duplicates are legal. The word "key" is doing damage here. Reserve it for something that an engine enforces: - a **declared key in a storage engine** is a constraint: the engine refuses data that violates it, and that refusal is the guarantee you are relying on when you reason about the data later; - a **row label in an in-process holding** is a description: it is written down beside the values, carried along by operations, and checked by no one. They look the same in a diagram and behave completely differently the first time the data misbehaves. ## What is actually maintained Something *is* maintained, and it is worth separating from the names so the two do not get confused: - **every value in a field shares one representation** - that is a property of how the field is stored, and the holding really does keep it true; - but that representation is not derived from the name. It comes from the values and from whatever the code asked for, and the two can disagree freely; - several designs also offer a **fallback representation that stores a reference per cell**, which lets a single field hold values of entirely different kinds without complaint, so even the one maintained property has an escape hatch. | stated by the holding, checked by no one | maintained by the holding | |---|---| | what a field is called | that a field's values share one representation | | that a name describes the contents | that the rectangle stays rectangular | | that row labels are unique | that a label, once set, is carried along by operations | | that a label means the same thing as an identifier elsewhere | nothing about what the label means | ## Where the false expectation comes from Almost everyone who believes labels constrain something is importing the belief from somewhere it is true. A storage engine rejects a duplicate on a declared key; a schema on a typed interface rejects the wrong kind of value. Both of those guarantees are made by a component whose job is to refuse things. An in-process holding's job is to hold things, and it refuses almost nothing - which is part of why it is fast and pleasant to use interactively. ## What to do about it 1. **Decide what you actually depend on.** Usually it is one or two properties: this field is numeric, these row labels are unique, this identifier is present on every row. 2. **Check them where the data enters your code**, not where it eventually breaks. The check is cheap relative to the analysis and it converts a silent wrong answer into a loud stop. 3. **Write names that describe rather than promise.** A name that implies a unit or a guarantee the data does not carry is worse than a vague one, because it is believed. ## Descriptive is not the same as worthless The trap on the other side is concluding that labels are pointless if they enforce nothing. They are not. A name is the only thing that keeps the meaning of a field attached to its values through a pipeline, and a row label is the only thing that survives a reordering so that two holdings can be brought back together by identity. Both are load-bearing. They are load-bearing as documentation and as correspondence, not as validation - and stating that distinction cleanly is the whole answer to this question.