Elliot Powell is the director of data and AI for Seattle-based heavy civil and marine contractor Pacific Pile & Marine. Opinions are the author’s own.
When we moved Pacific Pile & Marine onto a company-wide artificial intelligence platform, I expected the hard part to be the technology: choosing the model, connecting it to our systems, ensuring system security. Those turned out to be the parts that went to plan.
The hard part showed up once people started using it for real work, and it didn't look like an AI problem at all. Instead, it was a simple question: Which was the current revision of our submittal? Turns out, AI couldn’t answer that question with confidence, since we didn’t know the answer ourselves.
The model wasn't wrong. It was reading exactly what we'd given it: the same document saved in several places, under several names, with nothing to say about which copy actually mattered.
For years, people had filled that gap from memory. The superintendent knew which folder was the real one. The estimator knew that "final_v3_REV" beat "final_FINAL." AI doesn't have that tribal knowledge, so it surfaced every inconsistency we'd been quietly working around.
That's the lesson I'd pass to any contractor starting down this road. AI won't fix your data problems. Instead, it will expose them quickly and for everyone to see.
The problem was never the model
In a recent Construction Dive piece, two authors from Palantir argued that contractors' issue with AI isn't the software: “The problem is that no single tool understands the business the way the people running it do."
Their answer is an ontology, a digital model of the company that makes sure the field and the back office speak the same shared language. I agree with that takeaway.
From the field, though, that shared language starts much smaller than an enterprise ontology. It starts with what a folder is called, what goes in it and how a file gets named when someone saves it from a jobsite trailer at the end of a long shift.
If two project teams file the same document type in different places under different names, no platform will make those two jobs comparable, ontology or otherwise. For us, unifying the language meant agreeing on the nouns before applying it to anything.
We made that the first principle of our adoption framework. We asked every team to get a few things right before building an AI workflow. Data comes first, ahead of how you delegate it to the tool, how you describe the task and how you check what comes back.
Standardize one job, not the whole company
Our instinct was to write a companywide folder standard and roll it out. We didn't. Instead, we assigned one project manager to pilot a standard structure and naming convention on a live project. We're treating it as a field test rather than a policy.
That choice matters. A standard naming convention written in the office gets judged on whether it looks tidy. A standard convention used on a jobsite gets judged on whether someone in the field can find what they need without calling the office.
A trial run in the field tests what a conference room can't: whether a name is short enough to type on a phone, whether a folder makes sense to the crew as well as to accounting and whether two categories overlap in ways nobody noticed on paper.
It also changes who owns the standard. When a PM is the one proving it works, the standard stops being an IT mandate and becomes the way that project runs. That's the version other PMs are likely to adopt.
The second half of the work is deciding what counts as authoritative. Working project files are messy by nature, and they should be. The material an AI tool treats as the truth needs a person to review it before a final decision is made..
Our past project history is a good example. We need comparable jobs quickly for prequalifications, so rather than let a tool dig through years of closeout folders, we're building one consistent summary for each completed project. The AI part of that is easy. The real project is to agree on what every summary must contain.
Adaptability beat technical skill
Anthony Chiaradonna, Consigli Construction's chief information officer, put it well to Construction Dive earlier this year: "the biggest skills shift we've seen within the industry is not on the technical side. It's with how well teams are able to learn, adapt and manage the change in real-time without compromising on quality, safety or schedule."
That matches what I've seen, with a twist that's specific to data. The people who get the most out of a rollout aren't necessarily the most technical. They're the ones willing to change a habit they've had for most of their careers: how and where they save a file. That's a harder task than learning to write a good prompt.
It's also why our training, which includes a mandatory foundational course, a shared prompt library and open drop-in sessions, must cover where things go and not just what to ask.
It changes how we respond to resistance, too. When someone says the AI "doesn't work," the useful follow-up is to ask why. The answer is usually worth hearing, because AI tools can only find what’s already there, and what’s already there is usually the problem.
I’d tell other contractors to:
- Treat your first months of AI use as a data audit. Every bad answer points to a file, folder or naming problem.
- Agree on the nouns you want to use before choosing the platform. Folder names, document types and file-naming rules are the language your AI will speak.
- Pilot your naming convention on one live job with a PM who owns it.
- Decide what's authoritative and put a person between working files and the material AI treats as the truth.
- Train and hire for adaptability. The skill you'll need most is a willingness to change how work gets filed.
The model we ultimately pick will be replaced, probably sooner than any of us expect. The folder standard, the naming convention and the habit of deciding what's authoritative will outlast it. That's the part of an AI rollout nobody puts in the demo, and it's the part that decides whether the rollout works.
