About

Most sites are already watched. Very few are understood.

VisaRoxy exists because the gap in industrial video is not coverage. It is the distance between what a camera recorded and what anyone did about it. This page covers what we build, who for, and what we have chosen not to build.

Operations and engineering colleagues reviewing a factory workflow together from a production-floor mezzanine.

Why

The cameras were already there. The decisions were not.

Walk through almost any plant, distribution centre or utility site and you will pass more cameras than you notice. They were installed over years, for reasons that made sense at the time: a theft, an incident, an insurance condition, a planning requirement. Collectively they cover most of what happens on the site.

Almost none of that coverage produces a decision. Footage is reviewed after something has gone wrong, which means the site's response to a problem begins at the point where the problem has already cost something. The camera was watching the whole time; nobody was told.

The first attempt to close that gap was motion detection, and it failed on volume rather than on accuracy. A motion alert is not a decision, it is a notification that pixels changed. Give a team several hundred of those a day and they will correctly learn to ignore them, which leaves the site exactly where it started but with more notifications.

VisaRoxy was built on the view that the missing piece is judgement, not detection. The question is not whether a camera can see a forklift. It is whether the platform can know that this forklift, in this walkway, for eleven seconds, during operating hours, is the thing somebody needs to hear about right now — and then tell them.

What

What VisaRoxy is.

A layer that sits between the cameras a site already runs and the systems its teams already use. It reads streams, converts them into named operational events, applies site rules, and routes the result to somebody who can act.

It is not a camera, a recorder or a video management system, and it does not ask a site to replace any of those. It connects to what is installed, works with the recording that already happens, and adds the part that was missing: continuous judgement about what the video means for the operation.

The unit of configuration is an agent rather than a camera. An agent is a named job — dock flow, walkway segregation, blocked egress — with its own watch list, thresholds, schedule and escalation path. Agents are what a supervisor edits, what a shift inherits, and what can be applied to a second site without rebuilding anything.

Read the full capability list

What an agent is

A named job, not a camera setting

The job

Loading Dock Sentinel — watch the dock apron and the pedestrian walkway across Docks 01 to 04.

What it watches

  • Trailer dwell time per door
  • Queue length on the apron
  • Vehicles inside the walkway zone

What it does

  • Alerts the yard marshal
  • Escalates if unacknowledged
  • Keeps the event record

Who for

Built for the people who own the floor.

The buying decision sits with operations, safety and security leadership. The product has to be usable by the people who report to them.

VisaRoxy is built for organisations that run physical operations at a scale where a person cannot watch everything: manufacturing plants, distribution and fulfilment sites, retailers with many locations, utilities and infrastructure operators, and operators of public venues. The common thread is a site with existing cameras, a recurring operational problem that video could describe, and a team that already owns the outcome.

It is not built for a central data science function. If a deployment needs a specialist to translate an operational problem into a model, the platform has failed at its main job. The person who knows that a lane is blocked should be the person who can express that as a rule, and the platform's job is to make that expression precise enough to be useful.

That shapes everything about the interface. Rules read as sentences. Zones are drawn on the scene rather than described in coordinates. Thresholds are in seconds and minutes. Escalation paths are roles rather than user IDs. None of that is a simplification of the underlying engine; it is a deliberate choice about who is allowed to operate it.

Principles

Six decisions we keep making the same way.

These are constraints rather than aspirations. Each one has cost us something in scope, and each one is the reason a deployment behaves the way it does.

  1. 01 The site keeps its hardware A vision project should not trigger a camera replacement programme. If the platform only worked on new hardware, the sites that need it most could never adopt it.
  2. 02 Video stays where it is Collecting video centrally is convenient for the vendor and expensive for the customer. The deployment model defaults to processing frames where they are produced.
  3. 03 Store the decision, not the recording An event record with a short clip answers almost every operational question. A continuous archive answers the same questions while creating a large, sensitive dataset nobody asked for.
  4. 04 Rules belong to the people who own the zone If changing a threshold requires an engineering ticket, the agent will drift out of date within a quarter. Configuration has to be editable by the operational owner.
  5. 05 An event with no recipient is a log line Detection without delivery changes nothing. Every agent is configured with an escalation path before it is switched on, and an unacknowledged event has somewhere to go.
  6. 06 No claims we have not earned No certification badges, no quoted accuracy figures, no customer logos we do not have permission to show. Where something depends on a deployment, we say that it depends on the deployment.

Boundaries

What VisaRoxy is deliberately not.

A product is defined as much by what it refuses to do. These exclusions are choices, and they are the ones customers ask about most often.

Not a face recognition product. VisaRoxy does not identify people. Agents work with classes, zones and durations, and the pipeline does not produce an identity for a person in frame. For operations and safety questions, knowing that a walkway was breached for eleven seconds is the useful fact; knowing who breached it is a different product with a different set of obligations.

Not a video management system. VisaRoxy does not replace recording, evidence handling or the review tools a security team already uses. Sites keep their VMS, keep their retention policy and keep their evidentiary workflow. The platform reads a stream alongside all of it.

Not a general analytics platform. It is not a tool for exploring data, and it does not try to be. Events are structured and exportable precisely so that analysis happens in the tools built for it, alongside production data, rather than inside a vision product.

Not a hardware business. Where an edge appliance is the right deployment model, we supply one, but the platform is not tied to it. The same agents run in a customer's cloud tenancy, which keeps the software honest about being software.

Not an autonomous decision-maker. VisaRoxy raises events and routes them. It does not decide that a line should stop, a person should be disciplined, or an incident should be closed. Where an action touches equipment, it is configured deliberately and reviewed by the site as a safety question, not enabled by default.

If your problem needs one of these

We will say so on the first call rather than shape the platform into something it is not. Being the wrong tool for a job is useful information and it is cheaper to hear early.

How we work

A pilot, then a decision.

Vision projects fail quietly, when a proof of concept is declared a success and then never reaches a production floor. The engagement model is designed so the second step is a real decision rather than a drift.

Step one

A scoped pilot on one site

One site, one or two agents, one named operational owner. The pilot includes the shadow period, where the agent's events are reviewed against your own footage before anything is switched on for live alerting.

Step two

A review against your judgement

At the end of the pilot you have the agent's full event history and your team's assessment of it. That is the material for a decision, and it belongs to you whether or not you continue.

Step three

Scale by agent, not by site

A second agent on the same cameras costs a configuration session. A second site reuses the agent library with local thresholds. Growth is measured in jobs the platform has taken on, not in cameras installed.

We would rather run a small pilot that ends in a clear no than a large rollout that ends in an unused licence. If the honest answer at the end of a pilot is that the site should keep doing what it does today, that is a result, and it is a cheaper one than the alternative.

Tell us what your cameras are missing.

Describe one thing that happens on your site that somebody should know about sooner. That is enough to scope a first agent.