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 request to offered to committed to delivered to released lifecycle is logged on the canonical incident timeline so the watch-commander sees the entire mutual-aid chain in context.

Last Reviewed: 2026-05-05 Last Updated: 2026-05-05

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.
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.

Integration#

Argus Handoff Pipeline: The existing handoff envelope builder and delivery service are extended with an EDXL-RM serializer, 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.
PSAP Composer UI: A planned mutual-aid composer in the PSAP frontend lets the watch-commander assemble and send resource requests without leaving the incident view.

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.
mTLS (RFC 8705): partner endpoints are reached over mutual 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 argus.mutual_aid.requested, argus.mutual_aid.offered, argus.mutual_aid.committed, and argus.mutual_aid.released events using the CloudEvents envelope.
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.