Looks Right Is Not the Same as Is Right

A duplicate is shape-identical to its source. Same tables, same fields, same column count. That's exactly why shape can never prove a copy is the right one, and it's why we nearly built on top of the wrong record without noticing anything was wrong.

We keep an internal check that verifies a piece of infrastructure is wired to the right place before anything writes to it. It compares tables, field names, and structure. For a while, it passed every time.

It was checking the wrong thing.

The copy that looked exactly right

A record we depended on had been duplicated at some point, and the duplicate sat there, untouched, while real work kept happening on the original. Nobody meant for that to happen. It's just what a duplicate does: it exists, quietly, looking exactly like the thing it was copied from.

Our check compared the duplicate against what a correct setup should look like, and it matched. Same table names. Same sixteen fields. Same structure down to the letter. By every test we had, it was fine.

It was also completely stale, and had been for weeks.

Shape was never the right question

The check answered "does this look like the right thing." What it needed to answer was "is this the specific thing," and those are different questions with different answers here. A duplicate copies structure perfectly and copies almost nothing else. It doesn't carry the same history. It doesn't get the same updates. It just sits there, looking correct, because looking correct was the only thing anyone had taught the check to verify.

The property that actually distinguishes a real record from a copy of it is usually something nobody copies by accident: a name a person chose on purpose, not a structure a duplicate function reproduces automatically. Once we started checking that instead, the stale copy failed immediately, loudly, on the first run.

What actually changed

We stopped asking whether something has the right shape and started asking whether it's the specific thing we meant, verified against a property that a copy can't accidentally inherit. It's a small shift in the question, and it's the only version of the check that would have ever caught this.

The broader habit is the same one that shows up anywhere a fix gets trusted too early: confirm the thing itself, not a resemblance to it. A resemblance is cheap to produce, on purpose or by accident, and it will pass every test built to look for a resemblance.

A few questions this raises

Isn't checking structure still useful?

Yes, as a first pass. It catches something obviously broken. It just can't catch something obviously fine that happens to be the wrong one, and that's the failure mode that actually costs time, because nothing about it looks like a failure until much later.

How do you pick the property that actually proves identity?

Ask what a copy inherits automatically versus what a person has to set on purpose. Structure, field names, and column counts are usually inherited. A name someone typed in, a timestamp of when it was actually last touched, an id issued at the moment of creation — those are harder to duplicate by accident, and much more likely to expose a stale copy.

What's the cost of getting this wrong?

In our case, the fix would have looked complete and quietly done nothing, because it was aimed at a copy nobody was actually reading from. The failure wouldn't have shown up as an error. It would have shown up later, as confusion about why something that was supposedly fixed still behaved like it wasn't.