How the Monitoring Runtime keeps state

A permit is not a single frame

A hot-work permit says two things: combustible gas must stay at or below 10% LEL, and a fire watch must be present for the whole job.

At 13 seconds, a camera frame shows no fire watch. A gas monitor reads 10.4% LEL. A single-frame detector says “violation.” That is not enough for the person who has to review it.

The reviewer needs to know how long the condition lasted, whether the view was blocked, whether the gas reading went stale, and whether the situation recovered. Those are facts about time, and they are the difference between a momentary reading and an event that needs attention.

What a single label misses

“Fire watch not visible in this frame” and “fire watch absent for four minutes” are different facts. The first is an observation; the second is a condition that matters for review.

A detection system that only emits labels cannot tell a team how long a control was deviated, whether the camera was occluded, whether a required input went stale, or whether the situation recovered. It also cannot keep one continuous risk as one event: every new frame can look like a new alert.

Those questions have to be answered deterministically, not improvised by a model at answer time.

Why the Agent needs a separate Flow

The Agent is good at understanding “watch this hot-work job” and choosing the right tools. But that instruction is not a monitoring definition.

“A fire watch must be present, and LEL must stay at or below 10% for at least 30 seconds; otherwise open one event and ask for review” is a definition. It has to be written once, tested, versioned, and replayed—not reconstructed from the conversation each time.

We call that definition a Flow. It is not a general workflow engine. It is a reusable, testable, publishable statement of what to observe, how to judge it, how long it must hold, and what to emit when it does not.

Agent     — control loop: understand the goal, draft the Flow, bind devices, explain results
Flow      — frozen definition: what to observe, how to judge, how long, what to emit
Runtime   — data loop: observations -> state -> events -> action requests

A Flow separates the logic from the inputs. The Flow fixes the threshold, the duration, and the effect. A Task binding fixes the physical inputs: which camera, which gas monitor, which work context, and how often to sample.

• Swapping camera A for camera B is a new binding, not a new Flow.
• Changing the duration from 30 seconds to 60 seconds is a new Flow release.
• Changing “LEL ≤ 10%” to a different threshold is a new Flow release.

The Agent can draft the Flow and bind the devices, but a Flow becomes executable only after it is validated and published by an authorized person. After that, the Runtime runs the published definition. The model does not edit the threshold while a job is live.

How state is kept

The Runtime reduces a stream of observations with a short, fixed chain:

Input -> Observe -> Predicate -> Temporal -> Effect

• Input says where a value enters: the current frame, a gas measurement, or work context.
• Observe says what value is seen now. A model answers a current-frame question; a gas monitor produces a number.
• Predicate turns that value into matched, not matched, or unknown.
• Temporal decides whether the condition holds over time: instantly, or for a minimum duration.
• Effect opens, updates, or closes one event and creates an action request when needed.

The values the Runtime accepts are deliberately small: a boolean, a number, or a fixed enum. Free text can appear as explanation, but it does not drive the decision.

Here is the hot-work example as a saved timeline:

At 13 seconds the condition has held long enough, so one event opens. At 20 seconds the gas sample is missing, so the Runtime records input_error rather than guessing a safe value. At 21 seconds a fresh sample returns below threshold, so the same event closes as recovered. There is one event and one review request, not four.

Fail closed by design

Device offline is not unknown, and unknown is not met. The Runtime keeps those states separate on purpose.

• unknown means the input exists but cannot be judged—the camera is occluded or the model is not confident. It pauses the duration; it does not count as safe or as a violation.
• input_error means a required input is missing, stale, or invalid—for example, the gas sample exceeded its allowed gap. It is not rewritten into a safe reading.
• recovered is a real transition. It closes the same event instead of opening a new one.

Duplicate observations are ignored by ID, so a retried frame does not open a second event or send a second notification.

Replay is part of the mechanism

Because state is deterministic, the same observations always reduce to the same timeline, the same event, and the same review request. That makes the mechanism testable and inspectable.

Published replays on this site are saved synthetic samples. They show how duration, unknown time, and recovery accumulate; they are not a claim about any customer result.

What the Runtime does not decide

The Runtime reports met, deviated, unknown, and recovered. It does not issue a stop-work order, and it does not make a compliance determination. Publish and start remain explicit human actions, and stop, restart, exception, and closure belong to authorized people.

See the state

Watch a saved replay to inspect how one control moves from met to deviated to recovered, or ask us to evaluate one of your high-risk work scenarios.