You have watched an LLM state something false with total confidence. So have we. That's why the machine-answer path in PulseMQ is not “ask a chatbot about a document.” It is three specific rules, enforced at the code level, that keep industrial AI honest on the plant floor.
Every plant manager evaluating industrial AI has the same question: “How do I know it's not making stuff up?” That question is not paranoia. It's professionally cautious.
Large language models are extraordinary at fluent, confident, plausible-sounding output. That's their job. The problem is that fluent, confident, plausible-sounding output is exactly what you get whether the underlying facts are correct or not. In a marketing tool that's an annoyance. In a plant that has to keep making product, it's a hazard.
PulseMQ is an AI system for manufacturing. It runs on Claude (Anthropic) on AWS. It answers plain-English questions about live equipment. And the way we make it safe to deploy on a running production line is The Evidence Contract — three rules that are enforced in the code, not just in the marketing.
If a tag wasn't polled from the controller in this session, PulseMQ won't invent one. No hallucinated setpoints. No made-up cycle counts. No plausible-but-wrong sensor readings.
When an operator asks “what's Zone 1 doing right now?” the assistant does not go find that value in a document or a training set. It goes to the poll loop that reads the controller and asks for the freshest value. If the poll loop hasn't seen that tag, the assistant tells you so — it does not fabricate.
Operator asks: “What's the melt temperature on Extruder 2?”
AlarmIQ checks the live poll cache: Ext2_MeltTemp was last read 340 ms ago at 218°C. Answer: “218°C, read 340 ms ago.”
If that tag is not being polled, the answer is “I don't currently poll Ext2_MeltTemp. Do you want to add it to the poll list?” — not a guess.
Alarms, cycle legs, permissives, drift flags — every claim the assistant makes is stamped with the tag it came from, the moment it was read, and the source controller. Auditable. Replayable. Defensible when someone from Corporate asks “how did we decide to stop the line?”
This matters for two reasons. First, an engineer who wants to verify an answer can trace it back to the raw controller data in one click. Second, when the answer is used to justify an action — reset an alarm, adjust a setpoint, dispatch maintenance — the evidence chain is part of the audit log automatically. You don't have to remember to save it.
AlarmIQ says: “Line 5 is waiting on DI_Air_Pressure_OK = FALSE.”
Click the answer. You see: the exact rung that reads the input, the input's live state (FALSE), the timer that would clear the permissive if pressure returned, and the last 30 seconds of the input's history. Nothing invented. Everything traceable.
Machine Intelligence™ watches every leg of every cycle — forward stroke, return, total, dwell — across tens of thousands of runs. “Normal” is a measured range, not a predicted one. Drift detection is deterministic: the shuttle return leg averaged 4.2 seconds for the last 8,400 cycles; this one took 6.8 seconds. That's an observation, not an inference.
Predictive models can be wrong in ways that are hard to audit. A learned range can't. If PulseMQ says a mechanism is drifting, you can pull the last 8,400 cycles of data and see for yourself. If you disagree, the disagreement is about the data, not about a hidden model's confidence.
Machine Intelligence flags: “Pusher cylinder return leg drifting — current mean 5.1s, learned normal 4.6s ± 0.3s over 12,340 cycles.”
You can query the underlying dataset. You can dispute the flag. You can adjust the threshold. What you can't get is a black-box “the AI thinks something's wrong” without evidence.
The manufacturing AI market is filled with tools that generate plausible-sounding output about equipment those tools have never actually connected to. Vendors demo on synthetic data. Their “insights” are educated guesses dressed up as engineering conclusions.
That approach is fine when the cost of a wrong answer is low. It is not fine when the wrong answer causes an operator to reset an alarm that shouldn't be reset, or a maintenance tech to replace a part that wasn't broken, or a line to stop because a “drift warning” was actually noise.
The failure mode nobody talks about: an AI system that's right 95% of the time and wrong the other 5% in ways that look identical. If you can't tell the difference between a good answer and a hallucination, the “95%” is worthless — every answer needs to be verified anyway, so you might as well have skipped the AI.
The Evidence Contract fixes this at the design level. Every answer PulseMQ produces has a chain back to the raw controller data. If the chain can't be built, the answer isn't produced. You never see a confidently-wrong answer, because there's no code path that produces one.
Most AI “copilots” for manufacturing are wrappers around a language model that has been fed your documentation. That's not the same thing as an AI that reads your live equipment. Here's the difference.
“We promise our AI won't hallucinate” is a marketing claim. The Evidence Contract is a system property. Here's what makes it enforceable rather than aspirational:
The point isn't that our AI “doesn't lie.” The point is that the code paths that would allow it to lie don't exist.
The fastest way to evaluate the Evidence Contract is not to read about it. Give us a program export from one of your lines, and let us come back with your machine answering questions about itself — with the evidence chain attached to every answer.
Book a Pilot Get the Sales GuideDoes PulseMQ use an LLM?
Yes — for language understanding and response generation. But the language model never invents plant data. Every value it reports is fetched live from your PLC in the current session. If a tag wasn't read, PulseMQ won't reference it. If a controller is offline, the assistant says so instead of making something up.
How do I know an AI answer isn't hallucinated?
Every answer PulseMQ produces carries the tags it was built from, the moment they were read, and the source controller. Alarms link to the exact rung. Cycle drift links to the leg it was measured on. If the evidence chain can't be produced, the answer is not produced.
What happens if the PLC is offline?
PulseMQ tells you the controller is offline and cannot answer questions that depend on live state. It will not fall back to cached values or the last known reading. This is deliberate — a stale answer is worse than no answer on the plant floor.
How are “normal” ranges determined?
Machine Intelligence™ watches every leg of every cycle across tens of thousands of runs. Normal is a measured range, not a predicted one. Drift detection is deterministic: “the shuttle return leg averaged 4.2s for the last 8,400 cycles; this one took 6.8s.”