ADR from Meeting Minutes — Capturing Synchronous Decisions as Architecture Records

Why meeting-made decisions are the most commonly unrecorded

When an architecture decision is made through an RFC process, the RFC PR is the forcing function for the ADR: the RFC closes with a decision comment, and the closing comment names who should write the ADR and when. There is a named artifact, a named owner, and a clear handoff point. When an architecture decision is made in a meeting, none of these exist. The decision happens in the room, everyone leaves knowing what was decided, and nobody is explicitly responsible for writing the ADR.

Three patterns explain why the ADR doesn't get written:

1. No PR to attach it to. The most natural trigger for writing an ADR is "there is a PR open that implements this decision and the PR description requires an ADR link." For decisions made before any implementation work starts — or for decisions about processes and workflows rather than code changes — there is no PR. The ADR has no natural home.
2. The decision feels obvious in the room. After 45 minutes of whiteboard discussion, the decision that emerged feels so clearly correct that documenting it seems unnecessary. The problem is that this clarity is contextual: it's obvious to the five engineers who were in the room. For the engineer who joins the team six months later, the decision looks arbitrary without the Context section that explains what constraints made it necessary.
3. The alternatives were verbal, not written. In an RFC, rejected alternatives are documented in the RFC text before the decision is made — they're part of the record by construction. In a meeting, alternatives come up verbally, get discussed, and get rejected in real time. Nobody writes them down. By the time someone tries to write the ADR two days later, they remember the decision but have forgotten the specific alternatives that were considered and why they were rejected — which is the most valuable part of the ADR for future engineers.

The result is a systematic gap: meeting-made decisions are precisely the decisions that are most urgent to document (they often affect the widest set of people and establish the largest-scope architectural directions) and the least likely to be documented.

The 24-hour fidelity window

The 24-hour window is not a bureaucratic deadline — it reflects how decision memory degrades. In the first few hours after the meeting, you can recall:

• The specific alternatives that were raised and why they were rejected (the Alternatives Considered section)
• The constraints and forces that made this decision necessary right now (the Context section)
• The specific concerns raised by the person who dissented or was uncertain (the honest Consequences section)
• Who was in the room and who had authority to close the decision (the Decider and Stakeholders fields)

After 24 hours, the alternatives blur — you remember that three options were discussed but not the specific technical objections to each. After 72 hours, the Context section collapses — the forces that made this decision necessary feel self-evident in retrospect rather than specific. After a week, you remember the decision and you can reconstruct a plausible-sounding rationale, but the ADR you write at that point is rationalization, not record.

The practical implication: the ADR written the day of the meeting is worth far more than the ADR written the day before the PR review. The ADR written at 11pm the same day is worth more than the ADR written at 9am the next morning. This sounds extreme but reflects what actually happens in practice: the architectural reasoning that felt crisp in the room is genuinely time-sensitive.

The 48-hour maximum for emergency decisions

For time-critical decisions made during an incident or under immediate operational pressure — where writing an ADR the same day is genuinely impossible — the hard limit is 48 hours. This is the same window that governs emergency change ADRs in ITIL environments. Beyond 48 hours, write a note in the ADR frontmatter: retrospective-confidence: low. This is not a failure state; it's an honest signal to future readers that the ADR was written after the immediate context had faded and may not fully capture what was known at decision time.

What meetings produce that ADRs need

Meetings produce four inputs for the ADR that no other source provides as well:

1. Decision-maker identification

In a meeting, it is usually clear who made the final call — either because the most senior engineer present stated a preference that ended discussion, or because the meeting chair explicitly closed the discussion by summarizing the decision. This person is the ADR's decider. In an RFC process, the decider field is named in the RFC header upfront; in a meeting, it's often implicit. Write it down immediately: "Jane closed the meeting with the decision to use Postgres." That sentence becomes the Decider field in the ADR frontmatter, and it's only accurate if you write it while you still remember who said it.

2. Verbal alternatives that never reached a document

The most valuable part of an ADR for future engineers is the Alternatives Considered section — specifically the alternatives that were genuinely considered and rejected for specific reasons, not the strawman alternatives added for completeness. In meetings, these alternatives come up organically: "What about using Redis for this instead of Postgres?" "We talked about Kafka but dismissed it because of operational complexity." These verbally-dismissed alternatives are the best source for the Alternatives Considered section, and they are only available in the 24-hour window after the meeting. After that, you remember "we considered some alternatives" but not the specific objection to each.

