VSI GLOBAL // ENTERPRISE ARCHITECTURE

Crisis Monitoring Dashboard / Common Operating Picture

8 min read

Crisis Monitoring Dashboard / Common Operating Picture

Deliverable OSINT-062. Structure per cc02-standards/SYSTEM-STANDARD.md. Every component traces to a design basis (NEED/REQ) and to an acceptance criterion. This system is the visualization and event-of-record layer over the Real-Time Situational Monitoring service (OSINT-061); it does not itself collect - it fuses the lawfully collected alert stream OSINT-061 already produces.

1. Purpose and Design Basis

1.1 Scope and Objective

The Crisis Monitoring Dashboard (v2) is a single-screen Common Operating Picture (COP) for a developing crisis. It subscribes to the real-time alert and situational-summary stream emitted by OSINT-061 (Real-Time Situational Monitoring) and fuses every active watch item, its severity band, and its location into one authoritative live view. In parallel it writes every alert and operator action to an append-only event log, from which it exports a graded, timestamped timeline that seeds the Post-Crisis After-Action Report (OSINT-063).

1.2 Design Basis

This system replaces the manual reconciliation of scattered alert channels (email, messaging, voice) with one fused picture during time-critical crisis command. It renders severity deterministically from the Likelihood-times-Impact risk key already carried by OSINT-061 watch items, and it treats persistence as a first-class function: the picture is volatile, the event log is durable and tamper-evident, so the crisis can be reconstructed after the fact.

1.3 Needs

  • NEED-OSINT-062-01: Team Leader (RF) requires a single consolidated common operating picture that fuses all active situational-monitoring alerts, their severity, and their location into one live view.
    • Source: RF (CEO/TL) crisis command-and-control concern.
    • Context: During a developing situation, tripwire alerts from OSINT-061 arrive across separate channels with no unified severity or map view, delaying a shared understanding of the situation.
  • NEED-OSINT-062-02: Systems Engineer (CS) requires that every alert and status change shown on the COP be written to an immutable, timestamped event log.
    • Source: CS (Systems Engineer) reconstruction and audit concern.
    • Context: OSINT-063 reconstructs the crisis timeline from graded, timestamped records; a volatile dashboard with no persistence cannot support after-action reconstruction.
  • NEED-OSINT-062-03: Team Leader (RF) requires the COP to separate severity tiers visually using the standing risk key so the highest active severity is unambiguous at a glance.
    • Source: RF (CEO/TL) decision-support concern.
    • Context: Under crisis load, an operator must read the dominant threat condition in one look, without computing scores.

1.4 Requirements

  • REQ-OSINT-062-01 (Traceability: NEED-OSINT-062-01): The dashboard shall ingest the OSINT-061 alert and situational-summary stream and render each active watch item on a single consolidated view within 2 seconds of receipt [VR-OSINT-062-01].
    • Verification Method: Test (T)
  • REQ-OSINT-062-02 (Traceability: NEED-OSINT-062-03): The dashboard shall assign each active alert to a severity band derived from its Likelihood-times-Impact score using the verbatim key (1-5 Low, 6-10 Moderate, 11-15 Elevated, 16-20 High, 21-25 Critical) and present the highest active band as the primary indicator [VR-OSINT-062-02].
    • Verification Method: Inspection (I)
  • REQ-OSINT-062-03 (Traceability: NEED-OSINT-062-02): The dashboard shall append every received alert and every operator status change to an append-only, timestamped event log persisted to durable storage before the corresponding element is rendered [VR-OSINT-062-03].
    • Verification Method: Test (T)
  • REQ-OSINT-062-04 (Traceability: NEED-OSINT-062-02): The dashboard shall export the event log as a chronologically ordered, source-graded timeline artifact consumable by OSINT-063 [VR-OSINT-062-04].
    • Verification Method: Demonstration (D)

2. Architecture As Built

The system runs as four cooperating parts on one secure host. An ingestion listener daemon subscribes to the OSINT-061 alert and situational-summary stream and hands each received item to persistence. A SQLite append-only event log in WAL mode is the durable event of record: every alert and every operator status change is inserted before it is shown. A COP state builder reads the log and derives the current fused picture and the dominant severity band from the Likelihood-times-Impact (L x I) key. A Flask loopback web UI renders that picture as the single-screen severity board, asset/map layer, and live feed, and drives the graded timeline export that seeds OSINT-063.

Data flow:

  1. The ingestion listener daemon receives an alert or situational summary from the OSINT-061 stream (watch item, L x I score, location, timestamp).
  2. The listener appends the received item to the SQLite append-only event log in WAL mode before any render occurs.
  3. The COP state builder reads the append-only log and rebuilds the current fused picture, assigning each active item to its severity band from the L x I key.
  4. The Flask loopback web UI renders the fused picture, coloring each item by severity band and presenting the highest active band as the primary indicator.
  5. An operator status change (acknowledge, escalate, stand-down) is written back to the append-only event log as a new timestamped record.
  6. The timeline exporter renders the ordered, source-graded event log to the crisis timeline artifact consumed by OSINT-063.
