You draw it once, and it happens every time, also at four in the morning

A rule is a sentence: if a lorry enters the dock outside working hours, tell the shift supervisor, mark the recording and open an incident. Until now that sentence had to be written in code. Here you draw it: one block per part of the sentence, joined with cables. There are 74 blocks and 508 connectors, and every connector knows what it can accept, so joining two things that do not fit is impossible and the editor names both. A block can be muted, bypassed, grouped, or packaged whole for reuse in another flow. And if any value is impossible, it will not let you save: it points at it and says which.

Not everyone wants a canvas, so there are three ways in. The first is the gallery of 23 recipes: zone intrusion, directional line counting, occupancy by time band, plate reading, a person without protective equipment, blurring faces and plates. Pick one, fill in between two and seven fields by drawing on the live video, and it is running on day one, without having built anything. The second is six questions — what, where, when, how much, how and then — with a sentence at the top that writes itself from what you have answered so far. The third is the full canvas, no limits, for whoever builds the site. And here is the point: it is the same automation, and it moves up and down without losing your work. Not every recipe is available on every server; when one is not, the gallery says why.

Schedules are where you can tell whether the people who built this have ever stood on a site. You declare one once, with its name and colour, and reuse it across every camera and every flow. It takes time bands, weekdays, months, days of the month, and the first or last Monday of each month, which is exactly how maintenance days get written down. And it takes solar anchors: a rule that starts thirty minutes before dusk and ends at dawn works in January and in July with nobody touching it again. The same night schedule placed on cameras in three countries opens and closes at each local time, with no duplicate templates. Exception dates cover public holidays, shutdowns and plant stoppages. And there is a safety rule worth saying out loud: if the schedule cannot be evaluated, nothing fires. Never just in case.

Anyone who automates something fears the same thing: that it fires by itself at three in the morning and wakes up half the staff. That is why you test first. The simulator runs the flow against the camera latest real event and answers straight — on Tuesday at 14:32 this would indeed have fired, and these are the actions that would have run — but it sends nothing. The editor also puts an eye on every cable: click it and you see what really comes out there, with the image and the table of what passes the filter and what does not. Then you can publish in muted mode, the flow running and computing but executing no action at all, so you validate without bothering anybody; or pause it for an hour, four hours, a day, or until any date you name. On publishing, the confirmation tells you how many cameras it will switch on for, and which. And if a flow fails several times in a row, it switches itself off and leaves the reason in writing.

Everything that runs gets written down, and not only when it fails. Each run stores when it was triggered, when it started, when it finished, how long it waited in the queue, which camera it ran on, whether the condition held, how many actions ran and, when something broke, at which precise stage: the camera, the model, the condition or the action. That is the difference from a system that only says fine or failed: there are eleven possible outcomes, and five of them are different ways of having done nothing — the schedule was closed, another run was already going, the flow was stopped, the anti-bounce discarded it, or a pre-check failed — plus a sixth for when the per-minute cap throttled it. The activity panel shows the last twenty-four hours with the skip rate and the list of flows that are losing triggers, which is exactly the fault nobody sees. And when the history grows and has to be cleaned, the purge forces a preview: it states how many runs, how many incidents and how many measurements will go and how much space will be freed, and if what is there at that moment does not match what it showed, it refuses to delete.

A published automation is part of how the site runs, so it is governed as such. Read and write permissions are separate: someone without write access opens the editor read-only, sees the whole flow and can change nothing. An administrator also decides which blocks each role may use, and there is a detail here that pays off on a large site: a blocked block still shows in grey, so people know it exists and can ask for it, and the automations already published that use it do not break. Every published version is kept, renamed, restored as a draft and compared with another: the comparator shows on the drawing itself what was added, what was removed and what was changed, cables included. And there are no configuration files anyone has to edit by logging into the server: everything changes from the browser, live.