A team I was talking with recently lost their senior mechanical engineer to retirement. Forty-some years at the company. They threw him a party, posted about it, and hired a strong replacement from a competitor.

Six months later the next program shipped a mounting interface that failed thermal cycling in the field. Not catastrophically, but enough that warranty claims started coming in. The team chased it for weeks before someone called the engineer at home.

He looked at it for about ten minutes. "Yeah, we tried this in 2014. Same failure mode. We added a relief here for a reason."

That reason wasn't written down anywhere. The new engineer was good. He just hadn't been there in 2014.

What he actually knew

It's tempting to file this as lost knowledge. Forty years of it, out the door, and the usual response is to talk about documentation and mentoring and capturing tribal know-how before people leave.

But look at what he actually said. Not here's how thermal cycling works — the new engineer knew that. What he had was narrower and much harder to replace: he knew that on this class of interface, committing to that geometry forecloses the relief you'll need later.

That's not a fact. It's an ordering judgment. He knew which decisions close doors, and which doors.

And it's the same judgment the whole method runs on. Ranking constraints by how much freedom each removes is exactly what that engineer was doing in his head, on one interface, from memory, without ever calling it that.

Why nobody wrote it down

Here's the part that isn't anyone's fault.

There was no place to put it.

A drawing records what the part is. A spec records what it has to do. A design review records that a decision was approved. None of them record why this got decided before that one, and what the alternative would have cost.

So the ordering judgment on most programs lives in the one place it can: the head of whoever has been there longest. It doesn't get lost through negligence. It gets lost because the organization never had an artifact shaped like it.

That's the actual gap. Not documentation in general — most teams document plenty. A missing document type.

The artifact that holds it

A ranked constraint stack is that document type. It's short — a page, usually — and it holds three things a drawing can't.

The order. Which coupled constraints were ranked where, and therefore what got solved before what.

The reasoning. What each one forecloses, which is the sentence that makes the ranking defensible instead of arbitrary.

The rejected alternatives. The solution that was better for the constraint in hand and got turned down anyway, and what it would have closed off. This is the part that would have caught the 2014 problem, because we tried this, here's the failure mode, here's the relief we added is exactly the kind of line that belongs in it.

The stack is also versioned. The first ranking is a Rev A, and it moves as the solution space narrows — a constraint going from seven to three as concepts firm up is the process working, not a miss. Which means the revision history is the ordering judgment, written down as it forms. Not a summary of it after the fact. The thing itself, accumulating.

The other thing it buys

There's a second use for this that has nothing to do with retirements.

Every program slips on something eventually — a cost, a date, a spec that moved. And someone has to go upstairs and explain how it happened. That conversation goes very differently depending on whether you can show the order the decisions were made in and why.

Without it, you're reconstructing months later from memory and email, and it sounds like a defense. With it, you can point at the moment, show which constraint outranked which, and say what the alternative would have cost. The penalty still stings. But it reads as a trade that was made deliberately rather than a mistake that got discovered.

For anyone reporting to a CEO or a board, that distinction is most of the conversation.

You can't rehire it

The team in that story did everything right on paper. Good succession, strong hire, decent handover. What they couldn't transfer was the part nobody had written down, because there had never been anywhere to write it.

Judgment about ordering takes years to build and about ten minutes to demonstrate, which is why it's so easy to undervalue until it's gone.

You can't rehire it. You can write the ranking down while the people who hold it are still in the building.

If one person on your team is the reason programs don't go sideways, that's worth a conversation before their retirement party.