Rules, zones and schedules: why SAiFI is configured to your site, not the other way round

Why generic detection rarely survives contact with a real site

A vision-AI safety system that ships with a fixed set of behaviours will, sooner or later, be wrong about your site. Industrial environments do not match generic profiles. A pedestrian crossing inside a manufacturing cell behaves differently from a pedestrian crossing on a dock apron. A forklift in a constrained underpass is a very different risk picture from a forklift in an open yard. The same camera, the same detection model and the same alert logic will be correct in one of those contexts and wrong in the other.

The way SAiFI deals with that is to keep the parts of the system that are site-specific configurable, and the parts that are general (model performance, latency, audit, hardening) consistent across every install. Four layers do most of that work: detection models, zones, rules and schedules. They are intentionally decoupled so a site can change one without touching the others.

Layer 1: detection models

The detection models are the layer that answers the question “what is in the frame?”. The SAiFI library covers the detection domains most commonly required in industrial settings, with further domains added as new validated weights are released through the platform.

A detection model on its own does not constitute a safety system. It produces a stream of detections with classes and confidence scores. What turns those detections into safety outcomes is the next three layers, applied over the top.

Layer 2: zones

A zone is a spatial region defined per camera, with a meaning attached to it. Zones let the system distinguish “detected something in the gangway” from “detected something in the pedestrian walkway”, even though the detection itself is the same object in the same frame.

Zones in SAiFI are typically used for things like:

• •Exclusion zones around machinery, presses, conveyors or robotic cells where pedestrians should never be present during operation.
• •Vehicle lanes and pedestrian walkways that share the same footprint but need different rules applied to them.
• •Loading-bay and dock apron areas where the safety logic depends on whether a vehicle is approaching, parked, or actively manoeuvring.
• •Mandatory-PPE zones where the system checks for the PPE relevant to that area at the entry boundary.
• •Counting and compliance zones used for evidence collection rather than for triggering actions in real time.

Because zones are defined per camera and per site, two facilities with the same model library can end up with very different operational profiles. That is the point: the site, not the supplier, decides where the lines are drawn.

Layer 3: rules

A rule is the layer that decides whether a detection in a zone matters, and if so, what should happen. Rules combine context that a raw detection cannot, such as the combination of objects present, the relationship between them, the direction of movement, dwell time, and the time of day.

Conceptually, a rule combines a triggering condition (a particular combination of detections in a particular zone, with optional context such as direction of movement, dwell time or the time of day) with one or more configured actions. A rule protecting a loading-bay crossing, for example, might combine a pedestrian-in-zone signal with an approaching-vehicle signal during shift hours, and on a positive match drive the bay’s traffic light to red, activate the relevant warning indicators, and write an event to the audit log. As a snippet, that same rule looks something like this:

The rules engine is where SAiFI becomes context-aware rather than motion-based. The difference matters operationally: a well-defined rule will not fire when a pedestrian is walking down a clear walkway with no vehicle nearby, which is exactly the kind of false-positive that erodes operator trust in older systems.

The action side of a rule is equally important. SAiFI rules can trigger:

• •Deterministic outputs to existing safety infrastructure (beacons, signs, gates, sirens, interlocks).
• •Audit log entries for evidence and ALARP defensibility.
• •Compliance counters for reporting (for example, PPE adherence over a shift, week or month).
• •Operator notifications, where the appropriate response is human attention rather than a deterministic interlock.

Layer 4: schedules

A schedule is how a rule is bounded in time. Most rules are either 24/7 or shift-aligned, and the right choice depends on what the rule is protecting against.

• •A pedestrian-in-exclusion-zone rule around a press during production hours is likely 24/7, since the press should never have a person inside it whether or not it is shift time.
• •A loading-bay traffic-control rule may only run during shift hours when vehicles are present.
• •A PPE compliance counter may run only during operational periods, to avoid skewing the metric with maintenance windows.
• •A model-improvement capture window runs only during defined, consented periods, and is never active in parallel with live operation on the same rule.

Schedules also give the site a clean way to evolve behaviour as operations change. A new shift pattern, a temporary maintenance period or a seasonal change in throughput can be reflected by editing schedules without touching the underlying rules and zones.

Commissioning versus everyday operation

On top of the four layers above, SAiFI keeps the things a technician needs during commissioning separate from the things the site needs in everyday operation. In practice that means a commissioning workflow where rules can be exercised individually, behaviour can be observed and outputs can be dry-run before the system is allowed to drive physical actions; and a steady state where rules run continuously according to their schedules, drive their configured actions, and write to the audit log, with the dashboard kept intentionally light for monitoring and fault-finding.

Worked example: a typical underpass crossing

To make the four layers concrete, here is how a real configuration looks for a common scenario: a height-constrained underpass where pedestrians, vehicles and material-handling equipment share the same footprint.

• •Models — the detection domains relevant to that mix of people and vehicles, drawn from the standard SAiFI library.
• •Zones — one zone covering the entry on each side of the underpass; one zone covering the underpass volume itself.
• •Rules — one rule combining pedestrian presence with an approaching vehicle (drives a beacon and audible warning on the relevant side); a separate compliance reporting rule that aggregates adherence over the shift.
• •Schedules — the safety-action rule runs 24/7; the compliance reporting rule mirrors the shift pattern.

A different site, with the same model library, may need three zones instead of two, a different action mix, and a different schedule. That is the point of the architecture: the same platform serves both sites without either of them inheriting the wrong defaults from the other.

Why this matters when you are evaluating a system

A configuration-driven safety system gives you three things a fixed-behaviour system cannot:

• ✓A way to reflect the site’s real operational pattern rather than a generic profile, which directly reduces false-positive rates and the warning fatigue that comes with them.
• ✓A defensible audit trail — the system’s behaviour is documented in its rules, zones and schedules, not buried in opaque vendor logic.
• ✓A way for the system to evolve with the site without re-procurement — new shift patterns, new layouts, new detection domains can be reflected by configuration changes, not code changes.

It also gives the engineering team commissioning the system a clean unit of work. Each rule, zone and schedule can be tested, signed off and version-controlled on its own, which is how serious safety integrators have always worked, and how vision-AI safety systems should work too.