Two projects can share an algorithm and share almost nothing else. An anomaly model that works on pump vibration or substation telemetry is not a model that can be pointed at camera feeds of people without changing what the project is. The maths survives the transfer; the failure mode, the evidence burden, and the legal exposure do not. We build the first kind. We decline the second, and we say so before scoping rather than after.
That sounds like a values statement. It is mostly an engineering one. The two cases diverge at the point where you decide what a false positive costs, and every downstream requirement — sensitivity, retention, audit trail, integration surface — inherits that answer.
What does “industrial anomaly, not people-surveillance” mean when scoping a detection project?
It means the anomaly is a machine state, and the response is an engineering action.
Operational anomaly detection works on process metrics, energy-grid telemetry and network operations. The detector says a transformer’s dissolved-gas trend has drifted, a compressor’s vibration signature has moved off its normal manifold, a link’s packet-loss pattern is inconsistent with its traffic profile. Someone on call looks, forms a hypothesis, and either dispatches a crew or dismisses it. The subject of the alert is an asset.
Behaviour anomaly detection, person-of-interest identification and generic security-video monitoring work on people. The detector says this person is behaving unusually. The subject of the alert is a human being, and the response is a decision about that human being.
A false positive on a substation transformer costs an on-call engineer an hour. A false positive on a person costs that person something the system cannot give back. Everything else in this article follows from that single asymmetry.
The divergence is in the requirement set, not the model
Once the subject of the alert changes, the requirement set changes with it — and this is what teams underestimate when they assume a working pipeline is portable.
| Dimension | Operational anomaly (process, grid, network) | Behaviour / people anomaly |
|---|---|---|
| Subject of the alert | An asset or a signal | An identifiable person |
| Response to a detection | Engineering action — inspect, dispatch, reroute | A decision about that person |
| Cost of a false positive | An on-call hour, a wasted truck roll | Non-recoverable for the individual |
| Acceptable false-positive rate | Set by on-call triage bandwidth | Set by what is defensible about a person, which is a far tighter bound |
| Evidence burden | Reproducible detection on named incident classes | Justification of every inference drawn about a person |
| Data ingested | Sensor tags, historian series, flow records | Identifiable imagery or behavioural traces |
| Compliance path | Short — machine-state detection | Long, and it never gets shorter once identifiable people are in the pipeline |
| Our position | We build it | We decline it; the request routes to what we don’t do |
Read the false-positive row carefully, because it is the one that breaks project plans. In an operational deployment, the alert budget is an operations property: how many detections per shift can the on-call rota genuinely triage. We tune to that ceiling and spend the remaining headroom on rare incident classes, an argument developed at length in anomaly detection that earns its alerts. There is no equivalent ceiling for a system whose false positives land on people. You cannot budget them against a rota.
The expensive failure this boundary prevents
The most costly outcome in this space is not a bad model. It is a scoped, staffed programme that stalls at legal or ethics review after the model work has been paid for.
We see the shape of it repeatedly in early scoping conversations (an observed pattern across TechnoLynx engagements, not a measured incidence rate): a plant or grid operator has an operational anomaly requirement that is entirely buildable, and somewhere in the requirements document there is one line about “also flagging unusual activity on site”. That line, unresolved, drags the whole programme into a different compliance regime. The data-retention design changes. The review board changes. The model that was going to run on historian tags now has to justify itself against imagery of employees.
Keeping the requirement set clean protects the metrics the operational programme is actually judged on — time-to-detect on the rare incident classes that matter, false-positive rate held inside the on-call team’s bandwidth, and integration cost against the existing SCADA or observability stack. Those are hard enough targets without importing constraints that belong to a different kind of system.
Where computer vision legitimately sits
Vision is not the boundary. Cameras are a sensor modality, and plenty of legitimate operational anomaly work uses them: thermal imaging on switchgear, corrosion and leak detection on pipework, flare-stack monitoring, surface-defect inspection on a line. The pipelines behind these are ordinary — an OpenCV or PyTorch preprocessing stage, a detector trained on defect classes, ONNX or TensorRT for the deployed inference path, and an event-level alert rather than a frame-level score. The computer vision practice covers the modality itself; the tuning specifics for camera-sourced operational anomalies are worked through separately in operational anomaly detection applied to an industrial CV workload.
The test is not “is there a camera”. It is: is the anomaly a machine state, and would a human appearing in frame change what the system does? If a person walking through the scene is irrelevant to the detection — and better still, never leaves the preprocessing stage in identifiable form — the workload is operational. If the person is the signal, it is not our work.
Boundary cases, and how they resolve
Three come up often enough to have standard answers.
- Cameras on a plant floor. Buildable when the detection target is equipment or process state and the design constrains identifiability — masking or discarding person regions before the model, no re-identification, no retention of frames whose only content is people. If the requirement is “tell us when someone is in the wrong zone”, that is access control about people, not an equipment anomaly, whatever the vendor label says.
- Site access telemetry. Door and badge events aggregated as a facility-load or utilisation signal is operational. The same event stream keyed to individuals to score their patterns is behaviour monitoring. Same data, different system.
- Telecom subscriber patterns. Network-element anomaly detection on aggregate flow and element health is operational. Anomaly scoring at the subscriber level is a decision about people even when no camera is involved — the vision framing hides how often this case appears in pure telemetry work.
The resolution rule in all three: identify the entity the model scores. If it is a person, the project is out of scope regardless of the sensor.
Keeping the carveout enforceable after the kickoff
A boundary that lives in a conversation does not survive month four. Three mechanisms carry it into the build.
- A scope statement that names the exclusion. Not “the system detects anomalies” but “the system detects anomalies in process, grid and network telemetry; it does not ingest or score identifiable persons”. Written where the delivery team reads it, not in an appendix.
- Data-ingest constraints enforced in code. The pipeline rejects sources outside the declared tag set or camera scope. This is a schema and configuration check, versioned alongside the model and its tuning parameters, so a scope change requires a visible commit rather than a quiet new connector.
- Validation bounded to the same scope. Our monitoring harness validates detection quality on process, grid and network telemetry only. What the harness does not validate, the system does not claim.
When a client asks for the people-surveillance variant, we say no early and explain the reasoning rather than the policy — usually the boundary is genuinely useful to them, because it separates the part of their requirement that is buildable now from the part that needs a different owner and a different review path. The services scoping conversation is where that separation happens, and a scoping review is the cheapest place to catch it.
One question is worth carrying into your own scoping: for every detector you plan to run, what entity does it score — and would you be comfortable defending that inference to the entity itself?f?f?
Frequently Asked Questions
What does ‘industrial anomaly, not people-surveillance’ mean in practice when scoping a detection project? Industrial anomaly detection monitors equipment and product quality—never employees. For Industrial Anomaly Detection vs, it helps to be precise. It means the entity the model scores is an asset or a signal, never an identifiable person. Operational detection produces an engineering action — inspect, dispatch, reroute — while people-directed detection produces a decision about a human being. The scope statement should name the exclusion explicitly rather than leaving it implied.
What concretely distinguishes an operational anomaly from a behaviour anomaly, and why does the distinction change the engineering? An operational anomaly is a deviation in a process metric, grid telemetry series or network-operations signal; a behaviour anomaly is a deviation attributed to a person. The distinction changes the engineering because the acceptable false-positive rate, the retention design, the audit trail and the compliance path all derive from who or what bears the cost of being wrong.
Why do the two cases demand different false-positive tolerances and different evidence burdens? A false positive on a substation transformer costs an on-call engineer an hour, so the tolerance can be budgeted against the rota’s triage bandwidth. A false positive about a person costs that person something the system cannot return, so there is no equivalent budget and every inference must be independently defensible.
Where does computer vision legitimately sit inside operational anomaly detection without becoming people-monitoring? Vision is legitimate when the detection target is equipment or process state — thermal imaging on switchgear, corrosion detection, surface-defect inspection — and the design keeps people non-identifiable or discards them at preprocessing. The test is whether a person appearing in frame changes what the system does; if the person is the signal, it is outside scope.
What happens when a client asks for the people-surveillance variant? We decline that portion and say so during scoping rather than after model work has been paid for, and the request routes to our published statement of work we don’t take. In practice the split is useful to the client, because it isolates the buildable operational requirement from the part that needs a different owner and review path.
Why asset monitoring and workforce surveillance diverge
Equipment-focused anomaly detection operates on machine state; people surveillance analyzes behavior—conflating them creates both technical debt and compliance risk. The teams that do tend to ship the boring, correct version first.
