The Intent Ledger
← All articles

Design Teams: Six Field Decision Audit Trail for Critique Driven Work

Design Teams: Six Field Decision Audit Trail for Critique Driven Work

A decision audit trail is a short, source-backed project record that captures what was decided, why, and where the evidence lives. Design teams use it to preserve rationale, surface risks before they compound, and bring new people up to speed fast. The practice borrows heavily from architectural decision records, adapted here for critique-driven design work, and platforms like The Intent Ledger now automate much of the capture.

TL;DR:

  • Only create decision records for choices involving multiple viable options, downstream impact, or if reversing them would be slow and costly.
  • Use a simple six-field template—Decision, Alternatives, Constraints, Reasoning, Owner, Outcome—to keep records honest and easy to maintain.
  • Capture decisions promptly during meetings or critiques, linking to source artifacts and updating the outcome to ensure the record stays accurate over time.
  • Preserve superseded decisions by marking and linking them, rather than deleting, to maintain a clear history and avoid reintroducing rejected options.
  • Automating the linking of conversation transcripts to decisions helps surface risks early and keeps rationale connected to evidence.
Theintentledger
Keep Critique Decisions Connected
The Intent Ledger turns critique conversations, feedback, and client comments into source-backed records of design intent, risks, and actions.
Explore The Intent Ledger

Table of Contents

What a decision record needs to contain

A usable record fits on one screen and answers the questions a future reader will actually ask. The AWS prescriptive guidance on architectural decision records recommends capturing the decision, its context, the constraints that mattered, the alternatives considered, the rationale, and the consequences accepted, with lighter notes for routine choices and fuller write-ups for anything costly to reverse.

  • Decision statement: one sentence naming what was chosen.
  • Context or problem: what triggered the need for a decision.
  • Constraints and requirements: budget, timeline, code, or client limits that shaped the options.
  • Alternatives considered: the paths not taken and why they lost.
  • Rationale: the reasoning that tipped the choice.
  • Consequences or risks: tradeoffs the team accepted knowingly.
  • Owner and status: who is accountable and whether the decision is active.
  • Artifact links: the drawing, model, PR, or transcript the decision touched.

Each field earns its place by answering a specific future question: who do I ask, what did we rule out, and what proof backs this. A record missing artifact links is a claim with no evidence behind it.

When should a decision get its own record

Not every choice deserves a written record, and treating all of them equally is how logs become noise nobody reads. AWS’s guidance points to a useful filter: create a record when a choice has genuine alternatives, affects downstream work, or would be expensive to reverse, and use lightweight notes for everything else, as described in AWS’s ADR process.

Write a record when:

  • Multiple viable alternatives exist and someone will ask later why one won.
  • The choice has downstream impact on other decisions, disciplines, or budgets.
  • Reversing it later would be slow, expensive, or politically difficult.
  • It comes out of a design review or client approval that sets direction.
  • A pull request introduces a structural or architectural change.

Routine choices, like a minor color adjustment or a naming convention, get a one-line note at most. The timing matters as much as the content: capture the decision in the moment, or attach it directly to the PR or critique outcome that produced it, rather than reconstructing it from memory a week later.

Pro Tip: If you can’t explain the decision in one sentence right after the meeting, it probably needed more discussion before it was made, not more documentation after.

A compact template to start using today

Most design teams do not need the full architectural decision record format on day one. A practitioner essay on design decision logs proposes a six-field short log that is deliberately low-friction: Decision, Alternatives, Constraints, Reasoning, Owner, Outcome, each dated and linked to its source. The same source notes that writing entries at the time of the decision, and requiring a later outcome update, keeps the log honest rather than retrospective.

  1. Decision: what was chosen, in one line.
  2. Alternatives: what else was on the table.
  3. Constraints: what limited the options.
  4. Reasoning: why this option won.
  5. Owner: who is accountable for the outcome.
  6. Outcome: what actually happened, added later.

For decisions with wider architectural weight, an expanded ADR-style record adds Context, Consequences, Status, Review conditions, and References, following the structure Google Cloud and AWS both describe for architecture decision records. Store these near the work they describe: a folder like docs/decisions/001-facade-material.md alongside drawings or code keeps the record where people will actually find it, rather than buried in a wiki nobody opens.

One consistent structure across a project matters more than which fields you pick, because a mixed format is what makes a decision log unsearchable within a year. Teams that want a ready-made version of this can start from a decision log template rather than building one from scratch.

Capturing decisions before, during, and after they happen

A record is only as good as the moment it was written. The workflow splits into three stages, and skipping any one of them is usually where audit trails fall apart.

  • Before: share the scope and any relevant artifacts in advance, and pre-fill known constraints or shortlisted options so the discussion starts from something concrete.
  • During: keep a visible recorder taking notes in the room, tag the source explicitly, whether it is a meeting, a transcript, or a Slack thread, and note the emerging owner and any actions as they surface.
  • After: publish the record promptly, link it to the drawings, models, PRs, or transcripts it touched, and set a review date with a named owner for follow-up.

