7 min read

A classic ADR (Architecture Decision Record) gets written at the moment of a choice, filed into a documentation repository, and silently ages. Six months later, nobody knows whether the constraints that motivated it still hold. TEAF's Living ADR starts from a simple premise, demanding to uphold: an architecture decision is a flow, not a milestone. It doesn't quietly become wrong over time — it becomes visibly outdated, and that visibility changes everything.

The problem a classic ADR doesn't solve

A well-written ADR documents the context, the options considered, the choice made and its justification. That's already better than a decision made in a meeting and never written down. But a document remains a document: once published, nothing actively connects it to the conditions that justified it. If the vendor it cites changes its pricing policy, if the regulatory constraint evolves, if the capability involved gets rebuilt — the ADR doesn't know. It keeps asserting a truth that may no longer be one.

What makes an ADR "living"

A Living ADR stays connected to three things: the constraints that motivated it, the alternatives ruled out and why, and what has changed since in the Knowledge Backbone. When one of these constraints changes significantly, the decision isn't silently wrong — it's flagged for review, with the exact reason for the trigger. The difference isn't technological in itself: it's a governance discipline requiring decisions to stay linked to their conditions of validity, instead of being detached from them the moment they're published.

What that changes in practice

In an organization practicing classic ADRs, the question "does this decision still hold?" requires an investigation: re-read the document, find who wrote it, manually check whether context has changed. With a Living ADR, the question already has a structural answer: either the decision hasn't been flagged as outdated and is presumed valid, or it has been and the reason is documented. Individual doubt becomes system information.

The discipline behind the tool

None of this works unless the other components of the TEAF loop are genuinely kept fed — a Living ADR in isolation, without an up-to-date Knowledge Backbone or a review process, goes back to being a plain document that ages, just under a more ambitious name. The Living ADR's value is entirely conditioned on the update discipline of the rest of the system. It's an artifact that makes good governance visible, not a substitute for that governance.

  • A classic ADR detaches from its conditions of validity the moment it's published.
  • A Living ADR stays connected to the constraints, alternatives and knowledge that produced it.
  • It doesn't silently become wrong: it becomes explicitly "needs review," with the reason for the trigger.
  • Its value depends entirely on the update discipline of the Knowledge Backbone that feeds it.

Does this challenge sound familiar?

A first conversation to assess it together, at no cost.