The most common failure is ADRs as post-hoc justification. The decision was made in a conversation, and the ADR was written afterward to document the outcome. These ADRs are accurate records of what was decided, but they do not contain the reasoning — because the reasoning happened before anyone sat down to write. They look like analysis but function as announcements.
FM8 (Contract Violation) is the downstream failure. When the tradeoff is not documented, teams downstream of a decision do not know what they are depending on. They observe the behaviour of the system and infer guarantees that were never made. When the system changes and the inferred guarantee breaks, they experience it as a contract violation. The violation was actually a communication failure — the contract was never stated, so it could not be transmitted.
FM4 (Data Consistency) has an analogous pattern at the organisational level: when different teams have different understandings of the same decision, they build on conflicting foundations. The inconsistency compounds until a project hits a boundary where the two foundations are expected to integrate.
Concept: The Language of Architecture Decisions Thread: T12 (Tradeoffs) ← implicit tradeoff → named, documented, reversible Core Idea: Technical disagreements are almost always disagreements about unnamed tradeoffs; naming the tradeoff changes the conversation from correctness to context-appropriateness. Tradeoff: AT6 — ADR completeness vs simplicity; the useful ADR names the tradeoff and the reversal condition Failure Mode: FM8 — contract violation; downstream teams infer guarantees from undocumented decisions and break when the system changes Signal: When the same design decision gets relitigated more than once — the original decision did not name its tradeoff; write the ADR now Maps to: Reference Book, Framework 4