Mutual-Aid Resource Request via EDXL-RM

Overview#

A watch-commander handling a major incident often needs additional units from neighbouring agencies, but every partner CAD speaks a slightly different dialect. This module lets the commander send a standardised resource request that lands in the partner agency's CAD with all the incident context already filled in, and tracks the response on the same canonical incident.

The Mutual-Aid Resource Request module wraps an OASIS EDXL-RM 1.0 resource message inside an EDXL-DE 2.0 distribution envelope, signs it with HMAC SHA-256 using the Standard Webhooks pattern, and delivers it over an mTLS-authenticated webhook to subscribed partner endpoints (NAS, Garda, fire, civil defence, voluntary services). The full lifecycle, from request through offered, committed, and delivered to released, is logged on the canonical incident timeline so the watch-commander sees the entire mutual-aid chain in context. The lifecycle is enforced server-side: a guarded state machine permits only valid next stages, and the whole workflow is embedded in the unified command view rather than living in a detached form.

Key Features#

Standardised Resource Request Format: Mutual-aid asks are expressed as OASIS EDXL-RM 1.0 resource messages so partner agencies receive a consistent, machine-readable payload rather than free-text radio or phone traffic.
Distribution Envelope with Routing: Each request is wrapped in an EDXL-DE 2.0 envelope that carries sender, recipient, distribution scope, and incident references in a way partner systems already know how to parse.
Signed Webhook Delivery: Outbound requests are signed using the Standard Webhooks HMAC SHA-256 pattern so partner agencies can verify the message originated from the issuing watch centre and has not been tampered with in transit.
Mutual TLS to Partner Endpoints: Delivery uses mTLS so both the issuing and receiving agency authenticate each other at the transport layer, with OAuth 2.1 client-credentials available as a service-to-service fallback.
Lifecycle Tracking on the Canonical Incident: Every request, offer, commitment, delivery, and release event is appended to the unified incident timeline so the full mutual-aid chain stays anchored to the originating incident.
Guarded Stage Transitions: A server-side state machine moves each request through its stages (such as requested, accepted, deployed, and released) and permits only valid next steps, rejecting out-of-order or reversed transitions. Each transition can carry an explanatory note, and every operation is authenticated and scoped to the caller's organisation.
Live and Historical Request Queries: Agencies can list live mutual-aid requests or query a bounded lifecycle history, including closed requests, filterable per incident or per protocol run, so past aid chains remain reviewable long after stand-down.
Per-Action Audit Attribution: Each workflow action (request, accept, decline, deploy) produces its own tamper-resistant audit event attributed to the authenticated person and their organisation, so multi-agency coordination stays auditable stage by stage.
Hospital Capacity Awareness: Where requested resources include hospital capacity, OASIS EDXL HAVE messages can be used so receiving and sending agencies share a common bed and capability vocabulary.
Event-Driven Internal Fanout: Lifecycle changes emit CloudEvents 1.0 events so dashboards, after-action review, and analytics can subscribe without polling the request store.
Partner Endpoint Registry: A managed registry of partner agency endpoints, certificates, and dispatch agreements determines which recipients receive which classes of resource request.

Use Cases#

Major Incident Surge: A watch-commander on a multi-casualty road incident requests additional ambulances from NAS using a single standardised EDXL-RM message rather than coordinating by phone.
Cross-Service Cordon: An incident requiring a Garda cordon alongside fire and ambulance response is broadcast to all relevant partner CADs simultaneously with consistent incident context.
Hospital Capacity Coordination: A receiving facility uses EDXL HAVE to report available bed and trauma capability so the resource request is matched to a destination that can actually accept the patient.
Voluntary Service Activation: Civil defence and voluntary ambulance services receive the same standardised request format as statutory responders, removing the need for bespoke phone trees.
Resource Release Coordination: When committed units are released back to their home agency, the release event is recorded on the canonical incident and propagated to the partner CAD so both sides reconcile cleanly.
After-Action Review: Auditors replay the full mutual-aid chain on a single timeline to assess response time, partner availability, and where additional dispatch agreements would have helped.
Stage-by-Stage Accountability: A compliance officer reconstructs exactly who requested, accepted, and deployed mutual aid during a major incident, using the per-action audit events and the bounded lifecycle history for that incident.
Neighbouring-Agency Tracking: A commander requests ladder trucks from a neighbouring county and tracks acceptance, deployment, and stand-down against the incident record without leaving the unified command view.

Integration#

Argus Handoff Pipeline: The existing handoff envelope builder and delivery service are extended with an EDXL-RM serialiser, reusing the multi-channel delivery, signing, and retry behaviour already in place.
Dispatch Agreement Registry: The PSAP dispatch agreements registry determines which partner agencies are eligible recipients for a given resource type, geography, and incident class.
Federated Dispatch Primitives: The dispatch federation domain provides the shared addressing, identity, and routing primitives used to send and reconcile mutual-aid requests across agencies.
Canonical Incident Timeline: Each lifecycle event is written to the unified incident timeline with the recipient agency, requested resource type, and ETA so the watch-commander view is always current.
Partner CAD Webhooks: Partner agencies subscribe to signed webhook endpoints that deliver EDXL-DE wrapped EDXL-RM messages directly into their CAD intake.
Unified Command View: The mutual-aid workflow is embedded in the unified command view and bound to the owning incident, so the watch-commander raises requests, applies stage transitions with notes, and reviews the request history without leaving the incident.
Strongly-Typed Request API: Live request listings, bounded lifecycle history, and the guarded transition operation are exposed through the platform's strongly-typed API, with every call authenticated and scoped to the caller's organisation.
Tamper-Resistant Audit Trail: The mutual-aid workflow is wired into the platform audit pipeline so each lifecycle action lands as an identity-stamped audit event derived from the authenticated session, never from client-supplied input.

Open Standards#

OASIS EDXL-RM 1.0: resource requests use the OASIS Emergency Data Exchange Language Resource Messaging specification so the structure, request types, and lifecycle states are interoperable across partner systems.
OASIS EDXL-DE 2.0: every outbound message is wrapped in the EDXL Distribution Element envelope so sender, recipient, distribution scope, and incident references are expressed in a partner-compatible form.
OASIS EDXL HAVE: where requested resources include hospital capacity, the Hospital Availability Exchange specification provides a shared vocabulary for bed counts, services, and operational status.
Standard Webhooks (HMAC SHA-256): outbound delivery follows the Standard Webhooks signing pattern so partner agencies can verify message authenticity and integrity using a well-known scheme.
Mutual TLS: partner endpoints are reached over mutually authenticated TLS so both ends of the connection authenticate at the transport layer using client certificates.
OAuth 2.1 Client Credentials: service-to-service authentication is available as a fallback for partners that cannot terminate mTLS, using the OAuth 2.1 client-credentials grant.
CloudEvents 1.0: lifecycle transitions are published as CloudEvents-enveloped events covering the requested, offered, committed, and released stages, giving downstream consumers a consistent event contract.
AsyncAPI 2.6: the mutual-aid event channel is described using AsyncAPI so partner integrators have a machine-readable contract for the published events.
HTTPS / TLS: all transport happens over the modern secure web baseline, with mTLS layered on top for partner endpoints.
XML and JSON: EDXL payloads are exchanged as XML for partner CAD compatibility, while internal events use JSON for ease of consumption across the platform.

Last Reviewed: 2026-07-16 Last Updated: 2026-07-16