System Decomposition Report — Generated 2026-03-27 — UHT Journal / universalhex.org
This report was generated autonomously by the UHT Journal systems engineering loop. An AI agent decomposed the system into subsystems and components, classified each using the Universal Hex Taxonomy (a 32-bit ontological classification system), generated traced requirements in AIRGen, and built architecture diagrams — all without human intervention.
Every component and subsystem is assigned an 8-character hex code representing its ontological profile across 32 binary traits organised in four layers: Physical (bits 1–8), Functional (9–16), Abstract (17–24), and Social (25–32). These codes enable cross-domain comparison — components from unrelated systems that share a hex code or high Jaccard similarity are ontological twins, meaning they occupy the same structural niche despite belonging to different domains.
Duplicate hex codes are informative, not errors. When two components share the same code, it means UHT classifies them as the same kind of thing — they have identical trait profiles. This reveals architectural patterns: for example, a fire control computer and a sensor fusion engine may share the same hex because both are powered, synthetic, signal-processing, state-transforming, system-essential components. The duplication signals that requirements, interfaces, and verification approaches from one may transfer to the other.
Requirements follow the EARS pattern (Easy Approach to Requirements Syntax) and are traced through a derivation chain: Stakeholder Needs (STK) → System Requirements (SYS) → Subsystem Requirements (SUB) / Interface Requirements (IFC) → Verification Plan (VER). The traceability matrices at the end of this report show every link in that chain.
| Standard | Title |
|---|---|
| IEEE 1588 | Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems |
| NFPA 1221 | — |
| Acronym | Expansion |
|---|---|
| ARC | Architecture Decisions |
| CCCS | Completeness, Consistency, Correctness, Stability |
| DFSI | Digital Fixed Station Interface |
| EARS | Easy Approach to Requirements Syntax |
| ESN | Emergency Service Number |
| IFC | Interface Requirements |
| MSAG | Master Street Address Guide |
| OTAR | Air Rekeying |
| STK | Stakeholder Requirements |
| SUB | Subsystem Requirements |
| SYS | System Requirements |
| UHT | Universal Hex Taxonomy |
| VER | Verification Plan |
flowchart TB n0["system<br>Emergency Dispatch System"] n1["actor<br>Emergency Callers"] n2["actor<br>Field Responders"] n3["actor<br>Dispatchers"] n4["actor<br>Supervisors"] n5["actor<br>Telephone Service Providers"] n6["actor<br>Neighboring PSAPs"] n7["actor<br>State/Federal Reporting"] n8["actor<br>NCIC/NLETS Databases"] n1 -->|911 calls, text-to-911, telematics| n0 n0 -->|Dispatch assignments, incident data, CAD updates| n2 n2 -->|Status updates, GPS position, field reports| n0 n0 -->|Call/incident display, map, radio audio| n3 n3 -->|Dispatch commands, call handling actions| n0 n0 -->|Performance metrics, queue status, alerts| n4 n5 -->|Incoming calls via ESInet/PSTN| n0 n0 -->|Mutual aid requests, transferred calls| n6 n0 -->|NIBRS, NFIRS, CAD statistics| n7 n0 -->|Query requests| n8 n8 -->|Query responses, wanted/missing persons| n0
Emergency Dispatch System — Context
flowchart TB n0["system<br>Emergency Dispatch System"] n1["subsystem<br>Call Handling Subsystem"] n2["subsystem<br>Computer-Aided Dispatch Subsystem"] n3["subsystem<br>GIS Subsystem"] n4["subsystem<br>Radio Communications Subsystem"] n5["subsystem<br>Mobile Data Subsystem"] n6["subsystem<br>Records Management Subsystem"] n7["subsystem<br>Network Infrastructure Subsystem"] n0 -->|contains| n1 n0 -->|contains| n2 n0 -->|contains| n3 n0 -->|contains| n4 n0 -->|contains| n5 n0 -->|contains| n6 n0 -->|contains| n7
Emergency Dispatch System — Decomposition
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| STK-NEEDS-001 | The Emergency Dispatch System SHALL answer 90% of incoming emergency calls within 15 seconds and 95% within 20 seconds. Rationale: NENA standard 56-005 specifies 90 percent at 15 seconds and 95 percent at 20 seconds answer-time targets for E911 PSAPs. Exceeding these thresholds directly correlates with increased mortality in cardiac arrest and trauma cases where every second of delayed response reduces survival probability by approximately 10 percent. | Test | stakeholder, session-252 |
| STK-NEEDS-002 | The Emergency Dispatch System SHALL determine the location of an emergency caller with sufficient accuracy to dispatch the nearest appropriate unit, including for wireless and VoIP callers. Rationale: FCC wireless E911 mandates require location accuracy for emergency calls. Without accurate caller location, dispatchers must rely on verbal information that may be unreliable when callers are distressed, unfamiliar with the area, or unconscious. Incorrect unit dispatch wastes critical response time and can be fatal in time-sensitive emergencies. | Test | stakeholder, superseded-by-session-260 |
| STK-NEEDS-003 | The Emergency Dispatch System SHALL deliver incident type, location, caller information, and any hazard warnings to dispatched field units prior to their arrival on scene. Rationale: Field units arriving without incident context face elevated risk and delayed effective response. Pre-arrival information on hazmat, weapons, building layout enables en-route tactical planning and appropriate resource staging, directly improving both responder safety and victim outcomes. | Demonstration | stakeholder, session-252 |
| STK-NEEDS-004 | The Emergency Dispatch System SHALL maintain 99.999% operational availability, with no single point of failure causing complete loss of dispatch capability. Rationale: Emergency dispatch is life-safety critical with no acceptable downtime. 99.999 percent availability aligns with NENA NG911 core service reliability standards. Complete dispatch failure during a mass-casualty event could result in preventable deaths across the served jurisdiction, typically covering 100,000+ residents. | Analysis | stakeholder, session-252 |
| STK-NEEDS-005 | The Emergency Dispatch System SHALL record all emergency call audio, radio transmissions, and CAD operator actions, and retain these records in accordance with applicable state retention statutes. Rationale: State and federal regulations mandate retention of 911 call recordings as public safety records and potential legal evidence. Failure to record or retain creates legal liability for the PSAP, undermines post-incident review and quality assurance, and may violate discovery obligations in litigation arising from emergency response. | Inspection | stakeholder, session-252 |
| STK-NEEDS-006 | The Emergency Dispatch System SHALL provide supervisors with real-time visibility into call queue depth, unit deployment status, response times, and dispatcher workload to enable dynamic resource management. Rationale: Without real-time operational visibility, supervisors cannot detect queue overflows, unbalanced dispatcher workloads, or degraded response times until callers complain or incidents escalate. Dynamic resource management requires continuous metrics to trigger overtime callbacks, mutual aid activation, or position reassignment. | Demonstration | stakeholder, session-252 |
| STK-NEEDS-007 | The Emergency Dispatch System SHALL support call transfer and mutual aid coordination with neighboring PSAPs, including transfer of caller location data and incident context. Rationale: PSAPs must handle calls outside their jurisdiction and coordinate mutual aid during large-scale incidents. NENA i3 standards require location and context transfer between PSAPs. Without seamless transfer, callers must repeat information to receiving dispatchers, wasting time and risking transcription errors during high-stress situations. | Test | stakeholder, session-252 |
| STK-NEEDS-008 | The Emergency Dispatch System SHALL accept emergency requests via voice call, text-to-911, and telematics (automatic crash notification), ensuring equitable access for persons who are deaf, hard-of-hearing, or speech-impaired. Rationale: The Americans with Disabilities Act and FCC mandate that 911 services be accessible to persons who are deaf, hard-of-hearing, or speech-impaired. Text-to-911 and telematics channels are legally required access methods. Telematics automatic crash notification provides critical data for unresponsive vehicle occupants who cannot place voice calls. | Test | stakeholder, session-252 |
| STK-NEEDS-009 | The Emergency Dispatch System SHALL determine the location of an emergency caller to within 50 metres horizontal accuracy for wireless callers and 10 metres for wireline/VoIP callers within 10 seconds of call answer, enabling dispatch of the geographically nearest available unit from the correct response zone. Rationale: FCC E911 Phase II mandates 50-metre accuracy for 67 percent of wireless calls. Wireline ALI provides street-address-level accuracy. The 10-second time constraint ensures location is available before the call-taker finishes initial questioning. | Test | stakeholder, duplicate-of-STK-NEEDS-010, session-260 |
| STK-NEEDS-010 | The Emergency Dispatch System SHALL determine the location of an emergency caller to within 50 metres horizontal accuracy for wireless callers and 10 metres for wireline/VoIP callers within 10 seconds of call answer, enabling dispatch of the geographically nearest available unit from the correct response zone. Rationale: FCC E911 Phase II mandates 50-metre accuracy for 67 percent of wireless calls. Wireline ALI provides street-address-level accuracy. The 10-second time constraint ensures location is available before the call-taker finishes initial questioning. | Test | stakeholder, supersedes-STK-NEEDS-002, session-260 |
| STK-NEEDS-011 | The Emergency Dispatch System SHALL support software updates, security patches, and hardware maintenance without requiring complete system shutdown, maintaining minimum dispatch capability for voice calls and radio communications during maintenance windows. Rationale: Emergency dispatch is a 24/7 life-safety service that cannot tolerate scheduled downtime. PSAP administrators need the ability to apply security patches and perform hardware maintenance without interrupting dispatch operations. Maintaining voice call and radio capability during maintenance ensures the public can still reach 911 and dispatchers can still communicate with field units. | Demonstration | stakeholder, session-261 |
| STK-NEEDS-012 | The Emergency Dispatch System SHALL support software updates, security patches, and hardware maintenance without requiring complete system shutdown, maintaining minimum dispatch capability for voice calls and radio communications during maintenance windows. Rationale: Duplicate of STK-NEEDS-011 — created during validation session. This requirement restates the maintainability need for zero-downtime updates to the emergency dispatch system, ensuring 24/7 service continuity during maintenance windows. | Demonstration | stakeholder, session-261, duplicate-of-STK-NEEDS-011 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SYS-REQS-001 | The Emergency Dispatch System SHALL process a minimum of 150 concurrent incoming emergency calls across all media types (voice, text, telematics) without degradation of call answer time or audio quality. Rationale: Derived from STK-NEEDS-001. A metropolitan PSAP serving 500,000+ population may receive 3,000+ calls per day with peak concurrency during severe weather or mass events. 150 concurrent calls represents a 3x peak margin over typical busy-hour loads of 50 concurrent calls, ensuring the system does not become a bottleneck during surge events. | Test | system, session-252 |
| SYS-REQS-002 | The Emergency Dispatch System SHALL complete call setup from ESInet SIP INVITE receipt to dispatcher audio presentation within 2 seconds, including ANI/ALI lookup. Rationale: Derived from STK-NEEDS-001. The 2-second end-to-end target allocates processing budget across ESInet gateway, ACD routing, ANI/ALI lookup, and workstation presentation. Exceeding 2 seconds adds directly to the call answer time measured by NENA standards, and each additional second of silence causes callers to hang up and redial, creating phantom load on the system. | Test | system, session-252 |
| SYS-REQS-003 | The Emergency Dispatch System SHALL display the location of wireless callers with horizontal accuracy of 50 metres or better for 80% of calls, using the best available location source (device-based, network-based, or hybrid). Rationale: Derived from STK-NEEDS-002. The FCC E911 location accuracy benchmark requires 50-metre horizontal accuracy for 80 percent of wireless calls. This is the minimum needed to dispatch to the correct building in urban environments. Without this accuracy, responders may search the wrong location while the caller is in distress at a different address. | Test | system, session-252 |
| SYS-REQS-004 | The Emergency Dispatch System SHALL deliver a complete dispatch assignment (incident type, location, caller data, hazard flags) to the assigned field unit's mobile data terminal within 5 seconds of the dispatcher initiating dispatch. Rationale: Derived from STK-NEEDS-003. The 5-second dispatch delivery target ensures field units receive assignment data while still en route from their station. Longer delivery times mean units arrive at intersections without knowing which direction to proceed, or arrive on scene without hazard awareness. 5 seconds allows the MDT to display and the crew to acknowledge before reaching the response zone. | Test | system, session-252 |
| SYS-REQS-005 | The Emergency Dispatch System SHALL achieve 99.999% availability measured annually, with automatic failover to redundant components completing within 30 seconds and without loss of active call audio or in-progress incident data. Rationale: Derived from STK-NEEDS-004. 99.999 percent availability permits 5.26 minutes annual downtime. The 30-second failover window ensures active calls are not dropped during component failure. Loss of in-progress incident data during failover could cause dispatched units to lose their assignment or duplicate dispatches to be generated, creating confusion during active emergencies. | Analysis | system, session-252 |
| SYS-REQS-006 | The Emergency Dispatch System SHALL record 100% of emergency call audio and radio transmissions with dual-redundant recorders, and SHALL retain recordings for a minimum of 5 years with chain-of-custody metadata. Rationale: Derived from STK-NEEDS-005. Dual-redundant recording eliminates single-point recording failure which would create unrecoverable evidence gaps. 5-year retention satisfies the most stringent state statutes. Chain-of-custody metadata is required for recordings to be admissible as evidence in criminal proceedings and civil liability cases arising from emergency response. | Test | system, session-252 |
| SYS-REQS-007 | The Emergency Dispatch System SHALL present supervisors with a real-time dashboard refreshed at least every 5 seconds, showing call queue depth, oldest call in queue, unit status counts by discipline, and aggregate response time metrics. Rationale: Derived from STK-NEEDS-006. The 5-second refresh interval provides near-real-time situational awareness without imposing excessive query load on the CAD database. Supervisors use this dashboard to detect queue depth spikes within 10 seconds of onset, enabling immediate intervention such as activating overflow routing or recalling off-duty dispatchers. | Demonstration | system, session-252 |
| SYS-REQS-008 | The Emergency Dispatch System SHALL transfer calls to neighboring PSAPs via NENA i3 SIP REFER with caller location (PIDF-LO), callback number, and incident context delivered to the receiving PSAP within 3 seconds of transfer initiation. Rationale: Derived from STK-NEEDS-007. NENA i3 SIP REFER is the standard inter-PSAP transfer mechanism. The 3-second transfer completion target ensures the receiving PSAP has caller context before audio connects, preventing the caller from having to repeat their emergency while the receiving dispatcher has no information. Location and callback number transfer eliminates manual re-entry errors. | Test | system, session-252 |
| SYS-REQS-009 | The Emergency Dispatch System SHALL accept text-to-911 messages via the ESInet text control centre and SHALL present text sessions to dispatchers with the same priority queuing, location display, and incident creation workflow as voice calls. Rationale: Derived from STK-NEEDS-008. Equal priority queuing for text sessions ensures ADA-mandated equitable access. Text callers in active-shooter or domestic-violence situations cannot use voice and must not be relegated to a secondary queue. Unified workflow means dispatchers handle text with the same incident-creation and location-display tools as voice, reducing training burden and error rates. | Test | system, session-252 |
| SYS-REQS-010 | The Emergency Dispatch System SHALL implement CJIS Security Policy v5.9 controls including encryption of data at rest and in transit, multi-factor authentication for administrative access, and network segmentation isolating PSAP systems from external networks. Rationale: Derived from STK-NEEDS-004. CJIS Security Policy v5.9 is mandatory for any system accessing criminal justice information. PSAPs routinely query NCIC and state criminal databases during dispatch. Failure to implement CJIS controls results in decertification, loss of database access, and potential federal enforcement action. Network segmentation prevents lateral movement from compromised external-facing systems into the PSAP core. | Inspection | system, session-252 |
| SYS-REQS-011 | The Emergency Dispatch System SHALL provide a training mode that simulates call intake, incident creation, dispatch, and radio operations using synthetic data, isolated from the production environment with no risk of dispatching real units or generating real radio transmissions. Rationale: Cross-domain insight from air traffic control and naval CMS domains: complex real-time dispatch systems require training environments to certify new operators and validate procedure changes without risk to live operations. Isolation from production prevents synthetic training data from generating real dispatches, a failure mode documented in multiple PSAP incidents where test calls triggered real unit responses. | Demonstration | system, session-261, cross-domain-insight |
| SYS-REQS-012 | When one or more subsystems experience failure, the Emergency Dispatch System SHALL maintain degraded dispatch capability for a minimum of 150 concurrent voice calls and radio channel access to all active talk groups, with call-to-dispatch time not exceeding 120 seconds for Priority Emergency incidents, until full capability is restored. Rationale: NENA standards require PSAPs to maintain minimum dispatch capability during partial system failures. The 150 concurrent voice call floor reflects a medium-sized PSAP peak load. The 120-second call-to-dispatch ceiling for Priority Emergency ensures life-threatening incidents still receive timely response even when CAD, GIS, or records subsystems are unavailable and dispatchers fall back to manual procedures. | Test | system, session-261 |
| SYS-REQS-013 | The Emergency Dispatch System SHALL support failover to a geographically diverse backup PSAP site located a minimum of 25 miles from the primary site, with automatic failover completing within 60 seconds and the backup site capable of sustaining 100% of primary site dispatch capacity. Rationale: Geographic diversity of backup PSAPs protects against regional disasters (earthquakes, hurricanes, flooding) that could disable the primary site. The 25-mile minimum separation is derived from FEMA regional disaster impact zones. The 60-second failover target ensures callers experience minimal disruption during site transition. 100 percent capacity at the backup site prevents capacity degradation during extended primary outages. | Test | system, session-261 |
| SYS-REQS-014 | The Emergency Dispatch System SHALL support rolling software updates to any individual subsystem without interrupting active call processing, active radio channels, or active CAD sessions, with the update process completing within a 30-minute maintenance window per subsystem. Rationale: Derives from STK-NEEDS-011 maintainability need. Rolling updates to individual subsystems allow patching security vulnerabilities and deploying bug fixes without system-wide downtime. The 30-minute window per subsystem bounds maintenance impact and enables scheduling updates across subsystems sequentially during low-traffic periods while keeping all other subsystems operational. | Demonstration | system, session-261 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SUB-REQS-001 | The ESInet SIP Gateway SHALL terminate a minimum of 150 concurrent SIP sessions across voice, RTT, and video media types, with each session maintaining TLS 1.2+ mutual authentication and SRTP media encryption. Rationale: 150 concurrent SIP sessions matches the system-level capacity requirement SYS-REQS-001. TLS 1.2+ mutual authentication is required by NENA i3 security framework to prevent call injection and eavesdropping on the ESInet. SRTP encryption protects caller audio from interception, which is mandatory for calls involving law enforcement operations and domestic violence situations. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-002 | The ESInet SIP Gateway SHALL complete SIP INVITE processing, authentication validation, and media negotiation within 200ms of receiving the initial INVITE from the ESInet border control function. Rationale: The 200ms gateway processing budget is derived from the 2-second end-to-end target in SYS-REQS-002, allocating 10 percent of the total budget to protocol handling. This includes SIP parsing, TLS certificate validation, and SDP media negotiation. Exceeding 200ms at the gateway leaves insufficient budget for downstream ACD routing and ANI/ALI lookup within the 2-second system target. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-003 | The Automatic Call Distribution Engine SHALL route an incoming call to an available call-taker position within 500ms of receiving the session from the ESInet SIP Gateway, applying skill-based routing, geographic assignment, and load-balancing rules. Rationale: The 500ms ACD routing budget is allocated from the 2-second SYS-REQS-002 target after gateway processing. Skill-based routing ensures callers with specific language needs or call types reach qualified dispatchers. Geographic assignment routes callers to dispatchers familiar with their area. Load balancing prevents dispatcher burnout and ensures equitable workload distribution during sustained high-volume periods. | Test | subsystem, call-handling, acd-engine, session-253 |
| SUB-REQS-004 | The ANI/ALI Database Interface SHALL return caller location data to the Call-Taker Workstation within 2 seconds of call arrival, querying the appropriate location source (ALI database for wireline, MPC/GMLC for wireless Phase II, LIS via HELD for NG911) and selecting the best available location with uncertainty metadata. Rationale: The 2-second location delivery target consumes the remaining budget from SYS-REQS-002 after gateway and ACD processing. Multiple location source types must be queried because wireline ALI, wireless MPC/GMLC, and NG911 LIS use different protocols and return different accuracy levels. Uncertainty metadata is essential for dispatchers to understand whether the displayed location is accurate to a building or only to a cell sector. | Test | subsystem, call-handling, ani-ali, session-253 |
| SUB-REQS-005 | The Call Recording System SHALL capture 100% of emergency call audio from both caller and dispatcher channels with dual-redundant recording paths, storing recordings in G.711 or uncompressed PCM format with GPS/NTP-synchronised timestamps accurate to within 10ms. Rationale: 100 percent capture rate with dual redundancy derives from SYS-REQS-006. Any gap in recording creates an evidentiary hole that could invalidate prosecution of crimes reported via 911. G.711 or uncompressed PCM preserves audio fidelity required for voice identification and background-sound analysis. GPS/NTP timestamps accurate to 10ms enable synchronisation of caller and dispatcher audio channels for timeline reconstruction. | Test | subsystem, call-handling, call-recording, session-253 |
| SUB-REQS-006 | The Text-to-911 Gateway SHALL deliver incoming text messages to the assigned Call-Taker Workstation display within 1 second of receipt from the ESInet text control centre, supporting SMS, RTT per RFC 4103, and SIP MESSAGE transport protocols. Rationale: The 1-second text delivery target derives from SYS-REQS-009 equitable access mandate. Text-to-911 callers in active danger situations cannot tolerate multi-second message delivery delays. Support for SMS, RTT, and SIP MESSAGE covers the three transport protocols mandated by FCC for text-to-911 service, ensuring no text caller is excluded based on their device capabilities. | Test | subsystem, call-handling, text-to-911, session-253 |
| SUB-REQS-007 | When all call-taker positions are occupied and the queue depth exceeds 5 calls, the Automatic Call Distribution Engine SHALL initiate overflow routing to pre-configured backup PSAPs within 2 seconds, maintaining caller audio and location data through the transfer. Rationale: Overflow routing derives from SYS-REQS-005 availability and STK-NEEDS-007 mutual aid requirements. The 5-call queue threshold and 2-second activation target are based on NENA best practices for avoiding abandoned calls. Maintaining caller audio and location through transfer prevents callers from having to re-explain their emergency to the receiving PSAP, which is critical during high-stress situations. | Test | subsystem, call-handling, acd-engine, session-253 |
| SUB-REQS-008 | The Call-Taker Workstation SHALL simultaneously display the caller location on the GIS map, ANI/ALI data, active call controls, incident entry form, and protocol-guided interrogation script within 3 seconds of call presentation, across a minimum dual-monitor configuration at 1920x1080 resolution per display. Rationale: Simultaneous display of all call context derives from SYS-REQS-003 and SYS-REQS-004. Dispatchers must see location, caller identity, and incident entry simultaneously to avoid toggling between screens during time-critical calls. The 3-second presentation target ensures all context is visible before the dispatcher begins speaking. Dual 1920x1080 monitors are the minimum configuration to display map, ANI/ALI, and CAD panels without overlap. | Demonstration | subsystem, call-handling, workstation, session-253 |
| SUB-REQS-009 | The ESInet SIP Gateway SHALL operate in an active-active redundant configuration with stateful session replication, achieving failover to the standby gateway within 500ms without dropping active calls or requiring caller re-dial. Rationale: Active-active redundancy with 500ms failover derives from SYS-REQS-005. The ESInet SIP Gateway is the single entry point for all emergency calls and therefore the highest-criticality component. Stateful session replication ensures active calls survive gateway failure without requiring caller re-dial, which may be impossible if the caller is incapacitated. 500ms failover is achievable with modern SIP proxy clustering and prevents perceptible audio interruption. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-010 | The Incident Management Engine SHALL create, classify, and assign a priority level to an incoming incident within 500ms of receiving the incident creation request from the Call-Taker Workstation, applying NIMS-compliant incident type codes and one of three priority levels (Emergency, Urgent, Routine). Rationale: 500ms response time derived from NFPA 1221 standard requiring dispatch processing within 60 seconds total; each pipeline stage must contribute minimal latency. NIMS-compliant incident type codes required by FEMA for all emergency management agencies receiving federal funding. Three-tier priority enables differential response protocols. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-011 | The Incident Management Engine SHALL support a minimum of 500 concurrent active incidents with independent state machines, each tracking state transitions through Created, Dispatched, En Route, On Scene, Resolved, and Closed with sub-second transition latency. Rationale: 500 concurrent incidents sized for worst-case major metropolitan area during a large-scale event where multiple PSAPs consolidate. Independent state machines prevent cross-incident state corruption during high-tempo operations. Sub-second transition latency ensures dispatchers see current state without delays that could cause duplicate dispatches. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-012 | When two or more incidents are identified as referring to the same event, the Incident Management Engine SHALL merge them into a single parent incident within 2 seconds, preserving all original call records, assigned units, and timeline entries from each source incident. Rationale: Duplicate 911 calls for the same event are common — a highway accident may generate 20+ calls. Without merge, separate incidents consume separate units, depleting resources. 2-second threshold ensures merge does not delay primary dispatch. Preservation of all source records required for legal discovery and after-action review. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-013 | The Dispatch Decision Support Module SHALL generate a ranked list of at least 3 candidate unit assignments within 2 seconds of incident creation, using road-network travel-time estimation, unit capability matching, current unit workload, and historical response-time data for the incident location. Rationale: Road-network travel time is critical because actual response in urban environments can be 3-5x the straight-line estimate due to one-way streets, bridges, and traffic. 2-second computation window sized to keep total call-to-dispatch time within NFPA 1221 standards. Minimum 3 candidates gives dispatcher meaningful choice without overwhelming under time pressure. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-014 | When no dispatcher action is taken on a Priority Emergency incident within 30 seconds of recommendation presentation, the Dispatch Decision Support Module SHALL automatically dispatch the top-ranked available unit and present a confirmation alert to the assigned dispatcher workstation. Rationale: NFPA 1221 requires call-to-dispatch within 60 seconds for 90% of emergency calls. A 30-second timeout on Priority Emergency incidents provides a safety net if the dispatcher is overloaded, ensuring life-threatening calls are never indefinitely queued. Confirmation alert maintains situational awareness and allows override. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-015 | The Dispatch Decision Support Module SHALL apply configurable run-card rules that specify mandatory multi-unit response compositions for each incident type, and SHALL alert the dispatcher when the recommended assignment does not fulfil the run-card minimum (e.g., structure fire requiring 2 engines, 1 ladder, 1 battalion chief, 2 ambulances). Rationale: Run cards define minimum resource composition per incident type based on fire service doctrine and mutual aid agreements. A structure fire missing a ladder company directly endangers lives. Alerting the dispatcher when the recommendation falls short of run-card minimum prevents under-resourcing due to unit unavailability being silently accepted. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-016 | The Unit Tracking and Status Module SHALL ingest AVL position updates from a minimum of 2000 simultaneous field units at 5-second reporting intervals, with end-to-end latency from GPS fix to map display position update not exceeding 3 seconds. Rationale: 2000 simultaneous units sized for a large metropolitan dispatch center serving multiple agencies. 5-second AVL reporting interval balances position accuracy with cellular/MDT bandwidth. 3-second end-to-end latency ensures the map view is current enough for accurate nearest-unit recommendations. | Test | subsystem, cad, unit-tracking, session-255 |
| SUB-REQS-017 | The Unit Tracking and Status Module SHALL maintain and update unit status codes (Available, Dispatched, En Route, On Scene, At Hospital, Out of Service) within 1 second of status change receipt, and SHALL record each transition with timestamp and source (MDT automatic, MDT manual, dispatcher-initiated) in the unit activity log. Rationale: 1-second status update latency ensures the recommendation engine does not suggest units that are out-of-service or already dispatched. Recording transition source (MDT automatic vs manual vs dispatcher-initiated) is essential for after-action review — disputes about response time often hinge on when a unit actually went en-route vs when marked. | Test | subsystem, cad, unit-tracking, session-255 |
| SUB-REQS-018 | The Dispatcher Workstation Interface SHALL present an integrated display combining the GIS map with real-time unit positions, active incident list sorted by priority and age, recommended unit assignments, and radio channel status, with display refresh latency not exceeding 500ms for position updates across a minimum of 4 simultaneous monitors per dispatch position. Rationale: Integrated display eliminates context-switching between separate applications during emergencies that costs seconds accumulating into delayed response. 500ms position refresh derived from human perceptual threshold for smooth map movement. 4-monitor minimum reflects PSAP ergonomic standards for simultaneous views of map, incident queue, unit status, and radio controls. | Demonstration | subsystem, cad, dispatcher-workstation, session-255 |
| SUB-REQS-019 | The Dispatcher Workstation Interface SHALL support single-keystroke dispatch confirmation and common status update commands, enabling a dispatcher to accept the top-ranked unit recommendation and dispatch it without mouse interaction, completing the dispatch action within 2 keystrokes from recommendation display. Rationale: During peak operations a dispatcher handles 40+ incidents per hour. Mouse workflows add 3-5 seconds per action; keystroke dispatch eliminates this overhead. 2-keystroke maximum derived from cognitive ergonomics research showing more keystrokes increase error rate under stress. Directly supports NFPA 1221 call-to-dispatch targets. | Demonstration | subsystem, cad, dispatcher-workstation, session-255 |
| SUB-REQS-020 | The CAD Database and Event Logger SHALL sustain a minimum of 5000 write transactions per minute during peak operations, using synchronous replication to a standby database node with automatic failover completing within 10 seconds and zero committed transaction loss. Rationale: 5000 writes/minute derived from peak load: 500 concurrent incidents generating 10 state transitions per minute each. Synchronous replication with zero committed transaction loss is mandatory because incident records are legal evidence — a lost dispatch record could invalidate court proceedings. 10-second failover ensures brief interruption without losing dispatcher capability. | Test | subsystem, cad, database, session-255 |
| SUB-REQS-021 | The CAD Database and Event Logger SHALL encrypt all data at rest using AES-256 and implement role-based access controls compliant with CJIS Security Policy v5.9, including multi-factor authentication for administrative access and audit logging of all data access events. Rationale: CJIS Security Policy v5.9 is federally mandated for all systems accessing criminal justice information through FBI NCIC, NLETS, or state equivalents. Non-compliance results in loss of access to warrant checks, stolen vehicle databases, and wanted person records essential for officer safety. AES-256 at rest protects against physical media theft. | Inspection | subsystem, cad, database, cjis, session-255 |
| SUB-REQS-022 | The Supervisor Dashboard Module SHALL display call queue depth, oldest-waiting-call age, average and 95th-percentile response times by incident type, unit utilisation by district, and active incident count by priority, refreshing all metrics at 5-second intervals per SYS-REQS-007, and SHALL trigger visual and audible alerts when queue depth exceeds 5 calls or oldest-waiting-call exceeds 60 seconds. Rationale: Supervisors must detect dispatch bottlenecks in real-time to activate mutual aid or redistribute workload. 5-second refresh aligns with SYS-REQS-007. Queue depth >5 and oldest-call >60s thresholds derived from NFPA 1221 — exceeding these indicates the PSAP is falling behind service-level obligations and needs immediate intervention. | Demonstration | subsystem, cad, supervisor-dashboard, session-255 |
| SUB-REQS-023 | The Dispatch Radio Console SHALL support simultaneous monitoring of a minimum of 24 talk groups and 4 conventional channels, with independent volume control and audio routing per channel, and SHALL allow the dispatcher to transmit on any monitored channel within 100ms of PTT activation. Rationale: 24 simultaneous talk groups reflects typical large PSAP configuration monitoring fire, EMS, law enforcement, mutual aid, tactical, and administrative channels across jurisdictions. 4 conventional channels for legacy analog interoperability with volunteer departments. 100ms PTT latency is the maximum acceptable for real-time voice without perceivable delay disrupting natural speech. | Test | subsystem, radio-comms, dispatch-radio-console, session-256 |
| SUB-REQS-024 | When a field unit activates an emergency alert on any monitored talk group, the Dispatch Radio Console SHALL immediately unmute that channel, display a visual emergency indicator with the unit ID and talk group, and generate an audible alarm within 500ms of alert reception. Rationale: Emergency alerts from field units (officer down, firefighter mayday) are the highest-priority radio events — delayed notification directly endangers lives. 500ms ensures the dispatcher is alerted within one heartbeat. Automatic unmute prevents the alert from being missed when the channel is muted during multi-talk-group monitoring. | Test | subsystem, radio-comms, dispatch-radio-console, session-256 |
| SUB-REQS-025 | The Radio Gateway Controller SHALL bridge a minimum of 48 simultaneous voice paths between IP-connected dispatch consoles and the P25 trunked radio infrastructure, converting between G.711 mu-law and IMBE vocoder formats with no more than 50ms transcoding latency per direction. Rationale: 48 simultaneous voice paths sized for 24 dispatch positions with 2 concurrent transmissions each. G.711 to IMBE transcoding mandatory because IP dispatch uses G.711 while P25 trunked radio uses IMBE vocoder. 50ms transcoding latency ensures total end-to-end stays under 150ms, well below ITU 250ms conversational threshold. | Test | subsystem, radio-comms, radio-gateway-controller, session-256 |
| SUB-REQS-026 | The Radio Gateway Controller SHALL operate in an active-standby redundant configuration with stateful session replication, achieving automatic failover within 2 seconds with no loss of active voice paths and no dropped PTT transmissions. Rationale: Loss of the radio gateway during an active emergency severs communications between dispatchers and field units. 2-second failover ensures brief interruption that does not cause PTT timeouts. Stateful session replication prevents active calls from being torn down, critical during multi-agency incidents where re-establishment would require manual intervention from multiple positions. | Test | subsystem, radio-comms, radio-gateway-controller, session-256 |
| SUB-REQS-027 | The Talkgroup Management Module SHALL support configuration of a minimum of 500 talk groups across 32 zones, and SHALL complete dynamic talk group patch creation (connecting 2 or more talk groups for cross-channel audio) within 3 seconds of dispatcher request. Rationale: 500 talk groups across 32 zones reflects a regional system serving multiple jurisdictions and mutual aid agreements. 3-second dynamic patch creation enables dispatchers to bridge talk groups during emerging incidents without delay that would leave field units unable to communicate cross-agency during critical first minutes. | Test | subsystem, radio-comms, talkgroup-management, session-256 |
| SUB-REQS-028 | When a Priority Emergency call is received by the CAD, the Talkgroup Management Module SHALL automatically affiliate the assigned dispatch position with the incident talk group within 1 second, without requiring manual channel selection by the dispatcher. Rationale: Manual channel selection during high-tempo dispatch adds cognitive load and introduces errors where a dispatcher transmits on the wrong talk group. Automatic affiliation upon CAD dispatch confirmation ensures the dispatcher is immediately on the correct channel, supporting the 2-keystroke workflow in SUB-REQS-019. | Test | subsystem, radio-comms, talkgroup-management, session-256 |
| SUB-REQS-029 | The Interoperability Gateway SHALL support a minimum of 48 simultaneous cross-patched talk groups across ISSI (Inter-RF Subsystem Interface) connections to a minimum of 8 external P25 systems from different vendors, operating across VHF, UHF, and 700/800 MHz frequency bands. Rationale: Multi-agency mutual aid incidents require interoperability across jurisdictions using different P25 systems from different vendors. 48 simultaneous cross-patches sized for a major incident with 6 patches each across 8 partner systems. Multi-band (VHF/UHF/700-800 MHz) reflects real frequency allocations — federal on VHF, local LE on 800 MHz, rural fire on UHF. | Test | subsystem, radio-comms, interoperability-gateway, session-256 |
| SUB-REQS-030 | The Interoperability Gateway SHALL implement ISSI Group Call, Unit-to-Unit Call, and Emergency Alert services per TIA-102.BACA-A, and SHALL propagate emergency alerts from external systems to the Dispatch Radio Console within 1 second of reception. Rationale: TIA-102.BACA-A is the P25 standard for inter-system interoperability — compliance required for connection to partner networks. Emergency alert propagation within 1 second across system boundaries ensures a mayday from a mutual aid unit on an external system is immediately visible, preventing delayed response to personnel in distress. | Test | subsystem, radio-comms, interoperability-gateway, session-256 |
| SUB-REQS-031 | The Radio Logging Recorder SHALL capture 100% of radio transmissions across all monitored talk groups with audio quality of minimum 8 kHz sample rate and 16-bit depth, recording transmitter unit ID, talk group ID, RF site ID, and GPS-synchronized timestamp (UTC, accuracy within 10ms) for each transmission. Rationale: 100% capture with no missed transmissions required for evidentiary chain of custody — recorded radio traffic is used in criminal proceedings, internal affairs, and liability cases. 8 kHz/16-bit maintains intelligibility above P25 IMBE native quality. GPS-synchronized 10ms timestamps enable precise correlation with CAD events and body camera footage. | Test | subsystem, radio-comms, radio-logging-recorder, session-256 |
| SUB-REQS-032 | The Radio Logging Recorder SHALL retain all radio transmission recordings for a minimum of 7 years with tamper-evident storage, and SHALL support instant replay of the last 60 seconds of any monitored talk group from the dispatcher console within 2 seconds of request. Rationale: 7-year retention aligned with the longest common state records retention schedule for public safety communications. Tamper-evident storage mandatory for evidentiary integrity — recordings must be admissible in court. 2-second instant replay enables dispatchers to re-hear a garbled field transmission without leaving position or disrupting workflow. | Test | subsystem, radio-comms, radio-logging-recorder, session-256 |
| SUB-REQS-033 | The Encryption Key Management Module SHALL manage AES-256 traffic encryption keys (TEKs) and key encryption keys (KEKs) for a minimum of 5000 subscriber radios, supporting scheduled key rotation at configurable intervals (minimum daily) and emergency key zeroization of individual units or groups within 30 seconds of operator command. Rationale: 5000 subscriber radios reflects a large metropolitan agency fleet. Daily TEK rotation limits exposure if a key is compromised through a lost or stolen radio. 30-second emergency zeroization is critical when a radio is confirmed lost in a hostile environment — delayed key erasure could allow adversary monitoring of encrypted law enforcement communications. | Test | subsystem, radio-comms, encryption-key-management, session-256 |
| SUB-REQS-034 | The Encryption Key Management Module SHALL support Over-the-Air Rekeying (OTAR) per TIA-102.AACA for TEK distribution to field radios without requiring physical key loading, and SHALL confirm successful rekey of each targeted radio within 60 seconds of initiation. Rationale: Physical key loading requires each radio to be brought to a secure facility, consuming hours for a 5000-radio fleet. OTAR per TIA-102.AACA enables daily rotation without physical access, operationally essential for continuous field deployment. 60-second per-radio confirmation ensures the rekey completes within a manageable window. | Test | subsystem, radio-comms, encryption-key-management, session-256 |
| SUB-REQS-035 | The Map Tile Server SHALL serve raster and vector map tiles at a sustained rate of 200 concurrent tile requests with 95th-percentile response time not exceeding 200ms, supporting smooth pan and zoom across a minimum of 24 simultaneous dispatcher workstation map views. Rationale: The Map Tile Server must sustain 200 concurrent tile requests because a busy PSAP with 20 dispatch positions generates approximately 10 tile requests per second per workstation during active pan/zoom. 200ms 95th-percentile response time ensures smooth visual rendering — above this threshold, dispatchers perceive map lag that slows incident location identification. Raster and vector tile support enables both high-detail aerial imagery and fast-rendering road maps. | Test | subsystem, gis, session-257 |
| SUB-REQS-036 | The Geocoding Engine SHALL resolve street addresses, intersections, and common place names to WGS84 coordinates within 200ms with accuracy within 50 meters of the physical location, validating against the local MSAG (Master Street Address Guide) and returning MSAG-valid ESN (Emergency Service Number) for each resolved address. Rationale: The Geocoding Engine is the critical link between textual addresses from callers/ALI and map coordinates for dispatch. 200ms resolution time enables real-time geocoding as the call-taker types. 50-metre accuracy ensures the dispatched unit arrives at the correct building in urban areas. MSAG validation catches invalid addresses before units are dispatched to non-existent locations, reducing wasted response time. | Test | subsystem, gis, session-257 |
| SUB-REQS-037 | The Routing Engine SHALL compute road-network travel time estimates between any two points within the dispatch jurisdiction within 500ms, using a weighted road graph incorporating speed limits, one-way restrictions, turn prohibitions, and historical emergency response time data, with route accuracy within 10% of actual drive time for 90% of routes. Rationale: The Routing Engine provides travel time estimates that the Dispatch Decision Support Module uses to recommend the closest available unit. 500ms computation time is acceptable because route calculation happens after unit selection narrows candidates to 3-5 units. Incorporating speed limits, one-way restrictions, and real-time conditions prevents dispatching units along routes that are slower than alternatives, directly affecting emergency response time. | Test | subsystem, gis, session-257 |
| SUB-REQS-038 | The Spatial Database SHALL support point-in-polygon queries completing within 50ms to determine the ESZ, fire management zone, police beat, and EMS response area for any incident coordinate, using spatial indexes over a minimum of 20 geographic overlay layers. Rationale: Point-in-polygon queries determine which response zones (ESZ, fire district, police beat, EMS area) contain a given incident location. This determines which agencies and units are dispatched. 50ms query time ensures zone lookup does not delay the call processing pipeline. Spatial indexing (R-tree or GeoHash) is necessary because polygon boundary complexity in metropolitan jurisdictions makes brute-force computation too slow for real-time use. | Test | subsystem, gis, session-257 |
| SUB-REQS-039 | When the Spatial Database is updated with new geographic data, the Map Tile Server SHALL regenerate affected tile caches within 30 minutes and the Geocoding Engine SHALL reload its address index within 15 minutes, without interrupting service to active dispatcher sessions. Rationale: When ESZ boundaries or road networks change, outdated map tiles or address indexes could cause dispatchers to see incorrect zone assignments or geocoding failures. 30-minute tile cache regeneration ensures dispatchers see current boundaries within one shift. 60-minute address index reload balances index rebuild time against currency requirements. Without automated propagation, manual cache clearing is error-prone and risks dispatching to wrong jurisdictions. | Test | subsystem, gis, session-257 |
| SUB-REQS-040 | The Mobile Data Gateway Server SHALL maintain authenticated sessions with a minimum of 200 concurrent mobile data terminals, with per-session TLS 1.2+ encryption and session re-establishment within 3 seconds of connectivity restoration. Rationale: A metropolitan PSAP may have 200+ field units across police, fire, and EMS. The Mobile Data Gateway Server must maintain concurrent sessions with all of them. TLS 1.2+ encryption is mandated by CJIS Security Policy for data in transit. 30-second re-establishment time after disconnection limits the window during which a field unit cannot receive dispatch updates, which is critical when units are en route to emergencies. | Test | subsystem, mobile-data, gateway, session-258 |
| SUB-REQS-041 | When an MDT loses cellular connectivity, the Mobile Data Gateway Server SHALL queue all pending messages for that unit for a minimum of 30 minutes and deliver them in chronological order within 5 seconds of connectivity restoration. Rationale: FirstNet LTE coverage gaps occur in parking garages, building interiors, and rural fringe areas. Queuing messages for 30 minutes covers the typical duration of an on-scene event where the MDT may lose cellular connectivity. Chronological delivery ensures the field unit receives dispatch updates in the correct order (e.g., hazard update before cancellation). 5-second delivery after reconnection minimizes the stale-information window. | Test | subsystem, mobile-data, gateway, session-258 |
| SUB-REQS-042 | The Mobile Data Terminal Application SHALL display a complete dispatch assignment (incident type, address, cross street, caller information, hazard flags, responding units, and tactical notes) within 2 seconds of receipt from the Mobile Data Gateway Server. Rationale: Field units need complete dispatch information on the MDT screen within 3 seconds of radio dispatch to avoid requesting repeat information over the radio channel, which consumes shared airtime. The full information set (incident type, address, cross street, caller info, hazard flags, responding units, tactical notes) is what responders need to begin response planning en route. Hazard flags (violent subject, HazMat, structural collapse) are safety-critical. | Test | subsystem, mobile-data, mdt, session-258 |
| SUB-REQS-043 | The Automatic Vehicle Location Module SHALL transmit GPS position reports with unit identifier and UTC timestamp at a configurable interval of 5 to 60 seconds, with a default of 10 seconds for in-service units and 60 seconds for out-of-service units. Rationale: GPS position reports with unit ID and UTC timestamp are the minimum data set for the Unit Tracking and Status Module to plot field units on the dispatch map. Configurable intervals (5-60 seconds) balance position currency against cellular bandwidth — 10-second default provides adequate tracking resolution for urban response while limiting FirstNet data consumption. Faster intervals for in-service units enable more accurate arrival time predictions. | Test | subsystem, mobile-data, avl, session-258 |
| SUB-REQS-044 | The Automatic Vehicle Location Module SHALL achieve position accuracy of 3 metres CEP under open-sky conditions and 10 metres CEP in urban environments with multipath interference. Rationale: 3-metre CEP under open sky matches commercial GPS receiver specifications and is sufficient for vehicle-level positioning. 10-metre CEP in urban environments accounts for multipath from buildings and signal attenuation. These values enable the dispatch decision support module to correctly identify which unit is closest to an incident — position errors exceeding 10 metres in dense urban areas could cause incorrect closest-unit recommendations. | Test | subsystem, mobile-data, avl, session-258 |
| SUB-REQS-045 | The CJIS Query Proxy SHALL process NCIC/state criminal justice database queries from authenticated field MDTs and return results within 3 seconds of query submission under normal network conditions. Rationale: Field officers need NCIC query results within 3 seconds to maintain situational safety during traffic stops and field contacts. Beyond 3 seconds, officers may proceed without criminal history information, creating a safety risk. The CJIS Query Proxy handles query routing, response parsing, and audit logging as a centralized control point, which simplifies CJIS compliance auditing compared to distributed query endpoints. | Test | subsystem, mobile-data, cjis, session-258 |
| SUB-REQS-046 | The CJIS Query Proxy SHALL enforce CJIS Security Policy v5.9 requirements including FIPS 140-2 validated encryption for data at rest and in transit, advanced authentication for all query operators, and immutable audit logging of every query with operator ID, query type, timestamp, and result disposition. Rationale: CJIS Security Policy v5.9 is a mandatory federal compliance requirement for any system accessing criminal justice databases. FIPS 140-2 encryption, advanced authentication, and comprehensive audit logging are the three pillars of CJIS compliance. The CJIS Query Proxy is the PSAP's boundary for criminal justice data — if it fails compliance, the entire agency loses NCIC access, preventing field officers from running wants/warrants checks. | Inspection | subsystem, mobile-data, cjis, session-258 |
| SUB-REQS-047 | The FirstNet LTE Communications Module SHALL operate on Band 14 (758-768 MHz / 788-798 MHz) with Quality Priority and Preemption (QPP) enabled, maintaining data connectivity for public safety traffic when commercial network capacity is exhausted. Rationale: Band 14 is the dedicated FirstNet public safety spectrum allocated by the FCC Middle Class Tax Relief and Job Creation Act of 2012. QPP ensures public safety data traffic is prioritised over commercial users during network congestion. Operating on Band 14 is mandatory for FirstNet subscriber devices. Maintaining connectivity during commercial network congestion events (concerts, disasters) is critical because those are precisely the events generating the highest emergency call volumes. | Test | subsystem, mobile-data, firstnet, session-258 |
| SUB-REQS-048 | When Band 14 FirstNet coverage is unavailable, the FirstNet LTE Communications Module SHALL automatically roam to commercial LTE networks within 10 seconds, maintaining all active data sessions without requiring MDT operator intervention. Rationale: FirstNet Band 14 coverage does not reach all areas, particularly rural zones and building interiors. Automatic roaming to commercial LTE within 10 seconds ensures field units maintain data connectivity for dispatch and CJIS queries. Session persistence prevents loss of in-progress CJIS query results or dispatch acknowledgments during the handover. Without automatic roaming, units in coverage gaps would lose all MDT functionality. | Test | subsystem, mobile-data, firstnet, session-258 |
| SUB-REQS-049 | The Mobile Data Terminal Application SHALL provide one-touch status update capability allowing field units to transmit status changes (En Route, On Scene, Available, Out of Service) to the CAD system within 1 second of operator input. Rationale: Field units spend significant time on status updates (arriving on scene, going available, going out of service). One-touch status updates reduce the time officers spend interacting with the MDT while driving, improving safety. Sub-2-second update propagation to CAD ensures dispatchers see current unit status and can make correct dispatch decisions — stale status data leads to dispatching units that are already committed to other incidents. | Test | subsystem, mobile-data, mdt, session-258 |
| SUB-REQS-050 | The Incident Report Database SHALL store a minimum of 10 years of incident records (approximately 1 million records per year for a metropolitan PSAP) with full-text indexing and maintain query response times of 2 seconds or less for single-field searches. Rationale: State records retention statutes typically require 7-10 years of incident record retention. A metropolitan PSAP handling approximately 1 million incidents per year accumulates significant data volume. Sub-5-second query response on 10 years of data is necessary for investigative searches during active incidents where officers need prior incident history at a location. Full-text indexing enables narrative field searches that structured queries cannot satisfy. | Test | subsystem, records-management, session-258 |
| SUB-REQS-051 | The Retention and Purge Manager SHALL enforce configurable retention schedules per record type (incident reports, audio recordings, CAD event logs, radio transmissions) and SHALL suspend purge operations for any record subject to an active legal hold, producing a certified purge audit log with cryptographic hash verification for each deletion batch. Rationale: Records retention compliance is mandated by state law and subject to audit. Configurable schedules are necessary because different record types have different retention periods set by statute. Legal hold suspension prevents destruction of records subject to litigation or active investigation, which would constitute spoliation of evidence. Without automated purge management, manual deletion is error-prone and risks either premature destruction or unbounded storage growth. | Test | subsystem, records-management, session-258 |
| SUB-REQS-052 | The Report Generation Module SHALL generate FBI UCR and NIBRS-compliant submissions from incident data without manual data entry, producing monthly statistical reports within 4 hours of scheduled execution for datasets exceeding 100,000 incidents. Rationale: FBI UCR and NIBRS submissions are federal reporting mandates for law enforcement agencies. Automated generation eliminates manual data entry errors that have historically caused agencies to submit incorrect crime statistics. 4-hour execution time for monthly reports is acceptable for overnight batch processing. Without automated reporting, records staff spend 2-3 days per month on manual data extraction and formatting. | Test | subsystem, records-management, session-258 |
| SUB-REQS-053 | The Records Search and Retrieval Engine SHALL enforce role-based access control with a minimum of 5 permission tiers (public records clerk, investigator, supervisor, records administrator, system administrator) and SHALL automatically redact sealed juvenile records, protected witness information, and undercover officer identities from search results for unauthorized roles. Rationale: Role-based access control with 5 tiers prevents unauthorized access to sensitive records. Sealed juvenile records and protected caller information (domestic violence victims, informants) have legal restrictions on who may view them. Without granular RBAC, either everyone has access to sensitive records (legal violation) or access is so restricted that authorized personnel cannot perform their duties. The 5-tier structure maps to common PSAP organisational roles. | Test | subsystem, records-management, session-258 |
| SUB-REQS-054 | The Incident Report Database SHALL encrypt all data at rest using AES-256 with key management compliant with CJIS Security Policy v5.9, and SHALL maintain encrypted automated backups with a recovery point objective (RPO) of 1 hour and recovery time objective (RTO) of 4 hours. Rationale: CJIS Security Policy requires AES-256 encryption for criminal justice data at rest. The Incident Report Database contains caller PII, witness information, and linked CJIS query results that are subject to this policy. RPO of 15 minutes limits data loss to at most one major incident's worth of records. Without encrypted backups, a stolen backup tape would expose protected criminal justice information. | Test | subsystem, records-management, session-258 |
| SUB-REQS-055 | The Core LAN Switching Fabric SHALL achieve 99.999% availability measured annually through dual redundant core switches in an active-active topology with sub-50ms failover via Virtual Switching System or equivalent chassis redundancy, ensuring zero packet loss during any single switch or link failure. Rationale: NFPA 1221 requires 99.999% availability for PSAP communications infrastructure. The Core LAN carries all inter-subsystem traffic including life-safety SIP calls — any LAN failure causes total PSAP outage. Active-active topology with sub-50ms failover ensures no call-in-progress is dropped during a single switch failure. This is the most critical availability requirement in the system because every other subsystem depends on LAN connectivity. | Test | subsystem, network-infrastructure, core-lan, session-259, duplicate-of-SUB-REQS-056 |
| SUB-REQS-056 | The Core LAN Switching Fabric SHALL achieve 99.999% availability measured annually through dual redundant core switches in an active-active topology with sub-50ms failover via Virtual Switching System or equivalent chassis redundancy, ensuring zero packet loss during any single switch or link failure. Rationale: DUPLICATE OF SUB-REQS-055: This requirement duplicates the Core LAN Switching Fabric availability requirement. Tagged for removal during next review. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-057 | The Core LAN Switching Fabric SHALL enforce VLAN segmentation with a minimum of four isolated network zones: voice/SIP signalling, CAD/records data, CJIS-restricted traffic, and network management, with inter-VLAN traffic permitted only through the Firewall and Intrusion Prevention System. Rationale: CJIS Security Policy v5.9 mandates network segmentation between CJIS-connected systems and other network traffic. Inter-VLAN ACLs prevent lateral movement if one zone is compromised. Voice VLAN isolation ensures QoS for emergency calls. Four zones is the minimum: voice (SIP/RTP), data (CAD/Records), CJIS (criminal justice queries), and management (SNMP/syslog). Without segmentation, a compromised workstation could access NCIC databases directly. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-058 | The Core LAN Switching Fabric SHALL provide minimum 10 Gbps aggregate inter-switch link capacity and 1 Gbps to each access port, with Quality of Service policies guaranteeing strict priority queuing for voice VLANs with maximum 5ms one-way latency and less than 0.1% packet loss under full load. Rationale: 10 Gbps inter-switch capacity supports concurrent traffic from 150 SIP sessions (each ~100 Kbps = 15 Mbps), GIS tile serving (burst to 500 Mbps), CAD database replication, and CJIS query traffic. 1 Gbps access ports serve individual workstations and servers. Strict priority queuing for DSCP EF voice traffic guarantees that data bursts cannot cause voice jitter, which is essential for call-taker comprehension during stressful incidents. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-059 | The WAN and ESInet Gateway SHALL maintain dual redundant WAN uplinks from physically diverse carriers with automatic failover via VRRP or HSRP, achieving route convergence within 5 seconds of primary carrier failure without dropping active SIP sessions or requiring ESInet re-registration. Rationale: Dual diverse-carrier WAN uplinks are required because the ESInet is the sole ingress path for NG9-1-1 calls. A single-carrier failure (fiber cut, provider outage) would cause complete loss of emergency call reception. 5-second convergence via VRRP/HSRP ensures callers experience at most one ring-back delay during failover. Physical carrier diversity means independent last-mile paths to the PSAP. | Test | subsystem, network-infrastructure, wan-esinet, session-259 |
| SUB-REQS-060 | The WAN and ESInet Gateway SHALL implement BGP peering with the ESInet service provider and policy-based routing that prioritises NG9-1-1 SIP INVITE and BYE signalling traffic over all other WAN flows, with a minimum committed information rate of 100 Mbps per WAN link. Rationale: BGP peering with the ESInet provider is the standard routing protocol for NG9-1-1 interconnection. Policy-based routing prioritising SIP INVITE and BYE ensures call setup and teardown are never delayed by bulk traffic. Without SIP priority, a large CAD-to-CAD data sync or GIS tile update could delay emergency call delivery. MPLS VPN termination for inter-PSAP links enables mutual aid call transfer during major incidents. | Test | subsystem, network-infrastructure, wan-esinet, session-259 |
| SUB-REQS-061 | The Firewall and Intrusion Prevention System SHALL enforce CJIS Security Policy v5.9 network segmentation by restricting CJIS-zone traffic to authorised protocols and destinations only, terminating IPsec VPN tunnels for NCIC/state database queries, and blocking all unauthorised inter-zone traffic with default-deny policies on all interfaces. Rationale: CJIS Security Policy v5.9 compliance is a federal mandate for any PSAP querying NCIC or state criminal justice databases. Failure to enforce network segmentation can result in decertification and loss of CJIS access. IPsec VPN termination at the firewall is required for field MDT queries arriving over FirstNet. 5 Gbps throughput with IPS enabled ensures security inspection does not create a bottleneck for the PSAP's aggregate traffic. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| SUB-REQS-062 | The Firewall and Intrusion Prevention System SHALL operate in an active-passive high-availability configuration with stateful session failover completing within 1 second, and SHALL process a minimum of 5 Gbps throughput with IPS signatures enabled without adding more than 1ms latency to voice VLAN traffic. Rationale: Active-passive HA with stateful failover ensures existing TCP sessions (including active CJIS queries and SIP signalling) survive a firewall failure without requiring re-authentication. Sub-1-second failover prevents call drops during firewall failure. 5 Gbps throughput matches the aggregate WAN and inter-VLAN traffic capacity of the PSAP. Without HA, a single firewall failure would isolate all PSAP subsystems from the ESInet and WAN. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| SUB-REQS-063 | The Network Management and Monitoring System SHALL poll all network infrastructure devices via SNMP v3 at intervals not exceeding 60 seconds, aggregate syslog messages from all devices in real-time, and generate alerts within 30 seconds of detecting link failure, CPU utilisation exceeding 80%, or voice VLAN latency exceeding 5ms. Rationale: 60-second SNMP polling detects infrastructure faults within the NFPA 1221 required 2-minute notification window. Real-time syslog aggregation captures transient events (link flaps, authentication failures) that polling misses. Generating alerts when bandwidth exceeds 70% of capacity enables proactive capacity management before congestion affects voice quality. Historical data retention enables post-incident analysis of network performance during high-load events. | Test | subsystem, network-infrastructure, nms, session-259 |
| SUB-REQS-064 | The Time Synchronization Service SHALL provide Stratum-1 NTP time from dual GPS-disciplined clocks with OCXO holdover, achieving time accuracy within 1ms of UTC for all NTP clients and within 100 microseconds for IEEE 1588 PTP clients, with holdover drift not exceeding 10 microseconds per hour during GPS signal loss. Rationale: Stratum-1 NTP from GPS-disciplined clocks provides the most accurate time source available to the PSAP. Dual clocks provide redundancy — a single GPS receiver failure must not compromise time synchronization. OCXO holdover maintains microsecond accuracy for hours during GPS signal loss. 1ms NTP accuracy is sufficient for incident timeline correlation. 100-microsecond PTP accuracy is required by the call recording system for precise audio timestamp alignment during multi-channel recording. | Test | subsystem, network-infrastructure, time-sync, session-259 |
| SUB-REQS-065 | The DNS and DHCP Services SHALL operate as active-active redundant server pairs with zone transfer replication completing within 5 seconds, achieving DNS query resolution within 10ms for internal zones, and SHALL provide DHCP address assignment with VLAN-specific scopes including NTP server, TFTP boot server, and default gateway options. Rationale: Active-active DNS servers prevent DNS as a single point of failure — if DNS fails, NG9-1-1 SIP URI resolution fails and all call routing stops. 5-second zone transfer replication ensures both servers have consistent records after changes. 10ms query resolution for internal zones ensures SIP call setup is not delayed by DNS lookups. DHCP with PSAP-specific options automates provisioning of IP phones, workstations, and network devices, reducing manual configuration errors. | Test | subsystem, network-infrastructure, dns-dhcp, session-259 |
| SUB-REQS-066 | The Uninterruptible Power Supply System SHALL provide N+1 redundant online UPS modules delivering conditioned AC power to all network equipment racks, with minimum 30 minutes battery runtime at full load and automatic transfer switch cutover to generator power within 10 seconds of mains failure per NFPA 1221. Rationale: N+1 UPS redundancy ensures that a single UPS module failure does not cause network equipment power loss. 30-minute battery runtime at full load provides sufficient time for generator startup (typically 10-30 seconds) plus margin for generator failure and manual intervention. Automatic transfer to generator power within 10 seconds limits the UPS battery drain period. Without UPS, a utility power interruption causes immediate PSAP outage. | Test | subsystem, network-infrastructure, ups, session-259 |
| SUB-REQS-067 | The Firewall and Intrusion Prevention System SHALL update intrusion prevention signatures at least every 4 hours from the vendor threat intelligence feed, and SHALL generate real-time alerts to the Network Management and Monitoring System for any detected intrusion attempt targeting PSAP systems. Rationale: IPS signatures must be updated frequently because new vulnerabilities and attack patterns emerge daily. 4-hour update intervals balance signature currency against update processing overhead. Real-time alerts to the Network Management System ensure security events are visible to PSAP supervisors. The firewall is the primary defense against network-based attacks on life-safety infrastructure — outdated signatures leave known attack vectors undetected. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| IFC-DEFS-001 | The interface between ESInet SIP Gateway and Automatic Call Distribution Engine SHALL transfer authenticated SIP sessions via internal SIP trunk using TCP/TLS on port 5061, carrying caller PIDF-LO location, ANI, and media session descriptors at a rate supporting 150 concurrent session setups with less than 50ms interface latency. Rationale: This interface carries all emergency calls from protocol termination to routing. TCP/TLS on port 5061 is the NENA i3 standard for secured SIP signaling between ESInet elements. PIDF-LO location must traverse this interface because the ACD needs location for geographic routing decisions. The 50ms latency ceiling ensures gateway-to-ACD handoff does not consume more than 2.5 percent of the 2-second end-to-end budget. | Test | interface, call-handling, session-253 |
| IFC-DEFS-002 | The interface between ANI/ALI Database Interface and Call-Taker Workstation SHALL deliver location data as a structured JSON object containing civic address, geodetic coordinates (WGS84 latitude/longitude with confidence ellipse), location source type, and timestamp, via internal REST API over HTTPS with response time below 500ms. Rationale: Structured JSON with civic address, geodetic coordinates, and confidence ellipse enables the workstation to plot the caller on the GIS map with appropriate uncertainty visualization. WGS84 is the standard datum for NG911 location. The 500ms response time is allocated from the 2-second end-to-end budget after gateway and ACD processing, leaving margin for workstation rendering. | Test | interface, call-handling, session-253 |
| IFC-DEFS-003 | The interface between Text-to-911 Gateway and Automatic Call Distribution Engine SHALL present text sessions as queueable call objects with priority level, session identifier, originating number, and initial message text, using the same internal SIP signalling path as voice calls to enable unified ACD routing and queue management. Rationale: Presenting text sessions as SIP call objects through the same signaling path as voice enables the ACD to apply identical routing rules, queue management, and overflow logic to both media types. This unified approach derives from SYS-REQS-009 equitable access requirement and avoids maintaining a parallel routing system for text that would double the configuration complexity and diverge routing behavior. | Test | interface, call-handling, session-253 |
| IFC-DEFS-004 | The interface between Call Recording System and audio sources (ESInet SIP Gateway and Call-Taker Workstation) SHALL tap caller and dispatcher audio streams via SIPREC (RFC 7866) or port mirroring, delivering media to the recording system without introducing more than 1ms additional latency on the live audio path. Rationale: SIPREC (RFC 7866) is the IETF standard for session recording and provides metadata-rich recording without modifying the live audio path. The 1ms maximum added latency ensures recording does not degrade voice quality or introduce perceptible delay. Tapping both caller and dispatcher channels separately enables independent playback during incident review and legal proceedings. | Test | interface, call-handling, session-253 |
| IFC-DEFS-005 | The interface between Call-Taker Workstation and Computer-Aided Dispatch Subsystem SHALL transmit incident creation requests containing incident type, location (civic and geodetic), caller ANI, call-taker notes, and priority level via bi-directional API over HTTPS, with the CAD returning an incident number acknowledgment within 1 second. Rationale: This is the primary handoff from call-taking to dispatch operations. Bi-directional API enables the CAD to return incident numbers and status updates to the call-taker workstation, maintaining situational awareness while the caller is still on the line. The 1-second acknowledgment target ensures the call-taker receives confirmation before releasing the caller, preventing lost incidents. | Test | interface, call-handling, cad, cross-subsystem, session-253 |
| IFC-DEFS-006 | The interface between Incident Management Engine and Dispatch Decision Support Module SHALL transmit incident objects containing incident type code, priority level, location coordinates (WGS84), incident narrative text, and hazard flags via an internal publish-subscribe message bus with delivery latency not exceeding 100ms and guaranteed at-least-once delivery. Rationale: Publish-subscribe decouples the IME from the recommendation engine, allowing the DDSM to be upgraded or scaled independently. 100ms delivery latency ensures recommendations begin computing immediately after incident creation. At-least-once delivery guarantees no incident is silently dropped during bus congestion. | Test | interface, cad, ime-ddsm, session-255 |
| IFC-DEFS-007 | The interface between Unit Tracking and Status Module and Dispatch Decision Support Module SHALL provide current unit position (WGS84 lat/lon), status code, unit type, capability set, and assigned district via a shared in-memory data store updated at the AVL refresh rate, with read latency not exceeding 10ms for the DDSM to query the full fleet status. Rationale: Shared in-memory data store chosen over message-based interface because the DDSM needs to query full fleet status synchronously when computing recommendations. 10ms read latency ensures fleet queries do not bottleneck the 2-second recommendation window in SUB-REQS-013. | Test | interface, cad, utsm-ddsm, session-255 |
| IFC-DEFS-008 | The interface between Dispatch Decision Support Module and Dispatcher Workstation Interface SHALL deliver ranked unit recommendations as a structured message containing unit ID, estimated travel time, distance, capability match score, and run-card compliance status, delivered within 200ms of recommendation computation completion. Rationale: Structured message with travel time, distance, capability match, and run-card compliance gives the dispatcher all information for an informed decision in a single view. 200ms delivery budget allocated from the overall 2-second recommendation window, with 1.8s for DDSM computation. | Test | interface, cad, ddsm-dwi, session-255 |
| IFC-DEFS-009 | The interface between Dispatcher Workstation Interface and Incident Management Engine SHALL transmit dispatch commands (unit assignment, status override, incident update, incident close) as authenticated transactions with the dispatcher's user ID, timestamp, and action payload, with command acknowledgement returned within 500ms. Rationale: Authenticated transactions with dispatcher user ID are legally required — every dispatch action must be attributable to an individual for liability. 500ms acknowledgement ensures the dispatcher knows the action was accepted before moving to the next incident, preventing double-dispatch errors. | Test | interface, cad, dwi-ime, session-255 |
| IFC-DEFS-010 | The interface between Incident Management Engine and CAD Database and Event Logger SHALL write all incident state transitions, dispatcher actions, and system events as immutable audit records via asynchronous write-ahead logging, with write acknowledgement within 50ms and guaranteed persistence within 1 second under normal operation. Rationale: Write-ahead logging with asynchronous persistence prevents the database write path from blocking incident state transitions. 50ms write acknowledgement ensures the IME can process the next transition immediately. 1-second persistence guarantee limits data loss to at most 1 second during catastrophic database failure. | Test | interface, cad, ime-cdel, session-255 |
| IFC-DEFS-011 | The interface between CAD Database and Event Logger and Supervisor Dashboard Module SHALL provide pre-aggregated operational metrics (queue depth, response time percentiles, unit utilisation by district) via a read-replica query endpoint, with metric staleness not exceeding 5 seconds and query response time under 200ms for the standard dashboard metric set. Rationale: Read-replica endpoint isolates supervisor query load from operational write path, preventing dashboard queries from degrading dispatch performance. 5-second staleness aligns with SUB-REQS-022. 200ms query response ensures dashboard renders without lag. | Test | interface, cad, cdel-sdm, session-255 |
| IFC-DEFS-012 | The interface between Dispatch Radio Console and Radio Gateway Controller SHALL transport bidirectional audio using RTP (RFC 3550) with IMBE vocoder payload over a dedicated VLAN, with maximum one-way latency of 50ms and packet loss below 0.1%, using RTCP for quality monitoring and DFSI (Digital Fixed Station Interface) signalling for PTT, channel grant, and emergency alert control messages. Rationale: RTP over dedicated VLAN isolates voice traffic from data to prevent dispatch audio degradation during surges. 50ms latency and 0.1% packet loss are ITU G.114 requirements for conversational voice quality. DFSI per TIA-102.BAHA is the P25 standard for fixed-station digital voice interface. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-013 | The interface between Radio Gateway Controller and Talkgroup Management Module SHALL exchange talk group affiliation commands, dynamic regrouping directives, and patch configurations via an internal API with maximum response latency of 500ms, and SHALL support atomic patch operations affecting up to 8 talk groups simultaneously. Rationale: 500ms API latency ensures talk group operations complete within the 3-second user-facing threshold in SUB-REQS-027. Atomic patch operations are critical because partial patches create one-way communication — field units believe they can communicate cross-agency but messages are not reaching all parties. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-014 | The interface between Radio Gateway Controller and Interoperability Gateway SHALL transport cross-system audio and ISSI signalling over dedicated IP trunks using TIA-102.BACA-A Group Call and Emergency Alert message formats, with maximum cross-system audio latency of 200ms one-way. Rationale: Dedicated IP trunks provide deterministic bandwidth for cross-system audio, unlike shared paths that congest during large incidents when interoperability traffic peaks. 200ms one-way accounts for additional transcoding and ISSI protocol overhead beyond the 50ms intra-system budget, staying within ITU 250ms conversational threshold. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-015 | The interface between Radio Logging Recorder and Radio Gateway Controller SHALL tap all audio streams using passive port mirroring or SIPREC (RFC 7866) without introducing latency or jitter to the live audio path, and SHALL deliver transmission metadata (unit ID, talk group, site ID, timestamp) as structured records alongside each audio segment. Rationale: Passive port mirroring or SIPREC ensures recording cannot introduce latency, jitter, or failure modes into the live audio path. Structured metadata alongside each audio segment enables automated indexing by unit ID, talk group, and timestamp, supporting the 2-second instant replay requirement in SUB-REQS-032. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-016 | The interface between Encryption Key Management Module and Radio Gateway Controller SHALL distribute traffic encryption keys (TEKs) using OTAR key management messages per TIA-102.AACA over the P25 control channel, with end-to-end key delivery confirmation and rollback capability if rekey fails on more than 5% of targeted radios. Rationale: OTAR key delivery over P25 control channel uses existing radio infrastructure. 5% failure threshold for rollback prevents a partially rekeyed fleet from becoming fragmented where some radios cannot communicate with others due to key mismatch. Rollback ensures return to known-good key state. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-017 | The interface between Computer-Aided Dispatch Subsystem and Dispatch Radio Console SHALL transmit incident-triggered talk group selection commands via a REST API over HTTPS, and SHALL support automatic channel assignment upon dispatch confirmation, delivering the assigned talk group to the console within 1 second of CAD dispatch action. Rationale: REST over HTTPS provides a simple, auditable interface between CAD and radio subsystems that can traverse network boundaries. 1-second channel assignment ensures the dispatcher has the correct talk group active before first radio transmission to the field, supporting the 2-keystroke dispatch workflow. | Test | interface, radio-comms, cross-subsystem, session-256 |
| IFC-DEFS-018 | The interface between Routing Engine and Dispatch Decision Support Module SHALL accept route computation requests containing origin coordinates (WGS84), destination coordinates, and vehicle type, and return travel time in seconds, distance in meters, and route geometry as an encoded polyline, with end-to-end request-response latency not exceeding 600ms including network overhead. Rationale: The Routing Engine must receive structured requests from the Dispatch Decision Support Module to compute optimal response routes. WGS84 coordinates ensure interoperability with the GIS spatial database, and vehicle type affects route constraints (e.g., ladder trucks cannot use low-clearance routes). Without this interface, the dispatch recommendation engine cannot factor travel time into unit selection. | Test | interface, gis, session-257 |
| IFC-DEFS-019 | The interface between Map Tile Server and Dispatcher Workstation Interface SHALL deliver map tiles using the XYZ tile protocol (z/x/y addressing) over HTTP with ETag-based caching, supporting both raster (PNG 256x256) and vector (MVT) tile formats, with the workstation client maintaining a local tile cache of at least 500MB to reduce server load during pan operations. Rationale: The Map Tile Server must deliver map imagery to dispatcher workstations using the XYZ tile protocol, the industry standard for web map tile delivery. ETag-based caching reduces redundant tile re-fetches during pan/zoom, which is critical when dispatchers are tracking 50+ incidents. Without efficient tile delivery, map rendering latency exceeds dispatcher tolerance (>200ms) and situational awareness degrades during high-volume events. | Test | interface, gis, session-257 |
| IFC-DEFS-020 | The interface between Geocoding Engine and ANI/ALI Database Interface SHALL accept raw caller address strings from ALI records and return validated WGS84 coordinates with MSAG validation status and confidence score, with request-response latency not exceeding 300ms to support real-time incident location during call processing. Rationale: The Geocoding Engine must resolve raw ANI/ALI address strings into WGS84 coordinates to place callers on the dispatch map. ALI records from legacy PSAPs often contain non-standard formatting requiring fuzzy matching. MSAG validation status is essential because unvalidated addresses may not correspond to real locations, affecting unit dispatch accuracy. Confidence scores enable the call-taker to assess location reliability before dispatching. | Test | interface, gis, session-257 |
| IFC-DEFS-021 | The interface between Mobile Data Terminal Application and FirstNet LTE Communications Module SHALL use a local USB 3.0 or embedded PCIe connection with a dedicated network adapter presenting as a standard TCP/IP interface, supporting minimum 50 Mbps sustained throughput. Rationale: The MDT Application requires a reliable local connection to the FirstNet LTE module for field data communications. USB 3.0 or PCIe provides the bandwidth and reliability needed for concurrent voice (MCPTT) and data (dispatch, CJIS queries) streams. Presenting as a standard network adapter simplifies MDT application development and allows standard IP stack management including VPN tunnels. | Test | interface, mobile-data, session-258 |
| IFC-DEFS-022 | The interface between FirstNet LTE Communications Module and Mobile Data Gateway Server SHALL use WebSocket over TLS 1.2+ with persistent connections, 15-second keepalive heartbeats, and automatic reconnection within 3 seconds of transport failure detection. Rationale: The FirstNet LTE module communicates with the PSAP gateway server over a cellular WAN link subject to intermittent connectivity. WebSocket over TLS provides persistent bidirectional communication needed for real-time dispatch updates. The 15-second keepalive detects link failure faster than TCP keepalive defaults (typically 2 hours), and automatic reconnection within 10 seconds prevents dispatch message loss during brief coverage gaps in urban/rural fringe areas. | Test | interface, mobile-data, session-258 |
| IFC-DEFS-023 | The interface between Mobile Data Gateway Server and CJIS Query Proxy SHALL use a dedicated IPsec VPN tunnel with AES-256 encryption, transmitting queries and responses in NLETS XML format with maximum 500ms gateway-to-proxy latency. Rationale: CJIS queries from field MDTs must traverse a dedicated IPsec VPN tunnel because CJIS Security Policy v5.9 mandates FIPS 140-2 validated encryption for all criminal justice data in transit. AES-256 meets this requirement. NLETS XML format is the national standard for law enforcement data exchange. The 3-second maximum latency threshold ensures field officers can complete wants/warrants checks during traffic stops before returning to the vehicle. | Test | interface, mobile-data, cjis, session-258 |
| IFC-DEFS-024 | The interface between Mobile Data Gateway Server and Incident Management Engine SHALL use a RESTful API over HTTPS with JSON payloads conforming to the NIEM Justice domain schema, delivering dispatch assignments with maximum 1-second API response time and supporting 50 concurrent dispatch transactions per second. Rationale: The Mobile Data Gateway Server must relay dispatch assignments from the Incident Management Engine to field units. NIEM Justice domain schema standardises the message format for dispatch data exchange across agencies. HTTPS with JSON ensures compatibility with modern MDT applications while meeting encryption requirements. Near-real-time delivery (<5 seconds) is essential so field units receive dispatch information before the radio voice dispatch, enabling simultaneous text and voice notification. | Test | interface, mobile-data, cross-subsystem, session-258 |
| IFC-DEFS-025 | The interface between Automatic Vehicle Location Module and Unit Tracking and Status Module SHALL transmit position reports as UDP datagrams containing unit ID, WGS84 latitude/longitude, heading, speed, and UTC timestamp, with reports aggregated by the Mobile Data Gateway and forwarded via TCP to the CAD at 5-second batch intervals. Rationale: The AVL Module must transmit position reports to the Unit Tracking and Status Module to enable real-time unit tracking on the dispatch map. UDP is chosen over TCP because position reports are time-sensitive and individually non-critical — a lost report is superseded by the next one in 10 seconds. Including heading and speed enables the dispatch decision support module to predict unit arrival times. The 10-second default balances position currency against cellular bandwidth consumption. | Test | interface, mobile-data, cross-subsystem, session-258 |
| IFC-DEFS-026 | The interface between Incident Report Database and CAD Database and Event Logger SHALL use database replication (logical replication or CDC) to synchronize closed incident records from CAD to the Records Management system within 60 seconds of incident closure, preserving all event log entries, timestamps, and unit assignments. Rationale: Closed incident records must flow from the live CAD database to the Records Management database to enable long-term records management, FOIA response, UCR/NIBRS reporting, and investigative case building without querying the live CAD system. Database replication or CDC ensures data consistency without requiring the Records Management system to understand CAD schema changes. This separation prevents records queries from affecting CAD operational performance during peak call volumes. | Test | interface, records-management, cross-subsystem, session-258 |
| IFC-DEFS-027 | The interface between Incident Report Database and Call Recording System SHALL link audio recordings to incident records using the incident case number as the foreign key, with recordings accessible via URI reference stored in the incident record and retrievable within 3 seconds of request. Rationale: Audio recordings must be linked to incident records for evidentiary, quality assurance, and liability purposes. Using the incident case number as foreign key ensures recordings are retrievable in the context of the incident they document. HTTP/HTTPS streaming access enables playback from the Records Search and Retrieval Engine without requiring direct database access to the call recording system's storage, supporting role-based access control at the application layer. | Test | interface, records-management, cross-subsystem, session-258 |
| IFC-DEFS-028 | The interface between Records Search and Retrieval Engine and Incident Report Database SHALL maintain a search index synchronized within 5 minutes of source record changes, supporting full-text search across incident narratives, structured field queries, and fuzzy name matching with configurable similarity threshold. Rationale: The Records Search and Retrieval Engine requires a synchronized search index to provide sub-2-second query responses across millions of records. The 5-minute synchronization window balances index freshness against reindexing overhead. Full-text search over narrative fields is essential for investigative use where structured queries are insufficient. Multi-field faceted search supports records clerks processing FOIA requests who need to filter by date range, incident type, and location simultaneously. | Test | interface, records-management, session-258 |
| IFC-DEFS-029 | The interface between Core LAN Switching Fabric and Firewall and Intrusion Prevention System SHALL use 802.1Q trunk ports carrying all inter-VLAN traffic, with the firewall enforcing access control lists on each VLAN sub-interface, supporting aggregate throughput of 5 Gbps with less than 1ms added latency. Rationale: All inter-VLAN traffic in the PSAP must pass through the firewall to enforce the network segmentation required by CJIS Security Policy v5.9. 802.1Q trunking carries multiple VLAN tags over shared physical links, which is necessary given the PSAP's multiple security zones (voice, data, CJIS, management). The firewall applies zone-based policies that prevent lateral movement between VLANs, which is critical because a compromise of the public-facing ESInet zone must not reach the CJIS-restricted zone. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-030 | The interface between Core LAN Switching Fabric and WAN and ESInet Gateway SHALL use dedicated 10 Gbps Ethernet links with 802.1Q tagging to separate ESInet-bound SIP signalling from general WAN traffic, with DSCP marking preserved end-to-end for QoS policy enforcement at the WAN edge. Rationale: ESInet-bound SIP signalling must be separated from general WAN traffic to ensure NG9-1-1 call setup latency is not affected by non-emergency traffic. 10 Gbps links provide headroom for concurrent SIP sessions (each <100 Kbps but requiring low jitter) plus bulk data transfers like CAD-to-CAD replication. 802.1Q tagging at the WAN gateway enables the firewall to apply different security policies to ESInet traffic versus internet-facing traffic. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-031 | The interface between WAN and ESInet Gateway and Firewall and Intrusion Prevention System SHALL carry all inbound ESInet and internet traffic through the firewall before reaching internal PSAP networks, with the firewall performing stateful inspection and IPS analysis on all WAN-originated flows. Rationale: All inbound ESInet and internet traffic must pass through the firewall before reaching internal PSAP systems to prevent external threats from directly accessing life-safety systems. The firewall inspects SIP messages for malformed headers and SIP-specific attacks, and blocks unauthorized traffic from the internet. Without this, a compromised ESInet peer or internet-facing service could directly access the CAD database or CJIS systems. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-032 | The interface between Network Management and Monitoring System and Core LAN Switching Fabric SHALL use SNMP v3 with authentication and encryption over the dedicated management VLAN, with the NMS polling each managed device at configurable intervals and receiving SNMP traps within 5 seconds of event generation. Rationale: SNMP v3 with authentication and encryption is mandated by CJIS Security Policy for network management traffic to prevent credential theft and configuration data exposure. The dedicated management VLAN isolates monitoring traffic from production voice and data streams. 60-second polling intervals provide sufficient granularity to detect link failures within the NFPA 1221 required notification window (2 minutes for critical infrastructure faults). | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-033 | The interface between Time Synchronization Service and Core LAN Switching Fabric SHALL distribute NTP on UDP port 123 to all PSAP hosts and IEEE 1588 PTP on UDP ports 319/320 to latency-sensitive subsystems, with the core switches supporting PTP boundary clock mode to maintain sub-100 microsecond accuracy across switch hops. Rationale: Accurate time synchronization is critical for incident timeline reconstruction, call recording timestamp correlation, and radio log synchronization. NTP provides millisecond-level accuracy sufficient for most PSAP systems. IEEE 1588 PTP provides microsecond-level accuracy required by the call recording system and radio logging recorder for precise timestamp correlation during multi-agency incident review. Dual time sources on separate VLANs ensure synchronization survives a single-point failure. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-034 | The interface between Uninterruptible Power Supply System and Core LAN Switching Fabric SHALL provide conditioned AC power via dedicated circuits to each network equipment rack, and SHALL report power status, battery charge level, load percentage, and environmental sensor readings to the Network Management and Monitoring System via SNMP v3. Rationale: Network equipment requires conditioned AC power from the UPS to prevent data loss and service interruption during utility power events. SNMP-based power monitoring enables the Network Management System to alert operators when battery runtime drops below safe thresholds, triggering controlled shutdown procedures before battery exhaustion. Without UPS status visibility, an unannounced power event could cause uncontrolled switch reboots and extended PSAP outage. | Inspection | interface, network-infrastructure, session-259 |
| IFC-DEFS-035 | The interface between Core LAN Switching Fabric and ESInet SIP Gateway SHALL carry SIP signalling and RTP media on a dedicated voice VLAN with DSCP EF marking, supporting minimum 150 concurrent SIP sessions with per-session bandwidth allocation of 100 kbps and maximum one-way latency of 5ms from switch port to switch port. Rationale: SIP signalling and RTP media for NG9-1-1 calls must traverse the Core LAN on a dedicated voice VLAN to receive DSCP EF priority marking, ensuring jitter below 30ms and packet loss below 0.1% as required for intelligible voice. Supporting 150 concurrent SIP sessions on the LAN segment matches the system capacity requirement (SYS-REQS-001). Without dedicated VLAN isolation and QoS marking, data bursts from CAD database queries or GIS tile serving could cause audible voice degradation. | Test | interface, network-infrastructure, cross-subsystem, session-259 |
| IFC-DEFS-036 | The interface between Firewall and Intrusion Prevention System and CJIS Query Proxy SHALL terminate IPsec VPN tunnels from field mobile data terminals, restricting CJIS query traffic to authorised source IPs and destination ports only, with mutual certificate authentication and AES-256 encryption per CJIS Security Policy v5.9. Rationale: CJIS queries from field MDTs arrive over FirstNet LTE and must be decrypted and re-validated at the PSAP perimeter firewall. IPsec tunnel termination at the firewall ensures criminal justice data is encrypted end-to-end between the MDT and the CJIS Query Proxy. Source IP and certificate-based authentication restricts access to authorized MDTs only, preventing unauthorized queries against NCIC databases which would constitute a federal CJIS policy violation. | Test | interface, network-infrastructure, cross-subsystem, session-259 |
| IFC-DEFS-037 | The interface between Incident Management Engine and Radio Communications Subsystem SHALL transmit station alerting commands containing incident type, address, assigned units, and talk group assignment via a dedicated API, triggering fire station alerting tones and printouts within 2 seconds of dispatch confirmation for all fire and EMS incidents. Rationale: Fire and EMS station alerting is the most time-critical post-dispatch action. The 2-second latency bound ensures turnout time begins immediately after dispatch confirmation, directly impacting NFPA 1221 alarm handling benchmarks. Dedicated API decouples CAD incident management from radio subsystem internals while ensuring all required dispatch data reaches station alerting equipment without manual re-entry. | Test | interface, cross-subsystem, session-261 |
| IFC-DEFS-038 | The interface between Records Search and Retrieval Engine and Spatial Database SHALL support geographic incident queries using point-radius and polygon-based spatial filters, returning all incident records within the specified area sorted by date, with query response time not exceeding 3 seconds for searches spanning up to 12 months of records. Rationale: Investigators and analysts require spatial queries against historical incident data for crime pattern analysis, resource allocation studies, and hazard mapping. The 3-second response ceiling ensures interactive use during active investigations. Point-radius and polygon filters cover the two dominant query patterns: proximity searches around a location and searches within jurisdictional or geographic boundaries. | Test | interface, cross-subsystem, session-261 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| ARC-DECISIONS-001 | ARC: System Decomposition — Seven subsystems chosen to reflect the real functional and procurement boundaries of a metropolitan PSAP. Call Handling is separated from CAD because telephony (SIP/CAMA) is a distinct technology domain from dispatch logic, typically procured from different vendors. GIS is separate rather than embedded in CAD because spatial data management (MSAG maintenance, layer updates, geocoding engine) has independent lifecycle and interfaces with multiple consumers (CAD, MDT, supervisory dashboard). Radio Communications is isolated because P25 infrastructure operates on dedicated RF spectrum with its own certification requirements. Mobile Data is separate from Radio because it uses cellular/FirstNet rather than LMR and has distinct security requirements (CJIS on public networks). Records Management spans all other subsystems as a cross-cutting concern but has its own storage, retention, and compliance requirements. Network Infrastructure underpins all subsystems and has distinct availability, redundancy, and cybersecurity requirements. Rationale: Seven subsystems reflect actual PSAP procurement and operational boundaries. Telephony, CAD, GIS, radio, mobile data, records, and network are procured from different vendors with independent maintenance cycles. This decomposition enables parallel development and independent upgrade paths, which is critical for a system that cannot be taken offline for upgrades. | Inspection | architecture, system-decomposition, session-252 |
| ARC-DECISIONS-002 | ARC: Call Handling Subsystem — Decomposed into five components reflecting the NG911 call processing pipeline: ESInet SIP Gateway (protocol termination), Automatic Call Distribution Engine (intelligent routing), ANI/ALI Database Interface (location/identity retrieval), Call-Taker Workstation (human-machine interface), Text-to-911 Gateway (text channel processing), and Call Recording System (evidentiary capture). This decomposition separates protocol-level concerns (SIP, HELD, MLP) from routing logic and presentation, enabling independent scaling of gateway capacity versus workstation count. The ACD is centralised rather than distributed because PSAP call volumes (typically under 200 concurrent) do not warrant distributed routing complexity, and centralised state simplifies overflow management to mutual aid partners. Rationale: The six-component pipeline separates protocol termination from routing logic and presentation, enabling the gateway to scale independently of workstation count. Centralised ACD is chosen over distributed routing because PSAP call volumes under 200 concurrent do not justify the complexity of distributed consensus, and centralised state simplifies mutual-aid overflow management. | Inspection | architecture, call-handling, session-253 |
| ARC-DECISIONS-003 | ARC: Call Handling Subsystem — Decomposed into five components reflecting the NG911 call processing pipeline: ESInet SIP Gateway (protocol termination), Automatic Call Distribution Engine (intelligent routing), ANI/ALI Database Interface (location/identity retrieval), Call-Taker Workstation (human-machine interface), Text-to-911 Gateway (text channel processing), and Call Recording System (evidentiary capture). This decomposition separates protocol-level concerns (SIP, HELD, MLP) from routing logic and presentation, enabling independent scaling of gateway capacity versus workstation count. The ACD is centralised rather than distributed because PSAP call volumes typically under 200 concurrent do not warrant distributed routing complexity, and centralised state simplifies overflow management to mutual aid partners. Rationale: DUPLICATE of ARC-DECISIONS-002. Created in error during session 253. Content is identical to ARC-DECISIONS-002 and should be disregarded. | Inspection | architecture, call-handling, duplicate-of-ARC-DECISIONS-002, session-260 |
| ARC-DECISIONS-004 | ARC: Computer-Aided Dispatch Subsystem — Decomposed into six components separating dispatch logic from data management and presentation. The Incident Management Engine centralises incident lifecycle control because NIMS/ICS classification rules must be applied consistently across all incident types and agencies, and distributed incident state would risk conflicting priority assignments during multi-agency events. The Dispatch Decision Support Module is separated from the Incident Management Engine because recommendation algorithms (proximity weighting, run-card rules, automatic dispatch timeouts) evolve independently of incident state management and can be upgraded without affecting incident integrity. Unit Tracking and Status Module is isolated because AVL data ingestion at 5-second intervals from 2000+ units is a distinct high-throughput concern from dispatch logic. The Dispatcher Workstation Interface is separated because UI refresh cycles, ergonomic requirements, and multi-monitor layout are HMI concerns independent of backend logic. CAD Database and Event Logger is separated because persistence, replication, and CJIS-compliant encryption are infrastructure concerns with their own availability requirements. Supervisor Dashboard Module is separated because supervisory aggregation and alerting operate on different refresh cadences and access control policies than dispatch operations. Rationale: CAD subsystem decomposition follows separation of concerns: incident lifecycle management, recommendation algorithms, fleet tracking, human-machine interface, persistence, and supervisory monitoring are each isolated because they have independent scaling, update, and availability requirements. | Inspection | architecture, cad, session-255, duplicate-of-ARC-DECISIONS-005 |
| ARC-DECISIONS-005 | ARC: Computer-Aided Dispatch Subsystem — Decomposed into six components separating dispatch logic from data management and presentation. The Incident Management Engine centralises incident lifecycle control because NIMS/ICS classification rules must be applied consistently across all incident types and agencies. The Dispatch Decision Support Module is separated because recommendation algorithms evolve independently of incident state management. Unit Tracking and Status Module is isolated because AVL data ingestion at 5-second intervals from 2000+ units is a distinct high-throughput concern. The Dispatcher Workstation Interface is separated because UI refresh cycles and ergonomic requirements are HMI concerns independent of backend logic. CAD Database and Event Logger is separated because persistence, replication, and CJIS-compliant encryption have their own availability requirements. Supervisor Dashboard Module is separated because supervisory aggregation operates on different refresh cadences and access control policies. Rationale: DUPLICATE OF ARC-DECISIONS-004: This architecture decision duplicates the Computer-Aided Dispatch Subsystem decomposition rationale. Tagged for removal during next review. | Inspection | architecture, cad, duplicate-of-ARC-DECISIONS-004, session-260 |
| ARC-DECISIONS-006 | ARC: Radio Communications Subsystem — Decomposed into six components separating the dispatcher-facing console from the RF network gateway, with dedicated modules for talk group management, inter-agency interoperability, radio logging, and encryption key management. The Radio Gateway Controller is the critical choke point: all dispatch-to-field audio flows through it, making it the single highest-availability component. Talkgroup Management is separated from the gateway because talk group configuration changes frequently (multiple times per shift during multi-agency incidents) while the gateway's channel-grant logic must remain stable. The Interoperability Gateway is isolated to contain the complexity of cross-vendor P25 ISSI bridging and prevent mutual-aid configuration changes from affecting primary dispatch communications. Radio Logging is separate from telephony call recording because radio recordings carry different metadata (unit ID, talk group, RF site) and have different retention/chain-of-custody requirements for law enforcement evidentiary use. Rationale: Radio subsystem decomposition separates console interface, gateway bridging, talk group management, interoperability, logging, and encryption because each has distinct protocol stacks, regulatory compliance requirements, and failure modes that must be independently testable and upgradeable. | Inspection | architecture, radio-comms, session-256 |
| ARC-DECISIONS-007 | ARC: Geographic Information System Subsystem — Decomposed into four components separating map rendering, address resolution, route computation, and geographic data management. The Map Tile Server is isolated because tile rendering is a high-throughput, cacheable workload that scales horizontally and independently of query-response services. The Geocoding Engine is separated because address normalization and MSAG validation require a specialized index distinct from the spatial query engine. The Routing Engine is separated because road-network graph computation is CPU-intensive with a distinct scaling profile from tile serving. The Spatial Database is shared infrastructure serving all three consumers, using PostGIS for standardized spatial query semantics. Rationale: Four GIS components separate concerns that have different performance profiles and update cycles: map rendering is read-heavy and cacheable, geocoding requires fuzzy text matching with MSAG validation, route computation is CPU-intensive graph traversal, and spatial data management has its own update and backup lifecycle. Combining these into a monolithic GIS would create contention between tile serving throughput and geocoding accuracy requirements. | Analysis | architecture, gis, session-257 |
| ARC-DECISIONS-008 | ARC: Mobile Data Subsystem — Five components chosen to separate the field-side hardware/software (MDT Application, AVL Module, FirstNet LTE Module) from PSAP-side middleware (Mobile Data Gateway Server, CJIS Query Proxy). The MDT Application is software-only because the hardware platform varies by agency and vehicle type. AVL is a separate module rather than embedded in the MDT because it has an independent GPS antenna and must report position even when the MDT application is not in active use. The CJIS Query Proxy is isolated from the Gateway Server because CJIS Security Policy requires a separate security boundary with dedicated audit logging, encryption certification, and access control — co-locating CJIS functions in the general-purpose gateway would require the entire gateway to meet CJIS audit scope, increasing compliance cost and reducing deployment flexibility. Rationale: Separating field-side components (MDT Application, AVL Module, FirstNet LTE Module) from server-side gateway components reflects the physical deployment boundary — field components run in vehicles on battery/alternator power over cellular, while server components run in the PSAP data centre on conditioned power with LAN connectivity. The CJIS Query Proxy is isolated because it handles criminal justice data subject to separate security certification requirements. | Inspection | architecture, mobile-data, session-258 |
| ARC-DECISIONS-009 | ARC: Records Management Subsystem — Four components chosen to separate data storage concerns (Incident Report Database) from access patterns (Records Search and Retrieval Engine), compliance automation (Retention and Purge Manager), and reporting obligations (Report Generation Module). The Search Engine is decoupled from the primary database to allow independent scaling of read-heavy search workloads without impacting transactional writes from CAD replication. The Retention and Purge Manager is a separate component rather than a database trigger because retention policies vary by jurisdiction and record type, change frequently with new legislation, and must produce independently auditable purge logs — embedding this logic in the database layer would make policy changes a database migration event rather than a configuration change. Rationale: Separating storage (Incident Report Database) from access patterns (Search and Retrieval Engine) from lifecycle management (Retention and Purge Manager) from output generation (Report Generation Module) isolates compliance concerns. Records retention is driven by statute, search access by RBAC policy, and reporting by federal mandates — each has different stakeholders and change drivers. A monolithic records system would make compliance audits harder and create unnecessary coupling between unrelated policy domains. | Inspection | architecture, records-management, session-258 |
| ARC-DECISIONS-010 | ARC: Network Infrastructure Subsystem - Decomposed into seven components separating data transport, external connectivity, security enforcement, operational visibility, time integrity, name/address services, and power resilience. Core LAN is the central convergence point with VLAN segmentation enforced at the firewall. WAN/ESInet Gateway is separated from the firewall because BGP peering policies change independently. Time Synchronization is standalone because NTP/PTP accuracy is a legal evidentiary requirement under NENA i3. Collapsing NMS, DNS, and NTP onto shared servers was rejected to prevent correlated failure. Rationale: Seven network components reflect the functional layers of a PSAP network: physical transport (Core LAN), external connectivity (WAN/ESInet Gateway), perimeter security (Firewall/IPS), operational visibility (NMS), time synchronisation, network services (DNS/DHCP), and power conditioning (UPS). Each has distinct failure modes, maintenance windows, and vendor relationships. Collapsing these would violate defence-in-depth principles where the security boundary must be independently managed from the transport layer. | Analysis | architecture, network-infrastructure, session-259 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| VER-METHODS-001 | Verify IFC-DEFS-001: Load test with 150 concurrent SIP INVITE transactions through the gateway-to-ACD interface. Measure interface latency at p50, p95, p99 percentiles. Pass criteria: p99 latency below 50ms, zero session setup failures, TLS handshake completion on all sessions. Rationale: Integration test at the gateway-to-ACD boundary validates the most critical internal interface in the call processing pipeline. P50/p95/p99 percentile measurement catches latency outliers that average measurements would mask. 150 concurrent sessions represents full system load. | Test | verification, call-handling, session-253 |
| VER-METHODS-002 | Verify IFC-DEFS-002: Submit location queries for wireline, wireless Phase II, and NG911 VoIP call scenarios. Validate JSON response schema completeness (civic, geodetic, source, timestamp fields present), coordinate accuracy against known test addresses, and response time under 500ms for each scenario. Rationale: Location data accuracy directly determines whether the correct unit is dispatched to the correct address. Testing against known addresses validates the full location pipeline from query to display. Schema completeness check ensures no downstream rendering failures when optional fields are missing from specific location sources. | Test | verification, call-handling, session-253 |
| VER-METHODS-003 | Verify IFC-DEFS-003: Inject 20 concurrent text-to-911 sessions via the gateway while 100 voice calls are active. Verify text sessions appear in the ACD queue with correct priority, are routed to available positions using skill-based rules, and achieve routing within the same 500ms target as voice calls. Rationale: Mixed-media load testing validates that text sessions do not degrade voice call routing under concurrent load. The 20 text plus 100 voice scenario represents a realistic peak ratio. Verifying skill-based routing for text sessions ensures dispatchers with text-handling training receive text calls, as required by ADA compliance. | Test | verification, call-handling, session-253 |
| VER-METHODS-004 | Verify IFC-DEFS-004: Establish 50 concurrent calls and verify 100% recording capture on both caller and dispatcher channels. Measure live audio path latency with and without recording tap active. Pass criteria: zero recording gaps, added latency below 1ms, SIPREC metadata correctly correlates recordings to call sessions. Rationale: Recording completeness verification is essential because any recording gap creates an evidentiary void. The latency measurement with and without recording tap active validates that the recording system does not degrade live call quality. SIPREC metadata correlation check ensures recordings can be associated with specific incidents for legal discovery. | Test | verification, call-handling, session-253 |
| VER-METHODS-005 | Verify IFC-DEFS-005: Create 50 incidents concurrently from workstation interface to CAD. Validate all required fields are transmitted, incident numbers are returned within 1 second, and bi-directional status updates flow back to the originating workstation. Inject malformed payloads to verify input validation. Rationale: Concurrent incident creation validates that the CAD interface handles peak dispatcher activity without queuing delays. Malformed payload injection validates input sanitization at the workstation-to-CAD boundary, critical because this interface crosses trust domains between call-taking and dispatch subsystems. | Test | verification, call-handling, cad, session-253 |
| VER-METHODS-006 | Verify SUB-REQS-001: Execute load test generating 150 concurrent SIP INVITE sequences from a SIP load generator through the ESInet SIP Gateway. Verify all sessions establish with TLS 1.2+ and SRTP. Pass criteria: 150/150 sessions established, zero TLS handshake failures, zero SRTP negotiation failures under sustained 10-minute load. Rationale: The SIP Gateway is the single entry point for all emergency calls, making its capacity the system bottleneck. Load testing at full rated capacity for 10 minutes validates sustained performance, not just burst handling. TLS and SRTP failure at any session breaks the security chain mandated by NENA i3. | Test | verification, call-handling, session-253 |
| VER-METHODS-007 | Verify SUB-REQS-009: With 100 active calls, induce primary gateway failure (process kill, network disconnect, power loss). Measure time to failover detection and session recovery on standby gateway. Pass criteria: failover within 500ms, zero calls dropped, all callers maintain audio continuity without re-dial. Rationale: Gateway failover is the highest-risk failure scenario because all active calls traverse this component. Testing three failure modes (process, network, power) ensures the failover mechanism handles different failure signatures. The zero-calls-dropped criterion is absolute because any dropped 911 call during failover could result in a caller being unable to reconnect. | Test | verification, call-handling, session-253 |
| VER-METHODS-008 | Verify IFC-DEFS-006: Inject 200 concurrent incident creation events into the IME and measure message delivery latency to the DDSM subscription endpoint. Pass criteria: 100% of messages delivered, p99 latency under 100ms, at-least-once delivery confirmed by sequence number audit with no gaps. Test under both normal load and 2x peak load conditions. Rationale: Integration test validating IME-to-event-logger interface throughput under peak load. 200 concurrent incidents simulates a major metro disaster scenario. Latency measurement confirms the interface does not bottleneck CAD event persistence. | Test | verification, cad, ime-ddsm, session-255 |
| VER-METHODS-009 | Verify IFC-DEFS-007: Populate the shared data store with 2000 simulated unit records updating at 5-second intervals. Execute 100 concurrent full-fleet read queries from the DDSM and measure read latency. Pass criteria: p99 read latency under 10ms, all unit records contain current position, status, type, capabilities, and district fields with no stale data beyond one AVL cycle. Rationale: Integration test validating unit tracking data store performance. 2000 units at 5-second intervals represents a large metro PSAP with mutual aid activation. Verifies the shared store handles sustained write throughput without query degradation. | Test | verification, cad, utsm-ddsm, session-255 |
| VER-METHODS-010 | Verify IFC-DEFS-008: Generate 50 concurrent recommendation messages from the DDSM and measure delivery to the target dispatcher workstation. Pass criteria: all messages delivered within 200ms, message payload contains unit ID, travel time, distance, capability score, and run-card compliance fields with correct data types and valid ranges. Rationale: Integration test validating dispatch recommendation delivery to dispatcher workstations. 50 concurrent messages simulates peak multi-incident scenario. | Test | verification, cad, ddsm-dwi, session-255 |
| VER-METHODS-011 | Verify IFC-DEFS-009: Execute 100 dispatch command transactions from the DWI to IME including unit assignment, status override, incident update, and incident close. Pass criteria: all commands acknowledged within 500ms, each acknowledgement contains matching dispatcher user ID and timestamp, failed authentication attempts are rejected with appropriate error codes. Rationale: End-to-end test validating the dispatcher command interface to the incident management engine. Covers the critical dispatch path. | Test | verification, cad, dwi-ime, session-255 |
| VER-METHODS-012 | Verify IFC-DEFS-010: Generate 5000 incident events per minute through the IME and verify all events are persisted to the database. Pass criteria: write acknowledgement within 50ms for 99th percentile, all events persisted within 1 second verified by read-back, audit records are append-only with no UPDATE or DELETE operations permitted, unclean shutdown test confirms no more than 1 second of event loss. Rationale: Stress test validating CAD event persistence under extreme throughput. 5000 events per minute exceeds normal operations by 10x to verify the database handles surge conditions during major incidents. | Test | verification, cad, ime-cdel, session-255 |
| VER-METHODS-013 | Verify IFC-DEFS-011: With 500 active incidents and 2000 tracked units generating continuous events, query the supervisor dashboard metric set from the read replica. Pass criteria: metric staleness under 5 seconds measured by comparing metric timestamps to primary write timestamps, query response under 200ms for the complete standard metric set, metrics include queue depth, response time percentiles, unit utilisation, and incident counts. Rationale: Performance test validating supervisor dashboard responsiveness under realistic operational load. 500 active incidents and 2000 units represents a major metropolitan emergency scenario. | Test | verification, cad, cdel-sdm, session-255 |
| VER-METHODS-014 | Verify IFC-DEFS-012: Inject synthetic RTP streams from console to gateway at maximum load (48 simultaneous channels) and measure one-way latency using hardware timestamping. Pass criteria: p99 latency below 50ms and packet loss below 0.1% sustained over 8-hour test. Verify DFSI PTT signalling round-trip within 100ms using protocol analyser. Rationale: Stress test for radio console to gateway interface at maximum channel capacity. 48 simultaneous channels represents full console utilization. Verifies audio quality is maintained under peak load. | Test | verification, radio-comms, session-256 |
| VER-METHODS-015 | Verify IFC-DEFS-013: Issue talk group affiliation, patch creation (2, 4, and 8 talk groups), and dynamic regrouping commands via API under concurrent load. Pass criteria: all operations complete within 500ms, 8-group atomic patch is applied atomically (no partial state observable), and affiliation table is consistent across primary and standby gateways. Rationale: Functional test for talkgroup management operations including multi-group patching. These are critical interoperability functions used during multi-agency responses. | Test | verification, radio-comms, session-256 |
| VER-METHODS-016 | Verify IFC-DEFS-014: Establish ISSI connections to at least 3 external P25 simulators from different vendors. Measure cross-system audio one-way latency. Pass criteria: latency below 200ms for 95th percentile over 4-hour test, ISSI Group Call and Emergency Alert messages conform to TIA-102.BACA-A wire captures. Rationale: Interoperability test validating ISSI gateway connections to external P25 systems. Multi-vendor testing is essential because interoperability failures only manifest at system boundaries between different vendor implementations. | Test | verification, radio-comms, session-256 |
| VER-METHODS-017 | Verify IFC-DEFS-015: Record 24 simultaneous talk group audio streams for 8 hours. Pass criteria: 100% of transmissions captured (verified against gateway PTT event log), zero frames dropped from live audio path (measured by comparing latency with and without recorder connected), metadata records contain unit ID, talk group, and timestamp for every transmission. Rationale: Endurance test validating radio logging recorder under sustained multi-channel recording. 24 talkgroups over 8 hours simulates a full operational shift. 100% capture rate is required because missed recordings have legal and evidentiary consequences. | Test | verification, radio-comms, session-256 |
| VER-METHODS-018 | Verify IFC-DEFS-016: Execute OTAR rekey of 100 simulated subscriber radios. Pass criteria: delivery confirmation received for all radios within 60 seconds, failed rekey (simulated on 10% of radios) triggers rollback that restores previous TEK on all targeted radios. Verify TIA-102.AACA message format compliance via protocol analysis. Rationale: Security test validating Over-The-Air Rekeying of subscriber radios. OTAR is critical for key compromise recovery — if rekeying fails, compromised encryption keys remain in use across the fleet. | Test | verification, radio-comms, session-256 |
| VER-METHODS-019 | Verify IFC-DEFS-017: Trigger 50 consecutive dispatch confirmations from CAD test harness. Pass criteria: assigned talk group delivered to console and console affiliates within 1 second for 100% of dispatches. Verify incorrect talk group assignment is rejected (negative test with invalid talk group ID). Rationale: Integration test validating automated talkgroup assignment from CAD dispatch. This interface determines which radio channel a responding unit monitors — incorrect assignment means the unit cannot communicate with the incident commander. | Test | verification, radio-comms, session-256 |
| VER-METHODS-020 | Verify SUB-REQS-026: With active voice paths established on 48 channels, trigger primary gateway failure (power cut). Pass criteria: standby assumes all sessions within 2 seconds, no voice paths dropped (verified by continuous audio tone monitoring), no PTT transmissions lost (verified by gateway event log comparison). Repeat 10 times. Rationale: Failover test for radio gateway — verifies that voice communications survive hardware failure. This is a life-safety test: if the radio gateway fails without automatic recovery, field units lose voice communication with dispatch. | Test | verification, radio-comms, session-256 |
| VER-METHODS-021 | Verify IFC-DEFS-018: Submit 100 concurrent route requests spanning the full jurisdiction with varying origin-destination distances. Pass: 95th-percentile response time below 600ms, route distance within 10% of ground truth for 90% of routes, all responses contain valid travel time, distance, and encoded polyline. Rationale: Performance test for routing engine throughput. 100 concurrent route requests validates that the dispatch decision support module can compute optimal unit assignments for multiple simultaneous incidents. | Test | verification, gis, session-257 |
| VER-METHODS-022 | Verify IFC-DEFS-019: Request tiles across zoom levels 10-18 from 24 simulated dispatcher workstations performing simultaneous pan operations. Pass: 95th-percentile tile delivery below 200ms, all tiles render correctly, ETag caching reduces server requests by at least 40% on repeated pan operations. Rationale: Load test for map tile serving under realistic multi-dispatcher usage. 24 workstations with simultaneous pan/zoom represents peak shift operations. Verifies map rendering remains responsive during high-activity periods. | Test | verification, gis, session-257 |
| VER-METHODS-023 | Verify IFC-DEFS-020: Submit 200 geocoding requests using raw ALI address strings including misspellings, abbreviations, and intersections. Pass: 95% resolve within 300ms, 90% resolve within 50m of correct location, MSAG validation correctly identifies non-valid addresses. Rationale: Accuracy test for geocoding engine using realistic ALI data quality. Raw ALI address strings with misspellings and abbreviations represent actual field conditions. MSAG validation ensures dispatch to valid response zones. | Test | verification, gis, session-257 |
| VER-METHODS-024 | Verify IFC-DEFS-021: Connect MDT application to FirstNet LTE module via USB 3.0 interface. Execute sustained file transfer test for 60 seconds measuring throughput. Pass criterion: sustained throughput >= 50 Mbps with zero connection drops. Rationale: Hardware interface test validating MDT-to-LTE module connectivity. USB 3.0 throughput test confirms the physical interface supports concurrent voice and data streams without bandwidth contention. | Test | verification, mobile-data, session-258 |
| VER-METHODS-025 | Verify IFC-DEFS-022: Establish 200 concurrent WebSocket sessions between simulated MDTs and Gateway Server over cellular network. Inject network disruptions (3G/LTE handoff, 5-second blackout). Pass criteria: all sessions maintain TLS 1.2+, heartbeat interval 15 +/- 1 seconds, reconnection completes within 3 seconds of transport failure. Rationale: Scale test for mobile data gateway under full fleet connectivity. 200 concurrent WebSocket sessions validates the server handles all field units simultaneously. Heartbeat and reconnection testing validates reliability over cellular links. | Test | verification, mobile-data, session-258 |
| VER-METHODS-026 | Verify IFC-DEFS-023: Submit 100 CJIS queries through the IPsec VPN tunnel. Capture packets to confirm AES-256 encryption and NLETS XML format. Measure gateway-to-proxy latency per query. Pass criteria: all traffic encrypted AES-256, all messages valid NLETS XML, 95th percentile latency <= 500ms. Rationale: Security compliance test for CJIS query encryption. Packet capture confirms AES-256 IPsec encryption is applied end-to-end. FIPS 140-2 compliance is a federal mandate — failure means loss of CJIS access. | Test | verification, mobile-data, cjis, session-258 |
| VER-METHODS-027 | Verify IFC-DEFS-024: Generate 50 concurrent dispatch transactions per second via REST API from Gateway to Incident Management Engine. Validate JSON payloads against NIEM Justice domain schema. Pass criteria: API response time <= 1 second at 50 TPS, all payloads schema-valid, zero dropped transactions. Rationale: Throughput test for dispatch assignment delivery via REST API. 50 concurrent transactions per second validates the interface under mass-casualty incident conditions where many units receive simultaneous dispatch. | Test | verification, mobile-data, cross-subsystem, session-258 |
| VER-METHODS-028 | Verify IFC-DEFS-025: Simulate 200 units transmitting AVL reports at 10-second intervals via UDP. Verify Gateway aggregates reports and forwards batches via TCP at 5-second intervals to Unit Tracking Module. Pass criteria: all position reports contain unit ID, WGS84 lat/lon, heading, speed, UTC timestamp; batch interval 5 +/- 0.5 seconds; zero data loss over 10-minute test. Rationale: Integration test for AVL position report delivery. Verifies the Unit Tracking module receives and processes GPS updates at the required rate for accurate unit tracking on the dispatch map. | Test | verification, mobile-data, cross-subsystem, session-258 |
| VER-METHODS-029 | Verify SUB-REQS-040: Instantiate 200 simulated MDT clients connecting to the Mobile Data Gateway Server. Verify all sessions achieve TLS 1.2+ handshake. Disconnect 20 clients and reconnect. Pass criteria: 200 concurrent sessions maintained, all TLS 1.2+, re-establishment within 3 seconds. Rationale: Data integrity test for incident record replication from CAD to Records Management. Ensures closed incidents are faithfully replicated for long-term retention, FOIA response, and statistical reporting. | Test | verification, mobile-data, session-258 |
| VER-METHODS-030 | Verify SUB-REQS-044: Deploy AVL Module in test vehicle. Collect 1000 position reports over a 2-hour route including open highway, urban streets, and parking structures. Compare against RTK-GPS reference receiver. Pass criteria: CEP <= 3m for open-sky segments, CEP <= 10m for urban segments. Rationale: Integration test for audio recording linkage to incident records. Verifies recordings are retrievable by incident case number, which is essential for evidentiary chain of custody. | Test | verification, mobile-data, avl, session-258 |
| VER-METHODS-031 | Verify IFC-DEFS-026: Close 100 incidents in CAD within a 5-minute window. Monitor replication lag to Records database. Pass criteria: all 100 incident records appear in Incident Report Database within 60 seconds of CAD closure, with all event logs, timestamps, and unit assignments intact. Rationale: Search performance test for Records Search and Retrieval Engine. Index synchronization within 5 minutes ensures recently closed incidents are searchable for active investigations. | Test | verification, records-management, session-258 |
| VER-METHODS-032 | Verify IFC-DEFS-027: Create 50 incidents with associated call recordings. Retrieve recordings via URI reference from incident records. Pass criteria: all 50 recordings retrievable within 3 seconds, audio playback matches original, incident case number linkage correct. Rationale: Security test for PSAP perimeter. Validates that the firewall correctly enforces inter-VLAN segmentation required by CJIS Security Policy v5.9. Unauthorized lateral movement between zones would compromise criminal justice data. | Test | verification, records-management, session-258 |
| VER-METHODS-033 | Verify IFC-DEFS-028: Insert 1000 incident records into the database. Measure time until full-text search index reflects new records. Execute fuzzy name search with known misspellings. Pass criteria: index synchronized within 5 minutes, fuzzy match returns correct records at 80% similarity threshold. Rationale: Security test for WAN traffic inspection. Ensures all ESInet and internet traffic passes through the firewall before reaching internal systems. Bypass would expose life-safety systems to external threats. | Test | verification, records-management, session-258 |
| VER-METHODS-034 | Verify IFC-DEFS-029: Configure 802.1Q trunk between core switches and firewall with all production VLANs. Generate 5 Gbps aggregate traffic across all VLANs simultaneously using traffic generators. Measure per-VLAN throughput and latency at the firewall sub-interfaces. Pass criteria: aggregate throughput sustained at 5 Gbps with less than 1ms added latency on voice VLAN, all VLAN ACLs correctly enforced with no cross-VLAN leakage. Rationale: Integration test for network monitoring via SNMP v3. Validates encrypted polling, syslog aggregation, and alerting. Network faults must be detected within the NFPA 1221 two-minute notification window. | Test | verification, network-infrastructure, session-259 |
| VER-METHODS-035 | Verify IFC-DEFS-030: Establish 10 Gbps Ethernet links between core switches and WAN routers with 802.1Q tagging. Inject mixed SIP and bulk data traffic. Verify DSCP EF marking is preserved on voice packets from LAN ingress through WAN egress using packet capture at both ends. Pass criteria: DSCP marking preserved on 100% of voice-tagged packets, no DSCP remarking or stripping observed at any hop. Rationale: Accuracy test for time synchronization infrastructure. NTP and PTP accuracy are verified against reference clocks. Timestamp accuracy is critical for incident timeline reconstruction and multi-channel audio correlation. | Test | verification, network-infrastructure, session-259 |
| VER-METHODS-036 | Verify IFC-DEFS-031: Inject simulated ESInet SIP traffic and known attack signatures through the WAN gateway toward internal networks. Verify all traffic traverses the firewall with stateful inspection and IPS analysis. Attempt direct bypass of firewall via routing manipulation. Pass criteria: 100% of WAN-originated traffic inspected by firewall, all known attack signatures detected and blocked, no bypass route exists to reach internal networks without firewall traversal. Rationale: Functional test for UPS power conditioning and status reporting. Validates battery runtime meets the 30-minute requirement and SNMP alerts reach the Network Management System before battery depletion. | Test | verification, network-infrastructure, session-259 |
| VER-METHODS-037 | Verify IFC-DEFS-032: Configure SNMP v3 polling from NMS to all managed devices on the management VLAN. Simulate device failure by disconnecting a switch uplink. Measure time from failure event to SNMP trap receipt at NMS. Verify SNMP v3 authentication and encryption using packet capture. Pass criteria: trap received within 5 seconds of event, all SNMP traffic encrypted and authenticated, no SNMP v1/v2c fallback observed. Rationale: Performance test for SIP signalling over the dedicated voice VLAN. 150 concurrent sessions validates system capacity requirement. DSCP EF marking verification ensures voice traffic receives priority queuing. | Test | verification, network-infrastructure, session-259 |
| VER-METHODS-038 | Verify IFC-DEFS-033: Configure PTP boundary clock mode on all core switches. Connect PTP slave clocks at call recording and radio logging subsystems. Measure PTP offset from grandmaster over 24 hours including simulated GPS antenna failure. Pass criteria: PTP clients maintain sub-100 microsecond offset during normal operation, NTP clients within 1ms, holdover drift within 10 microseconds per hour during GPS loss. Rationale: Precision time test for PTP distribution via core switches. PTP boundary clock mode is required for sub-microsecond accuracy to latency-sensitive subsystems. Verifies call recording timestamp alignment. | Test | verification, network-infrastructure, session-259 |
| VER-METHODS-039 | Verify IFC-DEFS-034: Inspect physical power distribution from UPS to each network equipment rack for dedicated circuit isolation. Simulate mains power failure and verify ATS transfers to generator within 10 seconds. Verify UPS SNMP v3 reporting of battery charge, load percentage, and environmental sensors to NMS. Pass criteria: each rack on independent circuit, ATS transfer within 10 seconds, all UPS parameters visible in NMS within 60 seconds of polling cycle. Rationale: Security test for field MDT CJIS query path through the firewall. Validates IPsec VPN termination and source authentication ensure only authorized MDTs can query NCIC databases. | Inspection | verification, network-infrastructure, session-259 |
| VER-METHODS-040 | Verify IFC-DEFS-035: Establish 150 concurrent SIP sessions via the ESInet SIP Gateway with RTP media on the voice VLAN. Measure per-session bandwidth, one-way latency at switch ports, and verify DSCP EF marking. Simultaneously inject background data traffic at 80% link utilisation. Pass criteria: all 150 sessions maintain less than 5ms switch-to-switch latency, DSCP EF marking on 100% of voice packets, no packet loss on voice VLAN during data traffic saturation. Rationale: Functional test for DNS and DHCP infrastructure. Validates active-active redundancy, zone transfer replication, and IP phone provisioning. DNS failure would halt NG9-1-1 SIP URI resolution. | Test | verification, network-infrastructure, cross-subsystem, session-259 |
| VER-METHODS-041 | Verify IFC-DEFS-036: Establish IPsec VPN tunnels from simulated field MDTs through the firewall to the CJIS Query Proxy. Verify mutual certificate authentication and AES-256 encryption using packet capture. Attempt CJIS query from unauthorised source IP. Attempt connection without valid certificate. Pass criteria: authorised MDT queries succeed with full encryption, unauthorised source IPs blocked, certificate-less connections rejected, all CJIS traffic encrypted with AES-256. Rationale: Security test for IPS signature update mechanism and alert generation. Validates that the firewall maintains current threat intelligence and notifies operators of detected intrusion attempts. | Test | verification, network-infrastructure, cross-subsystem, session-259 |
| VER-METHODS-042 | Verify SYS-REQS-012: Systematically disable each subsystem (CAD, GIS, Records, Mobile Data) while maintaining 150 concurrent call load. Measure call-to-dispatch time for Priority Emergency incidents in degraded state. Pass criteria: voice call processing continues without interruption, radio channel access maintained for all active talk groups, call-to-dispatch time not exceeding 120 seconds for 95th percentile of Priority Emergency incidents during each degraded scenario. Rationale: Degraded mode verification requires systematic fault injection to confirm each subsystem can be lost independently without violating the minimum dispatch capability. Testing at 150 concurrent calls validates the stated capacity floor under realistic load conditions. The 95th percentile measurement for call-to-dispatch time accounts for statistical variation while ensuring the 120-second ceiling is met for the vast majority of Priority Emergency incidents. | Test | verification, session-261 |
| VER-METHODS-043 | Verify SYS-REQS-013: Execute full-site failover drill disconnecting primary PSAP from network. Measure time from primary site isolation to backup site accepting emergency calls. Pass criteria: backup site processing 100% of call volume within 60 seconds of primary site disconnection, no calls lost during transition, all CAD data replicated to backup site within RPO of 30 seconds. Rationale: Site failover is a high-consequence, low-frequency event that must be validated before it is needed. A full-site disconnection drill is the only way to confirm the 60-second failover target and verify that no calls are lost during transition. The 30-second RPO for CAD data replication ensures dispatchers at the backup site have near-current incident state and do not lose recently created incidents. | Test | verification, session-261 |
| VER-METHODS-044 | Verify IFC-DEFS-037: Dispatch 20 fire and EMS incidents in rapid succession through the CAD. Measure time from dispatch confirmation to station alerting activation at target fire stations. Pass criteria: alerting tones and printouts activated at all assigned stations within 2 seconds of dispatch confirmation for 100% of dispatches, incident details on printout match CAD data exactly, talk group assignment matches dispatch assignment. Rationale: Rapid-succession dispatch testing validates the 2-second station alerting latency under burst conditions, not just single-incident scenarios. 20 fire and EMS incidents exercises the interface under realistic multi-alarm conditions. Exact data match verification ensures the API does not corrupt or truncate incident details during high-throughput operation. | Test | verification, session-261 |
| VER-METHODS-045 | Verify IFC-DEFS-038: Execute 50 spatial queries using point-radius (1km, 5km, 10km) and polygon filters against a database loaded with 1 million incident records spanning 12 months. Pass criteria: all queries return correct spatial results within 3 seconds, results correctly sorted by date, polygon queries correctly exclude incidents outside boundary. Rationale: Spatial query verification requires a realistic data volume (1 million records over 12 months) to stress-test index performance and confirm the 3-second response ceiling is achievable at production scale. Testing multiple radius values and polygon filters covers the full range of query patterns used by investigators and analysts in real PSAP operations. | Test | verification, session-261 |
flowchart TB n0["component<br>ESInet SIP Gateway"] n1["component<br>ACD Engine"] n2["component<br>ANI/ALI Interface"] n3["component<br>Call-Taker Workstation"] n4["component<br>Text-to-911 Gateway"] n5["component<br>Call Recording System"] n6["component<br>ESInet SIP Gateway"] n7["component<br>ACD Engine"] n8["component<br>ANI/ALI Interface"] n9["component<br>Call-Taker Workstation"] n10["component<br>Text-to-911 Gateway"] n11["component<br>Call Recording System"] n6 -->|SIP sessions| n7 n7 -->|Routed calls| n9 n8 -->|Location/identity data| n9 n10 -->|Text sessions| n7 n6 -->|Audio stream| n11 n9 -->|Dispatcher audio| n11 n6 -->|Call arrival trigger| n8
Call Handling Subsystem — Internal
flowchart TB n0["component<br>Dispatch Radio Console"] n1["component<br>Radio Gateway Controller"] n2["component<br>Talkgroup Management Module"] n3["component<br>Interoperability Gateway"] n4["component<br>Radio Logging Recorder"] n5["component<br>Encryption Key Management Module"] n6["actor<br>P25 Radio Infrastructure"] n7["actor<br>External Agency P25 Systems"] n8["actor<br>Dispatcher Workstation"] n8 -->|PTT commands, channel select| n0 n0 -->|RTP/RTCP audio, DFSI signalling| n1 n1 -->|P25 ISSI RF channel interface| n6 n1 -->|ISSI cross-system audio| n3 n3 -->|ISSI/CSSI mutual aid bridge| n7 n2 -->|Talk group affiliations, patches| n1 n0 -->|Talk group select, patch requests| n2 n4 -->|Audio tap, SIPREC recording| n1 n5 -->|TEK distribution, OTAR commands| n1
Radio Communications Subsystem — Internal
flowchart TB n0["component<br>Mobile Data Terminal Application"] n1["component<br>Mobile Data Gateway Server"] n2["component<br>CJIS Query Proxy"] n3["component<br>Automatic Vehicle Location Module"] n4["component<br>FirstNet LTE Communications Module"] n0 -->|App data over LTE| n4 n4 -->|Encrypted LTE transport| n1 n3 -->|GPS position data| n0 n1 -->|CJIS queries and responses| n2 n0 -->|NCIC query requests| n2
Mobile Data Subsystem — Internal
flowchart TB n0["component<br>Incident Report Database"] n1["component<br>Records Search and Retrieval Engine"] n2["component<br>Retention and Purge Manager"] n3["component<br>Report Generation Module"] n1 -->|Search queries| n0 n2 -->|Retention policy enforcement| n0 n3 -->|Report data extraction| n0
Records Management Subsystem — Internal
flowchart TB n0["component<br>Core LAN Switching Fabric"] n1["component<br>WAN and ESInet Gateway"] n2["component<br>Firewall and IPS"] n3["component<br>Network Management and Monitoring"] n4["component<br>Time Synchronization Service"] n5["component<br>DNS and DHCP Services"] n6["component<br>Uninterruptible Power Supply"] n0 -->|802.1Q trunk, inter-VLAN| n2 n0 -->|10G Ethernet, DSCP EF| n1 n1 -->|Inbound WAN inspection| n2 n3 -->|SNMP v3, syslog| n0 n4 -->|NTP/PTP distribution| n0 n5 -->|DNS queries, DHCP leases| n0 n6 -->|Conditioned AC power| n0 n6 -->|SNMP v3 power status| n3
Network Infrastructure Subsystem — Internal
| Entity | Hex Code | Description |
|---|---|---|
| ANI/ALI Database Interface | 40ED7159 | Automatic Number Identification and Automatic Location Identification query interface retrieving caller identity and location data. For wireline calls, queries ALI database via NENA-02-501 protocol. For wireless Phase II, retrieves location from MPC/GMLC via MLP or HELD protocol. For NG911, queries Location Information Server via HELD dereferencing. Returns location data within 2 seconds of call arrival. Provides civic address, geodetic coordinates with uncertainty, and location source metadata to the call-taker workstation display. |
| Automatic Call Distribution Engine | 51B77B19 | Intelligent call routing engine distributing incoming emergency calls to available call-taker positions based on configurable rules: skill-based routing (language, call type), geographic assignment, load balancing, and priority queuing. Maintains real-time state of all call-taker positions (available, busy, wrap-up, logged-out). Supports overflow routing to backup PSAPs and mutual aid partners. Routes calls within 500ms of SIP gateway handoff. Implements NENA i3 queue management with priority levels for callback, transfer, and text-to-911 sessions. |
| Automatic Vehicle Location Module | 55F57219 | GPS-based vehicle tracking module that collects position reports from field units at configurable intervals (default 10 seconds in-service, 60 seconds out-of-service). Receives NMEA 0183 data from vehicle-mounted GPS antenna, packages with unit ID and timestamp, and transmits to the Mobile Data Gateway. Supports geofencing for automatic status changes (e.g., arrival at incident scene). Position data feeds the CAD unit tracking display and GIS routing engine. Accuracy requirement: CEP 3m under open sky, 10m in urban canyon. |
| CAD Database and Event Logger | 40853358 | Persistent storage component for all CAD operational data including incident records, unit activity history, dispatch actions, and system audit trails. Uses a high-availability database cluster (active-passive with synchronous replication) to ensure zero data loss. Maintains incident records with full event chronology for post-incident analysis and legal discovery. Supports real-time queries for active incident lookups (sub-100ms response) and complex historical queries for reporting (response within 5 seconds for 90-day windows). Implements data retention policies compliant with state records retention statutes (typically 7-10 years for emergency call records). Provides CJIS-compliant encryption at rest and role-based access controls for sensitive incident data. Must sustain 5000+ write transactions per minute during peak operations. |
| Call Handling Subsystem | 50B57358 | NG911-compliant call reception and processing subsystem for a metropolitan PSAP. Receives voice calls via SIP trunking over ESInet, legacy CAMA trunks from PSTN, RTT text-to-911, and telematics data (ACN/connected vehicle) via NENA i3 ECRF/LVF. Performs ANI/ALI lookup for wireline, Phase II wireless ALI with uncertainty polygons, and device-based location for smartphones. Manages call queuing with priority override for callbacks and abandoned calls. Supports call transfer (blind/consultative) to secondary PSAPs and agencies. Handles 150+ concurrent calls during surge events with <15 second average queue time. Must maintain call audio throughout transfer chain. |
| Call Recording System | 54E53359 | Continuous audio and metadata recording system capturing 100% of emergency call audio, radio transmissions routed through the dispatch console, and text-to-911 session transcripts. Records in uncompressed PCM or G.711 codec at minimum 8kHz sample rate with NICL-compliant timestamping synchronized to GPS/NTP within 10ms. Stores recordings with incident correlation metadata (ANI, ALI, incident number, call-taker ID) for minimum retention period per state statutes (typically 90 days to 7 years). Supports instant playback for active incident review and forensic export in standard formats (WAV, MP3) with chain-of-custody metadata. |
| Call-Taker Workstation | D4AD7818 | Integrated dispatch position hardware and software providing call-takers with multi-screen display of caller location on GIS map, incident entry forms, call controls (answer, hold, transfer, conference, release), real-time text display for text-to-911, and protocol-guided interrogation scripts (EMD/EFD/EPD). Includes IP desk phone or USB headset with noise cancellation, dual or triple monitor configuration, and keyboard/mouse interface. Supports simultaneous handling of voice call and text session. Each workstation connects to the ACD for call state, ANI/ALI for location, and CAD for incident creation. |
| CJIS Query Proxy | 50A53859 | Security-hardened proxy server that mediates all Criminal Justice Information Services (CJIS) and NCIC database queries from field MDTs. Enforces CJIS Security Policy 5.9 requirements including advanced authentication, audit logging of every query, encryption at rest and in transit (FIPS 140-2), and operator certification validation. Routes queries to state CJIS switch via dedicated VPN tunnel. Supports vehicle registration, driver license, wanted persons, and stolen property queries with sub-3-second response time. |
| Computer-Aided Dispatch Subsystem | 51F77B59 | Core dispatch engine for a metropolitan PSAP handling 800,000+ calls/year across police, fire, and EMS disciplines. Creates incident records from call data, applies MPDS/EMD/EFD/EPD protocol-based priority classification, and recommends units based on proximity (AVL), capability, jurisdiction, and run card rules. Manages unit status lifecycle (available, dispatched, en route, on scene, transport, clear). Supports multi-agency incidents with unified command tracking. Provides real-time dashboard of pending calls, active incidents, and unit deployment. Maintains duplicate incident detection within 200m/5min window. Processes 2,000+ status changes per hour during peak operations. Must support configurable business rules per agency/jurisdiction. |
| Core LAN Switching Fabric | 50A57018 | Redundant Layer 2/Layer 3 Ethernet switching fabric forming the backbone of a Tier-1 PSAP network. Dual-stack core switches in a collapsed-core topology with sub-50ms failover via VSS or StackWise Virtual. Carries all inter-subsystem traffic including SIP signalling for NG9-1-1, RTP voice streams from radio consoles, CAD database replication, and GIS tile serving. Supports 802.1Q VLANs segregating voice, data, management, and CJIS traffic per NFPA 1221 and CJIS Security Policy v5.9. Minimum 10 Gbps inter-switch links with 1 Gbps access ports. Must sustain zero-packet-loss forwarding during failover of any single switch or link. |
| Dispatch Decision Support Module | 41F73B09 | Algorithmic recommendation engine that suggests optimal unit assignments for each incident based on multiple weighted criteria: geographic proximity (using road-network distance, not Euclidean), unit capability match (incident type vs unit type), current workload per unit, response time predictions using historical data and real-time traffic, and mutual aid agreements for cross-jurisdiction incidents. Implements automatic dispatch for high-priority calls when no dispatcher action occurs within configurable timeout (default 30 seconds). Supports run-card/response plan rules that define mandatory multi-unit responses for specific incident types (e.g., structure fire = 2 engines + 1 ladder + 1 battalion chief + 2 ambulances). Must generate recommendations within 2 seconds of incident creation. |
| Dispatch Radio Console | D0ED7018 | Multi-channel IP-based radio console system used by PSAP dispatchers to communicate with field units over P25 trunked radio. Supports simultaneous monitoring of 20+ talk groups, selective transmit on any monitored channel, emergency alert detection with automatic audio unmute, talk group patching for multi-agency incidents, and instant recall recording. Connects to Radio Gateway Controller via RTP/RTCP over dedicated VLAN. Primary human interface for voice dispatch — failure means dispatchers cannot communicate with police, fire, or EMS units. Typical implementations: Motorola MCC 7500/7600, Harris Symphony, Zetron ACOM. |
| Dispatcher Workstation Interface | 50ED7318 | The dispatch operator console providing the primary human-machine interface for emergency dispatchers. Displays an integrated view combining GIS map with unit positions, active incident list with priority color-coding, recommended unit assignments, call queue status, and radio channel assignments. Supports keyboard-driven workflows with single-keystroke dispatch commands for time-critical operations. Provides split-screen capability for handling multiple concurrent incidents. Integrates text messaging with field units via MDT interface. Renders incident timeline view showing all state transitions and associated units. Must achieve display refresh under 500ms for unit position updates and support 4+ simultaneous monitor outputs per dispatch position. Compliant with NENA PSAP ergonomic guidelines for 12-hour shift operation. |
| DNS and DHCP Services | 40B77318 | Redundant DNS and DHCP infrastructure for the PSAP providing name resolution and dynamic IP address management for all networked devices. Split-horizon DNS architecture: internal zones for PSAP hosts and external-facing zones for ESInet interoperability. DHCP with relay agents across VLANs, issuing addresses with VLAN-specific lease times and options (NTP server, TFTP for IP phone provisioning). Active-active DNS servers with zone transfer replication and sub-second failover. Critical dependency: if DNS fails, SIP URI resolution for NG9-1-1 call routing fails, and CAD-to-CAD links using DNS-based service discovery lose connectivity. |
| Emergency Dispatch System | 50F57BD9 | Public Safety Answering Point (PSAP) system for receiving, triaging, and dispatching emergency services (police, fire, EMS) in a mid-to-large metropolitan area serving 500,000+ population. Handles 911/999 voice calls, NG911 text-to-911, and telematics data. Integrates Computer-Aided Dispatch, GIS mapping, P25 digital radio, mobile data terminals, and records management. Must meet NENA i3 standards for NG911, NFPA 1221 for reliability (99.999% availability), and maintain sub-60-second call answer times per FCC benchmarks. Operates 24/7/365 with hot-standby failover. Interfaces with telephone service providers via ESInet, neighboring PSAPs for mutual aid, and state/federal reporting systems (NIBRS, NFIRS). |
| Encryption Key Management Module | 40B77B59 | P25 AES-256 encryption key management system supporting Over-the-Air Rekeying (OTAR) per TIA-102.AACA. Manages key encryption keys (KEKs) and traffic encryption keys (TEKs) for up to 5000 subscriber radios. Performs scheduled key rotation, emergency key zeroization, and selective unit revocation. Interfaces with Key Management Facility (KMF) and Key Fill Devices (KFDs). CJIS Security Policy v5.9 compliant for law enforcement radio encryption. |
| ESInet SIP Gateway | 50B57118 | Session Initiation Protocol gateway terminating incoming NG911 calls from the Emergency Services IP Network. Handles SIP INVITE, UPDATE, BYE, and REFER transactions for voice, RTT (real-time text), and video media. Performs SIP-to-internal call routing translation, enforces TLS 1.2+ mutual authentication with ESInet border control functions, and provides SRTP key negotiation for encrypted media. Must process concurrent SIP transactions for 150+ simultaneous calls with < 100ms call setup contribution. Interfaces with ECRF/LVF for location validation and with the ACD for call distribution. |
| Firewall and Intrusion Prevention System | 51B53959 | Next-generation firewall cluster providing stateful packet inspection, deep packet inspection, and inline intrusion prevention for the PSAP perimeter and internal zone boundaries. Enforces CJIS Security Policy v5.9 network segmentation: isolates CJIS-connected systems from general PSAP traffic, restricts inter-VLAN flows to authorised protocols and ports, and terminates IPsec VPN tunnels for NCIC/state CJIS queries from mobile data terminals via FirstNet. Active-passive HA pair with sub-second stateful failover. Processes up to 5 Gbps throughput with IPS enabled without exceeding 1ms added latency for voice traffic VLANs. |
| FirstNet LTE Communications Module | D4E55058 | Band 14 FirstNet LTE radio module embedded in or connected to the MDT providing priority and preemption (QPP) data connectivity for public safety. Supports LTE-A Cat 12 with peak 600 Mbps downlink. Implements MCPTT (Mission Critical Push-to-Talk) over LTE as backup voice path. Manages multiple APN profiles: primary FirstNet, secondary commercial LTE roaming, tertiary satellite backhaul for rural coverage. Includes embedded SIM with FirstNet subscriber identity. Antenna is vehicle-roof-mounted with 2x2 MIMO. |
| Geocoding Engine | 51F77159 | Address geocoding and reverse-geocoding service for the emergency dispatch system. Converts street addresses, intersections, and common place names to WGS84 coordinates for incident location plotting. Supports MSAG (Master Street Address Guide) validation for 911 address verification. Must resolve addresses within 200ms with fallback to coordinate-based location when address resolution fails. Maintains a local MSAG database synchronized with the regional addressing authority. |
| Geographic Information System Subsystem | 50F57318 | Spatial data engine and map display for a PSAP serving a metropolitan area of 1,500+ square miles. Provides real-time geocoding of addresses against MSAG-validated street centerline database with 98%+ first-attempt match rate. Displays AVL positions of 500+ field units updated every 10 seconds via GPS. Calculates drive-time routing for unit recommendation using real-time traffic data where available. Manages PSAP jurisdiction boundaries, police beats, fire districts, EMS zones, and mutual aid areas as spatial layers. Supports reverse geocoding for wireless Phase II lat/lon positions. Integrates aerial imagery, building footprints, and floor plans for large structures. Must re-render map view within 500ms of pan/zoom for dispatcher responsiveness. |
| Incident Management Engine | 51B57B59 | Core CAD component that creates, classifies, prioritises, and manages the full lifecycle of emergency incidents. Receives incident creation requests from Call-Taker Workstations (incident type, location, caller data, priority). Applies NIMS/ICS-based incident classification rules to assign priority levels (Emergency, Urgent, Routine). Manages incident state transitions: Created → Dispatched → En Route → On Scene → Resolved → Closed. Supports multi-agency incident merging when multiple calls reference the same event. Handles priority-based queuing with sub-second state transitions for high-priority events. Must support 500+ concurrent active incidents in a large metropolitan PSAP. |
| Incident Report Database | 40853359 | Relational database (typically Oracle or PostgreSQL) storing the canonical record of every emergency incident handled by the PSAP. Stores incident reports, unit activity logs, caller information, disposition codes, and linked multimedia (audio recordings, images). Must comply with state records retention statutes (typically 5-10 years for incident records, 30 days minimum for audio). Supports structured queries for statistical reporting (UCR/NIBRS), FOIA requests, and investigative case building. Read-heavy workload with complex joins across incident, unit, and caller tables. |
| Interoperability Gateway | 50A57858 | ISSI (Inter-RF Subsystem Interface) and CSSI (Console Subsystem Interface) gateway enabling cross-agency radio interoperability for mutual aid. Bridges P25 trunked systems from different vendors and different frequency bands (VHF, UHF, 700/800 MHz). Supports up to 48 simultaneous cross-patched talk groups. Implements ISSI Group Call, Unit-to-Unit Call, and Emergency services per TIA-102.BACA. Critical during multi-agency responses to wildfires, mass casualty events, and HAZMAT incidents. |
| Map Tile Server | 50E57108 | Web map tile server providing pre-rendered and on-demand raster/vector map tiles for the dispatcher workstation GIS display. Serves OpenStreetMap-compatible tile layers including street networks, aerial imagery, parcel boundaries, hydrants, and jurisdiction boundaries. Must sustain 200+ concurrent tile requests at sub-200ms response time to support smooth pan/zoom across 24+ dispatcher workstations. Uses z/x/y tile addressing with caching at edge CDN nodes within the PSAP LAN. |
| Mobile Data Gateway Server | 50B57118 | Server-side middleware at the PSAP that bridges the CAD system to the cellular/FirstNet data network. Manages authenticated sessions with 200+ concurrent MDTs. Converts CAD dispatch messages into compressed mobile-optimized payloads. Implements store-and-forward queuing for units in dead zones. Provides WebSocket-based persistent connections with heartbeat monitoring at 15-second intervals. Runs as redundant active-standby pair with sub-5-second failover. |
| Mobile Data Subsystem | 50FD7A59 | Field communications and data terminal subsystem connecting 500+ police, fire, and EMS vehicles to the PSAP via cellular (LTE/FirstNet) and Wi-Fi networks. Mobile Data Terminals (MDTs) receive CAD dispatch assignments with incident details, location, and routing. Officers/medics update status via MDT touchscreen, reducing radio traffic by 40-60%. Supports NCIC/NLETS query from the field for wants/warrants, vehicle registration, and driver's license. Provides secure messaging between units and dispatch. Reports GPS position every 10 seconds for AVL. Supports pre-arrival instructions display for EMS (EMD cards). Must operate on FirstNet Band 14 with priority and preemption during network congestion. |
| Mobile Data Terminal Application | 40FD7119 | Ruggedized in-vehicle software application running on MDT hardware (typically Panasonic Toughbook or Motorola LEX L11). Displays dispatch assignments, incident details, map overlays, unit status buttons, and NCIC/CJIS query forms. Receives push notifications from CAD. Operates over FirstNet Band 14 LTE with fallback to commercial LTE. Must maintain session state across coverage gaps using store-and-forward. Supports touch and keyboard input in moving vehicles under vibration. |
| Network Infrastructure Subsystem | 50A53018 | Resilient IP network backbone for a Tier-1 PSAP with 99.999% availability requirement per NFPA 1221. Provides redundant 10GbE LAN fabric connecting all PSAP workstations, servers, and subsystems via dual-core switches with sub-50ms failover. WAN connectivity via dual diverse-path fiber to ESInet for NG911 call delivery, plus legacy CAMA trunk interface. Dedicated MPLS circuits to backup PSAP site 15 miles away with active-active database replication. Integrated cybersecurity stack: next-gen firewall, network IDS/IPS, SIEM integration, and micro-segmentation between subsystem VLANs. Supports QoS for voice/radio traffic prioritization (DSCP EF marking). UPS-backed with 30-minute battery runtime plus generator transfer within 10 seconds. |
| Network Management and Monitoring System | 40F77308 | Centralised network operations platform for the PSAP providing SNMP v3 polling, syslog aggregation, NetFlow analysis, and real-time health dashboards for all network infrastructure components. Monitors link utilisation, switch CPU/memory, firewall session counts, and WAN circuit availability. Generates SNMP traps and email/SMS alerts when thresholds are breached (link down, CPU >80%, latency >5ms on voice VLANs). Maintains historical performance data for capacity planning with 12-month retention. Integrates with the Supervisor Dashboard Module for network status visibility to dispatch supervisors during major incidents. |
| Radio Communications Subsystem | 54ED7218 | P25 Phase II TDMA digital radio dispatch console subsystem for a multi-agency PSAP. Provides 24 simultaneous radio channels across police, fire, and EMS talkgroups via IP-connected dispatch consoles. Supports channel patching for multi-agency interoperability during major incidents. Integrates ISSI gateway for cross-system P25 interoperability with neighboring jurisdictions and federal agencies. Provides instant recall recording of all radio traffic with 90-day retention. Supports emergency button (orange button) activation with automatic console alert and audio priority. Console audio mixing allows dispatchers to monitor 6+ channels simultaneously with selectable transmit. Must maintain <150ms voice latency end-to-end for real-time tactical communications. |
| Radio Gateway Controller | 51F57018 | IP-based gateway bridging the dispatch console network to the P25 Phase II TDMA trunked radio infrastructure. Converts VoIP (G.711/IMBE vocoder) to P25 ISSI fixed-station interface protocol. Manages talk group affiliations, channel grants, and PTT arbitration for console positions. Handles site trunking failover when master site controller is unreachable. Maintains heartbeat with all connected base stations. Processes approximately 500 PTT events per minute during peak operations. Failure isolates the dispatch center from the entire radio network. |
| Radio Logging Recorder | D4C41259 | Dedicated audio recording system capturing 100% of radio transmissions across all monitored talk groups. Records transmitter unit ID, talk group, timestamp (GPS-synchronized NTP), and audio with minimum 8kHz/16-bit quality. Stores recordings for minimum 7 years per state retention requirements. Supports instant replay for dispatchers (last 60 seconds per channel). Provides chain-of-custody metadata for legal proceedings. Separate from telephony call recording to ensure radio-specific compliance. |
| Records Management Subsystem | 40A53359 | Incident records, voice logging, and compliance reporting subsystem for a PSAP processing 800,000+ calls/year. Archives complete incident lifecycle from call receipt through unit clear with all CAD actions timestamped. Records all telephony audio (100% call recording) and radio traffic with dual-redundant recorders. Stores screen recordings of dispatcher workstations for QA review. Generates NIBRS-compliant incident reports for law enforcement and NFIRS reports for fire service. Provides statistical reporting on response times, call volumes, and unit utilization for operational management. Supports legal discovery with chain-of-custody metadata. Data retention: voice recordings 5 years, CAD logs 7 years, per state statute. Must support 50+ concurrent retrieval queries without degrading recording performance. |
| Records Search and Retrieval Engine | 50E73B19 | Full-text and structured search engine (typically Elasticsearch or SOLR backed) providing rapid retrieval of incident records across millions of historical entries. Supports fuzzy name matching, address proximity search, date range queries, and incident type filtering. Used by investigators, supervisors, and records clerks. Must return results within 2 seconds for single-field queries across 5 years of data (approximately 2 million incident records for a metro PSAP). Enforces role-based access control ensuring sealed juvenile records and protected caller information are only visible to authorized personnel. |
| Report Generation Module | 51E77B58 | Automated report generator producing standardized statistical and compliance reports from incident data. Generates FBI UCR (Uniform Crime Reporting) and NIBRS (National Incident-Based Reporting System) submissions, state-mandated monthly activity reports, response time analytics, and ad-hoc custom reports. Outputs in PDF, CSV, and XML formats. Scheduled reports run nightly during low-activity periods. Must handle data aggregation across 100,000+ incidents per year for statistical accuracy. |
| Retention and Purge Manager | 41B73B79 | Automated compliance module that enforces jurisdiction-specific records retention policies. Monitors record age against configurable retention schedules (incident reports: 7 years, audio recordings: 180 days to 2 years depending on call type, CAD event logs: 5 years). Generates retention expiration alerts, executes certified purge operations with cryptographic deletion verification, and maintains purge audit logs for regulatory compliance. Must support legal hold overrides that suspend purging for records subject to litigation or investigation. |
| Routing Engine | 41F73308 | Road network routing engine computing turn-by-turn travel time and distance estimates for dispatch recommendation. Uses a weighted road graph incorporating speed limits, one-way restrictions, traffic signal density, historical response-time data, and real-time traffic feeds. Must compute shortest-time routes between any two points in the jurisdiction within 500ms to support the 2-second recommendation window. Supports emergency vehicle routing with configurable signal preemption assumptions. |
| Spatial Database | 40A53158 | PostGIS-based geospatial data store containing all geographic layers used by the emergency dispatch system: jurisdiction boundaries, ESZ (Emergency Service Zones), fire management zones, police beats, EMS response areas, hydrant locations, hazmat sites, school zones, hospital locations, and road centerlines. Serves as the authoritative geographic reference for all spatial queries. Updated quarterly from county GIS and maintained by GIS administrators. Supports spatial indexing for point-in-polygon queries completing within 50ms. |
| Supervisor Dashboard Module | 50ED7B08 | Real-time operational oversight component for PSAP supervisors and shift commanders. Aggregates system-wide metrics: call queue depth and oldest-waiting-call age, average and 95th-percentile response times by incident type, unit utilization rates by district and agency, active incident count by priority, and dispatcher workload balance. Provides configurable threshold-based alerts (visual and audible) for queue overload (>5 calls waiting or >60 seconds oldest call), response time degradation, and unit availability drops below minimum staffing levels. Supports drill-down from summary metrics to individual incidents and units. Generates shift-handoff reports and daily statistical summaries. Refreshes dashboard at 5-second intervals per SYS-REQS-007. Must support web-based remote access for off-site supervisors via authenticated HTTPS connection. |
| Talkgroup Management Module | 40B77B58 | Software module managing P25 talk group assignments, dynamic regrouping, and talk group patching for multi-agency incidents. Maintains mapping between dispatch positions and talk group affiliations. Supports NENA-standard mutual aid talk groups. Handles priority preemption for emergency traffic. Configures up to 500 talk groups across multiple zones. Integrates with CAD for automatic talk group assignment based on incident type and jurisdiction. |
| Text-to-911 Gateway | 50F77359 | Gateway processing text-based emergency communications received via the ESInet text control centre. Supports SMS-based text-to-911, RTT (Real-Time Text) per RFC 4103, and SIP MESSAGE-based text sessions. Converts between text transport protocols and presents unified text session interface to call-taker workstations. Maintains session state for multi-message conversations, handles session timeout and reconnection. Must deliver text messages to call-taker display within 1 second of receipt. Stores complete text transcripts for evidentiary records. |
| Unit Tracking and Status Module | 40B57319 | Real-time tracking component for all field units (police, fire, EMS vehicles) using AVL (Automatic Vehicle Location) data received via Mobile Data Terminals or dedicated GPS feeds at 5-second update intervals. Maintains unit status codes (Available, Dispatched, En Route, On Scene, Out of Service) with timestamp logging. Integrates with GIS for map display of unit positions. Provides proximity calculations for dispatch recommendations. Tracks unit capabilities (e.g., ALS vs BLS ambulance, ladder truck vs engine) and shift assignments. Must handle 2000+ simultaneous unit tracks in a metropolitan service area with position update latency under 3 seconds from GPS fix to map display. |
| WAN and ESInet Gateway | 50B57018 | Edge routing and WAN termination equipment connecting the PSAP to the Emergency Services IP Network (ESInet), PSTN via SIP trunks, regional backup PSAPs, and the public internet for CAD-to-CAD interoperability. Handles BGP peering with ESInet service provider and MPLS VPN termination for inter-PSAP links. Supports policy-based routing to prioritise NG9-1-1 SIP INVITE traffic over all other WAN flows. Dual redundant routers with VRRP or HSRP, each with independent WAN uplinks from diverse carriers. Must maintain ESInet connectivity during single-carrier failure with convergence under 5 seconds. |
| Component | Belongs To |
|---|---|
| Call Handling Subsystem | Emergency Dispatch System |
| Computer-Aided Dispatch Subsystem | Emergency Dispatch System |
| Geographic Information System Subsystem | Emergency Dispatch System |
| Radio Communications Subsystem | Emergency Dispatch System |
| Mobile Data Subsystem | Emergency Dispatch System |
| Records Management Subsystem | Emergency Dispatch System |
| Network Infrastructure Subsystem | Emergency Dispatch System |
| ESInet SIP Gateway | Call Handling Subsystem |
| Automatic Call Distribution Engine | Call Handling Subsystem |
| ANI/ALI Database Interface | Call Handling Subsystem |
| Call-Taker Workstation | Call Handling Subsystem |
| Text-to-911 Gateway | Call Handling Subsystem |
| Call Recording System | Call Handling Subsystem |
| Incident Management Engine | Computer-Aided Dispatch Subsystem |
| Unit Tracking and Status Module | Computer-Aided Dispatch Subsystem |
| Dispatch Decision Support Module | Computer-Aided Dispatch Subsystem |
| Dispatcher Workstation Interface | Computer-Aided Dispatch Subsystem |
| CAD Database and Event Logger | Computer-Aided Dispatch Subsystem |
| Supervisor Dashboard Module | Computer-Aided Dispatch Subsystem |
| Dispatch Radio Console | Radio Communications Subsystem |
| Radio Gateway Controller | Radio Communications Subsystem |
| Talkgroup Management Module | Radio Communications Subsystem |
| Interoperability Gateway | Radio Communications Subsystem |
| Radio Logging Recorder | Radio Communications Subsystem |
| Encryption Key Management Module | Radio Communications Subsystem |
| Map Tile Server | Geographic Information System Subsystem |
| Geocoding Engine | Geographic Information System Subsystem |
| Routing Engine | Geographic Information System Subsystem |
| Spatial Database | Geographic Information System Subsystem |
| Mobile Data Terminal Application | Mobile Data Subsystem |
| Mobile Data Gateway Server | Mobile Data Subsystem |
| CJIS Query Proxy | Mobile Data Subsystem |
| Automatic Vehicle Location Module | Mobile Data Subsystem |
| FirstNet LTE Communications Module | Mobile Data Subsystem |
| Incident Report Database | Records Management Subsystem |
| Records Search and Retrieval Engine | Records Management Subsystem |
| Retention and Purge Manager | Records Management Subsystem |
| Report Generation Module | Records Management Subsystem |
| Core LAN Switching Fabric | Network Infrastructure Subsystem |
| WAN and ESInet Gateway | Network Infrastructure Subsystem |
| Firewall and Intrusion Prevention System | Network Infrastructure Subsystem |
| Network Management and Monitoring System | Network Infrastructure Subsystem |
| Time Synchronization Service | Network Infrastructure Subsystem |
| DNS and DHCP Services | Network Infrastructure Subsystem |
| Uninterruptible Power Supply System | Network Infrastructure Subsystem |
| From | To |
|---|---|
| ESInet SIP Gateway | Automatic Call Distribution Engine |
| ANI/ALI Database Interface | Call-Taker Workstation |
| Text-to-911 Gateway | Automatic Call Distribution Engine |
| Call Recording System | ESInet SIP Gateway |
| Call Recording System | Call-Taker Workstation |
| Call-Taker Workstation | Computer-Aided Dispatch Subsystem |
| Incident Management Engine | Dispatch Decision Support Module |
| Unit Tracking and Status Module | Dispatch Decision Support Module |
| Dispatch Decision Support Module | Dispatcher Workstation Interface |
| Dispatcher Workstation Interface | Incident Management Engine |
| Incident Management Engine | CAD Database and Event Logger |
| CAD Database and Event Logger | Supervisor Dashboard Module |
| Unit Tracking and Status Module | CAD Database and Event Logger |
| Incident Management Engine | Supervisor Dashboard Module |
| Dispatch Radio Console | Radio Gateway Controller |
| Radio Gateway Controller | Talkgroup Management Module |
| Radio Gateway Controller | Interoperability Gateway |
| Radio Logging Recorder | Radio Gateway Controller |
| Encryption Key Management Module | Radio Gateway Controller |
| Dispatch Radio Console | Talkgroup Management Module |
| Geocoding Engine | Spatial Database |
| Routing Engine | Spatial Database |
| Map Tile Server | Spatial Database |
| Routing Engine | Dispatch Decision Support Module |
| Map Tile Server | Dispatcher Workstation Interface |
| Geocoding Engine | ANI/ALI Database Interface |
| Mobile Data Terminal Application | FirstNet LTE Communications Module |
| Mobile Data Terminal Application | Automatic Vehicle Location Module |
| FirstNet LTE Communications Module | Mobile Data Gateway Server |
| Mobile Data Gateway Server | CJIS Query Proxy |
| Mobile Data Terminal Application | CJIS Query Proxy |
| Mobile Data Gateway Server | Incident Management Engine |
| Mobile Data Gateway Server | Unit Tracking and Status Module |
| Automatic Vehicle Location Module | Unit Tracking and Status Module |
| Records Search and Retrieval Engine | Incident Report Database |
| Retention and Purge Manager | Incident Report Database |
| Report Generation Module | Incident Report Database |
| Incident Report Database | CAD Database and Event Logger |
| Incident Report Database | Call Recording System |
| Incident Report Database | Radio Logging Recorder |
| Core LAN Switching Fabric | Firewall and Intrusion Prevention System |
| Core LAN Switching Fabric | WAN and ESInet Gateway |
| WAN and ESInet Gateway | Firewall and Intrusion Prevention System |
| Network Management and Monitoring System | Core LAN Switching Fabric |
| Time Synchronization Service | Core LAN Switching Fabric |
| DNS and DHCP Services | Core LAN Switching Fabric |
| Uninterruptible Power Supply System | Core LAN Switching Fabric |
| Core LAN Switching Fabric | ESInet SIP Gateway |
| Core LAN Switching Fabric | Radio Gateway Controller |
| Core LAN Switching Fabric | CAD Database and Event Logger |
| WAN and ESInet Gateway | ESInet SIP Gateway |
| Firewall and Intrusion Prevention System | CJIS Query Proxy |
| Incident Management Engine | Radio Gateway Controller |
| Records Search and Retrieval Engine | Spatial Database |
| Component | Output |
|---|---|
| ESInet SIP Gateway | Authenticated SIP sessions |
| Automatic Call Distribution Engine | Routed call assignments |
| ANI/ALI Database Interface | Caller location and identity data |
| Call Recording System | Timestamped audio and text recordings |
| Text-to-911 Gateway | Unified text sessions |
| Incident Management Engine | Classified and prioritised incident objects |
| Unit Tracking and Status Module | Real-time unit positions and status data |
| Dispatch Decision Support Module | Optimal unit assignment recommendations |
| Dispatcher Workstation Interface | Dispatch commands and incident updates |
| CAD Database and Event Logger | Persistent incident records and audit trails |
| Supervisor Dashboard Module | Aggregated operational metrics and alerts |
| Dispatch Radio Console | dispatcher voice transmissions and talk group patches |
| Radio Gateway Controller | P25 RF channel grants and VoIP-to-RF bridged audio |
| Talkgroup Management Module | talk group affiliation tables and dynamic regrouping commands |
| Interoperability Gateway | cross-agency patched audio channels |
| Radio Logging Recorder | timestamped radio transmission recordings with unit ID metadata |
| Encryption Key Management Module | encrypted traffic encryption keys and OTAR rekey commands |
| Map Tile Server | rendered map tiles (raster/vector) |
| Geocoding Engine | WGS84 coordinates from addresses |
| Routing Engine | travel time and route estimates |
| Spatial Database | geospatial query results |
| Mobile Data Terminal Application | dispatch assignment displays and unit status updates |
| Mobile Data Gateway Server | mobile-optimized dispatch payloads and session state |
| CJIS Query Proxy | NCIC/CJIS query responses and audit trail records |
| Automatic Vehicle Location Module | GPS position reports with unit ID at 10-second intervals |
| FirstNet LTE Communications Module | encrypted LTE data transport with QPP priority |
| Incident Report Database | canonical incident records and audit trails |
| Records Search and Retrieval Engine | filtered incident search results with role-based redaction |
| Retention and Purge Manager | retention compliance reports and certified purge audit logs |
| Report Generation Module | UCR/NIBRS submissions and statistical reports |
| Core LAN Switching Fabric | Layer 2/3 packet forwarding for all PSAP inter-subsystem traffic |
| WAN and ESInet Gateway | ESInet and WAN connectivity for NG9-1-1 call ingress and inter-PSAP links |
| Time Synchronization Service | Stratum-1 NTP/PTP time reference for all PSAP subsystems |
| Firewall and Intrusion Prevention System | Stateful packet inspection and CJIS-compliant network segmentation |
| Source | Target | Type | Description |
|---|---|---|---|
| SYS-REQS-006 | IFC-DEFS-038 | derives | |
| SYS-REQS-004 | IFC-DEFS-037 | derives | |
| SYS-REQS-005 | IFC-DEFS-035 | derives | |
| SYS-REQS-010 | IFC-DEFS-036 | derives | |
| SYS-REQS-010 | IFC-DEFS-028 | derives | |
| SYS-REQS-006 | IFC-DEFS-027 | derives | |
| SYS-REQS-006 | IFC-DEFS-026 | derives | |
| SYS-REQS-003 | IFC-DEFS-025 | derives | |
| SYS-REQS-004 | IFC-DEFS-024 | derives | |
| SYS-REQS-010 | IFC-DEFS-023 | derives | |
| SYS-REQS-004 | IFC-DEFS-022 | derives | |
| SYS-REQS-004 | IFC-DEFS-021 | derives | |
| SYS-REQS-001 | IFC-DEFS-020 | derives | |
| SYS-REQS-007 | IFC-DEFS-019 | derives | |
| SYS-REQS-003 | IFC-DEFS-018 | derives | |
| SYS-REQS-004 | IFC-DEFS-017 | derives | |
| SYS-REQS-010 | IFC-DEFS-016 | derives | |
| SYS-REQS-006 | IFC-DEFS-015 | derives | |
| SYS-REQS-004 | IFC-DEFS-013 | derives | |
| SYS-REQS-004 | IFC-DEFS-012 | derives | |
| SYS-REQS-007 | IFC-DEFS-011 | derives | |
| SYS-REQS-006 | IFC-DEFS-010 | derives | |
| SYS-REQS-004 | IFC-DEFS-009 | derives | |
| SYS-REQS-004 | IFC-DEFS-008 | derives | |
| SYS-REQS-004 | IFC-DEFS-006 | derives | |
| SYS-REQS-004 | IFC-DEFS-005 | derives | |
| SYS-REQS-006 | IFC-DEFS-004 | derives | |
| SYS-REQS-009 | IFC-DEFS-003 | derives | |
| SYS-REQS-003 | IFC-DEFS-002 | derives | |
| SYS-REQS-002 | IFC-DEFS-001 | derives | |
| SYS-REQS-003 | SUB-REQS-044 | derives | |
| SYS-REQS-005 | SUB-REQS-055 | derives | |
| SYS-REQS-005 | SUB-REQS-065 | derives | |
| SYS-REQS-005 | SUB-REQS-063 | derives | |
| SYS-REQS-005 | SUB-REQS-060 | derives | |
| SYS-REQS-005 | SUB-REQS-058 | derives | |
| SYS-REQS-006 | SUB-REQS-064 | derives | |
| SYS-REQS-010 | SUB-REQS-067 | derives | |
| SYS-REQS-010 | SUB-REQS-061 | derives | |
| SYS-REQS-010 | SUB-REQS-057 | derives | |
| SYS-REQS-005 | SUB-REQS-066 | derives | |
| SYS-REQS-005 | SUB-REQS-062 | derives | |
| SYS-REQS-005 | SUB-REQS-059 | derives | |
| SYS-REQS-005 | SUB-REQS-056 | derives | |
| SYS-REQS-010 | SUB-REQS-054 | derives | |
| SYS-REQS-010 | SUB-REQS-053 | derives | |
| SYS-REQS-007 | SUB-REQS-052 | derives | |
| SYS-REQS-006 | SUB-REQS-051 | derives | |
| SYS-REQS-006 | SUB-REQS-050 | derives | |
| SYS-REQS-003 | SUB-REQS-049 | derives | |
| SYS-REQS-004 | SUB-REQS-049 | derives | |
| SYS-REQS-006 | SUB-REQS-048 | derives | |
| SYS-REQS-006 | SUB-REQS-047 | derives | |
| SYS-REQS-010 | SUB-REQS-046 | derives | |
| SYS-REQS-010 | SUB-REQS-045 | derives | |
| SYS-REQS-001 | SUB-REQS-001 | derives | |
| SYS-REQS-002 | SUB-REQS-002 | derives | |
| SYS-REQS-002 | SUB-REQS-003 | derives | |
| SYS-REQS-003 | SUB-REQS-004 | derives | |
| SYS-REQS-006 | SUB-REQS-005 | derives | |
| SYS-REQS-009 | SUB-REQS-006 | derives | |
| SYS-REQS-005 | SUB-REQS-007 | derives | |
| SYS-REQS-008 | SUB-REQS-007 | derives | |
| SYS-REQS-003 | SUB-REQS-008 | derives | |
| SYS-REQS-004 | SUB-REQS-008 | derives | |
| SYS-REQS-005 | SUB-REQS-009 | derives | |
| SYS-REQS-004 | SUB-REQS-010 | derives | |
| SYS-REQS-004 | SUB-REQS-013 | derives | |
| SYS-REQS-004 | SUB-REQS-019 | derives | |
| SYS-REQS-005 | SUB-REQS-020 | derives | |
| SYS-REQS-007 | SUB-REQS-022 | derives | |
| SYS-REQS-010 | SUB-REQS-021 | derives | |
| SYS-REQS-001 | SUB-REQS-011 | derives | |
| SYS-REQS-003 | SUB-REQS-016 | derives | |
| SYS-REQS-001 | SUB-REQS-012 | derives | |
| SYS-REQS-004 | SUB-REQS-014 | derives | |
| SYS-REQS-004 | SUB-REQS-015 | derives | |
| SYS-REQS-004 | SUB-REQS-017 | derives | |
| SYS-REQS-007 | SUB-REQS-018 | derives | |
| SYS-REQS-006 | SUB-REQS-031 | derives | |
| SYS-REQS-006 | SUB-REQS-032 | derives | |
| SYS-REQS-005 | SUB-REQS-026 | derives | |
| SYS-REQS-004 | SUB-REQS-023 | derives | |
| SYS-REQS-004 | SUB-REQS-025 | derives | |
| SYS-REQS-004 | SUB-REQS-028 | derives | |
| SYS-REQS-010 | SUB-REQS-033 | derives | |
| SYS-REQS-010 | SUB-REQS-034 | derives | |
| SYS-REQS-002 | SUB-REQS-024 | derives | |
| SYS-REQS-004 | SUB-REQS-027 | derives | |
| SYS-REQS-008 | SUB-REQS-029 | derives | |
| SYS-REQS-008 | SUB-REQS-030 | derives | |
| SYS-REQS-007 | SUB-REQS-035 | derives | |
| SYS-REQS-001 | SUB-REQS-036 | derives | |
| SYS-REQS-003 | SUB-REQS-037 | derives | |
| SYS-REQS-001 | SUB-REQS-038 | derives | |
| SYS-REQS-009 | SUB-REQS-039 | derives | |
| SYS-REQS-004 | SUB-REQS-040 | derives | |
| SYS-REQS-010 | SUB-REQS-040 | derives | |
| SYS-REQS-004 | SUB-REQS-041 | derives | |
| SYS-REQS-004 | SUB-REQS-042 | derives | |
| SYS-REQS-003 | SUB-REQS-043 | derives | |
| STK-NEEDS-011 | SYS-REQS-014 | derives | |
| STK-NEEDS-010 | SYS-REQS-003 | derives | |
| STK-NEEDS-012 | SYS-REQS-014 | derives | |
| STK-NEEDS-004 | SYS-REQS-013 | derives | |
| STK-NEEDS-004 | SYS-REQS-012 | derives | |
| STK-NEEDS-012 | SYS-REQS-011 | derives | |
| STK-NEEDS-007 | SYS-REQS-004 | derives | |
| STK-NEEDS-004 | SYS-REQS-010 | derives | |
| STK-NEEDS-008 | SYS-REQS-009 | derives | |
| STK-NEEDS-007 | SYS-REQS-008 | derives | |
| STK-NEEDS-006 | SYS-REQS-007 | derives | |
| STK-NEEDS-005 | SYS-REQS-006 | derives | |
| STK-NEEDS-004 | SYS-REQS-005 | derives | |
| STK-NEEDS-003 | SYS-REQS-004 | derives | |
| STK-NEEDS-002 | SYS-REQS-003 | derives | |
| STK-NEEDS-001 | SYS-REQS-002 | derives | |
| STK-NEEDS-001 | SYS-REQS-001 | derives |
| Requirement | Verified By | Type | Description |
|---|---|---|---|
| SYS-REQS-013 | VER-METHODS-043 | verifies | |
| SYS-REQS-012 | VER-METHODS-042 | verifies | |
| IFC-DEFS-038 | VER-METHODS-045 | verifies | |
| IFC-DEFS-037 | VER-METHODS-044 | verifies | |
| IFC-DEFS-036 | VER-METHODS-041 | verifies | |
| IFC-DEFS-035 | VER-METHODS-040 | verifies | |
| IFC-DEFS-034 | VER-METHODS-039 | verifies | |
| IFC-DEFS-033 | VER-METHODS-038 | verifies | |
| IFC-DEFS-032 | VER-METHODS-037 | verifies | |
| IFC-DEFS-031 | VER-METHODS-036 | verifies | |
| IFC-DEFS-030 | VER-METHODS-035 | verifies | |
| IFC-DEFS-029 | VER-METHODS-034 | verifies | |
| IFC-DEFS-028 | VER-METHODS-033 | verifies | |
| IFC-DEFS-027 | VER-METHODS-032 | verifies | |
| IFC-DEFS-026 | VER-METHODS-031 | verifies | |
| IFC-DEFS-025 | VER-METHODS-028 | verifies | |
| IFC-DEFS-024 | VER-METHODS-027 | verifies | |
| IFC-DEFS-023 | VER-METHODS-026 | verifies | |
| IFC-DEFS-022 | VER-METHODS-025 | verifies | |
| IFC-DEFS-021 | VER-METHODS-024 | verifies | |
| IFC-DEFS-020 | VER-METHODS-023 | verifies | |
| IFC-DEFS-019 | VER-METHODS-022 | verifies | |
| IFC-DEFS-018 | VER-METHODS-021 | verifies | |
| IFC-DEFS-017 | VER-METHODS-019 | verifies | |
| IFC-DEFS-016 | VER-METHODS-018 | verifies | |
| IFC-DEFS-015 | VER-METHODS-017 | verifies | |
| IFC-DEFS-014 | VER-METHODS-016 | verifies | |
| IFC-DEFS-013 | VER-METHODS-015 | verifies | |
| IFC-DEFS-012 | VER-METHODS-014 | verifies | |
| IFC-DEFS-011 | VER-METHODS-013 | verifies | |
| IFC-DEFS-010 | VER-METHODS-012 | verifies | |
| IFC-DEFS-009 | VER-METHODS-011 | verifies | |
| IFC-DEFS-008 | VER-METHODS-010 | verifies | |
| IFC-DEFS-007 | VER-METHODS-009 | verifies | |
| IFC-DEFS-006 | VER-METHODS-008 | verifies | |
| IFC-DEFS-005 | VER-METHODS-005 | verifies | |
| IFC-DEFS-004 | VER-METHODS-004 | verifies | |
| IFC-DEFS-003 | VER-METHODS-003 | verifies | |
| IFC-DEFS-002 | VER-METHODS-002 | verifies | |
| IFC-DEFS-001 | VER-METHODS-001 | verifies | |
| SUB-REQS-044 | VER-METHODS-030 | verifies | |
| SUB-REQS-040 | VER-METHODS-029 | verifies | |
| SUB-REQS-026 | VER-METHODS-020 | verifies | |
| SUB-REQS-009 | VER-METHODS-007 | verifies | |
| SUB-REQS-001 | VER-METHODS-006 | verifies |
| Ref | Document | Requirement |
|---|---|---|
| STK-NEEDS-009 | stakeholder-requirements | The Emergency Dispatch System SHALL determine the location of an emergency caller to within 50 metres horizontal accurac... |