The Intent Ledger
← All articles

Link Drawings to Decisions With 10 Fields Mapped to ISO 19650

Link Drawings to Decisions With 10 Fields Mapped to ISO 19650

Link every decision to the exact drawing revision and the source conversation, then store that pair in an ILM Record with a minimal schema: decision ID, drawing revision, rationale, owner, and status. That one habit closes the gap between what a drawing shows and why it shows it. Below, we cover the schema, a four-step workflow, standards alignment, and a checklist you can paste into your next milestone review.

TL;DR:

  • Open the decision record before the meeting ends; waiting until a stage gate forces teams to reconstruct rationale from memory.
  • The full record has ten fields, adding rejected alternatives, constraints, acceptance criteria, status, and open actions to the core identifiers and rationale.
  • Keep stable revision identifiers in drawing metadata, approval status in the CDE, and changing actions in a linked decision database.
  • ISO 19650 separates decision points from information delivery milestones, while the RIBA Plan of Work expects stage end information to record its basis.
  • Do not publish a drawing without a decision ID or close a record as agreed without a drawing reference; review links at every milestone.
Theintentledger
theintentledger.com
Keep Drawing Decisions Connected
The Intent Ledger turns project conversations into source-backed records, helping design teams trace drawing decisions to their rationale and context.
Explore project memory

Table of Contents

Minimal ILM Record schema to copy into your project playbook

A drawing on its own tells you what was decided, not why. An ILM Record fills that gap with ten fields you can paste into a template, a decision log, or your building execution plan (BEP) today.

  • Decision ID: a unique code so the record can be referenced from drawings, emails, or meeting minutes.
  • Title and date: a short label and the date the decision was made, not the date it was written up.
  • Source conversation link: a pointer to the meeting note, transcript, or critique session where the decision happened.
  • Drawing revision reference: the sheet number and revision code the decision applies to, not just the drawing’s file name.
  • Rationale: two or three sentences on why this option won, written for someone joining the project in a year.
  • Alternatives considered: a short list of what was rejected and why, so the reasoning survives even if the team changes.
  • Constraints: budget, code, site, or client limits that shaped the decision.
  • Responsible owner: the person accountable for the decision standing.
  • Acceptance criteria and status: what “done” looks like, and whether the record is draft, agreed, or superseded.
  • Follow-up actions: anything still open before the decision can be closed out.

Where each field lives matters as much as what it says. Fast-changing fields like status and follow-up actions sit well in a linked ILM database, where they can be updated without touching the drawing file. Stable identifiers like the drawing revision code belong in drawing metadata itself, and container-level fields like approval stage fit naturally in your information container (CDE). A workable example: Decision ID DR-114, “Relocate service riser,” dated March 3, 2026, sourced from a design team call, referencing Sheet A-203 Rev C, rationale noting clearance conflict with structural beam, alternatives listing two riser positions rejected on cost, owner listed as the project architect, status “agreed.”

Step-by-step workflow: capture, attach, verify, publish

A link only holds if it is created at the moment the decision happens, not reconstructed later from memory. This sequence works whether you are running a five-person studio or a multi-consultant team.

  1. Capture the conversation immediately: jot a note, snap a photo of a markup, or save a short transcript, and open a decision record before the meeting ends.
  2. Identify the exact drawing revision: record the sheet number and revision code, then add a hyperlink or file pointer so the record resolves to that specific version, not “the latest one.”
  3. Set acceptance criteria, owner, and milestone: agree on what approval looks like and who holds it before anyone touches the drawing file again.
  4. Tag the drawing or CDE container with the decision ID: set the drawing status to match the record (draft or published) and keep revision history intact so the link survives future edits.
  5. Surface the record in review and sign-off: bring it into change control, and update it the moment the drawing changes rather than leaving the old rationale attached to a superseded sheet.

Skipping step one is the most common failure. Teams that wait until a stage gate to document decisions end up reconstructing rationale from memory, which is exactly the gap a source-backed record is meant to close.

How this practice maps to ISO 19650 and the RIBA Plan of Work

This workflow is not an invented process bolted onto standard practice. The RIBA Plan of Work 2020 organizes projects into eight stages and expects information delivered at the end of a stage to record the basis on which it was determined, which is another way of saying a drawing needs its rationale attached before it becomes the reference point for the next stage.

