Application Overview

What Tailings models, and the ideas behind it

Core Chains

Organisation → MineSite → TailingsFacility → FacilityComponent (self-nesting)
TailingsFacility → DesignBasis → DesignParameter
TailingsFacility → ConstructionStage → ConstructionQualityRecord → Nonconformance
InspectionTemplate → InspectionQuestion
InspectionSchedule → InspectionEvent → InspectionResponse → Defect
Instrument → InstrumentCalibration / MonitoringReading → MonitoringCurrent
ThresholdSet → ThresholdRule
TarpPlan → TarpActionDefinition
FacilityEvent / ThresholdRule / MonitoringReading → TarpActivation → TarpActionExecution
Defect / FacilityEvent → CorrectiveAction → WorkOrder
ReviewRecord → ReviewFinding → CorrectiveAction
ClosurePlan → ClosureCriterion → ClosureMonitoringResult
PublicationAuthority → Publication → Requirement → RequirementApplicability

Key Concepts

The facility is the spine. Twenty-three models hang directly off TailingsFacility — components, design, construction, inspections, instruments, thresholds, TARP plans, events, deposition, water balance, environmental samples, defects, corrective actions, work orders, reviews, emergency plans, closure plans and KPI results all carry a tailings_facility_id. One facility header (type, status, consequence category, crest elevation, operating level, minimum freeboard, storage vs design capacity) anchors the whole governance record.

Readings carry their validity. Every MonitoringReading records its unit, source, a reading_status (VALID / ESTIMATED / SUSPECT / REJECTED / MISSING / SUPERSEDED), who validated it and a trend direction. Only valid or estimated readings should update MonitoringCurrent, the one-row-per-instrument current state that also carries the instrument's current TARP level. High-frequency raw telemetry stays in the historian; the app holds the validated readings, threshold evaluations and decisions.

Thresholds drive graded response. A ThresholdSet (versioned, per facility or per instrument) holds ThresholdRules that map a trigger direction and value to a TARP level (NORMAL → LEVEL_1 → LEVEL_2 → LEVEL_3 → EMERGENCY). A breach opens a TarpActivation that references the rule, the reading and/or the event that triggered it, freezes the applicable plan version, and spawns TarpActionExecutions from the plan's TarpActionDefinitions — each with a responsible role, a completion target time and required evidence.

Escalation is one-way until verified. A TARP activation is not deactivated just because a later reading returns to normal — de-escalation is a recorded decision (with approval for high levels). Suspect readings can notify reviewers but must not auto-de-escalate.

Defects become work, work needs verification. Inspection findings and facility events raise Defects; Defects (and events and review findings) raise CorrectiveActions; physical work becomes a WorkOrder. A complete work order does not auto-close its corrective action or defect — closure follows an OPEN → … → VERIFIED → CLOSED path only after verification is recorded.

Everything is evidence. Attachments (photos, certificates), controlled documents (OMS, EAP, dam safety review), source references on readings, and the denormalized display fields make each record traceable. Independent reviews issue findings, emergency exercises test the EAP, and closure criteria track progress against measurable targets with monitoring results — the full lifecycle from active operation to accepted closure.