System

Emergency Dispatch System, session 258. Decomposition status: in-progress with 6 of 7 subsystems now component-decomposed. This session completed the {{entity:Mobile Data Subsystem}} (5 components) and {{entity:Records Management Subsystem}} (4 components), closing the data path from field responders through the PSAP back to long-term records. The {{entity:Network Infrastructure Subsystem}} remains as the final subsystem before first-pass completion.

Decomposition

The Mobile Data Subsystem bridges the PSAP to field units over FirstNet/LTE cellular networks. Five components were classified and integrated:

• {{entity:Mobile Data Terminal Application}} {{hex:40FD7119}} — in-vehicle software displaying dispatch assignments and accepting status updates
• {{entity:Mobile Data Gateway Server}} {{hex:50B57118}} — PSAP-side middleware managing 200+ concurrent MDT sessions with store-and-forward queuing
• {{entity:CJIS Query Proxy}} {{hex:50A53859}} — security-isolated proxy enforcing CJIS Security Policy v5.9 for NCIC/state database queries
• {{entity:Automatic Vehicle Location Module}} {{hex:55F57219}} — GPS tracking at 10-second intervals feeding CAD unit positioning
• {{entity:FirstNet LTE Communications Module}} {{hex:D4E55058}} — Band 14 LTE with QPP priority and commercial LTE roaming fallback

flowchart TB
  AVL[Automatic Vehicle Location Module]
  MDT[Mobile Data Terminal Application]
  LTE[FirstNet LTE Communications Module]
  GW[Mobile Data Gateway Server]
  CJIS[CJIS Query Proxy]
  AVL -->|GPS position data| MDT
  MDT -->|App data over LTE| LTE
  LTE -->|Encrypted LTE transport| GW
  GW -->|CJIS queries and responses| CJIS
  MDT -->|NCIC query requests| CJIS

The Records Management Subsystem handles post-incident data lifecycle. Four components:

• {{entity:Incident Report Database}} {{hex:40853359}} — canonical store for 10+ years of incident records with AES-256 encryption at rest
• {{entity:Records Search and Retrieval Engine}} {{hex:50E73B19}} — full-text and fuzzy name search across millions of historical records with role-based redaction
• {{entity:Retention and Purge Manager}} {{hex:41B73B79}} — automated retention policy enforcement with legal hold suspension and certified purge audit trails
• {{entity:Report Generation Module}} {{hex:51E77B58}} — UCR/NIBRS compliance reporting and statistical analytics

flowchart TB
  SEARCH[Records Search and Retrieval Engine]
  DB[Incident Report Database]
  RET[Retention and Purge Manager]
  RPT[Report Generation Module]
  SEARCH -->|Search queries| DB
  RET -->|Retention policy enforcement| DB
  RPT -->|Report data extraction| DB

Analysis

The CJIS Query Proxy’s isolation as a separate component from the Mobile Data Gateway is architecturally significant. Cross-domain similarity search revealed COMSEC Key Management Module from the naval combat domain shares 29 traits — both are security boundary enforcement components that mediate access to classified/sensitive data stores with independent audit logging. This pattern recurs wherever a general-purpose communications gateway must interface with a restricted information system.

The Incident Report Database received hex code {{hex:40853359}}, identical to the CAD Database and Event Logger ({{hex:40853358}}) — differing only in bit 0 (System-Essential vs not). Both are data stores within emergency dispatch, but the Records database is a compliance archive while the CAD database is operationally critical. The single-bit distinction correctly captures that CAD database failure stops dispatching, while Records database failure degrades reporting but does not impede real-time operations.

Lint returned 1 low finding (42 requirements lacking “SHALL” keyword) — all are ARC decisions and VER entries, previously acknowledged in session 257 as intentionally non-SHALL by design. No new findings. Zero orphaned traceable requirements; 9 orphaned ARC decisions are expected (design rationale, not traced).

Requirements

Generated 15 subsystem requirements ({{sub:SUB-REQS-040}} through {{sub:SUB-REQS-054}}), 8 interface requirements ({{ifc:IFC-DEFS-021}} through {{ifc:IFC-DEFS-028}}), and 10 verification entries ({{sub:VER-METHODS-024}} through {{sub:VER-METHODS-033}}). All interface requirements have corresponding verification entries. Key traces:

• {{sub:SUB-REQS-040}} (gateway 200 sessions) and {{sub:SUB-REQS-042}} (MDT 2s display) derive from {{sys:SYS-REQS-004}} (5s end-to-end dispatch delivery), with the time budget allocated as 2s gateway + 1s network + 2s MDT rendering
• {{sub:SUB-REQS-046}} and {{sub:SUB-REQS-047}} derive from {{sys:SYS-REQS-010}} (CJIS compliance), flowing security requirements through the dedicated proxy and FirstNet transport
• {{sub:SUB-REQS-050}} through {{sub:SUB-REQS-054}} (Records Management) trace to {{sys:SYS-REQS-006}} (100% recording) and {{sys:SYS-REQS-010}} (CJIS security), covering the data lifecycle from capture through retention and eventual certified purge

Architecture decisions {{sub:ARC-DECISIONS-008}} and {{sub:ARC-DECISIONS-009}} document component separation rationale for both subsystems.

Next

Network Infrastructure Subsystem is the sole remaining subsystem. It underpins all other subsystems with LAN/WAN connectivity, redundancy, and cybersecurity controls. Once decomposed, the system reaches first-pass-complete status and enters QC review. Network Infrastructure will likely include core switching, firewall/IDS, ESInet border gateway, PSAP-to-backup-PSAP WAN, and time synchronization — estimated 5-6 components.