The Decision Nobody Can Explain a Year Later

A decision survives. The system it changed is still running, the vendor is still under contract, the process still works the way it was set up to work. What does not survive is the reason. Ask why the decision was made, and the answer lives in a chat thread nobody can search, a slide deck from a meeting three reorganisations ago, or the memory of the one person who was in the room. If that person has moved to a different role, the reason is gone. The decision is not.

This is not a story about bad documentation habits. It is a story about where organisations choose to spend effort. Writing down a decision at the moment it is made costs a few minutes. Reconstructing it eighteen months later, when a new CIO wants to know why the landscape looks the way it does, costs days of asking around and guessing. Most organisations pay the second price without noticing they had a choice.

Why the reason disappears faster than the decision

The decision itself is durable because it is embedded in something that keeps running: a system stays deployed, a contract stays signed, a process stays in place until someone actively changes it. The reason behind the decision has no such anchor. It lived in a conversation, and conversations end. It lived in someone's judgement about the options available at the time, and that judgement was never written down because writing it down felt like overhead in the moment the decision was made.

So the asymmetry compounds. The decision persists by default. The reason decays by default. A year later, the organisation has the what and has lost the why, and the two are not equally replaceable: the what is visible in the system, the why has to be reconstructed from people, and people forget, leave, or remember it differently from each other.

What a reason actually needs to hold

A reason that survives does not need a full architecture repository behind it. It needs four things, and all four are small enough to write down in the minutes right after a decision is made, not months later.

What the decision was. Not the technical detail, the actual choice: which system, which vendor, which approach, stated plainly enough that someone unfamiliar with the project can read it and understand what changed.

What was known at the time. The context the decision was made in: what problem it was solving, what constraints applied, what information was available. This is the part that disappears fastest, because it stops being obvious the moment circumstances change. What looked like the only reasonable option in a given quarter can look arbitrary a year later if nobody recorded the constraints that made it reasonable.

What else was on the table. The options that were considered and set aside, and roughly why. A decision that names its alternatives is far easier to defend later than one that only names its outcome, because "we chose X" invites the question "why not Y", and if Y was never considered on the record, nobody can answer it with confidence.

Who decided, and what they expected to happen. A named owner, and the consequence the decision was meant to produce. Without an owner, a decision becomes an orphan that everyone can point to and nobody can speak for. Without a stated expectation, there is nothing to compare the outcome against later.

None of this is architecture documentation in the traditional sense. It is closer to a receipt: compact, attached to the moment of the decision, and useful specifically because it is light enough that someone will actually keep it.

What this looks like when it is kept

A decision log that holds these four things does something a slide deck cannot: it stays queryable after the meeting is forgotten. In Atlas, a decision record carries a stated context, the alternatives that were considered, an owner, a status, and the consequence that was expected. Each decision can also be linked to the applications and capabilities it touches, so someone asking "what does this decision actually affect" gets an answer instead of a guess. None of that replaces judgement. It just means the judgement someone exercised a year ago is still visible to the person who has to build on it today.

The organisations that lose the most time are not the ones with bad architecture. They are the ones where the architecture is fine but nobody can explain how it got that way. A landscape without traceable decisions is not wrong, but every question about it turns into an investigation. A landscape with traceable decisions turns the same question into a lookup.

A test you can run this week

Pick a decision your organisation made a year ago. Any decision: a vendor switch, a system retirement, a process change that stuck. Now ask a colleague who was not in the room to find out why it was made, without asking the person who made it.

If they can find the reason in a document, in a record, in something that does not depend on a specific person's memory being intact and available, the decision holds. If the only path to an answer runs through someone's recollection of a meeting, the decision is still standing, but the reason behind it already started disappearing the day it was made. The gap between those two outcomes is not a documentation preference. It is the difference between an organisation that can explain itself and one that can only guess.