Jesse Velay-Vitow is a deployment specialist and Jonas Lang is tech lead for artificial intelligence firm Palantir. Opinions are the authors’ own.
For three decades, the construction industry has been told that the answer to its operational fragmentation is another piece of software. The result has been a tangle of disconnected systems, a back office buried in reconciliation and a field crew that has largely opted out. Most recently, the solution pitched is artificial intelligence; creating the problem of AI slop.
We have come to a different conclusion: The problem isn't the tools. The problem is that no single tool understands the business the way the people running it do. What construction needs is an ontology.
Ontology: what it is and why it matters
An ontology is a digital model of how your company actually operates: the proper nouns and verbs of your business and the relationships between them. A job. A foreman. A material delivery. Equipment.
Each of these exists in your business, trapped in different systems, viewed through different lenses by different departments and reconciled only when something breaks.
Semantics is only half of the power. The true value comes from the kinetics (the verbs) in the ontology. Procure a material, assign a crew, execute a change order, validate a legal claim. Decisions made in one business process inform others. They are captured and compound.
When we design an ontology, we capture the full view of the business. How a piece of equipment looks to dispatch, to the mechanic, to the project manager. The ontology becomes the shared source of truth everyone operates from, while still letting each function see their slice of reality.
4 things the ontology must do
Working with our partners in construction including McCarthy Building Cos., Thomas Cavanagh, and Lennar, we've learned what works. The ontology must do four things, or it isn't worth building.
It must be companywide. If the field runs on one system and the back office runs on another, you've built a new silo on top of the old one. The ontology must span the entire business, from the moment a bid is priced to job closeout.
It must work for blue-collar operators. The most important users in construction are the ones with mud on their boots. If the foreman won't use it, nothing else matters. We design from the field inward, not the executive suite outward.
It must function like an Iron Man suit. The goal isn't to replace the experienced operator. It's to remove administrative burden and give them more awareness, speed and leverage.
It must reintegrate the business. By codifying how a construction company operates, the ontology lets functions that have been disconnected for decades start operating holistically again. Each piece of information is entered once and then is available to the entire business.
Construction ontology in practice
The core objects we model with our construction partners are straightforward: jobs, activities, labor, equipment, materials and contracts. The benefit of an ontology emerges by connecting this data from disparate source systems into a comprehensive, living model of your business.
Timecards. For many companies, timecards travel from a paper sheet or app, through approvals, into the ERP and finally into payroll. Under the best circumstances, this can take days. If there are exceptions, the burden on payroll teams can be immense. With the ontology, the timecard is the same object from field capture through approval, job cost-visibility and payroll. Adjustments can happen the same day, not the next pay period.
Equipment. Equipment is the classic example of a single object viewed through many different lenses. The field wants the right machine available when needed. Maintenance wants every unit serviced on schedule. Dispatch wants the right asset at the right job at the right time. With the ontology, they operate from one equipment record showing location, job assignment, cost, service status and upcoming demand.
Contracts. A typical project contract runs hundreds of pages and contains dozens of obligations, notice windows, change order procedures, weather provisions and insurance requirements. With contract clauses and AI agents in the ontology and linked to the events happening in the field, the document becomes a living seal of approval on day-to-day operations. Deadlines can surface before they're missed. Notice requirements can trigger automatically.
Procurement. A job churns through hundreds of vendors and thousands of invoices. In most back offices, anything under a threshold gets paid because the validation cost exceeds the risk. Anything above it consumes hours of manual effort and documentation. With AI agents and those documents all sitting in the same ontology, the validation can happen automatically. Designed to ensure you pay for exactly what you received, at the price you agreed to.
Every company's ontology will look different. That's the point.
The core objects described are the bones. The way your company operates is the meat on those bones, and it isn't the same as your competitor's.
A heavy civil contractor doesn't run like a mechanical sub, which doesn't run like a vertical builder. The ontology has to bend to the business, not the other way around.
Without an ontology, AI is a loose cannon with a good vocabulary and no foundation under it. With one, it's a tool that knows your business, respects your rules, re-enforces your security architecture, scales with your workforce and makes your people faster.
Facts Only
* Jesse Velay-Vitow is a deployment specialist, and Jonas Lang is a tech lead for Palantir.
* The construction industry suffers from operational fragmentation due to disconnected systems.
* A proposed solution involves creating an ontology to model business operations.
* An ontology models proper nouns (nouns) and verbs (actions) of the business and their relationships.
* The ontology must be companywide, spanning from bidding to job closeout.
* The ontology must work for blue-collar operators in the field.
* The goal is to reduce administrative burden and increase awareness, not replace experienced operators.
* Core objects modeled include jobs, activities, labor, equipment, materials, and contracts.
* Timecards, equipment status, contract clauses, and procurement validation are unified within the ontology.
Executive Summary
The core problem in the construction industry stems from operational fragmentation caused by disconnected systems, resulting in a back office buried in reconciliation and a field crew opting out of digital processes. The proposed solution involves creating an ontology—a digital model of how a company operates, capturing not just nouns but also the kinetic relationships (verbs) between business elements. This ontology aims to serve as a shared source of truth by modeling core objects like jobs, labor, equipment, materials, and contracts across the entire business.
The necessity for this system is demonstrated through tangible examples: streamlining processes like timecard management, providing a unified view of equipment status for dispatch and maintenance, managing complex contract obligations, and automating procurement validation. The ontology must be companywide, designed to serve blue-collar operators by reducing administrative burden and increasing awareness, functioning like an Iron Man suit rather than replacing experienced workers. Ultimately, the system aims to reintegrate previously disconnected functions so that data entered once informs the entire operation holistically.
Full Take
The narrative suggests a fundamental tension between operational reality and the technological implementation thereof. The move from viewing fragmented systems as a problem to defining an ontology as the solution highlights a shift from purely tool-based fixes to ontological modeling of business structure. The focus on "kinetics" (verbs) over mere semantics indicates that the value lies in capturing dynamic processes and compound decisions, rather than static data storage.
The requirement that the system must serve blue-collar operators—designing "from the field inward"—is a critical constraint that challenges the typical executive-led implementation of enterprise software. This suggests that technological efficacy is secondary to human adoption and situational relevance; an AI foundation without this contextual grounding risks becoming an abstract tool detached from operational reality. The implied pattern is one where sophisticated systems are only valuable when they align with the established, lived experience of the end-users.
The implication for AI deployment is profound: without this ontological foundation, artificial intelligence remains a "loose cannon with a good vocabulary and no foundation." This suggests that the current trajectory risks deploying advanced capabilities based on superficial data correlation rather than deep, verifiable structural understanding of complex physical and contractual realities. The central question becomes whether the pursuit of systemic integration can occur without sacrificing the necessary contextual integrity required for human agency and operational trust.