+---------------------------------------------------------------------------+
| OSINT-062 Crisis Monitoring Dashboard / Common Operating Picture          |
|                                                                           |
|  [OSINT-061 alert stream] --> [Ingestion Listener] --> [Append-Only       |
|                                       |                  Event Log (WAL)]  |
|                                       v                        |          |
|                               [COP State Builder] <------------+          |
|                                       |                        |          |
|                                       v                        v          |
|                       [Web UI: severity board          [Timeline Exporter]|
|                        + asset/map + live feed]                |          |
+---------------------------------------------------------------- | --------+
                                                                  v
                                                        [OSINT-063 timeline]

3. Components and Bill of Materials

ComponentSpecVendor / LinkPriceTierStatusTraceability
Ingestion ListenerPython 3.12 subscriber for the OSINT-061 alert/summary streamInternal$0.00-SELECTEDREQ-OSINT-062-01
Append-Only Event LogSQLite in WAL mode, insert-only crisis event tableOS$0.00-SELECTEDREQ-OSINT-062-03
COP State BuilderPython service deriving the current picture and severity bands from the logInternal$0.00-SELECTEDREQ-OSINT-062-02
Web UI (COP)Flask server with a static map layer and live severity board, loopback-boundOS$0.00-SELECTEDREQ-OSINT-062-01
Timeline ExporterPython module rendering the event log to a graded Markdown/CSV timelineInternal$0.00-SELECTEDREQ-OSINT-062-04

4. Build and Deployment

4.1 Environment Setup

  1. Deploy the ingestion listener and Flask COP server under the dedicated service user sc-cop in the local python engine environment on the secure host.
  2. Create the event-log directory and initialize the SQLite event log in WAL mode with the insert-only crisis event schema, then grant the service user INSERT only on the crisis event table: 
    install -d -o sc-cop -g sc-cop -m 0700 /var/lib/crisis-cop
sqlite3 /var/lib/crisis-cop/events.db "PRAGMA journal_mode=WAL;"

4.2 Application Start

  1. Set the OSINT-061 stream endpoint and the event-log path (/var/lib/crisis-cop/events.db) in /etc/default/crisis-cop.
  2. Install the systemd unit at /etc/systemd/system/crisis-cop.service, then reload the manager and enable and start the service: 
    systemctl daemon-reload && systemctl enable --now crisis-cop.service
    Confirm the listener is subscribed and the event log is writable.

5. Hardening Baseline

  • Network Hardening: Bind the Flask COP server to the loopback interface (127.0.0.1) only; reach it through the existing authenticated access path, never a public port.
  • Log Integrity: Grant the service user INSERT-only on the event table and deny UPDATE and DELETE so the crisis record stays append-only [REQ-OSINT-062-03].
  • Process Isolation: Run the COP under a dedicated unprivileged user sc-cop; disable Flask debug mode in the production environment.
  • Data-at-Rest: Restrict the event-log file to chmod 0600 for the service owner and include the log in the encrypted backup set for after-action retention.

6. Integration Points

InterfaceTypeDirectionContract
Ingest AlertsStream (JSON)ConsumedSubscribes to the OSINT-061 real-time alert and situational-summary stream (watch item, Likelihood-times-Impact score, location, timestamp)
COP ViewWeb portal (HTTP)ProducedLoopback interface presenting the fused severity board, asset/map layer, and live event feed
Timeline ExportFile (Markdown/CSV)ProducedEmits the chronological, source-graded crisis timeline consumed by OSINT-063

7. Acceptance Tests

CriterionMethodExpected ResultReference
REQ-OSINT-062-01TestInject a sample OSINT-061 alert and confirm the watch item renders on the COP within 2 seconds.VR-OSINT-062-01
REQ-OSINT-062-02InspectionFeed alerts spanning all five bands and verify the severity coloring matches the 1-25 key and the highest band is primary.VR-OSINT-062-02
REQ-OSINT-062-03TestEmit an alert, then attempt an UPDATE and a DELETE on the event row and confirm both are rejected while the INSERT persisted.VR-OSINT-062-03
REQ-OSINT-062-04DemonstrationExport the timeline after a scripted event sequence and confirm chronological order and source grades match the log.VR-OSINT-062-04

8. Run and Maintenance Handover

  • Console Start: Start the service via systemctl restart crisis-cop.
  • Maintenance Schedule: Rotate and archive the event log per engagement retention after each crisis stand-down; verify WAL checkpointing weekly; update the map/asset layer when the protected perimeter changes.
  • Ownership: Systems Engineer (CS); operational watch owner Team Leader (RF).

Annex A: Severity Key Mapping

The COP colors each active watch item by the severity band derived from its Likelihood-times-Impact (L x I) score, and the highest active band sets the primary board indicator [REQ-OSINT-062-02]. The five bands map to fixed dashboard visual indicators so the dominant condition reads at a glance:

BandL x I RangeDashboard Visual Indicator
Critical21-25Solid red board header with flashing alert marker; item pinned to top of the board
High16-20Red item row and red map marker
Elevated11-15Amber item row and amber map marker
Moderate6-10Yellow item row and yellow map marker
Low1-5Grey item row and grey map marker

END OF SYSTEM

Model wiring

Generated from cell frontmatter at publish time.

Graph View

Backlinks