Earlier I argued that most of a long-lived system’s shape was never decided — it’s whatever was expedient the first time, kept in place by everything that got built on top of it. That framing is archaeological: it’s about excavating a shape somebody left behind years ago. But the same process is running right now, in code being written this week, and from the inside it doesn’t feel like fossilization. It feels like getting something working.

Which raises a more useful question than “how do I dig up old expedients.” How do I notice one of mine setting?

Documenting More Doesn’t Help

The obvious fix is to write down the reasoning: leave a note explaining that this was provisional, that the shape is arbitrary, that the next person should feel free to change it. It’s a good instinct and it mostly fails, for a boring reason. On any given day you make dozens of small shape-setting choices — a field name, an ordering, where a boundary falls, what a function returns. You cannot annotate all of them, and you have no way of knowing which one matters. The choice that fossilizes is rarely the one that felt significant at the time. Significant choices get discussed, and discussion leaves a record. It’s the unremarkable ones that harden, precisely because nobody looked at them twice.

So a policy of “document the important decisions” leaves exactly the wrong set undocumented. The important ones were never the problem.

Fossilization Has a Leading Indicator

What you can’t predict in advance you can often observe as it happens. A provisional shape stays genuinely provisional for as long as it has one user: the thing you built it for. Changing it costs what it cost to write. The transition — the actual moment it stops being a temporary thing — is when something else starts depending on it. Not when it gets old. When it acquires its second caller.

That’s a visible event. Someone imports the module. A second code path reads the field. A script starts parsing the output format you picked in five seconds because it was the format that came to mind. At that instant the cost of changing the shape stops being yours alone, and every subsequent dependent multiplies it further. The shape hasn’t become correct. It’s become expensive, which in practice looks the same from a distance and gets treated the same way.

The useful part is that this event happens on a timescale where you’re still around and still remember. You don’t need archaeology to catch it. You need to notice, when someone builds on your work, that a shape you were treating as scratch just got promoted without a promotion review.

What to Do With the Signal

Not “stop and redesign it.” Most provisional shapes are fine, and the ones that aren’t usually can’t be improved much at that moment either — you still don’t know what the eventual usage looks like. The cheap move is smaller: when you see the second dependent appear, spend two minutes deciding whether this is a shape you’re willing to keep. If yes, it’s now a real decision, and a real decision is worth one sentence of justification somewhere durable, because it’s about to become load-bearing. If no, this is the last moment it’s cheap to change — there’s exactly one caller to update, and the fix that costs an hour today costs a migration next year.

Either way the outcome is the same in kind: the thing stops being an accident. It becomes something someone chose, with a reason attached, at the only moment when both the reason and the choice were still available. That’s the whole trick — not preventing expedients, which is impossible and wouldn’t be desirable anyway, but catching the handful that get built on before the record of why closes behind them.