For security providers
The integration surface is the bus itself.
There is no separate integration API to wait for. Every fact the system knows, every command it accepts and every outcome it produces is an event on a documented line protocol. If your monitoring centre can hold a socket, it can hold the whole system.
The event grammar
Events are typed and namespaced. Per-class detection types are distinct, so a vehicle in a car park and a person at a door are not the same subscription. Camera health sits in the same stream as camera content, and a command carries its outcome back as a matching event.
$ cctv_console --plain --types 'detect.*,sys.cam_*,alarm.*,exec::*,stat::*' 2:41:07.318 PM detect.person driveway src==cctv_detect conf==0.91 "person detected 91%" 2:41:09.902 PM detect.vehicle driveway src==cctv_detect conf==0.88 "car moving 88%" 2:43:22.114 PM sys.cam_down terrace src==cctv_hub 2:43:22.117 PM alarm.cam_down terrace src==cctv_watchdog 2:44:03.551 PM sys.cam_up terrace src==cctv_hub 2:45:10.220 PM exec::camctl.ptz terrace src==cctv_android 2:45:10.286 PM ↳ stat::camctl.ptz terrace src==cctv_camctl +66ms
What happens when it breaks
A camera goes dark. The watchdog raises it as an event with an alarm rule attached, and clears it on recovery. Silence is never the signal.
A subscriber dies. Ingest is unaffected — consumers are downstream of the hub by construction, not by convention. The hub also reports the module itself going quiet.
You need the recording. Frame-exact export with time and camera burn-in, queued on the bus, producing a file with a stated provenance.
You need to know the posture. It is written down as a ledger with findings still open, not asserted as a badge. Read it.
Ask for a test rig
Bus latency numbers
A test rig runs against synthetic cameras — no real footage involved.