Revolutionizing Construction

How Cavanagh and Palantir Are Building Construction’s OS for the 21st Century

Palantir
14 min readadvanced
--
View Original

Overview

This article details the partnership between Thomas Cavanagh Construction and Palantir to build Total Operations Management (TOM), a unified operating system for construction operations. It covers the discovery process, five key design principles, and how Palantir Foundry replaced fragmented legacy systems with a single ontology connecting contracts, labor, equipment, and materials across the entire organization.

What You'll Learn

1

How to design a unified operating system for construction by replacing fragmented tools with a single ontology-based platform

2

Why field-first design principles lead to better data capture and operational efficiency in industrial settings

3

How to apply purposeful friction in workflow design to enforce accountability without burdening frontline workers

4

When to challenge legacy processes using first-principles thinking rather than incremental digitization

5

How ontology-based data architecture enables replication of workflows without re-engineering

Prerequisites & Requirements

  • Understanding of enterprise data integration challenges and ERP systems
  • Familiarity with ontology-based data modeling concepts(optional)
  • Experience with operational workflow design or digital transformation initiatives(optional)

Key Questions Answered

What is Total Operations Management (TOM) and how does it work in construction?
Total Operations Management (TOM) is a unified operating system built on Palantir Foundry that runs an entire construction company from a single platform. It connects four foundational domains — Contracts, Labor, Equipment, and Materials — through a shared ontology, replacing fragmented legacy tools. Every object (truck, activity, crew, shift) exists once and powers dispatch, timecards, rentals, procurement, and payroll simultaneously.
How does Palantir Foundry replace legacy ERP systems in construction operations?
Palantir Foundry replaces the legacy ERP by becoming the single system that runs daily operations including dispatch, trucking, site management, and workforce coordination. The legacy ERP is being steadily removed from operations and will remain only as a financial ledger by year-end, while TOM handles all operational workflows through a unified ontology that captures data as work happens rather than requiring manual reconciliation.
What are the key design principles for building a construction operating system?
Five key principles emerged: (1) unify data into a single live source of truth to reduce coordination overhead, (2) automate accountability so it mirrors real-world asset responsibility, (3) design workflows with purposeful friction only where decisions carry risk or cost, (4) capture data as a natural byproduct of field work rather than requiring separate data entry, and (5) challenge legacy processes using first-principles thinking instead of patching existing workflows.
Why does construction technology adoption lag behind other industries?
Construction technology adoption has been slow and fragmented due to the industry's physical and decentralized nature. Many companies still operate on paper, spreadsheets, and siloed systems. Growth creates exponential coordination complexity — ten people create 45 coordination lines while 100 create nearly 5,000. Incremental fixes and layered systems create friction rather than flow, with software shaping behavior in unproductive ways.
How does field-first design improve data quality in construction operations?
Field-first design reverses the traditional relationship where field staff feed financial systems that give nothing back. Instead, when a foreman plans a shift, dispatches trucks, or confirms completed work, they simply perform their job while the system captures data automatically. Project teams and accountants receive real-time information without additional effort from the field, making the record of work indistinguishable from the work itself.
What does purposeful friction mean in workflow design?
Purposeful friction means making the right action effortless and the wrong one inconvenient, introducing friction only when a decision carries risk, cost, or accountability. For example, a foreman cannot close a shift without confirming quantities, but a driver is never stopped at a scale for a missing cost code. Workflows request only truly needed information, and if something can be determined automatically, the system does not ask again.
How does an ontology-based platform enable scalable construction operations?
Because TOM is built on a clean ontology where every object exists once in a shared structure, new workflows can be built in weeks instead of months by plugging directly into the same backbone. The same ontology that connects current projects can support ten times the workload without adding complexity, enabling horizontal scaling across projects and vertical scaling across divisions, suppliers, and partners without re-engineering.

Key Statistics & Figures

Employee daily Foundry usage
97%
Percentage of Cavanagh employees who use Foundry every day
Coordination lines for 10 people
45
Number of coordination lines created between 10 people, illustrating exponential complexity growth
Coordination lines for 100 people
nearly 5,000
Number of coordination lines created between 100 people, showing how coordination becomes exponentially harder as organizations grow
Company history
70 years
Duration of Cavanagh's steady growth before undertaking digital transformation
Partnership duration
Through 2030
Multi-year partnership timeline between Cavanagh and Palantir

Technologies & Tools