3. Voiced dissents

Meetings often surface concerns that get voiced but don't block the decision: "I'm still worried about the performance implications under load" / "I'm not fully comfortable with this but I won't block it." These dissents are the most honest input for the Consequences section (the negative half). An ADR that only records the benefits of the decision is incomplete; the voiced concerns of meeting participants who weren't fully convinced are exactly the risks the team accepted when making the decision. Write them down: they become the honest Consequences section that future engineers trust more than an all-positive Consequences list.

4. Attendee list and stakeholder scope

Who was in the meeting defines the scope of the decision: a decision made by five engineers from the same squad has different authority than a decision made with the CPO, the lead of the platform team, and two external stakeholders in the room. The meeting attendee list directly fills the ADR's Stakeholders field and establishes the consultative scope of the decision — information that determines whether the decision is legitimate (everyone who needed to be consulted was in the room) or under-consulted (key stakeholders were excluded). Capture it from the meeting invite before the invite expires.

The meeting-to-ADR template variant

The standard Nygard ADR template (Title, Status, Context, Decision, Consequences, Alternatives Considered) works for meeting-made decisions without modification. The following optional frontmatter fields capture meeting-specific context that the standard template doesn't have slots for:

# ADR-0043 — Use Postgres as the primary data store

**Status:** Accepted
**Date:** 2026-06-03
**Meeting date:** 2026-06-03
**Meeting type:** architecture-review
**Attendees:** Jane (lead), Tom, Priya, Marcus (CPO)
**Decider:** Jane
**Transcript:** doc/decisions/transcripts/2026-06-03-data-store.vtt
**Whiteboard:** doc/decisions/images/0043-data-store-whiteboard.png

## Context
[Forces that made this decision necessary, written same-day]

## Decision
We will use Postgres as the primary data store for user and session data.

## Consequences
**Positive:** Single operational surface, team familiarity, JSONB for flexible fields.
**Negative:** Marcus flagged future reporting scale concerns beyond 10M rows — accepted as a known risk; review at 5M rows milestone.

## Alternatives Considered
- **Redis:** raised by Tom for session data; rejected — Postgres provides durable session storage without a second operational dependency.
- **MongoDB:** raised by Priya for flexible schema; rejected — JSONB satisfies flexible-schema needs without giving up relational joins for the reporting queries Marcus flagged.

Notes on the extra fields:

• meeting_date vs date: Usually identical; they differ when the meeting happened on day N and the ADR was committed on day N+1. The date field (the decision date) should reflect when the decision was made (meeting date), not when the ADR was committed.
• meeting_type: Free-text, but useful values are architecture-review, sync-design, incident-response, 1on1, whiteboard. Useful when auditing the decision corpus to distinguish collaborative architecture reviews from solo or small-group decisions.
• Transcript: Optional — only populate if the meeting was recorded and the transcript is committed. A broken link to a transcript that was never committed is worse than an empty field.
• Whiteboard: Optional — populate if a whiteboard photo was taken and committed. See the protocol below.

The whiteboard photo protocol

Whiteboards and physical or digital drawing surfaces (Miro, FigJam) are the primary visualization tool for synchronous architecture discussions. The whiteboard at the end of the meeting is a snapshot of the decision space as it existed in the room: the three options drawn side by side, the constraints written in the margins, the winning option circled. It's the most compact representation of the Context section that the ADR will contain in prose.

The whiteboard photo protocol:

1. Take the photo before leaving the room. The whiteboard gets erased at the next meeting. The photo takes 10 seconds. Do it every time, regardless of whether you're certain you'll write the ADR.
2. Commit the photo to the repository. Convention: doc/decisions/images/NNNN-slug-whiteboard.png where NNNN is the ADR number (or a placeholder like 0043 if the number is already assigned). Commit it in the same PR as the ADR, or in a standalone commit if the ADR write takes longer.
3. Reference it in the ADR Context section. Example: "See attached whiteboard photo (doc/decisions/images/0043-data-store-whiteboard.png) showing the three-option comparison from the June 3 architecture review. The right-hand column showing 'Postgres + JSONB' addresses the flexible-schema requirement that arose in the meeting."
4. Do not link to a Miro board. Miro public links expire and break. If the discussion happened in Miro, export the relevant frame as PNG and commit that instead. See the Miro ADR template guide for the full frame export protocol.

