AI & Data
The full domain, and the other capabilities within it.
Computer Vision
Vision models on your camera and sensor feeds, with human review wherever the model is unsure.
What this is
Computer vision turns camera or sensor frames into structured events: a count, a classification, a detected object, a flagged deviation. A working system is a pipeline - sampling frames, annotating a representative dataset, training, deploying inference near the camera, and monitoring what changes after go-live.
The failure is almost always the dataset, not the architecture. A model trained on clean daytime footage from one camera angle degrades quietly when a lens gets dirty, a light is replaced, or the site adds a new shift pattern. Annotation quality and coverage of the awkward cases decide the outcome; the model itself is the easy part.
When you need it
If more than one of these is true, this is usually the right place to start.
- Cameras are installed and recording, but every event still needs a person to watch the footage.
- A proof of concept performed well on sample video and fell apart on live feeds from the actual site.
- Bandwidth limits or privacy rules mean video cannot be shipped to the cloud for processing.
- A deployed model's alerts have become noisy and nobody knows whether the model or the environment changed.
What the scope covers
- Feasibility assessment on your own footage, covering lighting, camera placement and which events are genuinely detectable.
- Annotation strategy and dataset build, with written labelling guidelines and an agreed handling of ambiguous frames.
- Training and validation pipeline with versioned datasets and a model registry.
- Edge or on-premises inference deployment where bandwidth, latency or privacy rules require it.
- Confidence thresholds, human review queues and drift monitoring after go-live.
What you receive
| Deliverable | What it contains |
|---|---|
| Feasibility report | An assessment on your real footage of what is detectable, what is not, and which camera or lighting changes would be needed. |
| Annotated dataset and guidelines | A versioned dataset with written labelling rules, including how edge cases and annotator disagreements are resolved. |
| Trained model and registry | Versioned models with their training data, validation results and deployment history recorded against each version. |
| Inference deployment and review queue | Inference running where the data is, with low-confidence detections routed to a human queue instead of acted on. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Precision and recall on a held-out validation set drawn from your own site, split by camera and lighting condition.
- Share of detections falling below the confidence threshold and routed to human review.
- Drift indicators tracked after go-live: input distribution shift, confidence distribution shift and reviewer override rate.
Questions we are asked
How much labelled data do we need?
It depends on how variable the scene is, not on a fixed number. One fixed camera under consistent lighting needs far less than a fleet across sites and shifts. We start with a small annotated batch to measure the learning curve, then tell you what more data would actually buy - sometimes the answer is better camera placement rather than more labels.
Can it run without sending video to the cloud?
Yes, and often it should. Inference at the edge keeps footage on site, cuts bandwidth cost and removes cloud round-trip latency. The trade-off is hardware to manage and a model update process to build, which we design in from the start rather than retrofit.
What accuracy can you commit to before we start?
None, honestly. Accuracy depends on your footage, your event definition and your labelling consistency, and any figure quoted before we have seen the data is marketing. We set the target with you after a feasibility pass on real frames, and we define what an acceptable error looks like in each direction.
What about privacy and people appearing in frame?
It has to be designed for, not added later. Depending on the use case that can mean on-device processing, discarding frames after inference, not storing identifiable regions, and a defined retention period. Where the purpose involves identifying individuals, that is a legal question for your counsel before it is a technical one.
What happens when the model is unsure?
It should do nothing automatically. Detections below the confidence threshold go to a review queue, and the reviewer decision becomes training data for the next version. A vision system that acts on every low-confidence detection generates alarm fatigue and gets switched off within weeks.
How do we know when to retrain?
Drift monitoring tells you. We track how input frames and the confidence distribution change over time, and how often reviewers override the model. A rise in overrides or a shift in the input distribution is the signal to retrain, rather than waiting for someone to complain.
Continue reading
Predictive Analytics
Forecasting and risk scoring on your own history, with point-in-time features, honest backtesting, drift monitoring and a benchmark against the simple method.
Data Platform & Analytics
Warehouse or lakehouse, tested transformations, a semantic layer and real governance, so reports agree with each other and every metric has an owner.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.