Preconstruction is invisible once a building is standing. The average person touring a finished project doesn’t think about the takeoff, the clash detection, or the sequencing worked out months earlier. Skip that work, though, and it shows up fast: rework, wrong orders, a schedule that doesn't hold.
Construction AI has its own version of preconstruction. Before an assistant can answer anything about your project or an agent completes a task on your behalf, it has to make sense of thousands (maybe millions) of documents across drawings, specs, submittals, RFIs, contracts, and schedules, usually scattered across three or four systems that don't talk to each other. We call that work “pre-processing,” and it's the reason why the answer you get back or the AI agent’s output is trustworthy.
What “pre-processing” actually is
Pre-processing is the work of turning a pile of disconnected documents into something an AI system can reason across: pulling every document in from wherever it already lives, classifying each one by type (a submittal is not an RFI is not a spec section, an architectural drawing is not a civil drawing, etc.), and then actually reading it: text, the visual language of drawings, structured data from schedules, tables, or data fields in other connected platforms. This work happens before an agent ever completes a task, or a superintendent asks a question.
Building the “knowledge graph”
The output of pre-processing isn't a bigger pile of searchable text. It's a knowledge graph: a structured map of how every document and data point on a project relates to every other, rather than a flat list or index. This submittal references this spec section and is amended by this RFI. This drawing detail is connected to this schedule line and appears on these two other sheets. This change order impacts all of these documents. Nothing on a construction project exists in isolation, and a knowledge graph lets a system reason the way an experienced superintendent already does, by holding the whole project in a connected project “brain.”
What it costs you to skip this step
Without pre-processing, an AI system has two options, and both don’t work for construction teams: guess from a narrow slice of context and miss the connections that matter, or re-read the relevant documents from scratch on every question or agent run. Both depend on a human remembering every relevant document for a given task or question, but when a project document set numbers in the tens or hundreds of thousands, this is an unrealistic expectation. Ultimately, neither option is reliable, and neither is cheap.
The cost problem compounds. Comparing an approach that reprocesses full documents on every call against one that reasons over a pre-built knowledge graph, the gap on common tasks is stark: drafting an RFI takes roughly 90,000 tokens versus 11,000, about 8 times more. Reviewing a submittal against a spec runs about 250,000 tokens versus 29,000, roughly 9 times more. That gap doesn't shrink as a project goes on; it grows, because document volume only increases as the project progresses.
The reliability problem is worse. Without a knowledge graph connecting documents together, a system can't catch cases where a spec section was tagged wrong, a newly issued RFI response updates the owner’s design intent, or a detail buried in a drawing set contradicts the written spec. It can only tell you what one document says, not whether that's still true once every other document on the job is accounted for.
What it makes possible
This is why pre-processing matters more than any single feature. In Trunk Tools platform data, TrunkSubmittal, a submittal review agent, corrects the spec section already assigned in the project management system in roughly 30% of submittals, because the knowledge graph has already connected these data points and can identify human error. The alternative is that 30% of reviewed submittals are missing critical context and will surface as a rejected submittal or a field conflict weeks later.
It's also why TrunkRFI, an RFI drafting and response analysis agent, can trace the downstream impact of an RFI response across every drawing, spec section, and schedule item it touches, and why TrunkBrowse lets you click any object in your drawings and see its full context: the schedule row, the spec section, and every RFI and submittal connected to it, instantly.
None of this works backward. A knowledge graph can't be bolted onto an AI system after the fact any more than preconstruction can be retrofitted into a building already framed. It has to happen first, on every project, before a single agent handles a task or a user asks a question. That's the trade Trunk Tools made: harder work up front, so the work that happens in our platform allows builders to offload the document processing and get back to building.