CAD Evidence Graph (NENA i3 / EIDO-Aligned)

The Computer-Aided Dispatch (CAD) system is where calls become action. The CAD Evidence Graph ensures every step of that workflow — from incident creation to closure — is verifiable, auditable, and immutable. Built on the 911 Trust Ledger, each CAD event is recorded as a cryptographically signed entry that links directly to its originating 911 call and subsequent responder activity.

The result is a single source of truth for incident data integrity — proving when, how, and by whom key decisions were made, without ever exposing private or operationally sensitive content.

Why It Matters

CAD is the operational backbone of public safety. It manages unit dispatch, incident updates, and the continuous exchange of data between call-takers, field responders, and other agencies. Yet, CAD logs are often siloed, vendor-locked, or vulnerable to alteration.

The CAD Evidence Graph solves this by recording each critical CAD transaction — creation, dispatch, updates, closures, and exports — to a shared ledger governed by the 911TL Foundation. Every event is independently verifiable, timestamped, and linked to its originating 911 call (via CallID), forming a provable chain of custody across the entire incident lifecycle.

How It Works

• Incident Graph Model – Each CAD event type (create, dispatch, status, update, close) becomes a signed blockchain transaction tied to an IncidentID.

• Cross-System Linking – Events reference their associated CallID from CHE records, ensuring interoperability between call-taking and dispatch.

• Policy Enforcement – Smart contracts define event sequencing and retention policy compliance.

• Privacy & Provenance – Only cryptographic proofs of CAD data are stored on-chain; full reports and logs remain within PSAP or agency systems.

Example Incident Lifecycle

IncidentCreated → UnitDispatched → StatusChange* → IncidentUpdated → IncidentClosed
                           ↘ ExportPackage → RetentionAction

CAD Evidence Graph — Field Guide

A) Identity & Linking (core)

• event_id (UUID)

• event_type (IncidentCreated | UnitDispatched | StatusChange | IncidentUpdated | IncidentClosed | ExportPackage | RetentionAction | Error)

• prev_event_id (UUID)

• incident_id (CAD unique incident identifier)

• call_id (originating CallID from CHE)

• related_incident_id (optional; for multi-agency or merged incidents)

• ts (UTC timestamp, ISO-8601 with ms)

• seq (monotonic per incident_id)

B) Provenance & Authority

• issuer (system identity, e.g., CAD-PSAP01)

• issuer_cert_chain_id (verifying PKI chain)

• schema_version (e.g., cad.v1.0)

• software_version (CAD vendor/build)

• user_id (dispatcher/operator ID)

• role (e.g., dispatcher, supervisor, auto-system)

• signature (detached digital signature)

  
  

C) Incident Context

• incident_type (NENA EIDO type: Fire, EMS, Police, Rescue, etc.)

• priority (High | Medium | Low | Auto)

• response_plan (reference to plan or SOP ID)

• description_hash (hash of incident narrative/notes)

• location_hash (hash of incident address or coordinates)

• jurisdiction_id (agency or sub-agency responsible)

• esn_id (Emergency Service Number)

• service_urn (NG911 service classification)

• call_source (911 | Admin | Field | AutomaticAlarm)

• call_received_ts (for correlation to CHE)

• status (Open | Pending | Dispatched | OnScene | Transport | Closed)

D) Dispatch & Unit Activity

• unit_id (vehicle or resource identifier)

• unit_agency (agency or mutual aid partner)

• unit_status (Available | EnRoute | OnScene | Transport | Clear)

• unit_status_ts (time of change)

• unit_location_hash (optional; GPS or AVL hash)

• officer_id or crew_id (optional, hashed for privacy)

E) Incident Updates

• update_type (Narrative | PriorityChange | LocationUpdate | Attachment | Command | AutoGenerated)

• update_hash (hash of updated content)

• linked_call_ids (array of related calls)

• attachments[] (off-chain references: images, video, PDFs, etc.)

F) Resolution & Closure

• disposition (NENA or agency-defined close code)

• close_code (Cancelled | FalseAlarm | NoTransport | Cleared)

• duration_ms (incident total elapsed time)

• closed_by (user_id or system ID)

• closure_notes_hash (hash of summary)

• retention_profile_id (for record retention tracking)

G) Artifacts (off-chain references)

artifacts[]: {
  type: "cad-json | cad-log | audio | video | attachment | export-package",
  hash: "sha256:…",
  uri: "cad://… | storage://…",
  retention_class: "2y_incident | 5y_export | casefile",
  size: <bytes>,
  segment: { index: 1, start_ts: “…”, end_ts: “…” }
}

H) Error Handling & Policy Fields

• error_code (for failed transactions)

• error_detail_hash (diagnostic hash)

• policy_refs[] (linked compliance or retention policies)

• redaction_of_event_id (if superseding/redacting)

• privacy_profile_id (for PII suppression schema)

I) Expected Event Chains

Workflow	Sequence	Description
Standard Dispatch	IncidentCreated → UnitDispatched → StatusChange* → IncidentClosed	Typical lifecycle from creation to closure
Multi-agency Incident	IncidentCreated → ExportPackage → IncidentClosed	Shared with partner CAD systems
Audit or Export	IncidentCreated → IncidentUpdated → ExportPackage	For QA or legal disclosure
Retention Policy	IncidentClosed → RetentionAction	Recorded proof of deletion or archive

J) Minimal vs. Recommended Fields

Minimal (MVP on-chain)event_id, event_type, incident_id, ts, issuer, user_id, status, artifacts[], signature, schema_version

Recommended (Full fidelity)Add: priority, incident_type, unit_id, disposition, description_hash, location_hash, response_plan, retention_profile_id, policy_refs[]