The ADR as a forcing function: how writing the record changes the decision

This isn't a subtle effect. Teams that adopt ADR practices consistently report that their deliberations change — not just their archives. The discipline of writing down alternatives, constraints, and consequences before a decision is finalized catches gaps in reasoning that verbal agreement had glossed over. The blank template is the most useful thinking tool in the room, and most teams never use it that way because they open it only after the decision is made.

This post is about the forcing-function property: what it is, how it works, and how to use it deliberately rather than accidentally.

What a forcing function does

A forcing function is any structure that makes previously invisible gaps visible. The ADR template is a forcing function because it requires specific content in specific slots — and the inability to fill a slot is diagnostic, not just inconvenient.

When you open a blank Nygard ADR template partway through a decision process and find that you can't fill in the Alternatives Considered section, that's information. It means you haven't actually evaluated alternatives — you've selected from a set you implicitly assumed was complete. The blank section makes the assumption visible in a way that the verbal conversation hadn't.

Three sections do the forcing work. Each targets a different failure mode in how decisions actually happen in engineering teams.

Mechanism one: Alternatives Considered forces enumeration

Most decisions feel like decisions. The team considered options, discussed trade-offs, arrived at a choice. The Alternatives Considered section tests whether this is true.

The test is specific: can you write down each alternative you considered with a concrete rejection reason — not "not chosen" but the actual reasoning behind the rejection? Not "Redis — not chosen" but "Redis — rejected because we have no operational experience running Redis at scale and the on-call burden for a three-engineer infrastructure team didn't justify the 5ms latency improvement we'd gain over PostgreSQL's built-in connection pooling."

For most decisions, teams discover mid-write that they seriously evaluated one or two options, not the three or four they assumed. One option was the obvious choice from the start. One option was raised and dismissed quickly. The other options were never formally on the table at all — they existed as vague awareness that alternatives existed, not as evaluated alternatives with concrete rejection reasons.

The blank Alternatives Considered section makes this visible. If you can write down three alternatives with specific rejection reasons, the decision was well-evaluated. If you can write down one alternative with a vague rejection ("too complex") and two placeholders, the decision was assumed rather than made. The section asks you to prove it, and you either can or you can't.

The failure to fill Alternatives Considered isn't always a problem — sometimes one option is genuinely right and the evaluation of alternatives is fast and clear. But the teams that consistently can't fill it are the teams that are making implicit decisions while believing they're making explicit ones. The blank section makes the pattern visible across decisions in a way that no single decision makes visible.

This is also why the review checklist for ADRs treats Alternatives Considered as the section most likely to fail review: not because engineers don't evaluate alternatives, but because the evaluation happened in verbal discussion or AI chat and was never written down with the specificity the section requires. The forcing function catches what the meeting missed.

Mechanism two: the constraint statement forces precision

The constraint is the single thing that made one option better than the others in this specific situation. Not the performance argument. Not the ecosystem argument. Not the "industry standard" argument. The constraint that was actually decisive, in this team, with this timeline, building this product.

The test: can you write the constraint in one sentence?

If you can't, you don't yet fully understand why you're making this choice. The verbalization of the reasoning felt complete — "we went with PostgreSQL because of its maturity and our team's familiarity." But "maturity and familiarity" is two constraints collapsed into one phrase, neither of which is specific enough to evaluate later. Maturity for what workload? Familiarity on whose part, and for how long, and does it still hold after the team turns over?

The one-sentence constraint requirement forces disambiguation. "Our team has four years of PostgreSQL operational experience and zero Redis production experience, and adding on-call burden for a new data layer during a six-week launch window was unacceptable" is a constraint. It's specific, time-bounded, and evaluable — a future reader can check whether those conditions still hold. "PostgreSQL maturity and familiarity" is a description of the outcome, not the constraint that produced it.

The false constraint problem — where an ADR documents a constraint that was never real — almost always originates from this imprecision. The team had a real constraint (team familiarity) and wrote a more defensible-sounding constraint (performance requirements) because the blank template felt like it was asking for a technical reason and the actual reason felt informal. The forcing function fails here not because the section is empty but because the answer is the wrong answer written precisely. The blank section being filled does not mean the constraint is accurate — but it does force the decision-writer to choose between the honest reason and the presentable reason, and that choice reveals something about the decision and the team culture.

Mechanism three: Consequences forces acknowledgment of trade-offs

The most revealing question in any decision is: what did we give up?

Teams that can answer this clearly have made a better decision than teams that can only describe what they gain. The "what did we gain?" question is easy — you chose the option because you expected to gain something, and listing the expected gains is just describing the motivation. The "what did we give up?" question requires admitting that the chosen option wasn't strictly better than the alternatives — it was better on the dimensions that mattered most in this situation, while being worse on other dimensions.

The Consequences section makes the trade-off visible by requiring both sides. Not "this gives us strong consistency guarantees and a mature ecosystem" but "this gives us strong consistency guarantees and a mature ecosystem; it means we're committed to a shared database process model that will require connection pooling at scale, and the migration path if we outgrow the single-instance model is non-trivial."