This before-during-after structure mirrors what the Nielsen Norman Group recommends for design critiques: share scope ahead of time, take visible notes during the session, and distribute notes and action items afterward. Where you store the record involves real tradeoffs. A code repository keeps decisions close to the artifacts they govern but is invisible to non-technical stakeholders. A wiki is more accessible but drifts out of sync with the work. A dedicated project memory tool sits between the two, linking conversations directly to the decisions they produced. Teams looking to reduce manual capture can look at automating meeting notes so transcripts feed records without extra typing.

Keeping the record honest as decisions change

Decisions get revisited, and a good audit trail shows that evolution instead of erasing it. Google Cloud’s guidance on architecture decision records recommends preserving earlier records when a decision changes and marking the old one as superseded rather than deleting it.

  • Use consistent status values: proposed, accepted, superseded, rejected.
  • Timestamp every status change, not just the original entry.
  • Link a superseded record to the one that replaces it, forming a visible chain.
  • Set a review cadence, quarterly for active projects is common, to catch decisions that have quietly gone stale.

The ontology of architectural design decisions developed by Kruchten treats a decision as a first-class object with its own state, scope, and relationships to other decisions, which is what makes a supersession chain legible rather than a pile of contradictory notes. Preserving the old record, instead of quietly editing it, also protects against someone reverting to a rejected option without realizing it was already tried and ruled out.

Pro Tip: Never delete a superseded record. Mark it, link it, and move on. The rejected path is often exactly what the next person needs to see.

Making the audit trail part of daily work

A decision record that lives outside the team’s normal workflow gets ignored. It has to show up where people are already looking.

  • Run critiques with a shared scope beforehand and a visible recorder during, then distribute notes and follow-ups immediately after, per NN/g’s critique guidance.
  • Attach or link the relevant record directly in pull requests and design handoffs so reviewers see the rationale without asking for it.
  • During onboarding, have new hires skim record headlines and statuses before their first working session, and include the full set in project handover packages.
  • Van Heesch, Avgeriou, and Hilliard’s documentation framework for architecture decisions found that decision views helped identify risks during architecture reviews, though the effort to build them should scale with project size rather than apply uniformly.

Turning decisions into traceable, assignable work is easier with a defined process, and a working system for tracking action items can close that loop between decision and follow-through.

Why decision records fail in practice

Most decision logs die from one of three causes: they get too heavy to maintain, they get written after the fact as justification rather than reasoning, or they go stale because nobody owns the follow-up. The fix is not a better template, it is a smaller one, enforced consistently. Start with the six-field version, require an owner on every entry, and treat the outcome field as mandatory, not optional.

Teams that skip the outcome field are the ones whose logs turn into retrospective spin, records written to make a past decision look inevitable rather than to explain what was actually known at the time. A short, timestamped entry written in the room beats a polished paragraph written a month later, every time.

— Rajas

Turning project conversations into structured records

Writing decision records by hand works until the project gets busy, and that is usually when the records matter most. The Intent Ledger turns meeting notes, transcripts, critique feedback, and client comments into ILM Records, structured entries that trace a decision back to the exact conversation it came from.

Theintentledger

  • Records link automatically to their source conversation, so rationale never gets separated from the evidence behind it.
  • Status and supersession tracking follow the same lifecycle logic used in architectural decision records, without manual upkeep.
  • Risks and unresolved questions surface earlier because they are captured alongside the decision, not reconstructed later.

The Intent Ledger offers various product lines and subscription plans, with pricing details available on its pricing page. For a closer look at what a well-structured record includes, see the Record of Decision breakdown or visit The Intent Ledger to see the platform directly.

Where to go deeper on decision records

For document control practices in fields where decisions carry safety weight, see this construction document control guide. Engineering teams linking design choices to cost can review this DFM review process. Teams wanting centralized dashboards for project data can look at Operiva’s project dashboards.

Sources

FAQ

What is the difference between a decision log and a decision audit trail?

A decision log is typically a running list of entries, while a decision audit trail emphasizes the traceable link between each decision and its source evidence, such as a transcript or meeting note. In practice, a well-built decision log that links to its sources functions as the audit trail.

How detailed should a design decision record be?

Most records should fit on one screen: a decision statement, the alternatives considered, constraints, reasoning, an owner, and an outcome. Fuller records with context, consequences, and review conditions are reserved for decisions that are costly to reverse, following the tiered approach in AWS’s ADR guidance.

Where should decision records be stored?

Storage should sit as close to the related work as possible, whether that is a folder near source files, a shared wiki, or a project memory tool that links directly to the originating conversation. Google Cloud’s architecture decision records guidance recommends keeping records accessible to the whole team and preserving history rather than overwriting it.

How often should decision records be reviewed?

A quarterly review cadence works for most active projects, checking for decisions whose status has quietly gone stale or whose constraints have changed. Superseded decisions should stay in the record, marked clearly, rather than being deleted.

Can The Intent Ledger create these records automatically?

The Intent Ledger converts meeting notes, transcripts, and critique feedback into ILM Records that trace decisions back to their source conversations. Plans start with one-off product lines like Working Set at $12, with subscription options detailed on its pricing page.