A construction project knowledge base that builds itself and answers back

Most construction “knowledge bases” are a wiki that one person has to keep current. They go stale by week three and nobody trusts them by week four. The premise is wrong. A construction project already owns its knowledge. The answer to almost any question is sitting in a submittal log, a spec section, a change order, or a text thread from a Tuesday in March. The problem was never that the knowledge did not exist. It is that nobody could lay hands on it in the one minute that counted, and asking the one veteran super who remembers was faster than digging.

That gap has a price, and the industry has measured it. Knowledge workers spend close to a fifth of the week just searching for and gathering information,^[1] and construction runs worse than the average office: field and office staff lose roughly fourteen hours a week to non-optimal work, with about five and a half of those hours spent simply looking for project data.^[2] A knowledge base worth having does not ask tired people to re-type what the job already produced. It gathers what is already there.

The knowledge already exists, it is just scattered

Walk a job and the record is everywhere and nowhere. The contract and its general conditions live in one binder. The submittal log lives in a different system. Cost codes and the schedule of values live in accounting. Field conditions live in a superintendent’s phone, in a few thousand photos nobody has labeled. The decision that mattered most last month lives in a group text between four people, two of whom have since rolled off.

Some of that knowledge resists writing down at all. A foreman knows why a wall got framed the way it did, and could not put it in a memo if you asked. That is tacit knowledge, the kind we hold but cannot fully tell,^[3] and a wiki is exactly the tool that fails to capture it. But a surprising amount of what feels tacit is actually written down somewhere already. The detail revision is in the drawing set. The substitution is in an approved submittal. The price was in an invoice. It was never missing. It was just not connected to the question being asked.

A knowledge base that builds itself

Brad reads what the job already produces: the plans, specs, contracts, change orders, invoices, field photos, lien waivers, COIs, daily logs, and the message threads where half the real decisions actually happen. It turns that stream into a searchable record without a template to fill in and without anyone filing anything. The knowledge base stays current because it is assembled from the documents themselves, which keep arriving whether or not anyone has time to organize them.

This is the move a wiki cannot make. A wiki asks a person to translate what they know into an article, then to remember to update it. Turning one person’s know-how into shared, explicit, durable knowledge is real work, and on a job nobody is staffed to do it.^[4] Brad does the translation from the artifacts the project already generates, so the record reflects what was actually drawn, priced, and approved, not what someone had time to type up afterward.

Connected, not just collected

A pile of documents in one searchable place is still a pile. The questions that matter on a job span documents. Which change orders touched the curtain wall spec? What did we actually pay against this cost code, net of retainage, and is the lien waiver in? Why was this detail built the way it was, and was the added cost ever authorized? A filing cabinet, even a searchable one, makes you open six files and reassemble the answer by hand.

Brad links the documents into a graph instead. Each spec, cost, vendor, RFI, and decision is wired to the others it touches, so an answer can cross from a change order to the spec section it revised to the schedule of values line it moved. Change one thing and what sits downstream of it surfaces too. That connection is the entire difference between a collection of files and a single source of truth. It is also where the quiet money is: bad data, the disconnected and untrustworthy kind, was tied to roughly 1.85 trillion dollars of cost across global construction in a single year.^[5]

The knowledge stays with the project

On most jobs the real knowledge base is one person’s head, and it walks off the site when they do. Turnover is not an edge case in construction, it is the weather. When the record lives with the job instead of in a veteran super’s memory, it survives the rollover. The next person inherits a project they can ask anything, rather than a cold inbox, a shared drive nobody named consistently, and a shrug.

That durability pays off most at the moments under pressure. A sourced, dated record is what you reach for at closeout when the as-builts have to reconcile with what was actually built, and it is what you reach for when a job turns adversarial. The single most common cause of construction disputes is a party failing to understand or comply with its contract obligations,^[6] and the cost of getting there is not small. A connected record of who decided what, when, and against which clause is the difference between a defensible timeline and a room full of people fairly sure it was sometime around April.

What this is and what it is not

Brad is document intelligence pointed at a construction project. It reads what you give it, connects it, and attaches the source to every answer, so you can check the citation rather than take its word. What it is not: a wiki you have to maintain, a replacement for the judgment that owns a decision, or a system of record that overrides your contract’s formal processes. A person still owns every call that matters. Your project’s content belongs to you and stays isolated to your workspace, walled off from every other tenant. If you need the specifics on how a project’s knowledge is stored or retained, ask us and we will walk you through exactly how it works.

You will not get the knowledge out of people’s heads by handing them another wiki to maintain. You get it by building the record from what the job already produces, connecting it so the answers span documents, and keeping it with the project instead of the person. The knowledge was always there. Brad is how the whole team can finally ask it a question and get the answer back with the receipt attached.