The whiteboard photo is not a substitute for the ADR Context section — it's a supplement. A reader who doesn't recognize the notation on the whiteboard needs the prose Context section. The photo adds the spatial reasoning and visual structure that prose can't reproduce efficiently.

Zoom and Teams transcripts as ADR source material

If the meeting was recorded — common for architecture review sessions and asynchronous-friendly organizations — the auto-generated transcript is the richest available source for the ADR, richer than notes because it captures the exact phrasing of rejected alternatives and dissents.

Auto-transcripts have known weaknesses for architecture ADRs:

• Technical terms get mangled: "Kafka" → "cap shop", "PostgreSQL" → "post-dress sequel", "Redis" → "Reedis". Verify every technical term before using a transcript as source material.
• Whiteboard content is not transcribed. The transcript captures spoken words; any information conveyed through the whiteboard is absent.
• Speaker attribution errors are common in mixed-accent teams. Verify who said what against your memory before using speaker-attributed quotes.

The practical workflow for transcript-to-ADR conversion:

1. Download the transcript from Zoom or Teams (VTT or TXT format).
2. Open Claude.ai or ChatGPT and paste the transcript with the prompt: "Extract this meeting transcript as an ADR in Nygard format. The decision was: [state the decision in one sentence]. Find and summarize: (1) the Context — what constraints or forces made this decision necessary; (2) the Alternatives Considered — every alternative option that was raised, and the specific objection to each; (3) the Consequences — both what we committed to and any concerns that were voiced but not blocking."
3. Review the AI's extraction against your memory of the meeting. Fix any technical term mangling. Add the whiteboard context that the transcript doesn't contain.
4. Commit the ADR and optionally commit the transcript to doc/decisions/transcripts/.

The Claude.ai or ChatGPT session where you ran the transcript extraction is itself valuable: it captures the full context of the decision synthesis. The WhyChose extractor processes this session and produces a structured decision record that connects the raw transcript to the ADR that emerged from it — useful if you want to audit the extraction fidelity or share the reasoning chain with stakeholders who weren't in the meeting.

Who writes the ADR after the meeting

Four options, ranked from most to least ADR quality:

1. The person who proposed the winning option. They understand the decision best — they can write the Decision section (one active-voice sentence) and the Alternatives Considered section (they know exactly what they compared it against and why they preferred their approach) from memory. They're the most likely to get the Alternatives section right rather than leaving it thin.
2. The meeting chair or facilitator. If the meeting had a designated facilitator who took notes, they have the full picture of the discussion including the alternatives raised and the dissents voiced. They may not understand the technical depth as well as option 1, but they have the record.
3. The named decision-maker (Decider). If the Decider was not the proposer, they can write the ADR with the authority context intact. Their Consequences section will accurately reflect what they accepted when they closed the meeting.
4. Rotation / documentation team. The worst choice for ADR quality. A rotating writer or a documentation team member will write an ADR based on meeting notes alone, without the Alternatives section material that only meeting participants have. The Consequences section will be thin. Reserve rotation for teams where the same 2-3 people consistently own decisions anyway and rotation is effectively option 1 or 2.

The round-trip check: whoever writes the ADR should post a draft (in Slack, in a shared doc, or as a PR with a 48-hour review window) to meeting attendees before merging. The question is not "does this look good?" but "does the Alternatives Considered section match what you remember from the room?" The Consequences negative section will make someone mildly uncomfortable — that discomfort is the signal the ADR is honest.

Retrospective ADRs for past meeting decisions

Teams that start writing ADRs after their ADR-less period face a backlog of significant past decisions that were made in meetings and never documented. If the meeting was months or years ago, the 24-hour fidelity window is closed. Retrospective ADRs from distant meetings have lower quality ceilings:

• Write the Decision section: one active-voice sentence describing what was decided. This should be accurate even years later — you remember the decision if not all the reasoning.
• Write one or two Consequences (the most obvious positive and the most obvious negative). Skip the full Consequences list if you're not confident.
• Leave the Alternatives Considered section empty or mark it as incomplete: "Alternatives Considered: not reconstructed — meeting predated ADR practice. See post-decision AI chat sessions for available reasoning (if any)."
• Add retrospective-confidence: low to the frontmatter. This signals to future readers that the ADR is a best-effort reconstruction, not a contemporaneous record.
• Do not fabricate alternatives or reasoning you're not certain of. A thin ADR with low confidence is more trustworthy than a full ADR with invented content.

