The Intent Ledger
← All articles

Decisions Backed by Sources: Six Steps Design Teams Can Audit

Decisions Backed by Sources: Six Steps Design Teams Can Audit

A source-backed decision ties each recommendation, assumption and tradeoff to identifiable evidence so a reviewer can verify the logic and reproduce the outcome later. The payoff is auditability: when a client questions a design choice or a board revisits a call, you can show exactly where each claim came from and who signed off. Teams making high-stakes design, investment or policy choices need this most.

TL;DR:

  • Link every claim to its exact passage, author, date, and stable identifier; snapshot web pages at capture so later reviewers can verify unchanged evidence.
  • Label claims as facts, calculations, or assumptions when captured; add confidence notes and version assumptions separately so corrections never erase the original reasoning.
  • Keep geography, date ranges, data extracts, scenario assumptions, and client feedback beside each output, rather than in separate files that can drift out of sync.
  • Reserve full passage level traceability and sign off for decisions such as zoning submissions or multiyear contracts; routine, reversible choices need only a brief note.
  • Review open questions weekly on active projects and monthly during quiet periods, assigning each unresolved item an owner and review date to prevent backlog growth.
Theintentledger
Keep the Reason Behind Each Decision
The Intent Ledger turns design conversations, feedback, and client comments into source-backed records that help teams trace decisions and preserve project context.

Table of Contents

The questions a source-backed workflow must answer

Before you trust a decision record, it has to answer a short set of questions. Skip one and the record becomes an opinion dressed up as a fact.

  • Where did each number or claim originate, down to the document, passage and timestamp?
  • Is the value an extracted fact, a calculated figure, or an analyst’s assumption?
  • Who created, verified and approved the item, with role and timestamp attached?
  • What changed between versions, and why was the change made?
  • What remains unresolved, and who owns the next action?

Most documentation failures trace back to one of these going unanswered. A number appears in a report with no origin, or an assumption gets treated as a fact because nobody labeled it. A six-step framework for turning raw data into decisions built for public-service teams makes the same point from a different angle: alignment between the question, the data and the eventual action has to be explicit at every step, not assumed. When a workflow can answer all five questions on demand, it stops being a narrative and starts being a record you can defend.

The source layer and passage-level traceability

Passage-level traceability means a claim links to the exact quote, source identifier and locator it came from, not just a document title in a footer. “Budget increased due to material costs” should link to the specific line in the meeting transcript or vendor email where that was said, not to the folder it sits in.

Each linked passage needs metadata: author, date, document type and a dataset or record identifier if the claim came from structured data. That metadata is what lets someone six months later confirm the source still says what the record claims it says.

Provenance differs from a simple action log. A log tells you a decision was made on a given date. Provenance tells you why: which passages were weighed, who read them, and what reasoning connected them to the outcome. The Decision Provenance Standard treats this passage-level link as the baseline requirement for any decision that might face later scrutiny.

For stable references, use permanent identifiers where they exist (DOIs for publications, version-locked snapshots for web pages and internal document IDs that do not change when a file gets renamed).

Pro Tip: Snapshot a source the moment you cite it. Web pages and shared drives change, and a broken link six months later defeats the entire point of traceability.

Separating facts from assumptions in your records

A reviewer who cannot tell a measured fact from an analyst’s best guess will treat both with equal confidence, which is how bad assumptions survive three design revisions unchallenged. Clear labeling fixes this at the point of capture rather than during a post-mortem.

  • Tag every claim as “fact,” “calculated” or “assumption” at the moment it enters the record.
  • Record a confidence note next to assumptions: why this estimate, and what would change it.
  • Version assumptions separately so a later correction does not silently overwrite the original reasoning.
  • Give reviewers a standing prompt to challenge assumptions: “what evidence would prove this wrong?”

Evidence-to-decision frameworks used in public health, including WHO-INTEGRATE and GRADE’s evidence-to-decision approach, formalize this by requiring explicit criteria beyond evidence quality alone, feasibility, acceptability and equity among them. The same discipline applies to design and business decisions: a tagged assumption inside a report is something a reader can question, while an untagged one is something they will mistake for established fact.

Keeping context attached to every output

A model or recommendation that gets separated from its original context becomes dangerous the moment someone reuses it for a different scenario. The fix is to make certain fields travel with the output by default, not as an afterthought.

  • Geography and market scope the analysis applies to.
  • The date range and data extracts actually used.
  • Scenario assumptions baked into the model (interest rates, material costs, timeline).
  • Links to the comment threads or client feedback that shaped the final call.

A budget model built for a renovation in one market, stripped of its scope and reused for a different project, will mislead anyone who inherits it without that context. Pairing a market snapshot with its underlying comment thread, rather than storing them separately, is what prevents this. Store context alongside the output in the same record rather than in a separate wiki page that drifts out of sync, and retrieval later becomes a matter of opening one file instead of reconstructing a trail from memory.

Six steps to make any decision source-backed

Turning this into a repeatable practice means walking the same sequence every time, whether the decision takes an afternoon or a month.

  1. Define the question and the decision output. Name the owner, the deadline and what a finished answer looks like.
  2. Map the evidence you need and assign owners. Decide who gathers client transcripts, who pulls market data, who checks code or cost estimates.
  3. Capture passage-level sources and tag each claim. Attach author, date and locator to every quote or figure as it comes in, not after the fact.
  4. Appraise the evidence with a simple trust and relevance rubric. Weight a verified client statement differently than a secondhand summary of one.
  5. Aggregate the evidence and state tradeoffs explicitly, each tradeoff linked to the citation behind it.
  6. Sign off, seal the decision and log an immutable audit entry recording who approved it and when.

