What the system of record was designed to do
The system of record did exactly what it was designed to do. It gave the industry one place to put things, then distributed that data outward to tools that each solved a specific, siloed problem. A tool for takeoff. A tool for scheduling. A tool for submittal logs. Each competent inside its own boundary.
What none of them do is connect to each other. That job goes to the people managing the job.
And it's the full view, not the individual document, that lets you draw the lines that lead to the right decision. A spec section governs a submittal. An RFI response amends that spec. A revision quietly contradicts an answer the design team gave two months ago. Those relationships are where the risk lives, and no single tool in the stack can see them, because each one only holds its own slice.
Dodge Construction Network's 2026 study with CMiC found that only 6% of contractors have a fully connected project controls environment, and just 41% can identify a potential overrun while it's still manageable on at least half their projects. A separate Dodge study of capital project owners put it more memorably: organizations are, in the words of research director Dr. Donna Laquidara-Carr, "operating in silos of excellence, rather than fully integrating their data, and that puts a ceiling on the benefits they can expect."
Silos of excellence. That's the point-solution era described precisely. Every tool good at its job, the project still blind between them, while 95.5% of the data captured in the industry goes unused.
The record isn't the problem. The record is good at being a record. The problem is that we kept adding tools on top of it and kept leaving the hardest work, the connecting, to the person with the least time to do it.
What a system of action does with a single bulletin
Here's the difference a fully integrated system can make compared to a set of disjointed tools. The project below is illustrative, but every step is a real capability running today.
Bulletin 4 lands. It revises 135 sheets across six disciplines: 86 Interior Design, 18 Technology, 13 Plumbing, nine Electrical, eight Architectural, one General. Under the old paradigm this is the beginning of a week.
Read the change and write it down. Three days after issue, the bulletin has a narrative. Not a diff, an explanation: guestroom finishes, casework, and device layouts reworked across unit types, and the enlarged unit plumbing plans picking up new cleanouts, floor drains, and fixture tags. One line matters more than the rest, and it's the one a reviewer under deadline is most likely to miss: the added plumbing scope in the enlarged unit gravity plans is not reflected in the current contract documents and may carry cost impact.
Localize it. Sheet P-402 holds the enlarged unit gravity plans. Comparing Bulletin 4 against the 100% CD set surfaces 11 change areas. In Unit KDA alone: a revision cloud with a note and tag, a floor drain (FD-1) added inside a cloud, a cleanout added to a 4" SS pipe with a "WC-1" tag added to the toilet, and a double swing door removed with its wall opening. Four changes, one unit, one sheet, out of 135.
Check it against the rest of the project. Click WC-1 and spec section 224000, Plumbing Fixtures, opens beside it. This is where a change stops being a drawing edit and becomes a scope question. The linked documents tell you whether it's inside your contract or outside it.
Decide whether the question is worth asking. Before drafting an RFI, the system reads P-402 against spec 224000, the P-601 fixture schedule, and the interior design finish schedule, then checks the existing RFI log. Its finding: the revision adds the cleanout without a type callout, neither the spec nor the fixture schedule designates floor versus wall there, and ID-003 still shows LVT in the area with no access panel called out. No existing RFI covers the scope. The question is genuinely unanswered, so draft it. The same reasoning that produces a good RFI is what prevents a bad one; an agent that can only draft will draft everything.
Price it. The change event carries a rough order of magnitude: ~$205,000, working range $140K to $270K, broken out by who bears it. Finishes and casework ~$105K across the 86 Interior Design sheets. Plumbing rough-in ~$40K. Electrical and technology ~$25K for device coordination. GC and architectural coordination ~$35K. From there it drafts as a potential change order, line by line, per subcontractor, labeled AI-generated, verify before submitting. The team still makes the call. What's gone is the three days of tracing required to make it.
Count the systems that would have had to talk to each other for that to happen in a point-solution world: drawing comparison, spec retrieval, RFI log, cost estimation, change management. Five tools, five exports, five chances to drop the thread. And none of them could have produced the $205,000 on its own, because that number is a function of relationships living outside every individual document.
Every system of action runs on a knowledge graph
This is the difference between a platform and a bundle.
A system of action cannot act on documents. It acts on a model of how documents relate. That model is a knowledge graph, and building it is the actual work. Every Trunk Tools project begins there: we read the construction documents and build the graph before any agent runs. Underneath it sits a construction ontology, a structured definition of what a submittal, a spec section, an RFI, a drawing detail, and a schedule activity each are, and how they depend on one another. That's what Cortex is.
Point solutions build knowledge graphs too. They just build shallow, private ones scoped to a single task, and throw them away at the boundary. Five AI point solutions means five partial models of the same project, none of which can see the others. That doesn't add up to a system of action. It adds up to five more places where context gets dropped. It's why the handoffs above are the product rather than a convenience: the RFI reasoning knew which change it was responding to because the review had already characterized it, and the change event carried per-trade pricing because the graph knew which trades touched which sheets.
How construction tech sprawl fails, in order
Tech sprawl doesn't fail all at once. It starts with slower detection, because nothing is watching the relationships between systems. That pushes teams back onto manual review and hallway communication. Then the value stops being visible to the people on site, who are doing the same work they always did plus logging into another tool. Trust erodes. Software nobody trusts becomes shelfware.
That last stage is where most AI pilots in construction quietly end. Not with a failed evaluation. With an unused license.
The question to take into your next vendor conversation
Most AI evaluations in construction ask what a tool can do. That's the wrong question, because the answer is always impressive and always narrow.
Ask instead: what does this system know about how my project documents relate to each other, and where did that knowledge come from?
If the answer is a general-purpose model with a good prompt, you're buying a point solution with better marketing. If the answer is a knowledge graph built from your documents, on an ontology that knows what a submittal is, you're buying something that can act. That's the same test as the questions worth asking any construction AI vendor before you buy.
Point solutions solved one problem each, and solved them well enough for the projects we were building a decade ago. They are antiquated for the realities of the modern jobsite. The volume is bigger, the documents are more connected, and the people who used to hold the lines together are leaving faster than they can be replaced.
Somebody still has to connect the dots. The only question is whether it's your project team, at 9pm, from memory.
Frequently asked questions
What is a system of action in construction? A system of action is software that acts on how project documents relate — drawings, specs, RFIs, schedules, and change — rather than only storing them. It runs on a knowledge graph of those relationships, so a bulletin review, an RFI draft, and a cost estimate can share context instead of being handed off between disconnected tools.
What's the difference between a system of record and a system of action? A system of record is the project management or document platform that stores files and distributes them to other tools. A system of action sits on top of that record, connects the documents to each other, and completes work across those connections. The record is necessary. It is not sufficient for reviewing, pricing, or deciding on change.
Why don't construction point solutions add up to a system of action? Each point solution builds a shallow, private model of one workflow and drops context at the boundary. Five AI tools on the same project produce five partial pictures, none of which can see the others. Connecting those pictures remains the job of the project team.
What is a construction knowledge graph? A construction knowledge graph is a structured map of how project documents depend on one another: this spec section governs that submittal, this RFI amends that spec, this detail appears on these sheets. Trunk Tools builds that graph from the documents on every project, on a construction ontology, before any agent runs. That graph is Cortex.
How should contractors evaluate construction AI vendors? Ask what the system knows about how your project documents relate to each other, and where that knowledge came from. If the answer is a general-purpose model with a good prompt, you are buying a point solution. If the answer is a knowledge graph built from your documents on an ontology that knows what a submittal is, you are buying something that can act.
By the Trunk Tools team. Last updated September 11, 2026.
Sources: Dodge Construction Network / CMiC, Most U.S. Contractors Still Struggle to Catch Cost Overruns in Time (2026); Dodge Construction Network, New Research Reveals Major Gap in Digital Maturity Among Capital Construction Owners (2026); Autodesk, Construction Insights: Data.