Skip to content

ThinkingExplainer

AI doesn’t need a data cleanup first. It needs your best people’s rules.

Owners are told to clean up their data or replace the ERP before AI can work. Most of what’s missing is the rules their best people apply when two systems disagree.

Ironworkers standing the first steel columns on a new concrete foundation at dawn.
Illustration generated for thinkⁿ
On this page
  1. What is an AI foundation?
  2. Which source wins
  3. Limits, and who signs
  4. Where to start
  5. Questions people ask

In September, at a demo for a steel fabricator we work with, someone asked our tool what an order cost.

It found the supplier’s order acknowledgment, a PDF, and came back with the right price. The ERP still showed an older one.

In their ERP, a purchase order price is provisional until a PM copies the acknowledgment in. On that order, nobody had.

Someone on the call checked. They pointed out our tool might not have been reading the ERP’s price column at all. So it was right, but maybe not for the right reason. I told it “good job” anyway. Trust, but verify.

Once it reads both prices, only a written rule tells it which one to trust. Without one, an invoice check would flag correct invoices as overcharges.

Think of a new buyer on their first day. They can open every system, and they’ll trust the PO price, because nobody has told them yet that it’s provisional. Someone sits with them for a few weeks and tells them what the screens don’t say. An AI tool gets the logins on day one and never gets the few weeks, unless someone writes them down.

In June and July I ran seven sessions with that fabricator’s leaders, project managers, plant managers, quality lead and finance lead. Most of the examples here come from them. A drawing set counts as ready when someone moves it from the approval folder to the IFC folder. A change order lives in email until someone remembers to follow it through. An empty inspection field in the ERP can mean the result is in the quality system.

None of that is written anywhere software can read. Some of it sits in the ERP. The rest is in folders, inboxes and other systems, and in knowing which one to look at.

The usual advice from ERP reps and consultants is to fix this first, with a data cleanup or a new ERP. They aren’t wrong that a tool reading a bad field repeats it with confidence, and some cleanup pays. But a company-wide cleanup has no question to answer, so nothing tells it when it’s done. And a new ERP is filled in by the same people, so the same fields stay blank.

Waiting for a smarter model won’t fix it either. A smarter model reads the same old price and sounds surer about it.

Most of the fix is the rules your best people carry, and right now they leave with the PM who knows them. My bet is that how your company actually works, once it’s written down, is the one part of an AI project that appreciates, because every question answered against it makes the next one cheaper, while the models and tools under it keep getting replaced. That written-down layer is what I mean by an AI foundation.

What is an AI foundation?

An AI foundation is the layer under a company’s AI tools that tells them how the business runs: connections to the systems you already have, one record of where each job stands, written rules for which source wins, limits on what software may change, and a named person who signs every draft.

Figure 1An AI foundation, in five parts
The tools sit between the limits and the people who sign. Every label is an example; yours will name your own systems and roles.

Connections come first, read-only, on accounts you control and can switch off. At the fabricator we connected the ERP and the shared drive first. For email, my plan was for each person to connect their own inbox and have the tool sort out what touched a job. Their team proposed one shared mailbox people copy in when they want the tool to know something. It’s safer, and it’s where we’re starting. Reading email may still have uses we haven’t found.

The record holds jobs, quotes, orders, ship dates and change orders, each with the settled answer and where it came from. In that shop, one kickoff email sets up each job twice, once in the ERP and once with the outside accountants, and “PO number” can mean the customer’s number or the shop’s own job number, depending on who’s talking. The record has to know which is which, and that the two entries are one job. Without it, a tool asked about a PO number can’t tell whose number it is, and may find two jobs where there’s one.

Why not just have the PM keep the ERP current? They should, and good PMs do. But acknowledgments, back-orders and revised dates land while the PM is on the phone about something else, and the ERP’s fields were never built to hold “back-ordered, earliest the 21st, waiting on confirmation.” Holding that until the ERP catches up is the record’s job. The one we’re building is meant to fill itself from the systems it reads and send the conflicts it can’t settle to whoever owns them, so nobody has to type into it.

A fabricator’s office at first light, drawings and a laptop on the desk, the shop through the glass.
Illustration generated for thinkⁿ

Which source wins

Figure 2Two prices, one order, and the rule that decides

Two sources

ERP · PO 4471$18,240Price entered when the order went out
Order acknowledgment · PDF in the job folder$18,960The supplier’s confirmed price, not yet copied in

The rule

The acknowledgment beats the PO price until a PM copies it in.Written down once, and approved by the PM who knows it.

“What did PO 4471 cost?”

$18,960.From the acknowledgment. The PM sees both prices and where each came from.To sign · PM
Switch the rule off and on. The PO number and the prices are made up.

The acknowledgment rule isn’t one you’d guess from outside. Neither is the blank inspection field. Most of the rules at the fabricator came out of those seven sessions. One that did, we didn’t build in time.

The finance lead told us the plant on a job record isn’t reliable there, and that they work out which plant did a job from the time clock. In August, the first time I showed our tool to one of their leaders, it had a job in the wrong plant. We never pinned down exactly what sent it there. What we did know was that we’d had the rule for two months and hadn’t built it in. We’ve since built the time clock’s hours into the job record.

Get drafts in front of the people who know, early, and check each one against the rules you’ve written down. If each branch or plant settles the same conflict differently, write each version down and have the owner decide whether they should differ. A branch with its own supplier may need its own rule; one that just drifted should follow the company’s.

Limits, and who signs

Read everything connected, write drafts only, and log every action. Widen it when the people approving the drafts say they’ve been right, and not before. If the tool reads email, decide whose, and tell the people affected in writing.

Every draft goes to the person who owns it, usually the PM or the buyer, and nothing reaches a customer or a supplier until they’ve signed it. Show them the sources and the rule that decided, or they’re approving blind.

Where to start

Pick one conflict your team settles by hand every week. Write down how it gets settled, and have the person who settles it approve what you wrote. Build the first tool on that, read-only, with a named person approving every draft, and build only as much of the foundation as that tool needs. The next tool reuses the connections and the rules instead of redoing them and then disagreeing with them.

Before anything connects, get four answers in writing from whoever builds it: where it runs, which AI models it uses, whether anything trains on your data, and what happens when you leave.

Then ask the PM you’d least want to lose: when the ERP and the paperwork disagree, which one do you believe, and how do you know? Write down what they say. That’s your first rule.

Questions people ask

Do we need a new ERP before AI?

Not for this. If you’re replacing the ERP anyway, write the rules down first, because they carry over to the new one.

Is an AI foundation the same as a data warehouse?

A data warehouse keeps copies of data for reporting, mostly looking back. A foundation holds where each job stands now and the rules for which source wins. A warehouse can be one of the systems a foundation reads from.

What happens when a rule turns out to be wrong?

The draft built on it is wrong, and the person who signs should catch it. Fix the rule, not just the draft, so the next one comes out right, and have whoever approved the rule approve the change.