Kliment Ho¹, Ilya Zaslavsky¹ ¹San Diego Supercomputer Center, UC San Diego
Emergency response systems generate data from many agencies and systems. In practice, correlating and updating this information across sources in a way that aligns with Next Generation 9-1-1 (NG9-1-1) data standards remains challenging. This paper presents SentinelAI, a data integration and standardization framework for transforming emergency communications into standardized, machine-readable datasets that support integration, composite incident construction, and cross-source reasoning. SentinelAI implements a scalable processing pipeline composed of specialized agents. The EIDO Agent ingests raw communications and produces NENA-compliant Emergency Incident Data Object JSON (EIDO-JSON). The Incident Data Exchange (IDX) Agent performs incident correlation across EIDOs, and the Geocoding Agent provides spatial enrichment. The contributions of this work are twofold: first, the operational treatment of EIDO as an evolving incident representation that is updated incrementally as new information arrives, rather than as a single static exchange object; and second, the implementation of an agent-based reference architecture aligned with the recently adopted NENA EIDO standard. This work focuses on data structuring and interoperability, rather than operational decision-making or predictive performance. We demonstrate a reference implementation of the three agents and an integration with Feature Manipulation Engine (FME), enabling interoperability with existing geospatial and emergency management systems.
Emergency response involves many kinds of data, both structured and unstructured, produced by different agencies and systems [3]. Information from operational systems, including dispatch platforms, reporting tools, communication systems, as well as news and governmental sources, often combines structured fields with unstructured elements - such as free-form text and audio - and remains difficult to integrate and process consistently at scale. Further, information needed to understand complex events, generated by police and fire departments, medical services, local governments, and news organizations, typically follows its own content and formatting standards and lifecycles. To enable cross-source analysis and interpretation of linked events, this information must first be transformed into a consistent, machine-readable, and standardized representation.
The deployment of Next Generation 9-1-1 (NG9-1-1) systems across the United States is changing emergency communications infrastructure. Unlike earlier 9-1-1 systems that were primarily designed around voice calls and limited media types, NG9-1-1 is an IP-based system designed to handle multiple modes of communication, including text, images, video, and sensor data, from diverse devices and locations [2, 4]. This transition, now underway nationwide, increases both the diversity and volume of data flowing through Public Safety Answering Points (PSAPs).
To support interoperability between systems operated by different agencies and jurisdictions, the National Emergency Number Association (NENA) defined a standard architecture that includes functional elements (FEs) and interfaces for next-generation emergency services [2]. A recently published NENA-STA-024.1.1-2025 standard formally specifies the Emergency Incident Data Object (EIDO) format [1]. EIDO provides a canonical JSON schema for representing emergency incidents, designed to facilitate seamless information exchange across the NG9-1-1 ecosystem.
Complementing EIDO, the Incident Data Exchange (IDX) concept, currently under active standardization by NENA, addresses the challenge of correlating and aggregating multiple EIDOs that describe the same real-world emergency event. In modern multi-agency responses, a single incident may generate many data points from different sources, including initial 911 calls, dispatch updates, officer reports, fire service notifications, and emergency medical services records [5]. IDX provides the framework for linking these discrete data objects into a composite, evolving representation of the incident.
In practice, incident information is distributed across multiple platforms, arrives incrementally, and varies in structure, terminology, and timing. Approaches that rely on monolithic data transformation pipelines often struggle to combine language interpretation, temporal correlation, spatial interpretation, and semantic normalization within a single workflow.
This paper presents SentinelAI, a system that addresses these challenges by decomposing the complex objective of data structuring into discrete sub-tasks, each delegated to a specialized autonomous agent. This multi-agent approach decomposes the overall task into smaller, well-defined processing steps. Our primary contributions are:
- Three-Agent Reference Architecture: A concrete reference implementation composed of three specialized agents (EIDO Agent, IDX Agent, and Geocoding Agent) that coordinate asynchronously through a shared repository to structure, correlate, and spatially enrich incident information.
- EIDO-JSON Implementation: An implementation of the NENA EIDO standard, including mechanisms for representing linked incidents and incremental updates across data objects.
- Linked Incident Representation: A reference-based representation of incidents in which individual EIDO objects are linked to a common incident context, allowing incremental updates from multiple sources without collapsing information into a single record.
- Enterprise Integration: Integration with Feature Manipulation Engine (FME) to enable bidirectional data exchange with geospatial systems and emergency management software, demonstrating practical interoperability with existing workflows.
The goal of SentinelAI is to support the consistent structuring and linkage of incident information so that it can be interpreted by both human operators and computational systems for analysis and operational use.
The EIDO-JSON format is the canonical data structure at the heart of the SentinelAI framework. The schema implements the NENA-STA-024.1.1-2025 standard for Next Generation 9-1-1 (NG9-1-1) data exchange [1, 2]. This section describes the core components of EIDO and places the standard in the context of existing event and observation data models.
A key principle of the EIDO standard is the concept of a composite incident. Emergency events evolve as information arrives from multiple sources, such as initial calls, dispatch updates, unit status changes, and field reports. Each new piece of information is structured as a distinct EIDO-JSON document that captures the incident state at a given time. The IDX Agent links these documents to a common incident context, creating a linked representation of the incident rather than a single static record.
The overall design is shown in Figure 1. Incoming incident reports from multiple sources are first processed by the EIDO Agent, which produces standardized EIDO-JSON objects. These objects are persisted and made available to other system components. The IDX Agent operates over this store to associate related EIDOs with a common incident context and to maintain composite incident views. The Geocoding Agent enriches location information using external reference data and services. Together, the agents operate asynchronously, with each focusing on a well-defined responsibility while contributing to a unified incident representation.
Figure 1. SentinelAI reference architecture showing the three-agent workflow.
This approach preserves how incident information accumulates over time while maintaining explicit links between related updates. Other systems can reconstruct incident history by following references between linked EIDO objects or retrieve the most recent state from the latest linked update. The design aligns with the operational realities of emergency response without imposing a rigid linear or graph-based incident model.
The EIDO-JSON schema organizes incident data into discrete components, including core event details (Incident), responding units (Resource), associated persons and vehicles (Entity), communication events (such as Call), and multi-format spatial information (Location).
A core principle of the EIDO standard is its reliance on controlled vocabularies and IANA-managed registries for key classification fields. This design ensures that incident types, priorities, and roles are interpreted consistently across agencies and jurisdictions, avoiding ambiguity introduced by local coding schemes.
Unlike many geospatial and event standards that emphasize precise geometric representations, EIDO accommodates multiple forms of location description, including civic addresses, landmarks, free-text descriptions, and geographic coordinates. This flexibility reflects emergency communications practice, where locations are often reported using informal or contextual references that require interpretation rather than direct coordinate parsing. The standard provides sufficient structure for machine processing while preserving the way information is communicated during emergency response.
SentinelAI is implemented as a system composed of three specialized agents, each responsible for a distinct function in structuring, correlating, and enriching emergency incident data. Rather than relying on a single monolithic pipeline, the system decomposes processing into agent-level responsibilities, allowing components to operate independently and be composed flexibly. The following sections describe the behavior and responsibilities of each agent in detail.
The EIDO Agent serves as the primary data ingestion point and is responsible for transforming heterogeneous input formats into standardized EIDO-JSON documents. The agent uses a language model to interpret and combine information from emergency communications that vary in format, wording, and level of detail. The specific model choice is not material to the architecture and is treated as a replaceable component. Its core functions are implemented in agent_core.py and include:
- Text Interpretation: The agent extracts structured information from unstructured sources such as call-taker notes, dispatch summaries, and radio transcripts. This includes identifying people, locations, organizations, time references, and descriptions of what occurred.
- Handling Agency-Specific Codes: Many dispatch systems use local incident type and priority codes (for example, “211A”, “P1”, or “Code 3”). The agent translates these local codes into the standardized values required by EIDO so that incident data can be interpreted consistently across agencies and jurisdictions.
- Timestamp Construction: Some legacy systems store date and time information across multiple fields, such as separate entries for year, month, day, and hour. The agent combines these fields into standard ISO 8601 timestamps so that events can be compared and ordered reliably.
- Template-Guided Structuring: The agent applies configurable EIDO templates that define which components and fields are expected for different categories of incidents. Templates distinguish required from optional information and capture incident-type-specific attributes. They are maintained outside application code, allowing subject-matter experts to adjust data requirements for specific incident types or jurisdictions without modifying core system logic. This mechanism provides consistency across similar incidents while still allowing narrative information to be captured where appropriate.
Table 1 illustrates representative transformations performed by the EIDO Agent:
| Legacy CAD Field | EIDO-JSON Target | EIDO Agent Structuring Task |
|---|---|---|
| Incident Type | incidentComponent.incidentTypeCommonRegistryText |
Normalize proprietary codes (‘211A’) to IANA registry value (‘ROBBERY-ARMED’). |
| Initial Problem Description | notesComponent.notesActionComments |
Summarize and extract core event narrative from multi-paragraph call-taker notes. |
| Response Hour, Day, Month | callComponent.callStartTimestamp |
Synthesize disparate temporal fields into compliant ISO 8601 timestamp. |
| Priority Level | incidentComponent.incidentCommonPriorityNumber |
Map agency-specific codes (‘P1’, ‘Code 3’) to standardized numeric scale (1-5). |
| Sector / Beat | locationComponent.locationDescriptionText |
Contextualize jurisdictional areas, appending them to location description. |
| Call Disposition | incidentComponent.incidentDispositionText |
Map disposition codes (‘ADV’) to descriptive text (‘Advised’). |
| First Unit Arrived | resourceStatusComponent.statusTime |
Create distinct status component for specific unit, parsing timestamp. |
| Unit Time on Scene | resourceStatusComponent fields |
Calculate duration; create start and end status objects. |
The IDX Agent is responsible for associating newly created EIDO documents with existing incidents or initiating new incident contexts. This capability is essential in multi-agency and multi-source environments, where a single real-world event generates multiple, partial, and incrementally reported observations.
An incident (I) is treated as a set of previously observed EIDO objects:
I = {E₁, E₂, …, Eₙ}
When a new EIDO (E_new) arrives, the agent evaluates its similarity to each existing incident using a weighted scoring function that combines temporal, spatial, and semantic evidence, as implemented in the Categorizer Service:
Equation 1
Σ(E_new, I) = w_t · φ_t(Δt) + w_g · φ_g(Δg) + w_s · φ_s(D_E, D_I)
The three components capture complementary aspects of incident relatedness. The temporal term φ_t measures how close the new report is in time to recent activity within an incident. The spatial term φ_g evaluates proximity between reported locations, using straight-line distance by default, with optional alternatives such as network-based or travel-time distance when appropriate data are available. The semantic term φ_s compares incident descriptions using vector embeddings derived from textual content [6].
The weights w_t, w_g, and w_s control the relative influence of each component and may be learned or configured based on operational context.
The new EIDO is linked to the incident I* that maximizes the similarity score, calculated using a cascading filter with temporal windows, geospatial proximity, and semantic text similarity, provided that the score exceeds a configurable threshold τ:
I* = argmax_I Σ(E_new, I) subject to Σ(E_new, I*) ≥ τ
The threshold τ represents the system’s tolerance for ambiguity in incident association. Higher values enforce conservative linking, while lower values permit more permissive aggregation. τ is not specified by the NENA standard and is treated as an operational parameter that may vary by incident type, jurisdiction, or deployment setting. In practice, τ is configured based on tolerance for false aggregation rather than optimized for predictive accuracy.
Figure 2. Decision logic employed by the IDX Agent to determine if an incoming report represents a new incident or an update to an existing one.
If no existing incident satisfies the threshold, the new EIDO initiates a new incident context.
Composite Representation
Once individual EIDO objects have been linked to a common incident context, the system can derive a composite representation C(I) that summarizes incident state across all available updates. This composite view is not stored as a separate authoritative record, but is constructed dynamically from the set of linked EIDOs associated with an incident.
Each incident is associated with a collection of linked EIDO objects. Composite attributes are computed by applying aggregation or selection rules over this collection. For example, the set of deployed or involved units U_C(I) is obtained as the union of unit references across all constituent EIDOs:
Equation 2: U_C(I) = ⋃_{i=1}^{n} U(E_i)
Other incident attributes are derived using rules appropriate to their semantics. Narrative information is constructed by combining notesComponent entries from linked EIDOs, ordered by their timestamps, to provide a consolidated account of reported observations and actions. State-oriented fields, such as incidentStatus, are resolved by selecting the most recent value available among the linked EIDOs, reflecting the current known state of the incident.
This composite representation supports query, visualization, and integration tasks that require a unified view of an incident, while preserving access to the underlying EIDO objects for traceability and audit. By computing composite views from linked updates rather than maintaining a single mutable record, the system avoids loss of information and accommodates the incremental, multi-source nature of emergency incident reporting.
The Geocoding Agent addresses a common challenge in emergency response: locations are often described using local landmarks, colloquial names, or contextual references rather than formal addresses. Callers may report incidents at a well-known market, a campus landmark, or a locally named site without providing a street address or coordinates.
To resolve such descriptions, the agent combines three complementary processes: leveraging local place knowledge, querying external mapping services, and applying incident context for disambiguation. Unlike general-purpose geocoders and gazetteers, which emphasize formal place names and addresses, the Geocoding Agent is designed to interpret how locations are described in everyday emergency communications. Many locally used names and informal references are absent from standard gazetteers and require additional context to resolve reliably [7].
Resolving a location begins with matching reported place names against a curated collection of locally relevant landmarks, businesses, and commonly used place references. These references reflect local usage and are spatially indexed to support efficient lookup. When local knowledge alone is insufficient, the agent queries public mapping services, such as Google Maps or OpenStreetMap, to retrieve candidate matches that include user-contributed names and informal place descriptions.
When multiple candidate locations are returned, the agent applies available incident context to select the most likely match. Relevant context may include the incident type, the reporting party, the responding jurisdiction, and proximity to other known incident features. By combining these signals, the agent reduces ambiguity without requiring callers to provide fully specified addresses.
The resolved location is incorporated into the EIDO locationComponent in several complementary forms. Geographic coordinates support spatial analysis and mapping, while matched landmark names and descriptive text preserve how the location was originally communicated. Where available, a civic address is included for formal documentation, and a confidence measure records the reliability of the resolution.
To support interoperability with existing emergency management and geospatial systems, SentinelAI integrates with Safe Software’s Feature Manipulation Engine (FME) [8]. This integration is presented as an example of enterprise integration, demonstrating how standardized EIDO-JSON data can be exchanged with existing systems without requiring changes to those systems.
FME is widely deployed in government and public safety environments and provides a practical integration surface for existing computer-aided dispatch, geospatial, and reporting systems. Rather than introducing a separate architectural layer, SentinelAI uses FME to enable bidirectional exchange between legacy data representations and EIDO-JSON through explicit reader and writer components. The following sections describe these components in detail.
The EIDOReader and EIDOWriter components provide a practical mechanism for moving data between existing systems and EIDO-compliant representations. Together, they support bidirectional data exchange, allowing legacy 9-1-1 data to be converted into EIDO-JSON and enabling structured EIDO output to be consumed by existing public safety and geospatial systems.
Figure 3. Integration with Feature Manipulation Engine (FME) showing EIDOReader and EIDOWriter components facilitating bidirectional data exchange.
The EIDOReader is designed to ingest, parse, and expose EIDO-JSON documents within FME workflows so that standardized incident information can be accessed by existing systems. The reader operates on complete EIDO-JSON documents and systematically traverses their nested structure, identifying individual components and their relationships.
Using core FME JSON transformers, the EIDOReader decomposes EIDO-JSON into a set of typed features corresponding to major schema components such as incidentComponent, locationComponent, personComponent, resourceComponent, and callComponent. Each component is emitted as a distinct feature with attributes derived directly from the EIDO fields, while reference links between components are preserved through identifiers. This approach allows downstream FME workflows to work with incident data using familiar tabular and geospatial abstractions while retaining the logical structure of the original EIDO.
By flattening EIDO-JSON in this controlled manner, the reader enables standardized incident data to be queried, visualized, filtered, and joined with other datasets using the broad ecosystem of formats and tools supported by FME, including spatial databases, GIS applications, analytics pipelines, and reporting systems.
The EIDOWriter performs the inverse operation of the reader by constructing NENA-compliant EIDO-JSON documents from structured source data available within FME workflows. It accepts input features representing records from legacy computer-aided dispatch systems, spreadsheets, databases, or other tabular and geospatial sources.
Within an FME workspace, attributes from these source features are mapped explicitly to EIDO components and fields. The writer assembles the required EIDO structure by creating component objects, assigning identifiers, and establishing references between components according to the EIDO schema. Where source systems provide partial or fragmented information, the writer supports assembling complete EIDO documents from multiple input features.
The resulting output is a validated EIDO-JSON document that conforms to the NENA standard and can be exchanged with NG9-1-1 systems or consumed by other SentinelAI agents. This capability allows existing operational data to be brought into compliance with EIDO without requiring changes to upstream systems or manual reformatting.
This paper presented SentinelAI, a multi-agent framework for structuring, linking, and enriching emergency incident data in alignment with the NENA Emergency Incident Data Object (EIDO) standard. The system operationalizes EIDO as an evolving, event-sourced representation, allowing incident information to be updated incrementally as new reports arrive rather than treated as a single static exchange record. Through the coordinated operation of three specialized agents, SentinelAI addresses core challenges in emergency data integration, including interpretation of heterogeneous inputs, correlation of related reports across sources, and spatial enrichment of informally described locations.
The primary contributions of this work are threefold. First, we describe a reference architecture composed of an EIDO Agent, an Incident Data Exchange (IDX) Agent, and a Geocoding Agent, each with clearly defined responsibilities and interfaces that reflect the asynchronous and multi-source nature of emergency response data. Second, we provide a practical implementation of the NENA EIDO-JSON standard that supports linked incident representations and preserves the provenance of individual updates. Third, we demonstrate interoperability with existing emergency management and geospatial systems through an integration with Feature Manipulation Engine (FME), illustrating how standardized EIDO data can be exchanged with operational workflows without requiring changes to upstream systems.
Together, these contributions focus on data structuring and interoperability rather than operational decision support or predictive performance. By providing a concrete, standards-aligned implementation and reference architecture, this work aims to support future research and system development that builds on consistent, machine-readable emergency incident data.
A reference implementation of the SentinelAI architecture, including the EIDO Agent, IDX Agent, Geocoding Agent, and the EIDOReader and EIDOWriter components for FME integration, is available for research and evaluation purposes. Source code, configuration examples, and documentation are provided via a publicly accessible repository.
Additional technical details, including representative templates, schema mappings, and illustrative examples, are maintained alongside the reference implementation in the project repository (as accompanying Markdown documentation).
The EIDO-JSON standard described in this paper is specified by the National Emergency Number Association (NENA) in NENA-STA-024.1.1-2025. We are grateful to Dmitri Bagh from Safe Software for advice on FME integration. Partial support from the US NSF (award 2330460) is gratefully acknowledged.
[1] National Emergency Number Association (NENA). (2025). NENA Standard for Emergency Incident Data Object (EIDO). NENA-STA-024.1.1-2025. [2] National Emergency Number Association (NENA). NENA i3 Standard for Next Generation 9-1-1. Technical information documents defining functional architecture and interfaces. [3] Federal Communications Commission (FCC). Next Generation 9-1-1 (NG9-1-1). https://www.fcc.gov/next-generation-9-1-1 [4] Cybersecurity and Infrastructure Security Agency (CISA). Next Generation 9-1-1 Overview. U.S. Department of Homeland Security. https://www.cisa.gov/next-generation-911 [5] Palen, L., & Anderson, K. M. (2016). Crisis informatics - New data for extraordinary times. Science, 353(6296), 224-225. [6] Reimers, N., & Gurevych, I. (2019). Sentence-BERT: Sentence embeddings using Siamese BERT-networks. Proceedings of EMNLP-IJCNLP. [7] Goodchild, M. F., & Li, L. (2012). Assuring the quality of volunteered geographic information. Spatial Statistics, 1, 110-120. [8] Safe Software Inc. Feature Manipulation Engine (FME). https://www.safe.com