Construction document control that knows which version is current

The expensive errors are not the ones where someone read the document wrong. They are the ones where someone read the wrong document. A revision updated a detail two weeks ago, the old sheet is still sitting in the folder, and the two look identical side by side. The crew builds to the stale one. Nobody was careless. Document control failed quietly, which is the only way it ever fails.

On an active project the documents never stop moving. Revisions, addenda, change orders, ASIs, RFI responses that update a detail in passing. Every one of those is a fresh chance to act on a superseded version. The usual defense is naming conventions and discipline, and that holds right up until a genuinely busy week, when the person who knew which sheet was current is on another job and the folder has six things that all look authoritative. The structural fix is to connect the versions so the system knows which one governs and you do not have to remember.

Put a number on it and the case makes itself. Bad data cost global construction an estimated $1.85 trillion in 2020, and the single largest slice of that was rework done off the wrong information.^[1] The interoperability problem is older than that: a NIST study put the annual cost of fragmented, non-interoperable facility data at $15.8 billion, with roughly two thirds of it landing on owners.^[2] A stale detail that gets built is not a clerical slip. It is a cost code that overruns and a conversation nobody wants to have.

Brad connects the revisions so it knows which one governs

Brad reads your project’s documents and connects them, the superseding changes included. A revision and the sheet it replaces. A change order that revises a detail. A clarification that overrides a spec note. An addendum that updates a sheet during bidding. Rather than treating each file as a standalone object in a folder, Brad ties them into the relationships that actually determine which one is current.

When you ask for a detail or a spec section, Brad favors the current controlling version and surfaces it first. When two documents in the set disagree, it does not pick a winner and move on. It flags the conflict and shows you both, because reconciling a discrepancy between the drawings and the spec is a person’s call, not an algorithm’s. The contract defines how those documents relate and which one governs, and Brad works inside that structure instead of inventing its own.^[3]

Control that spans the whole set, not one document type

Version drift is rarely contained inside one stack of drawings. A change order revises a detail. A clarification overrides a spec note. An RFI response updates a dimension. The trouble is that the change lives in one document and the thing it changed lives in another, so the set ends up true in three places and stale in a fourth. Whoever pulls the fourth one builds the old condition.

Because Brad’s connection spans the project, control is not trapped by document type. A change order that supersedes a detail is linked to that detail. A spec note overridden by a clarification is linked to the clarification. The current state stays consistent across plans, specs, contracts, and change orders, so the answer you get is the same one no matter which document you started from. That coherence is exactly what bad, disconnected data costs the industry, and most of that cost is rework done off a version that was already wrong.^[4]

What it prevents, and what it protects

The prevention list is short and specific. Building to a stale detail. Ordering material against a superseded spec section. Carrying a conflict between two documents nobody ever reconciled. Catching any of those before the field acts on it is the entire reason document control earns its keep. Caught after, the same conflict is a rework line, a schedule hit, and an awkward standup.

The other half of the value shows up months later, at closeout or in a claim, when memory has gone soft and the paper is all you have. Someone asks which revision governed at a given point in time, or whether a detail was changed before or after the slab poured. With the revision history connected, that answer is already assembled instead of getting reconstructed from old inboxes under deadline. That matters more than it sounds, because the most common cause of construction disputes is a party failing to understand or comply with its contract obligations, and the contract is made of documents whose current state someone has to be able to prove.^[5]

Where Brad stops and your protocol starts

Brad surfaces and connects document versions from what you bring it. It is an intelligence layer over your documents, not a contractual document-control protocol, not a system of record, and not the authority that decides which version governs when two genuinely conflict. It makes the protocol you already have far easier to follow, and it makes the current version far faster to find, but a person still owns the call. Your project’s content stays yours, and each workspace is walled off from every other one. If you have specific requirements about how document revisions are retained or handled, ask us and we will walk you through exactly how it works.

You will not stop documents from changing. You can change whether the next person to open a sheet gets the version that governs or the one a revision quietly retired two weeks ago. Document control is one question asked a few hundred times a week. Brad is how the answer stops depending on whoever happened to be paying attention.