Mutable Label As Identity

What goes wrong

An entity and its history are keyed on an attribute that can change or repeat — a name, a phone number, an email, a branch name — instead of a stable id, so when the label changes or is reused, one entity's history splits in two or two unrelated entities merge into one.

Example

Customers are keyed by phone number; a customer changes number, and their order history is now attached to whoever receives the old number.

Not to be confused with

Not a key missing one field (Key Omits A Dimension), not two spellings of one value comparing unequal (Equivalent values compare different), and not a late cleanup hitting a reused id (Generation Blind Cleanup).

Discovered by

@sks24git GitHub

Field notes · 8

@sks24git2026-11-04beat 4 review rounds

A script finds "the pull request for this branch" by branch name, and branch names get reused. An old merged request then passes for the new one, and the script reports a merge of work that never left the branch.

Identify a record by what it holds, not its name. Names get reused; the commit it carries does not.
Split once fixes start making bugs. Five rounds on one function means the cause is upstream.

@sks24git2026-11-04

A record keyed to a fingerprint of a parsed row hashes the model's default fields too, not just what the file says. Add one optional field to the model and every stored decision stops matching and silently disappears.

Fingerprint the source, not the parsed object. Defaults added later change the hash.
Test the hash against the raw row. It catches drift the moment the model grows.

@sks24git2026-11-03beat 1 review round

A runbook said to keep the item stamped with today's date and remove the rest. A run that crosses midnight removes the item it just made, and the next step reads that break as a miss elsewhere.

Keep the exact id you just made, not a date rule. The clock moves between steps.
Repeat every check after the irreversible step. One dropped check hides the copy only it reads.

@sks24git2026-10-14

A tracker dedups issues by the id of the run that reported them, and minor issues stay open. Each new run files them again, so old issues pose as regressions, fire escalations and inflate the counts that gate progress.

Dedup by what was reported, not by who reported it. Every new run brings a fresh reporter id.
Call it a regression only after a fix. An issue never fixed cannot come back.

@sks24git2026-10-09beat 1 review round

A nightly job claimed every new run folder of a persona as its own, by name alone. When another session ran the same persona in those minutes, the night counted and reported a run it never started.

Claim work by a tag you set, not by a name that others share. A shared output folder makes any name guess wrong.
Name the shortcut in the code. Then the reviewer weighs it, not rediscovers it.

@sks24git2026-09-15

A page worked out it was running on a developer's machine, stopped sending analytics, and two lines later still wrote a vote into the production table. That row is indistinguishable from a real visitor's for ever.

One predicate, every exit it should guard. A flag applied at one of two doors protects neither.
"Not measured" is not "not reachable."

@sks24git2026-09-15beat 3 review rounds

A refusal asked whether a branch with this name had ever merged, not whether this tree's work had. After a restart it answered yes, skipped the upload, and told the operator to force-delete the branch.

Ask about the thing, not about its name. A name outlives the work it once pointed to.
Never pair a guess with a destructive instruction.

@sks24git2026-09-11

The page numbered its rows by position, and the server sent only the rows that had something to say. Row one belongs to whoever spoke first, and changes owner the moment the other one speaks.

Send a slot per source, empty ones included. A compacted list plus an index is a name that moves.
Test the case where source one is silent. Such fixtures hide every ordering bug.