Configuration without a reason attached

Every ERP is full of configuration nobody currently at the business set up. A reorder threshold on a product. An approval limit on a purchase order. A routing rule that sends certain invoices to a specific approver instead of the default one. Each of these was a deliberate choice once. None of them carry any explanation now.

Why configuration drifts away from its reasoning

Configuration is set once and then left alone, often for years, because it works and nobody has a reason to touch it. That's exactly the condition under which the reasoning behind it evaporates — the person who set it moves to a different role, changes jobs, or simply forgets the specifics, and the setting keeps running with nobody left who can explain why it's there.

This isn't negligence. It's the natural result of "if it isn't broken" combined with time. Every business accumulates configuration nobody currently there fully understands, the same way every old house accumulates wiring nobody currently living there installed.

Where this becomes a real problem

Someone wants to change it and can't tell if it's safe. A reorder threshold looks too conservative, tying up cash in excess stock. Lowering it seems obviously right — until someone remembers, or doesn't remember, that it was set high specifically because this product had a supply disruption two years ago that nobody wants to repeat.

A new hire inherits settings with no context and either leaves them alone out of caution, which perpetuates outdated logic, or changes them without knowing what they'll break, which is worse — see what a system of record cannot do.

An investigation into an incident traces back to a configuration choice, and the honest answer to "why was it set this way" is "we don't actually know," which is a genuinely uncomfortable thing to tell an auditor or a board.

The specific failure mode: cargo-cult configuration

Once nobody can explain a setting, two things tend to happen, both bad. Some people leave it untouched indefinitely out of superstition — "it's probably there for a reason, don't touch it" — freezing decisions made under circumstances that may no longer apply. Others change it without understanding it, on the reasonable assumption that if nobody can explain it, it probably doesn't matter, which is sometimes true and sometimes exactly wrong.

Both outcomes trace back to the same root cause: the setting survived, the reasoning didn't.

What makes this different from documentation in general

General process documentation is a big, diffuse project that's easy to deprioritise indefinitely. Configuration reasoning is narrower and more tractable — there's a finite, known list of settings in any given system, and each one either has a reason worth recording or doesn't need one at all, because it's the obvious default nobody would question.

That narrowness is what makes this fixable. You don't need a documentation initiative. You need a habit applied at exactly one moment: whenever a setting is deliberately changed from its default, someone writes one sentence explaining why, attached to the setting.

Building the habit

Capture the reason at the moment of change, not afterward. Whoever changes a setting away from its default knows the reasoning right then. A month later, they may not; a year later, they've likely forgotten entirely or moved on.

Focus on deviations, not defaults. A setting left at its obvious default value doesn't need an explanation — the explanation is that nobody had a reason to change it. Only deviations carry risk if their reasoning is lost.

Review configuration alongside process, not separately. When a workflow is reviewed for effectiveness, its underlying configuration should be reviewed in the same sitting — see approval workflows people actually follow — since the two are inseparable in practice even if they're recorded in different places.

Common questions

Why does configuration lose its explanation over time?

Because settings are typically set once and left alone for years while they continue to work. The person who configured them moves on, changes roles, or simply forgets the specifics, and nothing about the setting itself preserves the reasoning behind it — only the outcome persists.

What's the risk of a setting nobody can explain?

Two opposite risks, both real. People either leave it untouched indefinitely out of caution, freezing a decision that may no longer apply to current circumstances, or they change it without understanding it, which can break something that mattered for reasons nobody currently remembers.

Do you need to document every setting in the system?

No. Settings left at an obvious default don't need explanation — there was nothing to decide. The only settings worth documenting are deviations from default, where someone made a deliberate judgement call that a future reader would otherwise have no way to reconstruct.

When is the best time to capture the reasoning behind a configuration change?

At the moment the change is made, by the person making it. That's the only point at which the reasoning is guaranteed to still be available — a month or a year later, the person may have moved on or simply forgotten the specifics that made the decision reasonable at the time.

Related: what a system of record cannot do · approval workflows people actually follow · what your ERP does not record