To build the AI, we rebuilt the stack.
We set out to build manufacturing AI that learns from the plant. It needed a live record of the work. No such record existed, so we built the system that keeps one.
We didn’t set out to replace four systems. We set out to build AI that gets better every time a plant makes a decision.
We call it recursive manufacturing intelligence: the operation’s own decisions improve the system that runs the operation. Replacing the stack was the price of getting there.
The AI needed a sandbox
A model can’t learn a plant it can’t see. To get better, it has to watch the real work as it happens: the batch step, the material it consumed, the sample pulled, the result entered, the deviation raised, the release decision. Then it has to see what people did next.
That means a sandbox of live operational data. Not a nightly export. Not a quarterly data-lake refresh. The work, as it happens, in one place.
The work wasn’t in one place
In life sciences manufacturing, one batch crosses four systems.
- ERP receives the raw material lot.
- MES issues it to the batch.
- LIMS samples it and records the result.
- EQMS logs the deviation, by hand-typed ID, pointing back at the other three.
Four vendors. Four data models. One lot number, typed three times. Before a lot ships, Quality stitches the batch record, the bill of materials, the certificate of analysis and the disposition checklist together by hand.
To build our sandbox, we’d have had to rebuild all of that, live: four data models, the mappings between them, and the reconciliation people do in between. That’s why every manufacturing AI initiative starts with the same eighteen months of integration. Not because the models are weak. Because the data was never one thing.
Integration doesn’t fix it
We looked hard at the obvious path: connect the four systems and feed the model.
It fails in three ways.
The data arrives late. A sync copies facts after they happen. A model learning from yesterday’s copy can’t act on what’s happening now.
The data arrives wrong. A lot number typed differently in two systems is two lots to a machine. Train on that, and the model learns the integration’s mistakes.
The model can’t act. Seeing four systems is hard. Acting across four systems, with one approval gate and one audit trail, is close to impossible.
Integration platforms, data lakes and dashboards all accept the fragmentation and pay to hide it. We needed it gone.
So the sandbox became the system
If the work happens on one record, the data is clean by construction and live by default. There is nothing to sync, because nothing is copied.
So we built that record. Plan, execute, test and release run on one operational model. A batch, its materials, its samples, its results and its quality events each exist once, linked by what they are, not by which application owns them. A sample pulled on the floor is visible to QC the moment it exists. A deviation is raised on the step where it happened and already knows which lots it touches.
The AI came next. Cella, our agent, works on that same record. She reads the batch, proposes the work, and executes only after the responsible person approves. Every action lands in the same audit trail as a person’s.
Then the loop can close
Every signature, rejection and amendment is now on one record, live, with its full context. That record is what makes recursive intelligence possible.
The next step is shadow inference: a second model running beside Cella, inside the customer’s walls, predicting what she will need and scored against what actually happened. It gets no influence until it beats an accuracy bar the customer sets, and it ships as a versioned release under their change control, like everything else in GxP.
We’re building that loop with our design partners. More on it in the next post.
Your operation was never four systems. Ours isn’t either.