Teams that consistently can't write the second half of the Consequences section — the "this forecloses" part — are teams that are rationalizing decisions rather than making them. Rationalization produces the answer first and the reasoning second. The Consequences section asks you to prove that you evaluated both sides, and the absence of trade-offs in the section is diagnostic.

This is the same property that makes the "not building this" record type so valuable: it's the only decision record that is structurally forced to name what was given up (the capability that won't exist) rather than what was gained (the decision that was made). The Consequences section of every ADR is doing the same work — it's just less obvious because it sits alongside the positive case.

The blank ADR as a pre-decision tool

Most teams open an ADR template after the decision is made and write the record from memory. The forcing function still operates — the blank sections still reveal gaps — but the decision is already committed, and the gaps you discover are now retrospective problems rather than forward-looking signals.

The more powerful use of the template is to open it before the decision is finalized and use the sections as the decision agenda.

The ADR-first meeting pattern works like this. Someone proposes a decision. Before the team evaluates it, one person opens a blank template and shares their screen. The meeting proceeds section by section: What's the context — what forces are at play that make this decision necessary now? What alternatives are on the table — and what are the concrete rejection reasons for the ones we're not choosing? What is the single constraint that makes one option better than the others in our specific situation? What does the chosen option enable and what does it foreclose?

The sections change the meeting because they make visible what hasn't been thought through. A team that reaches Alternatives Considered and can only name two alternatives knows it has more research to do before deciding. A team that can't write the constraint in one sentence knows the reasoning isn't fully formed. A team that can list gains but not trade-offs knows the Consequences section is incomplete. The blank fields are the signal.

This is different from the standard "someone takes notes" pattern. Notes record what was said. The blank ADR template records what hasn't been said and tests whether the team is ready to decide. The template is a checklist, not a transcript.

The retrospective ADR as a decision quality audit

Writing an ADR for a decision that was already made is standard practice — most decisions that get documented get documented after the fact. But the retrospective ADR does something the contemporaneous ADR doesn't: it reveals decision quality in hindsight.

The test is whether you can fill the sections from memory.

If you can't fill Alternatives Considered without research, the decision was made without formally evaluating alternatives. You may have had a good reason for the choice — one option may have been genuinely right — but you don't have the documentation to demonstrate that, and you don't have the record of what was considered so future team members can evaluate whether the alternatives situation has changed.

If you can't write the constraint in one sentence from memory, the original reasoning was implicit. The team knew why, but the knowing was distributed across multiple people's heads rather than stated explicitly, which means the reasoning is now fragile in the specific way that implicit reasoning is fragile: it degrades with turnover, with time, and with the normal forgetting that follows any decision once it's implemented and no longer front-of-mind.

If the Consequences section only lists gains and no trade-offs from memory, the decision was rationalized rather than evaluated. The team remembers the reasons to do it, not the reasons to have chosen differently — which is the signature of a decision that was made first and reasoned about second.

None of this means the decision was wrong. A fast, implicit, rationalized decision can still be the right one. But the retrospective ADR surfaces these patterns in a way that nothing else does, because it asks you to prove what you remember and the blank sections reveal what was never thought through carefully enough to be memorable.

This is also why running the WhyChose extractor on AI chat history before writing a retrospective ADR is so useful. The extractor surfaces the AI chat sessions where the decision was actually deliberated — and those sessions contain the alternatives, constraints, and trade-offs that were part of the live reasoning but never made it into formal documentation. The deliberation session before the decision is often more complete than the team's memory of why the decision was made, and the retrospective ADR written from the deliberation session tends to be more accurate than the one written from memory alone.

What changes for teams that use ADRs consistently

The most reliable observation about teams with mature ADR practices is that the forcing function becomes internalized. Engineers who have written thirty ADRs start asking "what are we giving up?" in the meeting, not just in the documentation. They notice when Alternatives Considered is thin and push for more evaluation before the team commits. They reach for the constraint statement when the reasoning feels vague: "Can someone say in one sentence what the single thing is that makes this option better than the others?"

This is the second-order effect of consistent ADR practice. The first-order effect is better documentation. The second-order effect is better decisions — not because the template is magic, but because the template makes the quality standards for decisions visible, and people who write against those standards regularly internalize them.

The broader documentation guide covers the mechanics of ADR practice. The point here is narrower: the discipline of writing ADRs is itself a decision-quality intervention, separate from the archival value of the records. A team that writes thin ADRs is making the same kinds of decisions they were making before — and a team that writes rigorous ADRs, with named alternatives and specific constraints and honest trade-offs, is making better decisions than they were before, regardless of how often the archives get read.

The blank template is the prompt. The sections are the questions. The forcing function is the structural pressure those questions create when they can't be answered — and the diagnostic signal that pressure reveals when you're not ready to decide.

Using the forcing function deliberately

Three concrete practices that use the forcing-function property intentionally rather than accidentally:

The pre-decision template review. Before any significant decision meeting, one person opens a blank ADR and shares it. The team works through the sections before committing. If any section can't be filled with specificity, the decision is tabled until it can be. This takes ten minutes in a forty-five-minute meeting and eliminates the most common failure mode: committing to a decision before the reasoning is complete.

