The Intent Ledger
← All articles

Week One, Single Source of Truth for Design Teams with ILM Template

Week One, Single Source of Truth for Design Teams with ILM Template

A single source of truth for design is an authoritative, source-backed record of decisions and the reasoning behind them, captured as ILM Records and linked to their original conversations. The first practical step is simple: start writing an ILM Record, a decision-log entry in the spirit of ADR-lite, for every meaningful choice your team makes this week, starting today with tools like The Intent Ledger.

TL;DR:

  • Establishing a single source of truth for design decisions reduces repetitive debates and ensures new team members understand the rationale behind previous choices.
  • Proper documentation of decision rationale, organized into navigable ILM Records, prevents knowledge erosion and improves collaboration in complex projects.
  • The ideal decision record is concise yet complete, linking the decision to its source conversation, including alternatives considered, reasoning, and potential reversal conditions.
  • Capturing decisions during or immediately after meetings helps maintain accuracy, with a focus on significant, non-reversible, or approval-related choices for full records.
  • Using tools like The Intent Ledger automates linking meeting materials to ILM Records, streamlining decision documentation and maintaining record integrity without excessive manual effort.
Theintentledger
Preserve the Why Behind Design Decisions
The Intent Ledger turns conversations, feedback, and meeting notes into source-backed ILM Records that keep project thinking connected and clear.
Explore The Intent Ledger

Table of Contents

What a single source of truth for design looks like in practice

Forget a shared drive full of loose files. A working single source of truth is record-first: each entry captures a decision, the reasoning behind it, and a link back to the conversation, review, or client call where it was made. The Intent Ledger structures this as an ILM Record, a compact unit that ties a decision to its source material rather than letting it float free in a chat thread or someone’s memory.

This is a different problem than maintaining a design-system repository of components and tokens. That kind of technical system of record answers “what does this button look like everywhere.” A single source of truth for design decisions answers “why did we choose this layout, and what would make us change it back.”

Done well, the payoff is concrete: fewer meetings spent re-litigating settled questions, and handoffs where a new team member can read the reasoning instead of asking around for it.

Why preserving design rationale matters

The case for recording rationale is not just tidiness. Research on communicating design rationale found that failing to capture it causes erosion of project knowledge, which leads teams to repeat past mistakes and burn time reconstructing reasoning that already existed once.

Documenting rationale reduces wasted effort tracking down decisions that were already made once, according to the Design Science research.

But documentation alone is not a fix. A 2026 study on how teams make sense of past decisions found that the problem is rarely too little documentation. It is documentation, people, and artifacts that are not organized into something navigable, and that is not matched to the type of decision being recorded. A one-line note works for a minor tweak; a structural decision needs the full record.

Separate research on architecture and engineering coordination backs this up from another angle: collaboration and information flow are among the most common failure points in project performance, and clear decision records are one of the more reliable ways to keep coordination from breaking down.

Essential fields: ILM Record template

An ILM Record does not need to be long. It needs to be complete enough that someone with no memory of the meeting can understand what happened and why. The Intent Ledger’s own record-of-decision template and decision-log template both build from the same core fields:

  • Decision ID: a short reference so other records and tasks can point back to it.
  • Date and context: when it was made and what prompted it.
  • Decision summary: the choice itself, in one or two sentences.
  • Alternatives considered: what else was on the table and why it lost.
  • Reasoning: the actual argument, not just the conclusion.
  • Linked evidence: a link to the meeting transcript, critique notes, or client email it came from.
  • Consequences and tradeoffs: what this decision costs elsewhere in the project.
  • Reversal conditions: what would have to change for the team to revisit it.
  • Owner: who is accountable for the decision holding.
  • Linked artifacts and next actions: files, tasks, or approvals tied to it.

Not every decision earns the full form. Small, reversible choices can get a minimal ADR-lite entry: summary, reasoning, owner, done. Structural or client-facing decisions warrant the full record, reversal conditions included. The design documentation template on The Intent Ledger’s blog has downloadable versions of both.

Pro Tip: Write the reasoning field before the decision summary. It forces you to justify the choice instead of just recording it.

Capture workflows: turning conversations into records

The friction that kills most decision logs is timing: people mean to write the record later, and later never comes. Treat each design session, review, or client call as the natural unit of capture instead of trying to log every edit.

  1. Group related edits into one session record rather than filing a separate entry for every small change discussed in the same meeting.
  2. Write the record during or immediately after the review, while the reasoning and the owner are still fresh, following the session-based capture pattern that industry teams use to cut noise.
  3. Confirm the owner and acceptance criteria in the record itself so there is no ambiguity about who signs off.
  4. Reserve full records for approvals, invariant changes, and non-trivial tradeoffs, and leave truly minor choices out of the log entirely.

