A working slice of your pipeline — in your stack, not a slide deck.
Motion-triggered detection at fleet scale: the camera is an edge pre-processor, not a video firehose. We rebuilt your path — ONVIF → detection → interpretation → operator — in Python/FastAPI, with AWS mocked so it runs anywhere. Here's a two-minute look.
Seven beats, one trace.
Fleet at scale → onboard a camera (no deploy) → motion streams in live → the Protocol Trace (real per-stage spans + latencies, one trace_id worker→backend) → operator ack/resolve → resilience (429 → DLQ → fallback; kill a camera, neighbours hold) → the quality gate.
The three workstreams, demonstrated.
Registry & provisioning
Onboard a camera by DB write — a worker spawns, streams live, no deploy. RTSP creds go to a secret store, injected at spawn.
DeepAlert adapter
POST /v1.0/analytics → mapped to your detection contract; client-minted job_id dedup. ROI → keyframe → interpretation run unchanged.
Resilience
Bounded retry → DLQ/held → circuit-breaker fallback; per-camera health; kill one, neighbours keep streaming. Fault isolation.
Does this match what you need built?
This was built in the days after the scoping call, in your stack, mapped one-to-one to the 250-camera + DeepAlert MVP you scoped. If the approach lands, we'd attach per-workstream effort estimates and start where the risk is — the DeepAlert adapter on your existing single-camera worker.