It’s 6:15 on a Tuesday. The cut room lead wants to know how many cases of 2x2 chuck are still in cooler 2, what the yield came in at on last Thursday’s lot, and whether the fab spec for a customer’s short ribs changed after the last call. All three answers are sitting in the plant’s database. The problem is that only one person knows how to get them out, and that person is on the dock.
So the lead does what everyone does now: opens a chatbot, pastes in an export, and asks.
That’s the moment the plant’s price lists, customer names, and lot history leave the building. Not maliciously — just because the fastest tool at hand was a public one. Most meat processing software was never designed to answer questions in plain English, and the gap gets filled by whatever is easiest.
This post is about a better way to fill it. Specifically: why a food processor should run an AI model on its own hardware for anything that touches live records, what “RAG” and “tool-calling” actually mean in a plant, and where a frontier model like Claude or ChatGPT earns its keep alongside the local one. It’s the thinking behind PPS Intelligence, and it applies whether you run PPS or not.
A local model is exactly what it sounds like — an open-source model running on a machine in your office, not in someone else’s cloud. For a processor, that choice does three concrete things.
The data stays home. Customer contract pricing, supplier costs, yield by lot, who bought what last month — none of it leaves the plant to be answered. There’s no third-party terms-of-service question, no “is this being used for training” question, and no export sitting in a browser history. Your yield book is a trade secret. A wall protects it better than a promise does.
It works at floor speed, on floor terms. A question from the office or the packing station is answered on the local network. If the internet connection at the plant hiccups — and at a lot of plants, it does — the assistant is still there. Unplug it, it still answers. And there’s no per-question meter running, so a lead asking twenty small questions during a shift isn’t a cost conversation.
It can be given a controlled line into the system. Because the model is inside the plant, it can be handed a read-only line into live production data and a defined set of reports it’s allowed to run — governed by the same permissions your staff already have. That’s much harder to do safely when the model is outside the wall.
PPS Intelligence runs this way by default: open-source models on hardware inside your walls, with a pipeline behind them that handles the two jobs described next.
Retrieval-augmented generation (“RAG”) is a technical name for a simple idea: before the model answers, it looks things up.
Without retrieval, a model answers from what it absorbed in training — fine for general knowledge, useless for “what does this customer mean by 'the usual on the strips.'” With retrieval, the model is handed the relevant pages first, then writes its answer grounded in them and tells you which binder it came from.
In a plant, the pages worth retrieving are the ones that live in filing cabinets, shared drives, and one veteran’s head:
Two things make this work in practice. First, every answer is cited — the assistant points at the section it read, so when it’s wrong you can see why and fix the source. Second, your documents never become part of the model. The engine reads the material fresh each time and keeps nothing; update an SOP and it’s current that minute. That’s also what keeps the model upgradeable: swap in a better one next year and the knowledge base doesn’t move.
So “what’s the receiving limit for fresh poultry, and what does our plan say to do at 46°F?” is answered from the plant’s own HACCP plan, with the section cited for the auditor — not from a general idea of what a HACCP plan usually says.
This is the part that makes operations people nervous, and it should — if it’s done carelessly.
The careless version is “let the model write SQL.” A model that can write arbitrary queries against the plant’s database can also write the wrong one: the wrong date window, a join that double-counts, a filter that quietly drops a lot. The number comes back looking perfectly confident.
The disciplined version is a catalog of governed tools. The model never writes a raw query and never does arithmetic. When a question needs a number, it asks PPS itself to compute it — a yielded cost, a lot trace, a margin-by-customer report — then explains the result. The arithmetic is done by the same system that runs your operation today, and the assistant shows the exact tool it called, with an audit trail.
Three design decisions follow from that, and they’re worth stating as plainly as the sales page does:
That’s the difference between an assistant and a liability: a menu of governed operations, not a blank query window.
Today’s open-source models are serious analytical engines — a 30B-class model handles the everyday plant workload of lookups, reports, and SOP questions at a brisk pace, and the larger 120B-class models do multi-step investigations that cross-reference yields, costs, and history in one pass. For most of what a plant asks in a day, local is not a compromise.
But it’s worth being honest about the edges. The very largest frontier models are still stronger at long, unusual reasoning across many sources, and at polished writing — a customer-facing price-change notice, a supplier negotiation, a summary for the bank. The question isn’t local or frontier. It’s how to use both without giving up the reasons you went local in the first place.
The Model Context Protocol (MCP) is the open standard for connecting an AI model to real systems. Instead of every vendor building a one-off integration for every model, a system exposes its tools once, through MCP, and any MCP-capable model can use them — governed, logged, and approved the same way regardless of which model is asking.
That’s how PPS Intelligence talks to PPS in the first place: querying data, pulling documents, and running reports as MCP tools rather than screen-scraping. And it’s what makes the hybrid safe. A frontier model from Anthropic or OpenAI connects through the same tools, with the same read-only line and the same audit trail. It asks a question; the tool answers with a scoped, permissioned result; the raw records stay in the building.
The rule that makes it work: frontier routing is opt-in, per use, with your keys. Day to day stays private and local. The frontier is there when the right moment calls for it — never a silent default.
A practical way to think about it:
| The job | Who handles it | Why |
|---|---|---|
| “How many cases of chuck in cooler 2?” | Local | Live inventory, instant, stays home |
| “Which customers received product from lot 2607103?” | Local | A mock recall in a sentence; the data must not leave |
| “What does the sanitation SOP say about the saw?” — in Spanish | Local (RAG) | Answer comes from your own document, in your team’s language |
| Raw ribeyes came in at $2.41/lb — what’s our yielded cost? | Local | PPS computes the number; the model explains it |
| Month-end yield narrative for the owner | Frontier via MCP, opt-in | Reasoning over summarized reports; the summary can travel, the records don’t |
| Drafting price-change notices for 40 customers | Frontier via MCP, opt-in | Writing quality; pulls only the price-list deltas it needs |
| “Why did margin drop on pork in August?” | Local first; frontier as a second opinion | Local pulls the scoped reports and does the first pass |
The rule of thumb: if the answer requires touching raw records, it’s a local job. If it requires reasoning over a summary, a frontier model can help — and it should only ever see the summary.
Because the tools are the same regardless of the model, you can start wherever your plant is and move without rebuilding:
The knowledge base moves with you between them. The engine upgrades; your binders don’t get re-scanned.
Monday morning, a new receiving lead asks the assistant what the plan requires when fresh poultry logs at 46°F. It answers from your HACCP plan, cites the CCP section, and doesn’t need to be told twice.
Wednesday, raw ribeyes come in at a new price. Someone asks for the yielded cost and list price; PPS computes it at your yield standard, and the assistant notes two current price-list lines sitting below the number. Adjusting the list is a person’s call — with the change logged.
Friday, the owner wants a plain-English summary of the month’s margin by customer, with a note on what changed. The local model runs the report. If the owner wants a second opinion from a frontier model on the narrative, that’s one explicit click — and the model sees the ranked summary, not the customer database.
Nothing left the building that didn’t have to. Nobody wrote a query. Nobody guessed a number. And the person on the dock got to stay on the dock.
That’s how PPS Intelligence approaches AI: local by default, frontier when it counts, one system from the receiving dock to the invoice.
Bring us one binder and ten questions. Start the conversation →
Further reading: What meat processing software actually has to do — the seven things a plant system has to get right.
Tell us how your plant works — we'll build the demo around it.
Schedule a Demo →