For recent meetings (within the last 3–4 weeks), the conversation where the decision was followed up — the ChatGPT or Claude.ai session where someone worked through the implications, or the Slack thread where people asked questions afterward — may preserve the reasoning better than memory. Use the WhyChose extractor to surface these post-decision AI chat sessions, which often contain better Alternatives Considered content than the original meeting because the follow-up analysis is more systematic.

The AI chat layer as informal meeting follow-up

Many meeting-made decisions get a follow-up AI chat session in the hours or days after the meeting: "we decided in our architecture review to use Kafka for event streaming — help me think through the partition strategy and the consumer group configuration." That post-decision Claude.ai or ChatGPT session often contains richer Alternatives Considered content than the original meeting did, because the AI surfaces alternatives the meeting didn't consider and stress-tests the decision against constraints that weren't raised in the room.

This follow-up session is excellent source material for the ADR's Alternatives Considered section. The pattern:

1. Write the core ADR fields the same day (Decision, Context, Decider, initial Consequences).
2. In the next day or two, run the follow-up analysis in Claude.ai or ChatGPT with the decision as context.
3. The AI session will surface alternatives, challenge assumptions, and clarify consequences more rigorously than the meeting could.
4. Merge the AI analysis into the ADR's Alternatives Considered and Consequences sections before finalizing.
5. The WhyChose extractor then processes the AI session and produces a structured record that links the post-decision analysis back to the ADR, useful for audits or team sharing.

This two-step pattern (same-day ADR draft from memory, plus next-day AI-assisted enrichment) consistently produces higher-quality ADRs than either approach alone. The same-day draft captures what only the meeting participants know; the AI follow-up surfaces what the broader decision literature and the AI's training corpus know about similar decisions.

Related questions

Further reading

• ADR vs RFC — what's the difference and when should you use each? — the comparison that frames meeting-made decisions in the broader decision-process landscape. RFC processes add a consultation layer before the decision; meeting-made decisions collapse the RFC and decision stages into a single synchronous session. This page covers when the RFC overhead is worth adding and when synchronous decision-making is the right call.
• The RFC-to-ADR process — lifecycle stages, review ceremony, and section mapping — the counterpart to this page: the formal RFC lifecycle that produces ADRs for decisions that cross team boundaries. Meeting-made decisions skip the RFC stages entirely; this page shows the full RFC → ADR handoff for decisions where the consultation layer is warranted.
• ADR template in Miro — whiteboard sessions and the diagram handoff — for teams that run architecture discussions in Miro rather than physical or digital whiteboard tools. Covers the frame export protocol (commit PNG, not Miro public link), the graduated handoff from Miro exploration to committed ADR, and the specific failure mode of linking Miro boards in ADRs instead of committing exported images.
• The ADR review checklist — a 12-item PR quality gate — the final quality gate before merging an ADR, applicable regardless of whether the decision came from a meeting, an RFC, or a solo analysis. The Alternatives Considered completeness test and the Consequences honesty test are especially important for meeting ADRs, which often have thin versions of both sections.
• ADR supersession pattern — when to supersede, when to annotate, and the bidirectional update protocol — for handling decisions that are reversed at follow-up meetings. The supersession pattern is the correct response to a meeting that reverses an earlier meeting decision; this page covers when supersession is appropriate (Decision section became false) versus when annotation or deprecation is right instead.
• ADR template for ITIL change management environments — for meeting-made decisions in regulated organizations where the architectural decision must also be submitted as a Change Record for CAB approval. The emergency-change ADR variant covers the situation where an incident response meeting makes a decision under operational pressure and the ADR must be written within 48 hours under the retrospective-confidence: low protocol.
• The open-source extractor — processes the Claude.ai or ChatGPT sessions where you ran your post-meeting follow-up analysis or transcript extraction. Surfaces the structured decision content — alternatives considered, trade-off reasoning, decision context — that feeds the Alternatives Considered section of the meeting ADR.
• Retrospective ADR template — writing decision records for pre-adoption choices — the companion page for decisions made before ADR adoption was in place. While this page covers the 24-hour fidelity window for current meetings, the retrospective page covers decisions from months or years ago — with AI chat exports as the primary source for reconstructing the Alternatives Considered section that memory has lost.