Architecture Decision Records have become a staple of modern software engineering.

They answer useful questions:

• What decision was made?
• When was it made?
• Who approved it?
• What alternatives were considered?

They're a significant improvement over tribal knowledge.

I think they're still missing the most valuable piece of information.

The Missing Section

Open almost any ADR and you'll find something like this:

Decision

Use PostgreSQL.

Use Kafka.

Split the monolith.

Adopt Kubernetes.

What you rarely find is this:

> What would cause us to reverse this decision?

That's a surprisingly important omission.

Every Architecture Decision Has an Expiration Date

Engineering organizations often behave as though architecture decisions are permanent.

Reality disagrees.

The assumptions that justified yesterday's architecture are constantly changing.

Traffic changes.

Teams grow.

Companies shrink.

Cloud pricing evolves.

Compliance requirements appear.

New technologies mature.

An architecture that was exactly right three years ago may now be introducing unnecessary complexity.

The problem isn't that the original decision was wrong.

The problem is that nobody recorded what conditions would make it wrong in the future.

Decisions Without Exit Criteria Become Dogma

Imagine reading an ADR that says:

> We are adopting Kubernetes.

Useful.

Now imagine reading this instead:

Decision

Adopt Kubernetes.

Assumptions

• Engineering organization will exceed 40 engineers.
• Multiple independent deployment teams are expected.
• Multi-region scheduling is anticipated within two years.

Revisit this decision if:

• Platform team remains under five engineers.
• Deployment frequency stays below once per week.
• Operational overhead consistently exceeds feature delivery gains.

Suddenly the document isn't just explaining today's decision.

It's telling future engineers how to know when it's time to rethink it.

We Version Code Better Than Decisions

Git captures every code change.

Yet architecture decisions often remain frozen.

Years later engineers ask:

• Why are we still doing this?
• Does anyone remember why we chose this technology?
• Is this still solving the problem it was meant to solve?

Those questions aren't signs of poor engineers.

They're signs of incomplete architecture records.

Every ADR Should Contain Predictions

One simple addition could dramatically improve the usefulness of Architecture Decision Records.

Every ADR should include explicit predictions.

For example:

We expect deployment frequency to double.

We expect incident recovery time to decrease.

We expect operational effort to remain constant despite customer growth.

Now reality has something to evaluate.

Instead of debating opinions years later, the organization can compare predictions with actual outcomes.

Every ADR Should Include a What Would Change Our Mind Section

This may be the single highest-leverage addition.

Every decision should answer:

• What evidence would invalidate this decision?
• What assumptions deserve monitoring?
• Which future events should trigger a review?
• What metrics should improve if this architecture is correct?

Those questions transform architecture from documentation into a living engineering hypothesis.

AI Makes This More Important

AI can generate architecture proposals remarkably well.

What it cannot do without context is determine whether the assumptions behind those proposals remain valid.

If future engineering systems are going to assist with architecture, they won't just need previous decisions.

They'll need the reasoning that explains when those decisions should evolve.

Living Architecture

Architecture shouldn't be treated as a collection of permanent truths.

It should be treated as the current best explanation of how to solve today's problem given today's understanding.

Tomorrow's evidence may demand something different.

Good architecture isn't architecture that never changes.

It's architecture that records enough context to make future change intelligent instead of accidental.

That's what Architecture Decision Records should ultimately preserve.

Not just what we decided.

But how we'll know when it's time to decide differently.