Two-part column headers were glued into single strings with an underscore, and a later step that split them back mis-assigned one column — how did that happen, and how do you prevent it?

## What gluing is, and what it trades A widening — turning one column's distinct values into new headers, filled from a second column — driven by two name columns produces labels with two parts. Where the tool stores labels as structured parts, that structure survives; where it stores them as flat strings, or where you want a table any consumer can read, the usual move is **gluing**: replacing the multi-part label with one string built from its parts and a separator. The trade is explicit if you say it out loud. You gain a label every consumer understands. You give up the parts — unless you can get them back, and getting them back means parsing. ## Why one label is enough Parsing a glued label is reversible **only while no part contains the separator**. That is a statement about data values, because the parts came from data values. When one part contains the separator, that one string produces more pieces than it was built from, and the pieces are assigned to the wrong roles: - a measure named with an underscore in it glued to a region gives four pieces, not two; - the first piece is taken as the measure, so the measure is a fragment; - the second piece is taken as the region, so the region is also a fragment; - the remaining pieces are surplus, and what happens to them is whatever the parsing code does with an unexpected count — often nothing, because nothing checks. The failure is **per-column**, not global. The other ninety-nine labels split correctly, so the output looks overwhelmingly right, and the one wrong column is usually discovered downstream as a group that should not exist or a measure that appears twice under different fragments. ## Why the usual checks do not see it This is what makes it a senior question rather than a trivia question: | check | does it fire? | why | |---|---|---| | row count before and after | no | gluing and splitting touch labels only | | column count before and after | no | the same number of columns exists throughout | | labels are unique | no | a glued label containing an extra separator is still a unique string | | absent-value counts | no | no cell changed | | piece count per label after splitting | **yes** | the only check whose value actually differs | Every structural assertion you would reach for by instinct passes. The one assertion that catches it is the one about the parse itself. ## Where the guard belongs Put the guard where the information still exists. At split time the parts are already gone and all you can do is notice that the count is wrong. At glue time you are holding both parts and can refuse: 1. **Refuse to glue** when any part contains the chosen separator, and fail there with the offending part in the message. 2. **Choose a separator that cannot occur in a label by construction**, and if you cannot guarantee that, normalise or escape the parts before gluing so that it becomes true. 3. **Assert the piece count** whenever you do split, so a collision that slipped through is loud rather than silent. 4. Treat a bounded split from one end as a **mitigation, not a guarantee** — it survives a collision in the other part and still breaks on a collision in the anchored one. ## The stronger repairs The guards above make the failure loud. These remove it: - **Keep the structure where the tool has it.** Dropping a part, reordering the parts or renaming one needs no parsing at all, so there is no separator and no collision. You pay for this in consumers that must understand compound labels. - **Carry the parts alongside.** Build a mapping from each glued name to its parts at the moment you glue, and hand it along with the table. Every later step reads the mapping instead of re-deriving the parts from the string. This keeps universally-consumable names *and* keeps the parts, at the cost of one more object to pass around. - **Widen later.** Keep the long layout — one row per measurement, with the measure's name in a column of its own — for as long as the work allows, and widen at the very end, where nobody needs to take the names apart again. ## The part people miss The separator guarantee is not static. The label parts are data values, so the set of labels changes with the input: a separator that never occurred in the sample arrives next month inside a new category name, and the pipeline that has worked for a year mis-assigns one column. That is why the guard has to run on every execution rather than once during development, and why "an underscore is fine, labels never have underscores" is a statement about a sample rather than about the data.