Computer Vision · Real-Time Alerting
Real-time AI workplace safety: enterprise smoke and anomaly detection where the entire value of the system is measured in seconds.
Incident to alert
From detection to a phone in someone’s hand
Continuous inference
Always-on monitoring across enterprise sites
Alert channels
WhatsApp and email fan-out per incident
OmniVision watches enterprise sites for smoke, safety anomalies and operational events, and tells someone about it immediately. Unlike an analytics product, its usefulness collapses if an alert arrives late. A detection that lands five minutes after a fire started is not a feature.
That single constraint drove the architecture. Video inference is computationally heavy and bursty; alerting has to be immediate and reliable. Coupling them directly would mean either a slow alert or a stalled pipeline, so they were separated by an event backbone from the start.
I built the Python/FastAPI backend with Kafka ingestion pipelines and RabbitMQ fan-out, so detection, alerting and analytics each scale on their own terms and one slow channel never delays another.
Detection has to reach a human within seconds, or the system has no safety value at all.
Continuous video streams create heavy, uneven compute that must not stall alert delivery.
Alerts must reach WhatsApp and email independently, so one failing channel never blocks the other.
The event bus in the middle is the whole design: it lets compute-heavy inference and second-critical alerting scale without touching each other.
Enterprise site coverage
Vision models served as a real service
Where one incident becomes many notifications
Seconds from incident to a human
Every stage after detection is designed to shed latency rather than add it. The event bus is what lets heavy inference and instant alerting coexist.
Continuous site video feeds arrive at the platform for sampling and analysis.
A Python/FastAPI service runs smoke detection and anomaly models against sampled frames.
A confirmed detection becomes an event on the Kafka ingestion pipeline rather than a direct call to anything.
One incident routes to multiple independent consumers, so WhatsApp and email delivery never block each other.
WhatsApp and email notifications reach responsible staff within seconds of the incident.
The same event stream feeds dashboards and reporting, giving sites a record and trends without a second pipeline.
Inference service
Python + FastAPI
Keeps the platform next to the vision and ML ecosystem while serving inference over a fast, typed HTTP layer.
Event backbone
Apache Kafka
Decouples heavy, bursty inference from time-critical alerting, so neither can stall the other.
Alert routing
RabbitMQ fan-out
One detection reaches several delivery channels independently, with per-channel failure isolation.
WhatsApp and email notifications delivered within seconds of detection.
Kafka pipelines keep compute-heavy detection off the alert delivery path.
Deployed for real workplace safety monitoring, not a proof of concept.
Operational reporting reuses the event log instead of duplicating the pipeline.
If any of the problems above look familiar, I can help, whether that's a full architecture or a second opinion on the one you have.
Open to remote and hybrid work worldwide