Surveillance Incident Lifecycle Management

Overview#

When a camera detection raises an alarm at three in the morning, the difference between a useful response and a missed event is whether someone can pick up that detection, understand it, act on it, and close it out without ever leaving the console. Surveillance Incident Lifecycle Management turns every detected video event into a tracked incident with a clear status, an owner, and a documented resolution, so nothing falls through the gap between the camera and the responder.

The module gives security operations teams a structured triage workflow that runs from the moment a detection is created right through to the unit arriving on scene. Incidents are created automatically from the detection pipeline, with built-in deduplication so a single event does not flood the queue, or raised by an operator through the API. Each incident carries its own geo-coordinates, confidence score, detecting model identity, secrecy level, and structured detection payload, and every operator action is captured in the audit record. Because resolved incidents are mirrored into the unified operations picture, surveillance events sit alongside incidents from every other channel, removing the manual handoff between the surveillance console and the wider command-and-control platform.

Key Features#

• Automated incident creation with deduplication: Detections from the video analysis pipeline are turned into incidents automatically, complete with the detecting model identity, confidence score, severity, priority, and the structured list of detections. A duplicate guard suppresses repeat events from the same camera and event type inside a short time window, and an idempotency key ensures a replayed message never creates a second incident.
• Operator-initiated creation: Human operators can raise incidents directly through the GraphQL API for events that need a workflow but did not originate from an automated detection, using the same incident shape and the same downstream handling.
• Explicit lifecycle state machine: Every incident moves through a defined set of states, new, acknowledged, investigating, and resolved, so the queue always reflects what has been seen, what is being worked, and what is closed.
• Acknowledge, assign, and resolve: Operators acknowledge an incident to claim it, assign it to a named owner as it moves into investigation, and resolve it with free-text resolution notes that stay attached to the record.
• Rich incident context: Each incident carries geo-coordinates, an optional address, the originating camera and zone, a secrecy level, the confidence score, the model identity and version, and a free-form detection payload, giving responders everything they need without leaving the record.
• Dispatch linkage with arrival feedback: Incidents hold the dispatch reference and the dispatched, acknowledged, and unit-arrived timestamps. As the dispatch side progresses, those timestamps are fed back onto the incident automatically, so the surveillance record reflects the real-world response.
• Real-time event streaming: Incident creation and every state change publish a live event over WebSocket topics scoped to the organisation, so consoles and dashboards update the moment something happens rather than on a refresh.
• Full audit trail and canonical mirroring: Every operator action, create, acknowledge, assign, and resolve, is written to the operations audit record, and each incident is mirrored into the canonical platform incident store so it appears in the same unified picture as incidents from any other source.

Use Cases#

Security Operations Centres#

A monitored detection becomes a live incident the instant it is created. The on-shift operator sees it appear in real time, acknowledges to take ownership, assigns a colleague to investigate, and resolves with notes once the situation is closed. The audit record shows exactly who did what and when.

Public Safety and Dispatch Coordination#

When an incident warrants a response, the dispatch reference and timestamps tie the surveillance record to the responding workflow. Operators watch the dispatched, acknowledged, and unit-arrived times populate on the incident itself, giving a single timeline from detection to boots on the ground.

Multi-Site and Managed Service Providers#

Because access is scoped per organisation on every read and write, a provider monitoring many tenants keeps each client's incidents fully isolated while running one consistent triage workflow across all of them.

Critical Infrastructure and Campus Security#

High-volume camera estates generate repeat detections during a single event. The deduplication window collapses these into one incident, keeping the operator queue focused on distinct events rather than noise, while the secrecy level on each incident keeps sensitive sites compartmented.

Integration#

• GraphQL API: Operators and integrations query incidents with filters for category, severity, and status, and drive the lifecycle through acknowledge, assign, and resolve operations. Authentication and per-tenant access control are enforced on every read and write path.
• Detection pipeline ingestion: The automated path accepts detection events keyed to a camera, resolves the camera's location, zone, and secrecy level, and produces a fully formed incident, so customers connecting a video analysis source get incidents without building their own creation logic.
• OAuth2 and JWT: All access is gated by standard bearer-token authentication, so the same identity and authorisation model used across the platform applies to surveillance incidents.
• Dispatch connector: A dispatch adapter carries incidents into the responding workflow using an idempotency key, and writes the resulting reference and arrival timestamps back onto the incident. Customers get end-to-end linkage without bespoke wiring between the two systems.
• Canonical incident adapter: An adapter mirrors surveillance incidents into the unified platform incident store with normalised priority, severity, location, and payload fields. The benefit is one operational picture: surveillance events are queryable next to incidents from every other channel, with no manual re-entry.
• Real-time WebSocket events: Creation and update events publish to organisation-scoped topics, letting any subscribed console or downstream service react live to new and changing incidents.

Open Standards#

• NENA i3 / NG911: Dispatch linkage fields, the dispatch reference plus the dispatched, acknowledged, and unit-arrived timestamps, follow CAD-to-CAD event conventions, so surveillance incidents interoperate cleanly with next-generation public safety answering point and computer-aided dispatch workflows.
• GraphQL: The incident query and lifecycle operations are exposed over a standard GraphQL interface, giving integrators a typed, self-describing contract for reading and driving incidents.
• OAuth2 Bearer Tokens (RFC 6749 / RFC 6750): Access is authorised with standard bearer tokens, aligning the module with the wider platform identity model.
• JSON Web Tokens (RFC 7519): Caller identity and tenant scope are carried in signed JWTs, so every request is attributable and authorised consistently.
• WGS 84 (EPSG:4326): Incident geo-coordinates are expressed as latitude and longitude in the WGS 84 reference frame, the global standard for interoperable geospatial positioning.
• WebSocket (RFC 6455): Live incident-created and incident-updated events are delivered over standard WebSocket topics for real-time console and dashboard updates.
• JSON: Structured detection payloads, location data, and event metadata are represented as JSON throughout, keeping the incident model portable and easy to consume.

Security & Compliance#

• Per-tenant isolation: Every read and write is scoped to the caller's organisation, so no operator can see or change another tenant's incidents.
• Secrecy levels: Each incident carries a secrecy level inherited from its source, supporting compartmented handling of sensitive sites and events.
• Immutable audit trail: Create, acknowledge, assign, and resolve actions are written to the operations audit record with the acting identity, the action, and the affected incident, providing an accountable history for compliance and review.
• Idempotent ingestion: Replayed detection messages cannot create duplicate incidents, protecting the integrity of the operational record under retries and at-least-once delivery.

Last Reviewed: 2026-05-26 / Last Updated: 2026-05-26