A construction decision log your project builds for itself

Most decisions on a job are never recorded as decisions. The slab moves four inches, the storm line gets rerouted, the rough-in goes on hold. Each call lives somewhere: a super’s head, a buried email thread, the margin of a set somebody marked up and forgot. Then the person who made the call rolls off, the owner asks why the slab moved, and the rationale is nowhere. The decision happened. The record of it did not.

The reasoning is the part that evaporates first. A field decision carries a lot of context that nobody bothers to write down, because the people in the room already understood it. That is exactly the tacit knowledge that resists being put on paper: we know more than we can tell.^[1] Six months later the people are gone and only the act remains, stripped of the why. Brad’s job is to capture the call and the context together, from the record the project already produces, so the why does not leave with the person.

Every decision, with the four answers that matter

A decision is not worth much later unless you can recover what was decided, why, when, and who made the call. Brad pulls all four straight from the record. The architect approves a substitution in an RFI response. A change order reroutes the storm line. A Tuesday text tells the super to hold the rough-in. Brad reads each one, files it as a decision, and keeps the surrounding context attached, so the reasoning rides along with the call instead of being inferred from it later.

You do not fill out a form or tag a thread. The log assembles itself from the email, texts, RFIs, change orders, and marked-up sheets the office and the field already send. That matters, because the moment you ask people to log decisions by hand, they log the ones they remember and skip the ones made on the fly, which are usually the ones in dispute later. Turning one person’s working knowledge into a shared, explicit record is the hard part of every knowledge system, and a log that builds itself from the actual traffic does it without asking anyone to stop and write.^[2]

Every entry carries the document that recorded it

A decision log nobody trusts is just a list of claims. Brad answers with the source attached. Ask why the panel schedule moved on the second floor and you get the answer plus the RFI response and the marked-up sheet it came from: the actual record, at the revision in force, not a paraphrase of a memory. The citation sits next to the entry the way a spec section sits next to an RFI answer, so the person reading it is checking a sourced claim rather than taking someone’s word for it.

This is the difference between a story and a record. When a dispute lands, the rationale is not something somebody recounts across a conference table from memory. It is a document with a date and a name on it. The most common cause of construction disputes is a party failing to understand or comply with its contract obligations, and those fights are won or lost on the paper trail.^[3] A decision log with the source attached to every entry is the difference between a defensible timeline and a room full of people who think it was probably around April.

Ask it like you’d ask the super who was there

Plain questions, answered in seconds. “Who approved the window substitution on Rev C?” “When did we decide to defer the canopy?” “What changed on change order 14, and who signed off?” Brad reads across the whole project record, submittals, RFIs, change orders, and the email and texts between office and field, and answers with the entries and their sources. You are not scrolling a year of threads hoping the right one surfaces before your patience runs out.

It works over the email and text your team already uses, so there is no new dashboard to log into and no status meeting spent assembling the history by hand. That is time the schedule gets back. Field staff already lose hours every week hunting for project data, and a decision log that answers a plain question in seconds takes a bite out of that.^[4]

The why survives turnover and disputes

People roll off jobs. A super moves to the next project, a PM leaves the firm, and the reasoning behind a hundred small calls walks out the door. Because Brad builds the log from the project’s own record rather than anyone’s memory, the why stays put. New people get caught up by reading the decisions instead of reconstructing them from scratch, and a transmittal, an RFI, or a change order from eight months ago is one question away.

When an owner or an attorney asks how something came to be, the answer is already on file with the document behind it. No archaeology through old inboxes the week before a deposition. The record was assembled while the work happened, which is the only time it can be assembled cleanly, before anyone has a reason to remember it differently.

What Brad records, and what stays your call

Brad is document intelligence pointed at the construction record. It reads what your project produces and hands the decisions back with the source attached. What it is not: a legal determination, a guarantee that a call was correct, or a stand-in for the contract and the official record. It captures what the documents say and shows you where it came from. The judgment stays yours. Your project’s content stays yours, and each workspace is walled off from every other one. If you have specific requirements about how decision data gets handled or retained, ask us and we will walk you through exactly how it works.

You will not get people to stop and document every call as they make it. You can capture the call and its source from the record they already leave behind, so the reasoning is on file with a date and a name on it before anyone needs it. The project memory you meant to keep and never had time to write down ends up written down anyway, while the work happens.