The objection, in full
This is the strongest thing said about this product, and it arrives in roughly these words:
"The pitch is using generative AI to explain to supervisors what a hazard means rather than just flashing a red light. In industrial safety that is incredibly dangerous. Generative AI is prone to hallucination. If a gas line bursts, a supervisor needs a deterministic, instantaneous, pre-programmed shutoff protocol - not a multi-second delay while a language model streams an interpretation of the event."
Every technical premise there is right. Language models do hallucinate. A safety response does have to be deterministic, has to be immediate, and has to be pre-programmed. A multi-second wait on a model between a release and a response would be indefensible, and a system built that way should not be bought.
The conclusion does not describe this system, and the rest of this page is the evidence. But the objection is a good one to arrive at, and anyone who has arrived at it is asking the question a buyer of a safety system should ask first.
What actually happens when a gas line bursts
The order of operations is the whole answer, so here it is with nothing left out.
The node samples its channels. Each reading is evaluated against absolute limits in firmware. The result is a classification - SAFE, WARN, DANGER or CRITICAL - and that classification drives the on-device display and the siren. Only then does the node attempt to publish anything. Publishing is deliberately the last step in the loop, because it is the only one that can fail without consequence for detection.
So the sequence between a release and a response contains no network call and no model call. It contains a sample, a comparison against a pre-programmed limit, and an output. That is a deterministic, instantaneous, pre-programmed response, which is what the objection asks for, and it is what the firmware does.
The behavioural layer - the part that recognises a developing hazard from how channels are moving rather than how large they are - runs in parallel with the absolute-limit floor, and the risk level is the more severe of the two. That ordering matters: the behavioural layer can only ever make the system respond earlier than the floor would have. It cannot make it respond later.
Where the model is, and what it is denied
The deterministic layer is authoritative: the absolute-limit floor, the behavioural signature layer and the local alarm decide the safety response. The generative-AI layer is advisory only, and structurally so - it has no software interface, permission or code path by which it can invoke any actuator, and the system runs undegraded when it is switched off.
The word doing the work in that sentence is "structurally". This is not a policy, a prompt instruction, or a promise about how the model is asked to behave - any of which a model can violate by hallucinating. It is an absence of wiring. There is no function the model's output is passed to that can raise, lower or clear an alarm, command the rotating base, or change a threshold. The model returns text, and text is rendered.
That distinction is the one to press any vendor on, including this one. The question is not "how accurate is your model". It is "which actuator can your model reach, and what happens when it is wrong". A model that can reach nothing cannot cause an unsafe action regardless of what it outputs, and a model that can reach something is a safety component no matter how carefully it is prompted.
What a hallucination actually costs here
It is worth being concrete rather than reassuring, because "advisory" can be used to wave a real cost away.
If the model hallucinates, an operator sees a wrong sentence on a dashboard beside a correct alarm state. That is a genuine harm - a misleading explanation can send someone to the wrong part of the building, and a system that did it often would train people to ignore it. It is mitigated by always showing the explanation next to the channel readings and the deterministic classification that produced it, rather than in place of them, so the operator can see what actually moved and judge the sentence against it.
What it is not is a safety failure, because nothing downstream of the model acts on its output. The siren has already sounded on the evidence of the readings. The incident has already been opened on the deterministic classification. The explanation is the last thing to arrive and the only thing that changes.
Then why have it at all
Because a red light is not an instruction, and neither is "CRITICAL, channel three, 1,180 ppm, rising".
The person who has to act is usually on the floor, often at night, and frequently not the engineer who commissioned the system. What they need is which hazard, coming from roughly where, heading which way, and what to do in the next five minutes. Turning eleven channels of movement into that sentence is a communication problem, and it is the one thing in this stack a language model is genuinely better at than a rule.
So it is given that problem and no other. It reads the current readings, the classification the deterministic layer already made, and the investigation record, and it writes an account of them. It is cost-gated with a per-device cooldown, it falls back to deterministic threshold output whenever it is unavailable or unaffordable, and the fallback is not a degraded mode - it is the same safety behaviour with less prose attached.
How to check this rather than believe it
Three ways, in increasing order of effort, and none of them require taking our word for anything.
Read the architecture. The firmware control loop, the threshold evaluation logic and the risk state machine are documented publicly, including the order in which the local alarm is driven relative to the publish step. A system that worked the way the objection assumes would have to be documented differently.
Ask the question directly during an evaluation: which actuator can the model reach. The honest answer here is none, and it should be given in the form of the code path that does not exist rather than an assurance.
Switch it off. In a pilot, disable the advisory layer entirely and confirm that detection, classification, the local alarm, incident creation and the dashboard are unchanged. That is the test that settles the question, it takes an afternoon, and it is the one we would run first.
Where we agree with the critics
Several things in this area deserve more scepticism than they usually get, and it would be dishonest to answer this objection without saying so.
A generative model in a control loop is dangerous, and "human in the loop" is not a fix when the human is being asked to referee a confident-sounding paragraph during an emergency. A vendor who cannot tell you what their model is prevented from doing has probably not prevented it from doing anything. And "AI-powered" as a headline claim on a safety product is a warning sign rather than a feature - it describes the least important layer of any well-built system, and it is the layer that must not be trusted.
This site led with that phrase in one place, which is fair grounds for the objection, and it has been changed. The system was always built the other way round; the description had drifted from the architecture.
The questions people ask
The short forms, for anyone who wants the answer without the argument.
- Can the AI in Alfa HazardX trigger an alarm? — No. It has no software interface, permission or code path by which it can invoke any actuator, alarm driver or motor command. The alarm is raised by the deterministic layer on the field node, and the generative layer is not consulted before that happens.
- Can the AI suppress or delay an alarm? — No, and this is the more important half of the question. The model is invoked after the deterministic layer has already classified a reading and driven the local alarm. It cannot lower a risk level, cancel an incident or hold a siren. If the model returns nothing, returns late, or returns nonsense, the alarm state is exactly what it would have been without it.
- Does a language model sit between a gas release and the siren? — No. A reading is sampled, evaluated against absolute limits, classified, and the display and siren are driven - all on the node, before anything is published to a network. A gas line bursting is handled by the absolute-limit floor in the firmware. No network call and no model call is on that path.
- What happens when the AI hallucinates? — A wrong sentence appears on a dashboard next to a correct alarm state. That is a real cost and it is why the explanation is always shown alongside the underlying channel readings and the deterministic classification, rather than instead of them - the operator can always see what actually moved. It is not a safety failure, because nothing downstream of the model acts on its output.
- What happens if the AI is unavailable or switched off? — The system runs undegraded. Detection, classification, the local display, the siren, incident creation and the operator dashboard all continue. The plain-language explanation is what is missing, and the deterministic output it would have explained is still there.
- Then why use a generative model at all? — Because "CRITICAL on channel three" is not an instruction, and at three in the morning the person who has to act is on the floor rather than at a screen. Turning channel behaviour into a named cause and a recommended action is a communication problem, and a language model is genuinely good at communication problems. It is given that job and only that job.
- Is it safe to use AI in industrial safety systems at all? — It is safe where it advises and unsafe where it decides. The distinction is architectural rather than a matter of prompt quality or model choice: a model that cannot reach an actuator cannot cause an unsafe action no matter what it outputs. Any vendor claiming an AI-driven safety decision should be asked which actuator the model can reach and what happens when the model is wrong.
