Application Overview

What the Emergency Preparedness and Exercises app models, and the ideas behind it

Core Operating Chain

SourceAuthority → SourceDocument → Requirement
  → PlanRequirementLink → EmergencyPlan        (what the law and standards demand)

MineSite → OperatingArea
EmergencyScenario → ScenarioControl            (credible worst case + its controls)
EmergencyScenario ↔ EmergencyPlan              (ScenarioPlanLink)

EmergencyPlan → EmergencyProcedure             (by ResponsePhase: ALERT → RECOVERY)
EmergencyPlan → CommandStructure → CommandRoleAssignment
                 ↳ primary / alternate EmergencyControlLocation
MineSite → EmergencyContact / NotificationTemplate

EmergencyResource → ResourceScenarioLink       (what each scenario needs, and by when)
EmergencyResource → ResourceInspection         (available? functional? in date? → readiness)
Competency → EmergencyRoleCompetency           (what each command role requires)
Competency → PersonCompetency                  (who holds it, and until when)
ReadinessAssessment → ReadinessAssessmentItem  (the whole picture, rated item by item)

EmergencyExercise → ExerciseObjective          (weighted, measurable, rated afterwards)
                  → ExerciseHazardAssessment   (stop criteria + real-emergency protocol)
                  → ExerciseParticipant / ExerciseLocation
                  → ExerciseInject             (planned offset → actual release → outcome)
                  → ExerciseEventLog           (real_event flag separates reality from play)
                  → ExerciseCommunication      (simulated flag, notification status)
                  → ExerciseMuster → MusterPerson
                  → SimulatedCasualty / ResourceDeployment
                  → ExerciseObservation        (per objective, per role, rated)
                  → ExerciseDebrief → ExerciseFinding → CorrectiveAction
                  → ExerciseReport
EmergencyPlan → PlanReview → superseding EmergencyPlan revision

Key Concepts

Readiness is evidence, not assertion. Nothing in the model lets a site claim it is ready. EmergencyResource.readiness_status is one of READY / READY_WITH_LIMITATION / NOT_READY / OUT_OF_SERVICE / UNKNOWN / INSPECTION_OVERDUE, and it is meant to be driven by ResourceInspection rows that record four separate facts — available, functional, expiry acceptable, access clear — plus a quantity actually counted. The demo carries a medical trailer sitting at READY_WITH_LIMITATION because two dressing packs expire in November, and a muster kit at INSPECTION_OVERDUE because its 90-day inspection lapsed in June. Both are true statements about the site, not administrative noise.

The exercise is a controlled event with a declared exit. ExerciseHazardAssessment is a first-class record with four required text fields: the risks the exercise itself creates, the controls, the stop_exercise_criteria, and the real_emergency_protocol. EmergencyExercise separately carries real_emergency_override_procedure. An exercise is a deliberate injection of confusion into a live workplace, so the model insists that the way out is written down and approved before anyone starts.

Simulation must never be mistakable for reality. Two flags carry this: ExerciseEventLog.real_event and ExerciseCommunication.simulated. The demo's November exercise log includes a genuine event — a light vehicle broke down on the access road mid-exercise — recorded in the same timeline but flagged real, which is exactly the case the flag exists for. Every simulated message in the demo opens and closes with "EXERCISE", and the pack ships a notification template (NT-EXER-01) that does nothing but enforce that prefix.

Controllers, players and evaluators are different people. ExerciseParticipant carries three independent booleans — controller, evaluator, observer — alongside the person's exercise_role. The exercise director releases injects; the players respond; the evaluators watch and rate. Collapsing those roles is how an exercise ends up marking its own homework.

Objectives are weighted and rated, not narrated. ExerciseObjective carries a success_measure, a target_value, a weight_percent, and — after the fact — a result_rating on the same five-value scale used by observations and readiness items (EFFECTIVE / PARTLY_EFFECTIVE / INEFFECTIVE / NOT_TESTED / NOT_OBSERVED). NOT_TESTED is the important one: it lets a readiness assessment say honestly that a control is assumed, not demonstrated. The demo uses it for mass-casualty triage, and that single rating is what drives the open action to exercise it.

Findings are classified, owned and independently verified. ExerciseFinding.classification runs COMMENDABLE_CONFORMANCE → OBSERVATION → IMPROVEMENT_MINOR → NONCONFORMANCE_MAJOR → NONCONFORMANCE_CRITICAL. Each finding points back at what it implicates — the objective, the plan, the procedure, the resource — so the improvement is traceable to the thing that failed. CorrectiveAction carries owner_person_id, completed_by_person_id and verified_by_person_id as three separate columns precisely so closure can be checked against a different person from the owner.

The loop closes on the plan. PlanReview records what triggered the review (SCHEDULED / EXERCISE / INCIDENT / CHANGE_OF_RISK / …), what it found, and the proposed_revision; EmergencyPlan.supersedes_plan_id then chains the new revision to the old one, which moves to SUPERSEDED rather than being edited. The demo carries the full arc: the November 2025 exercise found command handover had no written format → finding EXF-2025-00032 → action ECA-2025-00123 → plan review PR-2025-004 → Revision B of EMP-DEMO-001, approved January 2026, superseding Revision A.

An exercise does not close while its serious actions are open. The proforma pack's CLOSE-001 rule says an exercise cannot reach CLOSED with unverified major or critical actions. The demo's November exercise therefore sits at ACTIONS_OPEN — five of its six findings are resolved, but the call-out roster action is still AWAITING_VERIFICATION.

The application is not the response. The boundary carried over from the proforma pack, and worth repeating: live emergency response must remain usable without this application or the network. What is modelled here is the preparation, the assurance and the improvement around the response — plans, readiness evidence, exercise records and corrective actions — not the command of a live emergency.

What Is Phase 2

The proforma pack ships lifecycle state machines (plan, exercise and resource readiness), thirteen business rules (PLAN-*, EX-*, RES-*, COMP-*, FIND-*, ACT-*, CLOSE-*) and escalation timers — 90-day contact verification, 4-hour critical resource escalation, 24-hour critical finding assignment, 14/30-day report due dates. None of that is enforced by the schema; the demo data is consistent with those rules rather than validated against them. Mobile field flows (controller console, evaluator capture, resource inspection, muster capture) and the analytics/graph projections are likewise documented intent, not built. See the header of apps/emergprep/schema/emergprep.dsl for the full translation record.