Application Overview

What the Progressive Rehabilitation and Mine Closure app models, and the ideas behind it

Core Operating Chain

SourceAuthority → SourceDocument → Requirement        (where the obligation came from)
  ClosurePlan → PlanRequirementLink ← Requirement     (how the plan answers it)
  ClosurePlan → ClosureAssumption                     (what the plan rests on)
  ClosurePlan → ClosureObjective → DomainObjective    (what it is trying to achieve)

MineSite → SpatialArea (self-nesting)                 (where the ground is)
  ClosureDomain (self-nesting, over a SpatialArea)     THE OPERATIONAL UNIT
    ClosureDomain → DomainLandUse ← PostMiningLandUse (what the land becomes)
    ClosurePlan → CompletionCriterion → DomainCriterion  (measurable "done")

  ClosureDomain → DisturbanceEvent                    (what created the liability)
  ClosureDomain → LandAvailabilityEvent               (the area-state audit trail)

  ClosureDomain → RehabilitationPrescription (self-superseding)   (approved treatment)
  RehabilitationCampaign → RehabilitationWork ← Prescription      (delivery)
    RehabilitationWork → WorkMaterial                 (what went in)
    RehabilitationWork → WorkInspection               (hold points, pass/fail)

  MonitoringProgram → MonitoringSchedule ← MonitoringLocation
    MonitoringSchedule → MonitoringEvent → MonitoringResult       (the evidence)
      DomainCriterion → CriterionAssessment           (THE JUDGEMENT)

        CertificationApplication → CertificationCriterion         (progressive certification)
          RelinquishmentApplication → RelinquishmentDomain        (whole-of-site handback)

ClosureRisk ─┐
MonitoringEvent / CriterionAssessment → Finding → CorrectiveAction
ClosureCommitment ─┘                                (the improvement loop)

Stakeholder → EngagementEvent → ClosureCommitment    (what was promised, to whom)
ClosureCostEstimate (self-superseding) → ClosureCostItem
                                       ActualClosureCost         (estimate vs actual)
MineSite → ClosureReview                             (and back around the loop)
Evidence / Document / Approval                       (attached across the whole model)

Key Concepts

A certified hectare is traceable back to the disturbance that created it. The spine of the model is one long chain, and the demo carries it end to end for a single 12-hectare domain. PRMC-DST-2019-00041 disturbed 12 ha of the Stage 2 footprint in April 2019; six LandAvailabilityEvent rows walk that ground from NOT_AVAILABLE through AVAILABLE, REHABILITATION_STARTED, REHABILITATED, MONITORING, CERTIFICATION_PENDING to CERTIFIED; four RehabilitationWork records deliver it against prescription RRM-PRS-D01 Revision B with four accepted hold-point WorkInspection rows; five annual landform and vegetation MonitoringEvent rows with their MonitoringResult values feed four CriterionAssessment records; and certification PRMC-CERT-2026-0001 carries each of those assessments as a CertificationCriterion. You can read the chain in either direction from any point in it.

Four area states, never conflated. ClosureDomain keeps disturbance_hectares, available_for_rehabilitation_hectares, rehabilitated_hectares and certified_hectares as four separate stored columns, because they answer four different regulatory questions and move at very different rates. D01 in the demo reads 120 / 32 / 18 / 12 — 120 ha disturbed, only 32 released for work, 18 actually treated, 12 certified. The LandAvailabilityEvent rows are the audit trail for every transition, each carrying the previous status, the new status, the area, the reason and who authorised it.

A criterion is not met because someone says so. CriterionAssessment is the only thing that can move a DomainCriterion to MET, and it carries an assessment period, an evidence summary, a confidence level, an explicit limitations field, and three separate people — assessed_by, reviewed_by and approved_by. The demo's landform assessment PRMC-ASM-2026-00046 is the worked example: five annual surveys show erosion falling from 21.5 to 4.4 t/ha/yr against a reference site value of 3.9, the 2026 reading of 7.8 is still inside the 0–8 range but reverses the trend, and the assessment says so in limitations rather than burying it. It was still assessed MET — but on a recorded, reviewable basis that a regulator can argue with.

Partially met is a real answer. PRMC-ASM-2026-00048 assesses the Stage 2 water criterion PARTIALLY_MET, because the downstream compliance point integrates Stage 2 with the whole dump catchment and cannot resolve the Stage 2 contribution. Rather than deferring the certification application, the application discloses it, and the decision comes back APPROVED with a condition requiring three more years of monitoring. That path — disclose, get a conditional decision, carry the condition as a tracked ClosureCommitment — is the realistic one, and the demo shows it in preference to a clean pass.