ISO 19650 guidance pushes this further by recommending that information requirements be purpose-driven: defined around the decision a drawing needs to support, with a responsible reviewer and acceptance criteria set before production starts. The guidance also draws a useful distinction between key decision points, the moments a choice actually gets made, and information-delivery milestones, the points at which that information must be formally available. Your ILM Record should link to both: the conversation where the decision happened, and the project milestone that required the drawing to reflect it.

Adding this to a BEP is straightforward: name the minimal schema as your information production method, and state where metadata for each field will live.

There are three common places to store a drawing-to-decision link, and each has a tradeoff.

  • Drawing file metadata: fast to check and travels with the file, but hard to search across a whole project.
  • CDE information containers: good for approval status and version control, but the rationale itself often gets lost in container-level fields.
  • A linked ILM database: searchable across every drawing and decision, and the pattern we built our own product around.

In practice, a record looks like this: create an ILM Record from a design review transcript, attach the Sheet A-203 Rev C reference, and keep a small snapshot of the markup as evidence of what was actually discussed. That pairing gives a living project memory: anyone who joins the project later can trace a drawing straight back to the conversation that shaped it, which shortens onboarding and cuts the rework that comes from reinterpreting an undocumented change. We cover copyable versions of this schema in decision-log templates and in posts on design intent drawings on our blog.

Copyable implementation checklist for your next milestone

Paste this into a BEP, your meeting minutes template, or a task board, and assign an owner to each line.

  1. Adopt the schema: confirm all ten fields across the team, owner: project lead.
  2. Set naming and revision rules: agree on sheet and revision codes before drawings start moving, owner: documentation lead.
  3. Train the team: a short walkthrough of one real ILM Record beats a written policy, owner: studio lead.
  4. Capture at the event: write the record during or immediately after the conversation, owner: whoever is in the room.
  5. Tag drawing metadata: add the decision ID to the file or CDE container, owner: drawing custodian.
  6. Review at milestone: check every published drawing has a linked, current record, owner: project manager.
  7. Archive with links intact: close out the project with records still pointing to their drawings, owner: project lead.

Two rules stop most unlinked drawings before they happen: no drawing moves to “published” without a decision ID attached, and no decision record closes as “agreed” without a drawing reference.

Pro Tip: A quick spreadsheet filter that lists drawings with a blank decision-ID column catches most gaps before a milestone review, no special tooling required.

Rajas’s perspective: a short practitioner note

The failure I see most often isn’t a missing drawing, it’s a missing reason. Teams redo work not because the drawing was wrong, but because nobody could say why a dimension or a material changed, and the safest move became redoing it from scratch. On one small renovation project, a single linked record settled a riser-location dispute in minutes instead of a re-survey. Try the schema on one milestone before you roll it out further.

, Rajas

Try The Intent Ledger to turn conversations into linked ILM Records

Theintentledger

We built project memory software that turns meeting notes, transcripts, and critique feedback into structured ILM Records, each one traceable back to the conversation it came from and linkable to the exact drawing revision it affects. That pairing means less lost context when a team member rotates off a project, and a clear, source-backed rationale ready at sign-off instead of a scramble to reconstruct one. If your team is ready to evaluate the workflow on a live project, start with our pricing page or explore the product landing page to see how ILM Records work across a full project timeline.

FAQ

An ILM Record is a structured, source-backed entry that captures a decision, its rationale, and the conversation it came from. Linking it to a specific drawing revision means anyone reviewing the drawing later can see exactly why it looks the way it does, not just what it shows.

Capture it at the conversation itself, since ISO 19650 guidance favors regular, event-based information sharing over waiting for stage gates. Waiting until a milestone review often means rebuilding rationale from memory, which introduces gaps.

Where should decision metadata actually live?

Stable fields like the drawing revision code sit well in drawing metadata, while status and approval fields fit better in your information container or CDE. A fast-changing field like follow-up actions is easiest to manage in a linked database such as an ILM Record system.

How does this align with the RIBA Plan of Work?

The RIBA Plan of Work 2020 expects stage-end information to record the basis on which it was determined, which is exactly what a linked decision record provides. Treating a drawing as evidence of a decision, rather than the decision itself, keeps that basis intact as the project moves between stages.

Update the ILM Record the moment the drawing changes rather than letting the old rationale stay attached to a superseded sheet. A 2023 traceability study found decisions are often left inadequately updated, so a consistent schema checked at each milestone is a practical safeguard.

Sources

Link Drawings to Decisions With 10 Fields Mapped to ISO 19650: The Intent Ledger Blog