Light IT · working prototype · PT-895
VERDUN

A working slice of your pipeline — in your stack, running today.

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.

REAL · 4-brand ONVIF · dedup · ROI · retry→DLQ · circuit-breaker fallback · distributed trace · server-side keyframe SIMULATED · RTSP/KVS & ECS (your worker reused as-is) VALIDATED · 59 tests green · types clean
The walkthrough

The whole path, one trace.

Seven beats: fleet at scale, onboard a camera with no deploy, motion live. Then the Protocol Trace — real per-stage spans and latencies on one trace_id worker→backend — operator ack/resolve, resilience (429 → DLQ → fallback; kill a camera, neighbours hold), and the quality gate.

~105s · silent (captions carry it) · recorded against the live stack
Open the live prototype ↗ Live, hosted console — click ⚡ Trigger motion to send an event through the pipeline.
Mapped to your scope

The three workstreams.

A · Fleet

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.

B · Detection

DeepAlert adapter

POST /v1.0/analytics mapped to your detection contract, with client-minted job_id dedup. ROI, keyframe, and interpretation run unchanged.

C · Hardening

Resilience

On a 429 we retry, then hold to DLQ and fail over through the circuit breaker. Per-camera health isolates faults — kill one camera and the neighbours keep streaming.

The ask

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.