Immutability is by supersession, not editing. Approved records are replaced by writing a superseding row that points back at what it replaced. The demo shows this five times over: ClosurePlan Revision A is SUPERSEDED by Revision B; criterion STAB-00 (an unmeasurable "no significant erosion is visible on inspection") is superseded by STAB-01 (a measurable comparison against a reference analogue); prescription RRM-PRS-D01 Revision A gives way to Revision B; cost estimate RRM-EST-002 Revision A to Revision B; and a superseded SourceDocument points at its replacement. The reason each supersession happened is legible from the records around it — the 2025 closure review found STAB-00 could not support a certification decision and that the Revision A batter design was measuring 14.2 t/ha/yr against a reference of 3.9.

Accountability is separable by design. Wherever a decision needs a second person, the schema gives it its own column: CriterionAssessment separates assessed / reviewed / approved; RehabilitationPrescription separates prepared / reviewed / approved; ClosureCostEstimate does the same; CorrectiveAction separates assigned_to_person_id from verified_by_person_id; WorkInspection separates the inspector from whoever accepted the result. tab_config.yaml labels every one of these roles, so a Person page reads "Assessments Made", "Assessments Reviewed" and "Assessments Approved" as three different facts.

Monitoring results are governed data, not the sensor or laboratory feed. The boundary carried over from the pack: authoritative geometry stays in the GIS, and high-frequency environmental and laboratory data stays in the source platform. SpatialArea.geometry_reference, MonitoringResult.source_system / source_reference / laboratory_sample_reference and ActualClosureCost.purchase_order_reference carry the handles. What is stored here is the validated result, the decision it supported and the evidence — not the historian, the GIS or the general ledger.

Certification is progressive, relinquishment is not. A CertificationApplication can be lodged for a single domain — the demo certifies 12 ha of a 120 ha dump while the rest is still being built — but RelinquishmentApplication covers the whole site and carries a RelinquishmentDomain row per domain with its own readiness status. The demo's relinquishment sits in READINESS_REVIEW and explicitly excludes D02, the East Pit, whose EXTREME inherent safety risk and unvalidated pit-lake terminal-sink assumption cannot be resolved before mining ceases in 2034. The readiness review recommends not lodging, and says which two long-lead items to start now.

The open finding sits on the certified ground. This is deliberate. Finding PRMC-FND-2026-00014 — post-storm rill and incipient gully development — was raised in February 2026 on the same Stage 2 batter that was certified in June 2026, and its corrective action is still IN_PROGRESS. That is the case a relinquishment readiness assessment actually has to answer for, and it is the case a demo that only shows clean passes never surfaces.

The application is a record and assurance system, not a determination. The boundary worth repeating from the pack: this does not establish legal compliance, calculate statutory financial assurance, replace the approved GIS, or substitute for jurisdiction-specific plans, regulator decisions, landholder agreements or Traditional Owner engagement. What is modelled here is the obligation, the plan, the delivery, the evidence, the judgement and the decision record around progressive rehabilitation and closure.

What Is Phase 2

The proforma pack ships prmc_workflows_rules.yaml (lifecycle workflows, guards, calculations and notifications), the numbering masks (PRMC-WRK-{YYYY}-{SEQ:06} and friends), four dashboards, eight reports, six graph views and four mobile field flows in prmc_navigation_dashboards.yaml. None of that is enforced by the schema — the demo data is consistent with those rules rather than validated against them, and the reference numbers follow the masks by hand. In particular, the four area-state columns on ClosureDomain and the estimate and cost-item totals are stored values populated by the seed; nothing rolls them up from the events beneath them. The DuckDB analytics datasets and the Neo4j graph projection in prmc_application.yaml are likewise documented intent, not built.

See the header of apps/rehab/schema/rehab.dsl for the full translation record, including the one FK cycle that had to be broken (DomainCriterion.current_assessment_id ↔ CriterionAssessment.domain_criterion_id — the child side was kept) and the three enums that had to be repaired, all of them whitespace-tokenisation damage in the pack: RehabilitationType's DRAINAGE INSTALL TOPSOIL PLACE AMEND SOIL became DRAINAGE_INSTALL, TOPSOIL_PLACE, AMEND_SOIL, and CostCategory's SOIL TREATMENT became SOIL_TREATMENT.