How it works
From a stream you already publish to an action someone takes.
This page is the long version: what happens during onboarding, what the platform does to every frame, where it can run, and what a pilot is measured against. It is written for the people who have to make it work, not just approve it.
Onboarding
Five stages from first call to a live agent.
A pilot covers one site and one or two agents. Stages three and four are the ones that decide whether the agent is any good, and they are the ones most vendors skip.
-
1
Scope the workflow
We pick one recurring problem that costs the site time, and write down what a good outcome looks like in operational terms: fewer blocked walkway minutes, faster dock turnaround, an audit trail for blocked exits. If the problem cannot be stated as a condition a camera can observe, it is the wrong first agent.
You bring: the operational owner of the zone, and the last two or three examples of the problem as you experienced them.
-
2
Onboard the cameras
We confirm which cameras see the zone, read their streams, and check the view is actually usable: is the walkway visible end to end, is the lighting stable, is the lens pointed where the drawings say it is. Cameras that need repositioning get flagged before anything is configured, because no amount of tuning fixes a lens pointing at a wall.
You bring: stream addresses and credentials, plus network access policy for the runtime.
-
3
Configure the agent and its rules
Zones are drawn on the scene, the rule is written as conditions, thresholds, schedules and escalation, and the actions are wired to the destination systems. This is a working session with the person who owns the zone, not a handover of a configuration form.
You bring: the escalation path, the operating hours, and any planned exceptions.
-
4
Run it in shadow mode
The agent observes and writes events without notifying anyone. At the end of the period we review every event it produced against your own footage and sort them into real, marginal and noise. Thresholds move, conditions get narrowed, and the deduplication window is set from what the site actually does rather than what we assumed.
You bring: thirty minutes with someone who knows the footage, once a week.
-
5
Switch on live alerting
Alerts start flowing to named people. The agent keeps its full event record, so the first weeks after go-live are still a tuning period and the team can see exactly what changed when a threshold moved. From here, additional agents reuse the cameras already onboarded.
You bring: nothing new. The agent runs on the configuration agreed in stage three.
Under the hood
What actually happens to one frame.
Worth reading if you are the person who has to explain this to a security review. Nothing here is proprietary magic; it is a pipeline with defined inputs and outputs.
The runtime holds an open stream per camera and decodes frames at the rate the busiest assigned agent needs — commonly a handful of frames per second rather than the camera's full frame rate. Frames are not written to disk at this stage.
Each decoded frame goes through detection, which produces a list of objects with a class and a bounding box. The tracker then matches those boxes against objects it saw in the previous frames, so each object carries an identity and a duration. This is the step that turns "there is a forklift in this picture" into "this forklift has been in the walkway for four seconds".
Zone geometry is resolved against the tracked object's position on the ground plane rather than its position on screen, so a zone drawn at the far end of a camera's view covers the floor area it appears to cover. Each agent then evaluates its own rules against the tracked objects that fall inside its zones.
A rule match produces an event. The event carries the zone, the class, the duration, the timestamp, the camera and the severity. If the rule's action set includes a clip, the runtime writes the short window around the event and attaches it. Continuous video is never retained by the platform.
Privacy zones run before inference, not after
An excluded area is removed from the frame before detection sees it. There is no stage at which the model receives those pixels, which is a different guarantee from blurring an area on output.
- Decode Frames pulled from RTSP stream 5 frames in the last second
- Exclude Privacy zones removed from frame 2 zones · welfare entrance, neighbouring yard
- Detect Objects resolved with class and box 6 people · 1 vehicle · 2 trailers
- Track Objects matched across frames 7 identities held, 1 new
- Evaluate Agent rules run against tracked objects 1 match · vehicle in walkway · 4s
- Act Event written, actions dispatched Alert sent · clip attached · 12s
Illustrative interface with sample data.
Where it runs
Three deployment topologies. Pick one per site.
The choice is usually made by the network and security team, and it is per site. A group can run one plant on an edge appliance and another in a cloud tenancy without changing the agent configuration.
| Consideration | Edge appliance | Your private cloud | Managed tenancy |
|---|---|---|---|
| Where frames are processed | On hardware inside the site network. | In a tenancy your team controls. | In a tenancy operated by VisaRoxy. |
| Does video leave the site | No. Streams stay on the local network. | Yes, into your own environment. | Yes, into a tenancy we operate for you. |
| Behaviour when the WAN drops | Keeps analysing. Events queue for delivery. | Depends on the link to your tenancy. | Depends on the link to our tenancy. |
| Who patches the runtime | VisaRoxy supplies signed updates; your team applies them. | Split: your infrastructure, our application. | VisaRoxy. |
| Typical reason to choose it | Sites with unstable WAN, or a rule that video never leaves the building. | Central IT already runs a cloud landing zone. | Smallest operational lift, fastest start. |
Prerequisites
What the site needs to provide.
The list is short on purpose. If a site can publish a video stream and reach an outbound endpoint, it can run VisaRoxy.
- Camera streams
- IP cameras publishing RTSP or ONVIF, reachable from the runtime. Analogue cameras behind an encoder count, because the encoder already publishes a stream.
- Compute
- Either an edge appliance supplied for the site, a virtual machine in your cloud tenancy with access to the camera network, or nothing at all if you choose the managed tenancy.
- Network path
- Inbound access from the runtime to each camera's stream, and outbound access to the endpoints you want events delivered to. No inbound path from the internet into the site network is required.
- Identity
- A decision on how operators sign in — single sign-on against your existing directory, or accounts managed inside VisaRoxy. Both are supported and the choice is made during onboarding.
- Named owners
- An operational owner for each zone and an escalation path. Agents without a named owner tend to accumulate rules nobody reviews.
- Destination systems
- The alerting, ticketing or dashboard endpoints that should receive events, and the credentials or tokens needed to reach them.
Start with the zone that costs you most.
Bring the workflow, the cameras and the escalation path. We will show you the agent configuration before anything is switched on.