How to keep an architecture decision log that lasts
Decisions are made in meetings, emails and site visits, then lost. Five fields, one owner and a weekly sweep keep a decision log current.
·
5 min read
A client approves a cheaper tile during a site visit. Three months later, at the punch walk, nobody can say who agreed to it or when. A decision log is the record that answers that question in one search.
Decisions scattered across email, meetings and WhatsApp? Nori can notice them, propose log entries and draft the written confirmations for you to approve.
Why do project decisions get lost?
Decisions are rarely made where the record lives. A normal week on a project might include:
A client meeting that ends with "let's go with option B."
An email from the structural engineer that changes a beam depth.
A site visit where the contractor asks, you answer, and everyone nods.
A late WhatsApp message from the client asking to keep the skylight.
Each of these is a decision. None of them arrives labeled as one. The meeting may reach the minutes. The rest stays where it happened.
The cost is time. Procore's 2025 research estimates that 18% of project time is lost searching for data. A decision that was never written down is among the slowest things to find.
What does a decision log protect?
The value of each entry appears months later, usually when something is in question.
Liability. If a dispute turns on what the client approved, a dated entry with a source carries more weight than recollection.
Scope. Changes requested in passing are easy to absorb and hard to bill. A log makes additional services visible while there is still time to raise them.
Settled questions. Without a record, closed topics return. The same finish is debated again because nobody can point to when it was agreed.
Handoffs. When someone joins the team or a consultant changes, the log explains why the project looks the way it does.
None of this requires a sophisticated system. It requires a consistent one.
What should an architecture decision log include?
Five fields are enough. More than that and the log starts to feel like a form.
Date. When the decision was made, not when it was recorded.
Decision. One plain sentence. "Client approved kitchen layout option B."
Who decided. The person with authority, and anyone who confirmed it.
Source. Meeting, email, call, site visit or message, with a link or file name.
What it affects. Drawings, specifications, cost, schedule, consultants.
An optional sixth field, status, helps with decisions that still need confirmation: proposed, confirmed or superseded.
Best for: any project where more than two people make or relay decisions, which is most of them.
A simple decision log template
Use a spreadsheet, a shared document or a page in the project folder. The format matters less than having one place.
Date | Decision | Who decided | Source | Affects | Status |
|---|---|---|---|---|---|
2026-09-14 | Kitchen layout: option B | Client (Maria), confirmed by PM | OAC meeting, minutes item 4 | A-201, A-501, millwork budget | Confirmed |
2026-09-18 | Beam B3 depth increased to 18 in | Structural engineer | Email, Sep 18 | S-102, corridor ceiling height | Confirmed |
2026-09-22 | Skylight retained | Client | WhatsApp message, Sep 22 | Roof plan, cost estimate | Proposed, confirm in writing |
2026-09-25 | Tile substitution accepted | Client and PM | Site visit | Finish schedule | Supersedes Aug 30 entry |
The last row matters most. When a decision replaces an earlier one, record it. That single habit prevents most disagreements about what was agreed.
Keep entries short. If an entry needs more than one sentence, the detail belongs in the source, and the log should link to it.
How do you keep a decision log current?
A log fails when it depends on remembering at the end of a long day. A few habits keep it alive.
Log at the moment of transition. Right after a meeting ends or a call finishes. Two minutes then saves twenty later. After a site visit, add what was agreed on site before closing the laptop.
Point to the record. A date and a link are enough. The log does not need to repeat the email.
Sweep once a week. On a fixed day, spend ten minutes on sent email, meeting notes and project chats, and look for anything that reads like agreement. If your meetings already produce minutes with numbered action items, cite the item number in the source column.
Confirm the important ones in writing. Anything that touches scope, cost or schedule deserves a short message:
Hi Maria, confirming that on September 22 you asked to keep the skylight. We will update the roof plan and send a revised estimate by Friday. Please let me know if this differs from what you intended.
It takes a minute and turns a chat message into a record.
Name one owner per project. Anyone can add entries. One person reviews the log each week.
A log that captures most decisions, consistently, is worth keeping. The goal is a reliable answer to "what did we decide," not a transcript of the project.
Where should the log live?
Next to the project, not in personal notes. A shared spreadsheet in the project folder works, as does a page in a tool the team already opens every day. Avoid a new application for this alone. An extra login is often the reason a log stops being updated.
If you share the log with the client, share a read-only view. Clients tend to raise disagreements earlier when they can see what was recorded, and an early disagreement costs far less than one discovered during construction.
How Nori helps
I watch email and Slack (WhatsApp and text are coming) for messages that read like decisions: an approval, a substitution, a "let's go with option B."
I propose a log entry with the date, who decided, the source and what it affects, and flag entries that replace an earlier decision.
When a decision touches scope, cost or schedule, I draft the written confirmation. You review and approve it before anything is sent, and judgment stays with your team.
The log stays in one place, with a link back to where each decision was made.
Nori is in early access, by invitation, at heynori.ai.
