Trunk Tools' stack cut document review from 60 days to 10 by ditching general-purpose models
Digital Frontier EditorialJuly 3, 20265 min read
Key Takeaways
Trunk Tools replaced general-purpose LLMs with a three-layer specialized stack — perception, semantics, agents — slashing construction document review from 60 days to 10
Foundation models fail on niche domains because they're optimized for breadth, not the jargon-dense, abbreviation-heavy, format-specific reality of industry data
Real competitive advantage comes from pre-training on proprietary domain data, fine-tuning on practitioner examples, and building custom evaluations — not from bigger context windows
The construction vertical proves a replicable blueprint: structure chaotic proprietary data into knowledge graphs, then train models that actually reason like domain experts
Sixty days to ten. That's not incremental improvement. That's a category error in how the industry thinks about AI adoption.
Trunk Tools didn't achieve it by prompting GPT-4 harder. They did it by accepting an uncomfortable truth: general-purpose models are fundamentally mismatched to the work that actually matters in construction.
Most verticals don't run on clean SaaS databases. They run on PDFs with handwritten markups, proprietary naming conventions, implicit workflows that veterans "just know," and million-page document sets that change daily. Foundation models choke on this. They're trained for breadth — okay at everything, weak at anything niche.
The architecture that replaced the foundation model
Trunk Tools built a three-layer stack: perception, semantics, agents. Perception ingests the chaos — scanned plans, RFIs, submittals, specs — and structures it. Semantics maps that structure into a construction ontology, then a knowledge graph. Agents reason over the graph to automate review cycles that used to take months.
Sarah Buchner, founder and CEO, put it bluntly: "We really set out to take the data from dispersed systems, pre-process it, structure it, go through our ontology into a knowledge graph, and then train AI models." She was a carpenter before she was a founder. She knew the data was ugly. She built for ugly.
Why RAG isn't the answer
The industry's reflex is retrieval-augmented generation. Feed the model better context, get better answers. Kriti Faujdar, a senior product manager in AI infrastructure, calls this a band-aid: "RAG helps a little. But it's just giving better facts to a model that still can't reason properly in the domain."
She's right. A GPT-4-class model can parse a French legal contract but fumbles the specific article references a construction lawyer needs to cite. The vocabulary isn't the problem. The reasoning is. The model doesn't know what a "submittal log" implies about schedule risk. It doesn't know that "per spec section 09 90 00" carries different weight than "per architect's instruction."
Those implicit rules never made it into pretraining. They live in internal systems, proprietary formats, the heads of superintendents with 30 years on job sites.
Fine-tuning for reliability, not intelligence
Sébastien De Bollivier, a developer who works on domain-specific AI, argues the industry fine-tunes for the wrong thing: "Don't fine-tune to make the model 'smarter' about a domain. Fine-tune to make it more reliable on the specific output format your workflow requires."
That distinction matters. Trunk Tools didn't need a model that understands construction theory. They needed one that consistently extracts drawing revision numbers, links them to specification sections, and flags conflicts in the exact format their reviewers expect. A few thousand examples from real practitioners beats millions of scraped, noisy ones.
Mixture-of-experts architectures help specialize without blowing up inference costs. Hybrid stacks work too: a general-purpose model for orchestration, a smaller fine-tuned model for domain extraction. But the principle holds — specialization happens at the data layer, not the prompt layer.
The blueprint is portable
Construction isn't special. Every regulated, document-heavy, field-dependent vertical has the same problem. Healthcare has prior authorization letters and clinical notes. Insurance has loss runs and policy endorsements. Manufacturing has shop drawings and quality audits.
In each case, the valuable data is proprietary, format-specific, and reasoning-dense. In each case, foundation models hallucinate the nuances that practitioners live by.
Trunk Tools proved the pattern: ingest the mess, structure it through a domain ontology, build a knowledge graph, train models on practitioner-verified examples, evaluate against real workflow outputs. The stack is replicable. The willingness to do the unglamorous data work is not.
Stop waiting for the next model release
Companies still betting on "GPT-5 will solve this" are losing to competitors who accepted that it won't. The next foundation model will be broader, not deeper. It will still fail on your abbreviation-heavy, jargon-dense, format-specific proprietary data.
The moat isn't access to the best API. The moat is the ontology you build, the evaluations you design, the practitioner feedback loops you institutionalize. Trunk Tools cut 60 days to 10 because they stopped treating construction data as text and started treating it as structured knowledge.
That's the only way any vertical escapes pilot purgatory. The models aren't coming to save you. Build the stack.
