The Intent Ledger
← All articles

Record of Decision: 8 Fields Design Teams Must Capture

Record of Decision: 8 Fields Design Teams Must Capture

Hands assembling design decision tokens

A record of decision is a short, source-backed, append-only entry that captures the accepted choice, the alternatives considered, and the rationale behind it. The recommended practice is simple: keep each entry brief, link it to the meeting or file it came from, and never edit it once accepted. Do that consistently and you get traceability, faster onboarding, and fewer arguments about “who decided this and why.”

TL;DR:

  • Record of decision entries should focus on decisions with real alternatives, project-wide impact, or lasting constraints to avoid noise.
  • Once accepted, records must remain append-only to preserve historical context and link subsequent decisions through superseded entries.
  • Storage should be close to related work with consistent tagging and linking from design files and meeting notes to ensure accessibility.
  • Decision ownership involves clear roles: one author drafts, one owner maintains, and one approver validates, to prevent stagnation.
  • Using automated tools like The Intent Ledger can streamline decision logging by extracting decisions from meeting transcripts and linking them directly to source material.

Table of Contents

When Should a Design Team Write a Record of Decision?

Not every choice deserves a record. If your team writes one for every color swap and font tweak, the log turns into noise nobody reads. The useful filter: does this decision have real alternatives, does it affect more than one part of the project, was it actually debated, or does it lock the team into a lasting constraint? Effective decision records prioritize choices with real alternatives, cross-cutting impact, or lasting constraints, while trivial taste calls can stay out of the log entirely.

In architecture and design practice, that usually means things like:

  • Choosing a structural system or facade material over a competing option
  • Locking a component library or design token system across a product
  • Setting an accessibility standard the team will hold to for the rest of the build
  • Agreeing on a client-facing change that alters scope, budget, or timeline

Capture the record at the moment of acceptance, not while you’re still exploring. Sketches, mood boards, and brainstorm notes belong somewhere else. The distinction between exploratory documentation and the decision log itself is what keeps the record short enough that people actually read it.

Pro Tip: If you find yourself re-explaining the same decision in three separate meetings, that’s your signal it should have been logged the first time.

What Goes in a Record of Decision Template?

Keep the fields minimal. A record of decision template that tries to capture everything ends up capturing nothing, because nobody finishes filling it out. ADRs work best around one page, and design teams do well borrowing that same discipline. The core fields:

  1. Decision — one sentence stating what was agreed
  2. Alternatives considered — the two or three options that were actually on the table
  3. Rationale — why this option won, in plain terms
  4. Date — when it was accepted
  5. Owner — who is accountable for it
  6. Status — proposed, accepted, or superseded
  7. Sources — links to the meeting notes, transcript, or file where the discussion happened
  8. Confidence — how solid the team feels about this holding up, and what would trigger a revisit

That last field matters more than teams think. Recording confidence levels and revisit triggers helps a future project lead know whether to treat a decision as settled or as something worth re-checking before building further on it.

Here’s a filled example from a mid-project studio scenario:

Decision: Use a modular curtain wall system instead of a custom-fabricated facade. Alternatives: Custom fabrication, precast concrete panels. Rationale: Modular system cuts lead time and stays within the client’s revised budget after the scope change. Date: February 14, 2026 Owner: Facade lead Status: Accepted Sources: Client review call transcript, 02/12; vendor comparison spreadsheet Confidence: High, unless the client revisits budget again

UX teams can trim this even further. A four-field quick version covering decision, why, alternatives, and date/owner works fine when speed matters more than depth. The goal either way is a link-rich entry, not an essay.

Why Should Accepted Records Stay Append-Only?

Once a record is accepted, leave it alone. Editing it destroys the very thing that made it useful: a snapshot of what the team knew and believed at that moment. Recommended practice treats accepted records as fixed and handles change through a new, linked entry instead.

When circumstances shift, the fix isn’t a revision. It’s a new record that:

  • References the original decision’s ID
  • States what changed and why
  • Marks the old record’s status as “superseded”
  • Carries its own date, owner, and rationale

Use monotonic IDs (RD-001, RD-002, and so on) so the sequence stays traceable even as the project spans months or years. A design lead scanning the log six months later should be able to follow the chain from RD-004 to RD-011 and see exactly how thinking evolved, without guessing which version is current.

Pro Tip: Never delete a superseded record. The moment you remove history, you lose the ability to explain to a client why the team changed course.

Where Should Design Teams Store Decision Records?

Storage matters as much as content. A record nobody can find is functionally the same as a record that was never written. Storing records close to the related work, with predictable naming and metadata, is what actually gets them read.

Common options, each with tradeoffs:

  • Project memory software (purpose-built for decision logs, source-linked, searchable by topic or date)
  • A shared knowledge base (flexible, but easy to let sprawl without discipline)
  • Comments or notes inside design files (convenient, but hard to search across a whole project)
  • A source repository alongside code or drawings (keeps records near the work, but less friendly for non-technical stakeholders)

Whatever you pick, add consistent tags (project phase, discipline, decision type) and link back from Figma comments, ticket descriptions, or meeting notes so a reader hits the record from wherever they’re working, not just from a central index. That combination of a central store plus links from local artifacts is the pattern that actually holds up under real project pace. For more on when documentation earns its keep versus when it’s overhead, the discussion in this design feedback tools guide is worth a look.

Who Owns a Record of Decision, and How Does It Get Approved?

Keep the roles simple: one author drafts it, one owner is accountable for the decision holding, and one approver signs off before status flips to “accepted.” Spreading ownership across a committee is how records rot in “proposed” limbo for months.

  1. Author drafts the record right after the decision is made, while context is fresh
  2. Owner is named in the record and answers for it going forward
  3. Approver reviews and moves status from proposed to accepted (or rejects and sends it back)
  4. Team audits the log periodically, closing or superseding stale entries

Short readouts covering one to three meetings keep decisions moving instead of dragging into extended debate cycles. Track time-to-decision as a rough health metric for the whole system.

How Does The Intent Ledger Support This Workflow?

Hands placing a decision token in organizer box

Theintentledger builds this pattern directly into the tool instead of leaving it to discipline alone. It turns meeting notes, transcripts, and critique feedback into ILM Records: structured entries that carry status, sources, and links back to the original conversation. Records stay append-only by design, and superseded entries link forward automatically instead of getting overwritten. Commercial tools ingesting correspondence and meeting minutes into decision logs show this kind of automated capture is becoming standard practice in AEC workflows, not a novelty. For a studio trying to adopt this without adding overhead, that structure does most of the enforcement work a manual process would otherwise depend on someone remembering to do.

What Practitioners Get Wrong About Decision Records

Teams overbuild the template, then abandon it after two entries. Brevity is what makes people keep writing them. The real trade-off is speed versus detail. Manage it by capturing less per entry, more often, and linking to source material instead of re-explaining it. Pilot this on one project before rolling it out everywhere.

— Rajas

Try The Intent Ledger on Your Next Project Review

Theintentledger is the fastest way to turn a messy meeting into a clean decision log, without asking anyone on the team to write more than they already do. Instead of someone manually filling out a record of decision template after every critique, the software listens to the source material, pulls out the actual decisions, alternatives, and rationale discussed, and links each entry back to the transcript or notes it came from.

Theintentledger

A good way to see it work: pull your next client review or internal critique and let it generate the first ILM Record from that single conversation. You’ll have a source-linked, status-tracked entry before the meeting notes would normally even get typed up. Start with The Intent Ledger and pilot it on one project this month.

Sources