This mirrors the ask, acquire, appraise, aggregate sequence described in OpenStax’s evidence-based decision-making framework, where structured workshops can produce a reasoned proposal in a few hours for routine calls or stretch across several days for anything with real stakes.

Pro Tip: Match the timeline to the stakes: a one-day workshop suits a routine material swap, but a zoning decision or multi-year contract deserves a multi-week review with documented sign-off at each stage.

How The Intent Ledger operationalizes source-backed decisions

We built ILM Records to carry this entire workflow in one place. Each record captures a design decision, the risk or action tied to it, and the original conversation it came from, so the rationale never gets separated from the outcome.

  • Capture and tagging happen as transcripts, critique notes and client comments get turned into structured records.
  • Appraisal and aggregation live in the same record, with facts and assumptions kept distinct.
  • Sign-off and audit trail are built in: every ILM Record preserves who decided, why, and when.

Teams that adopted traceable feedback practices similar to this cut rework significantly within 90 days by catching misunderstood decisions before they compounded. Our Decision Audit Trail template and decision log template give teams a starting structure for the same six fields.

Common challenges and solutions when building source-backed records

The most common failure is capture fatigue: tagging every claim with a source feels productive for the first week and gets abandoned by the third. The fix is narrowing scope. Not every conversation needs a full record, only the ones tied to a decision, a risk or a commitment. Teams that try to log everything burn out; teams that log decisions survive.

A second challenge is inconsistent labeling across team members. One person’s “fact” is another’s “assumption,” and without a shared standard the record becomes unreliable. A short, written rubric, even three lines, on what counts as verified versus estimated solves most of this.

A third is link rot: sources move, get deleted or get renamed, and a record that pointed to a live document six months ago now points to nothing. Snapshotting sources at the time of capture, rather than linking to a location that can change, avoids this.

Finally, teams struggle with ownership drift: a decision gets logged, but nobody remembers who is supposed to revisit an unresolved question. Assigning an explicit owner and a review date to every open item, not just to closed decisions, keeps the backlog from silently expanding. An independent evidence review can help when a team needs outside validation on a contested assumption rather than relying solely on internal appraisal.

Best practices for maintaining project memory over time

A project memory is only useful if it stays current, and the habits that keep it current are small and recurring rather than one big cleanup effort.

Review open questions on a fixed cadence, weekly for active projects, monthly for ones in a quiet phase, so unresolved items do not silently age out of relevance. Revisit assumptions whenever a major input changes (a budget revision, a new client requirement, a code update) and version the change rather than overwriting the original note.

Archive closed decisions instead of deleting them. A rejected design direction from early in a project often becomes relevant again when a client revisits an old idea, and the record of why it was rejected saves a repeated debate. Keep the audit trail intact even after a decision is superseded: a new decision should reference the old one, not erase it.

Assign a single owner for the memory itself, not just for individual decisions, so there is accountability for keeping the system usable rather than letting it become a dumping ground nobody trusts. Teams using structured, traceable meeting notes have reported documentation time cut by 46% once the system became routine rather than a separate chore layered onto regular work.

When full provenance is worth it and when it is not

Not every decision needs a six-field audit trail. Match rigor to stakes: a material swap with low reversal cost needs a quick note, while a zoning submission or multi-year contract needs full passage-level traceability and sign-off. Ask one question before you log anything: what happens if this gets challenged in a year?

, Rajas

Put source-backed decisions into practice with The Intent Ledger

We built The Intent Ledger so design teams never have to choose between moving fast and keeping a defensible record. Every conversation, critique note and client comment turns into an ILM Record that preserves the rationale behind a decision, not just the outcome.

Theintentledger

  • Capture: transcripts and comments become structured records automatically.
  • Tag and appraise: facts and assumptions stay labeled and distinct inside each record.
  • Sign off and audit: every record keeps who decided, why and when, ready for review.

Our Working Set and Project Record product lines suit teams starting out, and our Working Memory plan at $29 per month gives ongoing teams continuous record creation. Check pricing and plans or visit The Intent Ledger to see how a project memory fits your next decision.

FAQ

What is another way to say data-driven decision making?

Common alternatives include evidence-based decision making, source-backed decisions and analytical decision strategies. Each term emphasizes the same core idea: conclusions are tied to verifiable data or documented evidence rather than intuition alone.

What are the main steps in a decision-making process?

A widely used structure moves through defining the question, acquiring evidence, appraising its trustworthiness and relevance, and aggregating it into a decision, as described in OpenStax’s evidence-based decision framework. Many teams add a final sign-off and audit step to make the decision traceable after the fact.

What is data-backed decision-making?

Data-backed decision-making means grounding a choice in measurable information rather than opinion, with each figure traceable to its source. It typically includes cleaning and aligning data to the specific question before drawing a conclusion, a process outlined in CSPS’s six-step data decision framework.

What is an example of a data-driven decision?

A design team adjusting a material specification after transcript evidence shows a client repeatedly flagged budget concerns is a data-driven decision. The choice ties directly to a documented, traceable source rather than a general impression of client preference.

How detailed should a decision record be?

The level of detail should match the stakes: a routine choice needs a brief note with an owner and date, while a high-stakes decision needs passage-level sources, tagged assumptions and a sealed audit entry. The Decision Provenance Standard treats this level of traceability as the baseline for decisions likely to face later scrutiny.

Sources

Decisions Backed by Sources: Six Steps Design Teams Can Audit: The Intent Ledger Blog