Gold Standards & ADRs

Every healthy engineering org has a set of default technology choices — the language, the framework, the database, the patterns it reaches for first. Think of them as a paved path. Walking the paved path is the boring, correct default, and the whole point of having one is that you don't re-litigate it on every project. The interesting question isn't 'which stack should I pick?' — it's 'what do I owe everyone when I want to step off the path?' The answer is an ADR.

Gold standards are the agreed-on defaults — chosen once, deliberately, for the whole organization rather than reinvented per project. When you use them as intended, you owe no justification and you write no decision record. That's the reward of the paved path: the choice has already been made and blessed, so reaching for it is free. A new project that uses the standard framework, the standard data store, and the standard patterns simply inherits all that prior thinking. Silence is the correct documentation for the default.

You only owe a record when you leave the path — when you introduce a new library, depend on a new external service, or adopt a new pattern the standards don't cover. That record is an ADR: an Architecture Decision Record. It exists to capture why this project stepped off the paved path, so that six months from now — when someone wonders why this one service uses an unusual queue — the reasoning is written down rather than lost. An ADR is the toll you pay for leaving the default, and it's a fair price.

A good ADR is honest, not a sales pitch. It lists the alternatives considered — including the option of staying on the gold standard — because an ADR that doesn't even mention the default is hiding the most important comparison. For each option it states the trade-offs honestly, rather than stacking the table so your preferred choice obviously wins; a comparison rigged to flatter your decision isn't a decision record, it's marketing. And it spells out the consequences — the future costs, the new maintenance burden, the things that get harder later. The diagram below shows the paved-path default sailing straight through, while a deviation branches off into an ADR that goes to the architect for approval.

There's a role boundary baked into this process. Juniors present ADRs; the architect approves them. You do the work of laying out the options and trade-offs honestly, then you bring that record to the person who owns the architecture — you don't get to wave your own deviation through. Self-approval defeats the purpose, because the whole value of the gate is a second set of eyes weighing your trade-offs against the wider system. The ADR is your argument; approval is someone else's call.

Gold standards and ADRs are the engine of the technical track inside the greenfield workflow: the track starts from the standards and only branches into an ADR when a deviation is needed. And the architect's approval is just one more of the review gates that govern the whole approach — a place where an artifact has to be good enough to pass, not merely exist. Keep your defaults boring, document your departures honestly, and let someone else hold the gate.