Overview#
Generate and distribute a fully structured situation report in seconds, not minutes, by drawing every operational fact directly from the live incident record.
During a declared major incident, every passing minute that commanders spend manually composing situation reports is a minute not spent on coordination. The Watch-Commander SitRep module eliminates that overhead by automatically assembling a complete operational picture from the canonical incident record and dispatching it as a signed, standards-formatted packet to all subscribed agencies simultaneously. Reports can be issued on a configurable cadence throughout an incident or triggered on demand by the watch-commander whenever the situation changes materially.
Key Features#
-
Scheduled and Ad-Hoc Generation: Reports are emitted automatically on a configurable cadence (for example every 30 minutes during a mass-casualty incident) while the manual composer lets a watch-commander issue an additional report at any moment.
-
Canonical Incident as Single Source of Truth: Every SitRep is assembled from the same live incident record that drives the rest of the operational picture, ensuring figures cannot drift between systems or between recipients.
-
Triage and Resource Snapshot: Each report carries patient counts by triage category, the deployed resource summary, scene status, estimated times of arrival, and any outstanding mutual-aid requests in one structured packet.
-
EDXL-SitRep Serialisation: Output is formatted per OASIS EDXL-SitRep 1.0 and wrapped in an EDXL-DE 2.0 distribution envelope so partner systems can ingest the packet without bespoke parsers.
-
Signed Delivery: Each SitRep is signed with HMAC SHA-256 and delivered using the Standard Webhooks pattern, providing tamper-evidence and replay protection on every outbound message.
-
Auditable Distribution Record: Every generation and delivery event is logged on the canonical incident timeline, recording which recipients received each report and when, creating a complete audit trail for post-incident review.
-
ISO 22324 Severity Banding: Severity within each SitRep follows the ISO 22324 colour-banded warning levels for consistent interpretation across agencies operating under different national frameworks.
-
Escalation to Public Alerting: When a SitRep crosses a configured escalation threshold, the same canonical incident state can drive a separate EDXL-CAP 1.2 public-alert flow without any recomposition.
Use Cases#
Major Incident and Mass-Casualty Cadence#
During a declared major incident the scheduler emits a refreshed operational picture on a fixed interval to the national ambulance service, the national emergency operations centre, and fire headquarters without requiring manual recomposition at each cycle.
Ad-Hoc Watch-Commander Update#
A watch-commander issues a SitRep immediately after a significant change such as a triage reclassification, a new mutual-aid request, or a change in scene access. The manual composer presents the auto-assembled draft for review before dispatch.
Cross-Agency Mutual-Aid Coordination#
Outstanding mutual-aid requests are visible in every dispatched SitRep so partner agencies can plan committed resources without relying on separate telephone updates.
Post-Incident Review and Audit#
Reviewers can replay the full timeline of every SitRep generated and delivered during an incident, including the recipient list and delivery timestamps for each one, supporting after-action reviews and statutory reporting obligations.
Multi-Recipient Operational Briefing#
A single signed packet reaches all subscribed agencies simultaneously rather than relying on separate emails, phone calls, or manual radio broadcasts.
Integration#
The SitRep module exposes a REST API under /api/v1/edxl/sitrep that accepts both scheduled trigger calls and ad-hoc composition requests from your operational interface. Authentication uses OAuth 2.0 Bearer tokens scoped to the relevant incident role.
Inbound data flows from the canonical incident record held by the platform, covering role assignments, resource deployment state, triage tallies, and mutual-aid requests. No separate data entry is required for SitRep composition.
Outbound delivery uses the platform's shared webhook delivery rail. Recipient agencies subscribe via the platform's agency configuration screen, providing their webhook endpoint and optionally an email or SIP address. Each outbound message carries the Standard Webhooks signature headers so recipients can verify authenticity independently.
EDXL-SitRep payloads are available as both XML and JSON representations. The distribution envelope follows EDXL-DE 2.0, meaning any EDXL-capable command-and-control system can consume reports directly.
Lifecycle events are published on the platform's event bus whenever a SitRep is generated or delivered, enabling downstream workflows (dashboards, notification services, audit consumers) to react in real time.
Escalation to public alerting is triggered by configuring threshold rules on the incident. When conditions are met, the platform automatically initiates an EDXL-CAP 1.2 alert workflow from the same incident data, without operator intervention.
Open Standards#
-
OASIS EDXL-SitRep 1.0: the structured situation report format used as the canonical SitRep payload, defining field semantics for patient counts, resource status, and operational narrative.
-
OASIS EDXL-DE 2.0: the distribution envelope that wraps each SitRep for interoperable delivery across partner command-and-control systems.
-
OASIS EDXL-CAP 1.2: the Common Alerting Protocol format used when a SitRep escalation threshold triggers a public alerting flow from the same incident state.
-
ISO 22324: colour-banded emergency warning levels that drive the severity classification field included in each SitRep, enabling consistent interpretation across agencies.
-
Standard Webhooks (HMAC SHA-256): the outbound delivery signing and replay-protection pattern applied to every dispatched SitRep.
-
CloudEvents 1.0: the event envelope format used for SitRep lifecycle notifications (generated and delivered) on the platform's internal and external event bus.
-
AsyncAPI 2.6: the specification format in which the SitRep delivery channel is documented for partner integration teams.
-
ICS-209: the US National Incident Management System incident status summary format, referenced for cross-pattern interoperability with international partners operating under NIMS-aligned frameworks.
Security and Compliance#
All SitRep content is scoped to the tenant that owns the incident. Distribution lists are controlled per-incident by credentialled operators, and the platform enforces that only agencies with an active subscription to that incident may receive its SitReps.
Every outbound message carries a verifiable HMAC SHA-256 signature. Recipients can independently confirm authenticity and detect any in-transit modification.
The full generation and delivery audit trail is immutable once written, satisfying statutory record-keeping requirements for emergency services under national civil-protection legislation and supporting post-incident inquiry processes.
Last Reviewed: 2026-05-05 / Last Updated: 2026-05-05