The constraint test. In any technical discussion where someone proposes a direction, ask: "Can you state the constraint in one sentence?" Not the benefits — the constraint. The single thing that makes this option better than the alternatives in this specific situation. If the answer is vague or takes three sentences, the reasoning isn't done yet. This question can be asked in the middle of a conversation without requiring a template or a formal process.

The retrospective audit. For decisions made in the last quarter without ADRs, write the records from memory first, then compare against AI chat history using the extractor. The gaps between what memory produces and what the deliberation sessions contain are the decision quality signal. This is not about documenting the past — it's about calibrating future deliberations based on where memory and deliberation diverge.

The quarterly decision review is the natural cadence for this audit. The review that produces the best follow-through isn't the one that focuses on whether records are complete — it's the one that asks whether the decisions in the archive show the pattern of well-evaluated choices, and whether the team can see its own tendencies (toward thin Alternatives Considered, toward rationalized constraints, toward consequences that list only gains) in the record.

The MADR "because" clause

The MADR 4.0 format makes the forcing-function property explicit in a way the Nygard format doesn't. MADR's Decision Outcome section requires a "because" clause: "We decided [option] because [reason]." The constraint has to appear in the decision statement itself, not in a separate section that can be skimmed or left thin.

This is a meaningful structural difference. In the Nygard format, the constraint lives in the Context section, which is typically written before the Decision section — meaning the constraint is stated as background before the choice is revealed. In MADR, the "because" clause forces the author to name the constraint as part of the decision statement, which makes it easier for reviewers to check whether the stated reason actually distinguishes the chosen option from the alternatives.

Neither format is universally better. The Nygard Context-as-forces framing produces richer context for decisions with complex backgrounds. The MADR "because" clause produces cleaner constraint statements that are easier to verify. The choice of format shapes which forcing-function effect is strongest — Nygard creates pressure to fully articulate the situation, MADR creates pressure to name the decisive reason precisely.

Why this matters more when decisions are made in AI chat

Most consequential decisions are now made partly or entirely in AI chat sessions — the deliberation happens in a conversation with an LLM, not in a document or a meeting. This changes the forcing-function dynamic in a specific way: the blank ADR template is no longer present during the deliberation.

In a traditional decision-making process, the template could be open alongside the discussion. In an AI chat session, the template is typically not present — the engineer is thinking through the problem in conversation with the model, not filling in sections. The ADR gets written after the chat, from memory.

The gap between deliberation and documentation is larger for AI-chat decisions, and the forcing function's ability to improve decision quality is correspondingly reduced. The template can still surface gaps retrospectively — the blank Alternatives Considered section still reveals that the chat only seriously evaluated two options — but it can't stop the decision before it's made the way a blank template in a meeting can.

This is the specific reason that recovering the deliberation session from AI chat history is valuable for ADR writing: the session contains the alternatives that were discussed, the constraints that were weighed, and the trade-offs that were acknowledged in real time, even if none of those made it into the ADR written after the fact. The extractor surfaces this material, and the retrospective ADR written against the deliberation session is much more likely to show the genuine reasoning than the one written from memory.

The forcing function that should have been present during the deliberation can be partially recovered by comparing the memory-ADR against the chat session. The gaps are the signal: the alternatives the engineer evaluated in chat but didn't transfer to the ADR, the constraint that was decisive in the conversation but got replaced with a more defensible-sounding reason in the documentation.

The blank template is the artifact with the highest decision-quality leverage

The standard argument for ADR adoption focuses on the archive: the records you'll have, the reasoning future engineers will find, the documentation that answers the "why did we build it this way?" question. All of that is real.

But the blank template — before any section is filled — is the artifact with the highest leverage on decision quality. Not the finished record. Not the archive. The blank page with the sections waiting to be filled in, opened before the decision is committed, used as the agenda for the deliberation rather than the transcript of a decision already made.

The new-CTO onboarding problem is the most common proof that the archive matters. But the decision quality problem — that engineering teams make implicit decisions while believing they're making explicit ones, commit to choices without fully evaluating alternatives, state constraints they can't actually defend — is more pervasive and more costly, and the blank template addresses it directly in a way that no other tool does.

The question isn't whether to write ADRs. It's whether to write them before or after the decision is made — and what the difference is between those two choices for the quality of the decision you're documenting.

Further reading

• Nygard ADR template — the blank template structure that does the forcing-function work described in this post
• The MADR 4.0 spec — the "because" clause format that makes the constraint statement mandatory rather than optional
• The ADR review checklist — what Alternatives Considered looks like when it passes review vs. when it doesn't
• The cost of a wrong constraint — what happens when the constraint section is filled with a rationalized reason rather than the decisive one
• Decisions that never get written down — the "not building this" record type and why it's the hardest consequence to name
• How to document architecture decisions — the broader practice guide
• WhyChose extractor — recovering the AI chat deliberation session to fill a retrospective ADR from genuine reasoning rather than from memory
• The quarterly decision review — the cadence at which the retrospective audit reveals decision quality patterns across a quarter's worth of records
• The new-CTO onboarding problem — what inheriting decisions made without the forcing function looks like from the outside