AI hallucination in IoT stops being an abstract worry when a response reaches an actuator. A valve controller cannot interpret persuasive prose as permission to open. It needs a bounded command, current evidence and an independent policy that determines whether execution is allowed. Restricting the response format removes one failure class. It does not establish that the selected action is appropriate.

When the answer moves a relay

Consider a water inlet with a normally closed valve and a local leak detector. The proposed model classifies whether a requested fill should proceed. Its application output is allow, deny or review. A free-form answer such as “allow briefly unless the leak seems significant” introduces timing and judgment that the receiving controller has never defined. A parser that searches for the word allow could turn an explanation into a command.

The controller should accept only an explicit recognized value attached to the current request. A leak interlock overrides any allow result. In this illustrative system, invalid or missing advice leaves the inlet closed and raises a review event. That default follows from this particular hazard analysis; closing every valve is not a universal safe action for industrial equipment.

Keep model advice separate from actuator authority. The policy layer checks device mode, input freshness, interlocks and whether the requested transition is permitted. It also imposes duration and repetition limits. These checks need predictable execution even when the model process stalls, restarts or returns a result that looks perfectly well formed.

Why a generative LLM is risky in a control loop

A text generator can produce unrecognized options, extra explanation or ambiguous units. Formatting instructions reduce some errors but are not a parser contract. Even valid JSON can contain an unsupported action or an invented observation. Treat generated sensor claims as untrusted unless they can be tied to actual measurements supplied by the device.

Latency includes more than generation time. Remote calls add queuing, connection setup, network delay and retry behavior. Output length can also vary. A control deadline cannot depend on an average response duration. Assign a deadline, decide what happens when it expires and discard an answer that arrives after the corresponding control opportunity has passed.

Repeated requests can produce different suggestions, depending on the model and configuration. Even a repeatable model can change after a service update or input-pipeline revision. Store the versions needed to investigate a decision. Do not assume that replaying an old prompt against a current endpoint reproduces a deployed system's behavior.

Cost also varies with request frequency, payload size and service design. A troubleshooting conversation and a continuously sampled control decision have different economics. Count decisions during fault bursts and retries, not just normal operation. Generative systems can still help operators interpret logs or propose maintenance steps where a person reviews the answer before anything physical changes.

What 'no hallucination' can honestly mean

For a constrained decision interface, the useful promise is that accepted output belongs to a known set. If the allowed choices are allow, deny and review, an invented fourth choice must never reach the actuator policy. The producer can constrain generation, and the consumer must validate the received result independently. Network corruption, version mismatch and integration mistakes remain possible.

Bounded output is not correct output. The model can select allow for a leaking installation while satisfying every schema rule. It can assign a high score to a faulty interpretation, or misclassify an input outside its training conditions. Evaluate false accepts, false rejects and abstentions against the consequences of each outcome, rather than reporting only aggregate accuracy.

The same distinction applies to explanations. An explanation accompanying a valid class does not prove the class follows from the supplied evidence. Keep explanatory text outside executable fields. If the system retains explanations for investigation, make their role clear to operators and avoid turning them into a second undocumented command channel.

A useful acceptance contract therefore has separate structural and operational checks. Structure establishes field types, enumerations and permitted ranges. Operational checks establish whether evidence is recent, whether this device may take that action and whether an independent rule forbids it. Passing the first stage cannot bypass the second.

Decision models instead of text generators

A decision model can return a score, such as an anomaly score used for routing observations. Define the scale, direction and missing-value behavior; a score is not automatically a probability. A threshold becomes meaningful only after validation against the deployment conditions and the costs of the resulting action.

A choice interface returns an enumerated class. Keep label identities stable across versions and distinguish an unknown input from an ordinary negative class. A yes/no-with-probability interface returns a Boolean assessment and an associated probability estimate. Test calibration before treating that estimate as a reliable indication of uncertainty, particularly after a change in sensors or installation conditions.

The “System 1” label, borrowed as an analogy from Kahneman's distinction between fast and deliberative thinking, describes the intended interaction here: small decisions instead of generated discussion. It is not a technical guarantee about a model's architecture, reasoning or safety. Select the interface because it matches the application contract, not because the label suggests human cognition.

Several questions can be evaluated against the same captured state: is the reading unusual, does it need review, and should it be uploaded? Parallel evaluation can avoid serial service dependencies, but the outputs are not necessarily independent or mutually consistent. Attach a shared snapshot identifier and use deterministic policy to resolve incompatible recommendations.

Other ways to bound the output

A classic on-device classifier naturally exposes a finite label space. Its wrapper still needs to handle inference failures, non-finite scores and incompatible input dimensions. Verify preprocessing and label mappings as carefully as the model itself. An out-of-range input should trigger a defined response rather than being silently squeezed into a familiar category.

Structured output or constrained decoding can restrict a generator to a grammar or schema. Check the actual guarantees of the selected implementation, including refusal, truncation and transport errors. A syntactically valid response can contain a semantically wrong action. Enforce enumerations, required fields and range checks at the receiver, regardless of producer-side restrictions.

Schema validation plus a safe default is another necessary boundary. Reject unknown fields when they could hide integration drift, require a request identifier and impose a freshness limit. For the inlet example, malformed output, timeout or a failed integrity check leaves the valve closed. Record the reason so operators can distinguish denied permission from an unavailable decision service.

These techniques combine. A classifier can supply the ordinary path, a constrained generator can support reviewed exceptions, and the device can validate every received recommendation. The operational contract belongs with what makes an IoT device production ready: recovery and diagnostics must survive model failure.

Cloud decision API or local model

A cloud decision API can centralize model maintenance and combine wider context, but its response must traverse the network. A local model avoids that dependency for its own execution while consuming device memory, compute and update capacity. The placement criteria in part 1: on-device inference apply equally to a small constrained response.

When the service is unreachable, stop waiting at the application deadline. In the inlet example, retain the closed state, expose degraded status and queue a bounded diagnostic event. Do not replay an expired allow response after reconnection. Re-evaluate the current state with a new request identity before authorizing a new fill.

Compare total fleet costs using actual decision rates, payloads, connectivity and support needs. There is no defensible universal price advantage without those inputs. MQTT versus HTTP for connected devices addresses transport trade-offs; neither protocol makes an old decision safe simply because delivery eventually succeeds.

A hybrid pattern that fails safe

Use a local filter for cases that validation shows it handles reliably. Route ambiguous observations to the remote service only when the deadline permits. Define an acceptance threshold T from held-out deployment data and the cost of false acceptance. Below T, or when input-quality checks fail, hand authority to a deterministic conservative rule or a human operator.

For the inlet, a leak indication always blocks filling. An uncertain model result requests review while the valve remains closed. A confident result still passes through the interlock and freshness checks. If no operator is available, the documented default continues; uncertainty does not justify inventing a permission.

Monitor rejection rate, threshold crossings, stale responses and operator overrides by model version. A rising review rate may indicate environmental change or a broken sensor, not merely a need to lower T. Test those conditions during rollout, including contradictory outputs and loss of connectivity. The boundary earns trust when it behaves predictably while the model is wrong or absent.