This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

The Problem

In Industrial IoT systems, we work with deterministic logic. A sensor gives a specific value, and hardware has physical limits that cannot be changed. Recently, many developers are using LLMs (like Gemma 4) to manage workflow logic and decision making.

However, there is a big problem. The nature of probabilistic AI and deterministic hardware is different. An LLM is a probabilistic generator that predicts the next text. LLM is not a control system for hardware. If an AI agent sends a command that ignores physical constraints, for example, trying to move a robot arm when battery is very low, the hardware will try to do it. This can cause expensive equipment failure.

Thus, we need a governance layer between the AI and the actual hardware execution.

The Solution

I developed SilverAi, a lightweight Python middleware that works like a filter for our hardware. Its job is to check agent requests against the current system state before any command is sent to the driver.

SilverAi does not "reason" or think about the command. It only checks if the command violates hard-coded safety rules.

For implementation, I use Python decorators to define the safety constraints. These rules are checked before the function body runs.

@guard(
    rules=[
        MaxLoad(100.0),
        rules.BatteryMin(20),
        StateGate("motor_temp", max_value=80.0),
    ]
)
def _execute_guarded(...) -> Dict[str, Any]:
    ...

By separating the AI agent intent from the validation layer, we do not need the LLMs to be "smart" about safety. This is because, with SilverAi, the model can propose actions, but it cannot override the rules.

SilverAi also comes with a dry-run mode. This lets developers simulate hardware problems (like thermal overload or connection loss) without needing real physical machines.

Finally, in SilverAi, when a request is blocked, the reason is logged. This creates an audit trail to understand why an operation was stopped, which is very important for troubleshooting IoT systems.

Figure 1: The moment the SilverAi guardrail saves the hardware. Arize Phoenix trace showing the guard_check intercepting and blocking a hazardous AI command that exceeded the 100.0 maximum belt load limit.

Demo

Code

• SilverAi Demo Code

How I Used Gemma 4

For this project, I chose the Gemma 4 E4B model.

The system needed to run on local industrial hardware without a dependency on a cloud-based GPU cluster. In a warehouse or EOC environment, we cannot rely on low-latency internet or massive server-grade compute just to parse a telemetry string.

The E4B model was the right fit because it provides the necessary reasoning capability for high-level workflow parsing while maintaining a local footprint that does not choke a standard industrial workstation. It is the correct tool for a system where the "intelligence" is secondary to the deterministic safety layer it sits behind.

As we know, industrial systems are flooded with unstructured data—operator log notes, legacy serial strings, and unformatted maintenance overrides. Traditional automation requires rigid, hardcoded string parsing (like Regex), which breaks the moment an operator types a command differently.

Gemma 4 unlocked semantic translation of unstructured intent.

When an operator inputs a natural language command—such as "Divert package PKG-400 to Aisle 3 because the main sorter is jamming", Gemma 4 successfully parses the messy string, identifies the operational intent, and structures it into a JSON payload ({"route": "Aisle 3", "load": 5.0}).

This is where the model's intelligence becomes a liability. Gemma 4 is smart enough to interpret the human operator's intent, but because it is a probabilistic model, it is completely oblivious to real-time physical telemetry. It does not know that while it successfully generated the routing plan, a hardware sensor just reported a thermal spike on the Aisle 3 motor.

That is exactly why this architecture is a two-tier system: Gemma 4 unlocks the flexibility to understand unstructured human input, while the SilverAi middleware provides the determinism to block that input the millisecond it violates a physical invariant.

Wrap-up

If an automation system depends on the LLM being "smart enough" to be safe, the system is already broken. Our goal wtih SilverAi is not to make AI safe, but to build a safety layer that ignores AI suggestions when they violate the physical laws of the machine.