Series: Building the AI Foundation — Part 3b of 3a/3b. Part 1: Stop Picking AI Tools laid out the seven-layer architecture. Part 2: The Context Layer covered how AI reaches your systems. Part 3a covered layer six for developers. This piece covers the same layer for manufacturing and ERP operations. Part 4 will cover the control plane.
Part 3a covered the system-of-record layer from the developer side: one gate, no exceptions, and twenty years of tooling built to enforce it. This is the other half, and I’m writing it from the floor, not the office. The planner whose ERP now has an AI copilot suggesting reorder points. The quality engineer whose disposition assistant drafts a nonconformance resolution. The process engineer whose routing just got updated by an agent that read a work instruction and decided it knew better. All of them are changing systems of record every day, and almost none of them have a gate.
I’m focusing this on manufacturing and ERP specifically, since that’s where I’ve spent 25 years and where I think the stakes are different from a typical back-office example. A miscategorized sales lead is embarrassing. A wrong substitute component on a bill of materials can ship a defective unit, and in some industries, that’s not a business problem, it’s a regulatory one.
What’s actually happening
An AI copilot inside the ERP updates a bill of materials, swapping a component for an approved substitute, based on a supply shortage it read about in a planning note. A quality assistant closes out a nonconformance disposition because the defect looked similar to one it had closed before. A planning copilot adjusts safety stock on a critical part because demand looked flat for two weeks. A routing gets a new standard time because an agent recalculated it from recent cycle data. Genie, or a similar tool, answers an OEE or yield question by writing its own query against the plant’s data.
In each case, something that used to require an engineer’s or a planner’s deliberate judgment now happens because an AI decided it should. In most plants I’ve seen, nothing stands between that decision and it becoming the official version of the record.
What “system of record” means on the floor
A system of record is wherever an organization keeps the trusted version of something, plus the process that decides what earns that status. On the floor, that’s the item master, the bill of materials, the routing, the production order, and the quality notification, all living inside the ERP, with a process that’s supposed to govern changes to each one. Most of those processes were built assuming a person made every change. None of them were built assuming an AI agent might.
If your plant doesn’t have that process updated for AI involvement, sit with what that likely means. An agent has probably already touched a BOM, a routing, or a quality disposition, and nobody flagged it as different from a change an engineer made by hand. It won’t look like a safety incident. Nothing shuts down. A substitute part gets used that engineering never formally approved, or a quality hold gets released based on a disposition nobody double-checked, and you don’t find out until an audit, a customer complaint, or worse.
Why none of this works without governed data
Every check I describe below assumes something underneath it: that the data feeding the check is itself reliable. A BOM reconciliation check only works if engineering’s approved revision is the one actually sitting in the system. A routing change check only means something if the standard times it’s comparing against reflect current reality, not a routing that was updated informally six months ago and never synced back. A quality rule check depends on a defect taxonomy that means the same thing in every plant, not one that’s been redefined locally three different ways.
This part is easy to skip, because it doesn’t look like a system-of-record problem. It looks like a master-data problem, which sounds smaller and further upstream. It isn’t smaller. Governed data, meaning data with clear ownership, a known schema, defined lineage, and accountable stewardship, is the precondition for everything else in this piece. I’ve watched a single item master discrepancy between two plants on the same ERP instance cause a planning error that took weeks to trace back to its source. An AI agent making decisions on top of that same discrepancy doesn’t fix the problem. It just makes the wrong decision faster, and with more apparent confidence.
This is also where Part 2 connects directly to this layer. The curated layer with shared definitions that The Context Layer described sitting in front of multiple ERPs is what makes a downstream BOM or routing reconciliation check meaningful in the first place. Skip that layer, and every check described here validates a change against data nobody has actually agreed on, plant to plant.
Developers get a warning when this goes wrong, since a bad schema tends to break a build loudly, as Part 3a covers. A plant doesn’t get that warning. A BOM that means something different in two plants doesn’t break anything visibly. It just makes every downstream production order, and every automated check built on top of it, quietly wrong at the same time.
The gate this layer needs
A change to a BOM, a routing, or a quality disposition should move through something structurally similar to a pull request: a proposed edit, a check against whatever rules govern that record, review by whoever owns it, and only then adoption as the official version. Developers have tooling for every step of that, covered in Part 3a. Most ERPs have the last step, a save or a transaction code that commits the change, and not much enforcing what comes before it when an AI made the proposal.
An engineering change control process can stand in for branch protection. A BOM or routing edit shouldn’t go live until it clears the same formal review a human-initiated change would require, whatever tool proposed it.
Quality and engineering rules can stand in for automated tests. Does this substitute component appear on the approved list for this item. Does this routing change fall within the standard-time variance engineering allows. Does this disposition match a defect code that’s actually been delegated for automatic resolution.
A named owner can stand in for CODEOWNERS. A BOM change routes to engineering. A quality disposition routes to the quality engineer of record. A safety stock change routes to the planner who owns that part family.
The merge-rights rule from Part 1 applies here too. An agent can propose a change to any of these. A person decides whether it becomes official.
Traceability
Most ERPs already keep change documents, so you can usually see that a BOM or a routing changed and when. What they rarely tell you is whether an AI copilot proposed that change on its own initiative, what it based the change on, or whether anyone with the right authority reviewed it before it went live. Quality systems are often worse, especially once an AI assistant is drafting disposition language directly into a record with no trail that distinguishes it from an engineer’s own notes. Genie sharpens the same problem for plant analytics, since someone can generate an OEE or yield number through a conversational query with no artifact resembling a change document behind it. Even where a record of change exists, a record of AI involvement usually doesn’t.
Review at scale, without a queue
Developers have a capacity problem, covered in Part 3a: AI-assisted pull request volume outpacing human review capacity. Manufacturing has a different problem, and it isn’t about volume. Most plants never had a review role for this kind of change in the first place, whether the change came from a person or an AI. There’s no queue to overwhelm, because nobody built a queue. A planner might notice a safety stock level looks off. A stockout or a quality escape is often the first time anyone looks closely enough to ask where a number actually came from.
Where this connects back to The Context Layer
Part 2’s registry logs what an agent read: which system, which fields, under whose identity. This piece logs what changed afterward. Put those two together and something useful happens. An agent that queried inventory data across two plants through Genie, then in the same session proposed a BOM substitution, produces a signal that only makes sense once someone’s looking at both logs side by side.
Failure patterns worth naming
Most of what follows traces back to the same root cause: a gate that looked correct, running on data nobody had actually governed.
An AI copilot substitutes a component on a BOM based on a supply note, and the substitute was never qualified for that application, which nobody catches until a field failure traces back to it.
A quality assistant closes a disposition that reads fine but releases a hold engineering never actually signed off on, caught only when an audit asks for the paper trail.
A planning copilot drops safety stock on a part because recent demand looked flat, and a single large order turns it into a stockout that stops a line.
Someone asks Genie for a yield number, gets an answer built on a different definition than the one engineering certifies against, and only finds out when the plant’s own report disagrees with it in a review meeting.
What building this taught me
The developer side of this layer, covered in Part 3a, was the easy part to specify when I put together the IT org’s AI adoption plan. GitHub rulesets, required reviews, CODEOWNERS on critical paths, all of it maps onto tooling that’s existed for years.
The harder conversation, in every manufacturing environment I’ve worked in, was never about the ERP’s change-control features. Those exist. It was about whether anyone had updated the assumption underneath them, that a human initiated the change being controlled. An AI agent proposing a BOM substitution doesn’t trip any of the alarms built for a careless engineer, because it isn’t careless. It’s confident, fast, and occasionally wrong in a way a human reviewer would have caught immediately if they’d known to look.
Where this leaves you
Whether the change is a BOM, a routing, or a quality disposition, the discipline should be the same one Part 3a described for code: one governed path, resting on governed data, applied identically regardless of which AI proposed the change. Most plants are operating without that path today, and I’d guess yours is too, unless someone’s specifically gone looking. That’s the bigger risk sitting on most shop floors right now, not because the technology is unsafe, but because nobody’s built the gate for it yet.
Next in this series: the control plane, the layer that ties together what The Context Layer logs about access and what Parts 3a and 3b log about change, into one picture instead of separate logs nobody cross-references.