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. 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. 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. 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. 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. 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.

Pipeline · Camera 04 — Receiving

Stream healthy · 5 fps analysed

Running
  • 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.

Deployment topologies compared. The right answer depends on connectivity, video policy and who operates the runtime.
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.

Judging the pilot

What a pilot is measured against.

A pilot that ends with "the technology works" has told you nothing. These are the questions we ask at the end, and the ones worth putting in the agreement before it starts.

The first measure is precision against your own judgement. We take the events the agent produced during shadow mode and you sort them: this was real, this was marginal, this was noise. An agent that fires on a handful of real events a week with almost no noise is ready to alert. One that needs a person to filter it is not, and the honest answer is to narrow the rule rather than ship it.

The second measure is whether the response actually changed. An agent can be accurate and still useless if its alerts arrive somewhere nobody looks, or if the person who receives them has no authority to act. Getting the escalation path right usually matters more than getting the threshold right.

The third measure is operational cost to the site. Who has to look after this on a Tuesday? If the answer involves an engineer logging in to check the pipeline, the agent is not finished. The end state is a zone owner who can change a threshold themselves and see the effect in the event list.

What we will not promise

Specific accuracy percentages, detection rates, or response times. Those depend on camera placement, lighting, the object classes involved and the rule you write, so they are established against your footage during the pilot rather than quoted in advance.

When the pilot ends, the agent either becomes the first entry in a library that other sites inherit, or it is switched off and you keep the event history. Both are acceptable outcomes, and the second one is cheaper than a rollout that nobody uses.

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.