It’s a Tuesday in month nine, and the owner is standing in the lobby asking why the floor tile in the elevator alcove doesn’t match the renderings. The super remembers the answer. Sort of. There was a substitution back in the spring — the spec’d porcelain came back on a sixteen-week lead, the architect approved an equivalent, the budget moved a little, and everyone agreed in a meeting that, at the time, felt completely routine. But the super can’t find the email. The PM who ran that meeting rolled off in July. The approval is somewhere — maybe in a submittal, maybe in a text, maybe in a thread sixty messages deep. And now a decision that took twenty minutes to make is going to take three days to reconstruct, if it can be reconstructed at all.
Every construction project runs on thousands of decisions like that one. Most are small. A few are expensive. And almost all of them get made faster than they get recorded — which is the whole problem. The work moves on, the reasoning evaporates, and six months later someone is paying to relearn something the team already knew. A decision log is the cheap insurance against that. It isn’t a new app or a new meeting. It’s a single running record of the choices a project makes, why it made them, and where the proof lives.
What a decision log actually is
Strip away the jargon and a decision log is a list. Each row is one decision the project made that someone might later need to understand or defend — not every email, but the calls that change the work, the money, the schedule, or who’s responsible for something. The tile substitution. The decision to pour the slab a week early ahead of the rain. The call to accept the alternate window manufacturer. The agreement to eat the cost of a field fix rather than process a formal change order. It’s easy to confuse this with the logs sitting next to it: an RFI log tracks questions and answers, a submittal log tracks what got reviewed and stamped, a change order log tracks the formal, priced, signed contract modifications. A decision log is the connective tissue underneath all of them — the running narrative of judgment calls, including the many that never became a formal RFI or CO but still shaped the building. (For the one-line definition, see the glossary entry; this is the deep version.)
A decision log is the difference between your file cabinet and your memory. The cabinet holds the documents. The log holds the reasoning that connects them.
Why a project needs one
The reasons aren’t abstract. They show up as specific, recurring jobsite pain. Continuity, when the PM who made the call rolls off and takes the context with them. Disputes, when the owner or a sub claims a decision went a different way and the only counterargument is “I’m pretty sure we said.” Closeout, when the as-builts and the warranty binder need to reflect what was actually built, not what was originally drawn. And accountability — the plain ability to answer, months later, who decided this, when, and on what basis, without it turning into an interrogation. There’s a quieter reason too: a team that keeps a decision log makes better decisions, because writing down the why forces a sentence of real reasoning. “We took the alternate because the spec’d unit was a sixteen-week lead and we needed it on site by August” is a real decision. “We just went with the other one” is a decision waiting to be re-litigated.
What belongs in a single entry
Keep entries short — one or two sentences of substance beats a paragraph nobody will read. And resist the urge to log everything: a decision log that captures which sandwiches to order for the OAC meeting is a decision log nobody maintains. The bar is simple. Would a reasonable person, six months from now, need to know this choice was made and why? If yes, log it. If it’s housekeeping, let it go. Log the decisions someone will have to defend, not the ones nobody will remember.
How to keep one without the busywork
Here’s the honest catch, the reason most decision logs die: the discipline. Somebody has to remember to open the spreadsheet after every meeting and every consequential text, and on a busy job that somebody is also running three crews and chasing a long-lead order. A log that depends on a human reliably doing data entry at the end of a fourteen-hour day goes stale by month two and gets abandoned by month four. The way out is to stop treating the log as a separate document you fill in, and start building it from the project’s own record — the emails, texts, RFIs, and submittals the team is already producing. The decision didn’t happen in the spreadsheet. It happened in a thread, or a reply, or a photo with a caption. The raw material is already there. The work isn’t writing it down a second time; it’s finding it, connecting it, and being able to pull it back up with the source attached.
- 1
Capture in place
Let the decision live where it was made — the email, the text, the RFI response. Don’t rely on re-typing it into a separate file later.
- 2
Pin the five fields
For anything consequential, make sure the what, why, when, who, and source are all findable — even if that’s just a clear reply on the thread.
- 3
Connect it to the record
Tie the decision to the spec section, the CO, the budget line, or the drawing it touched, so it doesn’t float alone.
- 4
Retrieve with the citation
When someone asks months later, you want the answer and the proof in one move — not a three-day archaeology dig.
Where BRAD fits
This is the part a decision log has always been bad at — not the writing, the retrieval, six months out, under pressure. BRAD is built for exactly that. You forward it the documents and messages that run the job — the plans and specs, the RFIs and submittals, the change orders, the email and text between office and field — and it reads them and connects them into one searchable record. So when the owner asks about the elevator-alcove tile, you ask BRAD in plain language, over the same email or text you already use, and get back the answer with the source attached: the substitution, the date, the architect’s approval, the budget line it moved. Instead of a clerk transcribing decisions into a parallel spreadsheet that drifts out of date, the log is assembled from the real record — the thread where the decision actually happened — and the why and the source come along with it. You’re not maintaining a second system. You’re asking the first one what it already knows. The tile decision, after all, was a good one — sound substitution, approved, absorbed, on schedule. The only thing that went wrong was that nobody could find it nine months later.