For legacy projects with no existing record, do not try to reconstruct everything at once. Start with the decisions still actively affecting current work, and use a template like the one in how to automate meeting notes for design teams to turn transcripts into entries faster.

Pro Tip: If a decision took more than ten minutes of debate, it belongs in the log. If it took ten seconds, it probably doesn’t.

Governance: keeping the record trustworthy

A record nobody maintains becomes noise within a few months. Governance is what keeps it usable:

  • Assign a decision owner for every entry, accountable for the choice holding until it is formally reversed.
  • Assign a record steward who checks new entries for completeness and flags stale ones.
  • Enforce a no-silent-change rule: nothing overrides a recorded decision without a new entry that references the original decision ID.
  • Define reversal conditions up front, as recommended in the Session Continuity Protocol, so a future change is a documented decision, not a quiet override.
  • Keep the operating summary short. A Project Memory Pack should stay a concise, versioned front page, not a long appended log everyone dreads opening.
  • Set a review cadence so outdated entries get archived instead of sitting alongside current ones.

Real-world examples and common pitfalls

A common pattern: a team revisits a layout decision three months in, nobody remembers why the original layout was rejected, and the rework repeats a mistake that was already solved once. A Project Memory Pack with even three or four ADR-lite entries would have prevented it.

The usual pitfalls are consistent across teams. Too much noise buries the decisions that matter. No named owner means nobody updates the record when things change. Disconnected artifacts, decisions stored separately from the files and tasks they affect, defeat the purpose. Oversized memory packs get skipped entirely because nobody wants to read forty pages before a meeting.

Recovery is straightforward: bootstrap a Project Memory Pack from the decisions still shaping current work, prioritize the ones with the biggest blast radius, add reversal conditions retroactively, and link each entry back to whatever transcript or notes still exist.

Pro Tip: Recovering a lost record is easier than it looks: three well-written entries beat thirty vague ones.

A lead’s first-week checklist for a single authoritative record

Start small. In week one, create a Project Memory Pack and write full ILM Records for three recent decisions your team still argues about. Assign a steward for each, and set a 30-day review to check whether the records actually got referenced during real work, not just written and forgotten.

That 30-day checkpoint matters more than the initial writing. A record nobody consults is decoration. A record someone pulls up mid-meeting to settle a dispute is the thing you were trying to build.

— Rajas

How The Intent Ledger helps

Writing ILM Records by hand works, but it is slower than it needs to be when the raw material, meeting notes, transcripts, critique feedback, client comments, already exists. The Intent Ledger turns that material into structured, source-backed ILM Records automatically, tracing each decision back to the conversation it came from instead of leaving that link to memory.

Theintentledger

For a team ready to try this on a live project, two pages are worth starting with:

  • The product page explains how ILM Records connect decisions, risks, and unresolved questions to their original source material.
  • The pricing page lists the options: monthly plans for ongoing use, plus one-off product packages for teams that want a fixed batch of records without a subscription.

Check the pricing page directly to pick the option that matches how many records your team expects to generate.

Sources

For the evidence behind rationale erosion, read the Design Science paper and the Aalto study. For handoff and continuity templates, see design continuity for project workflows and the NCC handover documentation guide.

FAQ

What counts as a decision worth recording?

Anything that took real debate, involves a tradeoff, or would be expensive to reverse belongs in the record. Minor, easily reversible choices can stay out of the log to keep it usable, following the typology of decision types suggested by researchers studying past-decision sense-making.

How is this different from a design-system repository?

A design-system repository stores components and tokens as a technical system of record. A single source of truth for design decisions is a record of choices and reasoning, not assets, and it links back to the conversations where those choices were made.

Who should own the decision record?

Assign a named decision owner for each entry and a separate record steward who checks entries for completeness. The Session Continuity Protocol recommends this split so accountability for the decision and upkeep of the record do not fall on the same overloaded person.

How often should the record be reviewed?

A 30-day cadence works well for most teams starting out, since it is frequent enough to catch stale entries before they pile up. Beyond that, review whenever a project hits a major milestone or a decision’s reversal conditions are triggered.

Can The Intent Ledger generate these records automatically?

The Intent Ledger turns meeting notes, transcripts, and client comments into structured ILM Records that trace back to their source conversation. Plans start at $29 per month on the pricing page, with one-off record packs also available for teams that prefer not to subscribe.

Week One, Single Source of Truth for Design Teams with ILM Template: The Intent Ledger Blog