Technology

The technology behind Alfa HazardX

Alfa HazardX rests on four ideas. Fuse different sensor types, so a hazard that spans several channels becomes visible. Decide risk on the device itself, so the alarm never depends on a network or a model. Forecast the time left before a threshold breaks, so the warning arrives first. And use a generative model only to explain decisions the deterministic layer has already made.

Alfa HazardX is a deployable V2 field node. It is not a certified industrial safety product, and nothing on this page should be read as a certification claim.

Alfa HazardX dual-layer hazard analysis: an authoritative deterministic layer running thresholds, trend and baseline deviation on every reading, alongside a gated advisory AI layer that produces severity, cause and recommended action but cannot act.
The central architectural decision, in one diagram. The deterministic layer decides and is authoritative; the generative layer explains and is advisory. Nothing the AI does can change what the alarm does.

Sensor fusion, not eleven alarms

A node carries four gas channels, flame, vibration, sound and ambient climate sensing. Read independently, each is a mediocre detector with its own failure modes: the gas elements drift, vibration sensors trip on a passing forklift, sound sensors hear everything.

Read together, they become considerably better than the sum. Rising temperature alone is weak evidence. Rising temperature correlated with a change in vibration signature and a change in sound is a machine failing, and that correlation is the kind of hazard no single-channel detector on the wall will ever report.

Deterministic risk classification

Every reading is evaluated against per-sensor thresholds and classified SAFE, WARN, DANGER or CRITICAL. The evaluation runs on the node controller before the reading is published, and it is what drives the display and the buzzer.

Determinism here is a feature, not a limitation. The same input produces the same classification every time, the logic can be read in the source, and an alarm can be explained after the fact by pointing at a number and a constant. None of that is true of a model.

Prediction: where a channel is heading

Threshold detection answers 'is this bad now'. Prediction answers 'when will this be bad', which is the more useful question if you intend to act rather than to record.

Linear regression over a recent window gives each channel a trend. Projecting that trend at the threshold yields a time-to-threshold estimate. Separately, deviation from the node's own captured baseline is expressed as a z-score, so 'unusual for this machine, in this room' becomes a number rather than an opinion. Both are arithmetic over stored readings - auditable, reproducible, and cheap enough to run continuously.

Generative AI, deliberately constrained

Alfa HazardX AI analysis gating: a threshold breach checked against a per-device cooldown before the model is invoked, with a deterministic threshold-only fallback when the model is unavailable.
Three gates before a model is called: severity, cooldown, availability. The fallback path is deterministic output, never a delay.

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.

A language model is an excellent explainer and a poor safety authority. It can be unreachable. It costs money per invocation. It can be fluently, confidently wrong. Any one of those properties disqualifies it from deciding whether a buzzer sounds.

The model is gated three ways. By severity, so it is only asked about readings that already matter. By a per-device cooldown, so a node sitting just over a threshold cannot trigger a call on every reading. And by availability: if no key is set or the service cannot be reached, thresholds alone still run. What comes back is a severity, a plain-language cause and a recommended action - written for the supervisor on shift, not the engineer offsite.

The stack

Three layers, and the order matters. The field node carries the sensing set and the risk engine together, so classification and the local alarm happen on the device with nothing else in the path. The platform layer holds history, multi-node correlation and the behaviour-signature library - everything that needs more context than one node can keep. The AI layer sits above both and explains, never decides.

The platform is a typed web application over a relational store with row-level isolation between plants, pushed rather than polled so the dashboard moves when the plant does. Compute runs in the same region as the data, because a dashboard that makes several sequential queries pays the round trip several times and geography turned out to matter more than code.

Offline by design

The node is the safety-critical component, so it is deliberately the one with the fewest dependencies. Detection, classification, display and buzzer are entirely local. A network outage costs dashboard visibility and AI explanation; readings buffer and resend when the link returns.

This is the inverse of most connected safety products, where the cloud is the brain and the device is a sensor. Here the cloud is where analysis, history and coordination live - valuable, and never load-bearing for an alarm.