Platform
Palantir Foundry
Core platform powering the unified operating system (TOM) with ontology-based data architecture
AI Platform
Palantir Aip
AI platform enabling reasoning on structured and unstructured data for autonomous action
AI/ML
Large Language Models
Next-phase capability for interacting with operational data and taking autonomous action

Key Actionable Insights

1
Design systems that capture data as a natural byproduct of field operations rather than requiring separate data entry steps. When workers perform their normal duties — planning shifts, dispatching equipment, confirming work — the system should automatically record the relevant data for downstream consumers like accounting and project management.
This 'field-driven data' principle eliminates the burden on frontline workers who previously had to feed financial and project systems that gave nothing back to them, improving both data quality and worker morale.
2
Introduce purposeful friction only at decision points that carry risk, cost, or accountability, while making the correct default action effortless. Most legacy systems inadvertently make the right thing difficult and the wrong thing easy — flip this by designing workflows that request only truly needed information.
Applied at Cavanagh, this meant foremen must confirm quantities before closing a shift (high accountability) but drivers are never blocked at scales for missing cost codes (system can determine this automatically).
3
Before digitizing existing processes, map how work is actually performed rather than how it is documented, then challenge every legacy process from first principles. Many reports, approvals, and data capture steps persist only because 'that's how it has always been done' or because another system demands the data.
Cavanagh's internal deep dive found countless examples of reports no one read, approvals that added no value, and data captured only because another system demanded it — eliminating these removed friction without losing value.
4
Commit fully to a single platform and single source of truth rather than building pilots or partial integrations across multiple tools. This forces clarity in design and decision-making, removes data duplication, and aligns all teams around a shared objective.
Cavanagh's 'all in' approach resulted in 97% of employees using Foundry daily, with every other software needing to justify its existence against the unified platform.
5
Anchor accountability to mirror reality by automatically recording responsibility through daily workflows such as asset checkout, inspection, reassignment, and return. Traditional systems separated accountability from action by assigning equipment to jobs rather than to people who actually control the assets.
By creating a living map of accountability through natural workflow events, the system eliminates confusion about who is responsible for what without requiring manual tracking or reconciliation.
6
Recognize that the biggest constraint in rapid digital transformation is change management, not technology. When development speed outpaces organizational adaptation, invest in helping people adjust to how quickly the system evolves rather than waiting for tools to catch up.
At Cavanagh, the speed of development on the clean ontology pushed the organization to its limits on change management, with workflows that once took months now buildable in weeks.

Common Pitfalls

1
Layering new software systems on top of existing fragmented tools rather than unifying them into a single source of truth. Each new form, spreadsheet, or software system solves an immediate need but collectively creates friction rather than flow, making the organization harder to coordinate as it grows.
Cavanagh experienced this firsthand over decades of growth — incremental fixes produced an organization that worked hard but had outgrown its tools. The solution was committing to one platform rather than adding more integrations.
2
Designing data capture around system requirements rather than field reality, forcing frontline workers to feed financial and project systems that provide nothing useful back to them. This creates resentment, reduces data quality, and embeds frustration into the workflow.
The field-driven data principle reverses this by making data capture a natural byproduct of operational work, so field staff see the system as helpful rather than burdensome.
3
Over-collecting data that does not serve decision-making simply because other systems demand it, while the information that truly matters — the state of work, crew readiness, material movement — remains inaccessible or delayed.
Cavanagh discovered much of their captured data existed only to satisfy other systems' requirements. The fix was to prioritize capturing facts of work as it happens rather than data for reporting purposes.
4
Assigning accountability to abstract entities like jobs or cost codes rather than to the actual people responsible for assets and actions. This separates accountability from action and creates confusion about who is responsible for equipment and decisions.
The solution is to anchor accountability to operators and foremen through natural workflow events (checkout, inspection, reassignment) rather than through manual cost coding.
5
Attempting to digitize existing paper-based processes as-is rather than redesigning workflows from first principles. Many legacy processes persist because 'that's how it has always been done,' including reports no one reads and approvals that add no value.
The breakthrough insight is that LLMs and modern platforms enable reimagining workflows entirely, not simply automating the paperwork of old ways of working.

Related Concepts

Ontology-based Data Modeling
Digital Transformation In Construction
Enterprise Resource Planning (erp) Replacement
Activity-based Costing
Change Management
Forward Deployed Engineering
First-principles Thinking
Operational Data Architecture
Field-first Design
Unified Source Of Truth
Ai-driven Operations Management