The test issue 11 left open
The previous issue read the 2026 AI-in-manufacturing pitch from the floor and reached a two-part verdict: the cloud agentic platform that claims to reason over the machine is the part the numbers do not yet support, and the small task-specific model running locally on owned hardware is the part that works. It closed by naming the obvious next move. Put a language model exactly where the pitch insists it belongs, on the alert the reference stack already emits, and model what it adds rather than accept what a demo asserts.
That is a bounded test and this issue runs it on paper. The reference stack, built across the first ten issues, ingests a Sparkplug B stream, scores vibration with an Isolation Forest, gates the false alarm, and emits a flag: this asset, this timestamp, this anomaly score, above threshold, confirmed by the gate. Until now the flag ends at a dashboard and a human. The question is what a small local model does when it is handed that flag and the machine's manual, and the honest answer is that it does one thing well and a neighboring thing badly, and the two things look almost identical from the outside.
Two tasks the pitch keeps fused
The agentic pitch describes a single smooth motion: the system reads the alert, understands the machine, decides the fault, and opens the right work order. Taken apart on a real floor that motion is two tasks with a competence cliff between them.
The first task is document retrieval and reformatting. Given the alert and the maintenance manual, produce the work order that a maintenance planner would write from the same two inputs: name the asset, quote the applicable procedure, list the parts and tools, state the lockout and tagout steps, and stop. Nothing in that task requires understanding the machine. It requires finding the right section of a document and rendering it in the shape of a work order, which is what language models are built to do.
The second task is diagnosis. Given the vibration signature, decide what is physically wrong, the worn bearing versus the misalignment versus the imbalance, and it is a different act entirely. FactoryBench (Merzouki et al., arXiv:2605.07675) measured it directly and found the best current models scoring 17.7 percent on deciding a root cause from the signal, and its own conclusion is that retrieving a protocol document and interpreting sensor data are separate competencies these models conflate. The whole risk of wiring a model to the alert is that the loop invites it to slide from the first task into the second without anyone noticing the altitude change.
What the model does well: the first-line work order
Hand a small model the flag, the asset identifier, and the relevant pages of the manual, and ask only for the work order, and the output is genuinely useful. It reads back the asset and the anomaly, quotes the inspection procedure the manual specifies for that asset class, lists the consumable parts and the tools that procedure calls for, and reproduces the lockout and tagout sequence verbatim from the safety section. A maintenance planner receives a draft that is ninety percent typed for them and has to supply the priority, the scheduling, and the assignment, the judgments a human should own anyway.
This is the retrieval-augmented-generation shape, and published work on applying it to maintenance and equipment documentation reports the same result the FactoryBench split predicts: models retrieve and reformat procedure text reliably, and their quality degrades sharply the moment the answer requires inferring something the manual does not state. Kept strictly on the retrieval side, the task is one the 17.7-percent finding does not touch, because drafting the work order never asks the model to know why the machine is anomalous. It asks the model to write down what to do about an anomaly a different, smaller model already detected. The division of labor is the point: the Isolation Forest reads the signal, the language model reads the manual, and neither does the other's job.
Where the same loop crosses the line
The trouble is that the retrieval task and the diagnosis task share an input and a loop, and the slide from one to the other costs nothing to make and everything to catch. A work-order prompt that says "describe the likely cause and recommend the fix" has quietly moved the model from quoting the manual to diagnosing the machine, and the model will answer, fluently, because it always answers. The output will name a bearing fault with a plausible sentence of justification, and on the 17.7-percent evidence it will be wrong most of the time, and nothing in the phrasing will mark it as a guess.
That is the specific danger of putting a language model in the maintenance loop, and it is worse than no model at all in one respect. A blank cause field is obviously blank and a planner fills it with judgment. A confidently written wrong cause is indistinguishable in tone from a right one, so it gets filed, and the maintenance record accumulates plausible fiction that later analysis trusts. The model does not fail loudly by refusing. It fails quietly by answering a question it cannot answer in the same voice it uses for the question it can.
The latency and cost, modeled
The economics decide whether the retrieval task is worth wiring at all, and the same edge-inference benchmarks issue 11 cited answer it. A one-to-three-billion-parameter model runs at single-digit to low-double-digit tokens a second on edge hardware, roughly six tokens a second for a three-billion-parameter model on an NVIDIA Jetson Orin Nano and nine to thirteen for smaller one-to-1.5-billion-parameter models on the same board. A first-line work order is a few hundred tokens, so the model produces it in tens of seconds, in the background, in the interval after a gated flag when nothing needs the answer instantly because a human has not yet walked to the machine.
That throughput is exactly matched to the retrieval task and exactly disqualifying for the diagnosis task the model should not be doing anyway. Tens of seconds to draft paperwork a planner reads minutes later is fine. Tens of seconds is nowhere near a real-time agent reasoning in a control loop, which is the workload the agentic pitch implies and the hardware cannot serve. The cost follows the pattern the series has argued since issue 02: the model runs on an owned edge box whose hardware amortizes to a few dollars a month, and there is no per-query meter, so the marginal cost of the thousandth work order equals the cost of the first. The cloud agentic platform inverts that, cheap in the demo and metered in production, which is the third number that killed the business case last issue.
The one rule that keeps the model honest
The design that earns the model its place is a single rule enforced structurally rather than by instruction: the model may quote the manual and may never infer the cause. The pipeline implements the rule by controlling the inputs. The model receives the alert metadata and the relevant document sections and it does not receive the raw vibration signal, because without the signal it has nothing to hallucinate a diagnosis from, and the work-order prompt asks only for the procedure, the parts, and the safety steps, never for the cause or the recommendation.
Enforcing the boundary at the input, by withholding the signal, is stronger than enforcing it in the prompt, because a prompt that merely asks the model not to diagnose still hands it the temptation and the material. Give the model the document and not the signal, and the task it can do is the only task it can attempt. The cause field stays where it belongs, with the detector that produced the anomaly score and the human who reads it, and the model fills the part of the work order that is transcription, which is the part it is good at.
Where this leaves the bill, and the beat
The stack gains one component this issue, a small local model on the edge box drafting work orders from flags, and the modeled bill barely moves because the hardware is owned and the queries are unmetered. What the stack gains is a labor saving with a hard boundary drawn around it, the paperwork automated and the judgment left human, which is the only shape of AI in the maintenance loop the FactoryBench numbers actually license.
The beat continues from the floor. Issue 13 takes the next claim in the agentic pitch and models it the same way: predictive maintenance that forecasts the failure before the anomaly, the step past detection that vendors sell as solved, tested against what the published remaining-useful-life literature can and cannot deliver on the kind of signal and history the reference stack keeps, and against the cost of being wrong in each direction.
Method. Figures in this issue are modeled from published third-party benchmarks and vendor specifications, with sources linked inline. Where a number describes the reference stack, it is a modeled figure for that configuration, not a measurement of a production deployment.