System Diagram

The Exploration Licence & Work Programme Management data model, mapped — 24 models, 40 relationships

🔍 For serious exploration, open the Interactive Diagram Viewer — pan, mouse-wheel zoom, fit-to-screen, full-screen, per-module tabs, the full 40-relationship ERD, and a focus mode that draws one model and its neighbours at a chosen depth. Tenement (16 links) and ExplorationProject (15) are the tenure/project columns that fan out to nearly everything, so the viewer hides those links by default — a toggle brings them back. The diagrams below are the readable, static summary of the principal links only.

Architecture Overview

Six areas mirror the sidebar menu. Every arrow means "one row of the left model is referenced by many rows of the right model".

flowchart LR
    subgraph OVR["📊 Compliance overview"]
        ExplorationProject
        Tenement
        ComplianceSnapshot
    end

    subgraph OBL["📋 Obligations & commitments"]
        StatutoryObligation --> ObligationAction
        WorkProgrammeCommitment
        ExpenditureObligation --> EligibleExpenditure
        LicenceCondition
    end

    subgraph APP["✅ Approvals & access"]
        ApprovalPermit
        LandAccessAgreement
        TenementParty
    end

    subgraph REP["📤 Reporting & evidence"]
        StatutorySubmission --> SubmissionRequirement
        StatutorySubmission --> RegulatorCorrespondence
        EvidenceItem --> ObligationEvidence
    end

    subgraph CHG["🔄 Licence changes"]
        VariationApplication
        ExemptionApplication
        Renewal
        Relinquishment
    end

    subgraph ASR["🛡️ Assurance & reference"]
        Jurisdiction
        ComplianceRisk
        Decision
    end

    Jurisdiction --> Tenement
    ExplorationProject --> Tenement
    ExplorationProject --> ComplianceSnapshot
    Tenement --> TenementParty
    Tenement --> StatutoryObligation
    ExplorationProject --> StatutoryObligation
    Tenement --> WorkProgrammeCommitment
    Tenement --> ExpenditureObligation
    Tenement --> LicenceCondition
    Tenement --> ApprovalPermit
    Tenement --> LandAccessAgreement
    Tenement --> StatutorySubmission
    StatutoryObligation --> StatutorySubmission
    Tenement --> RegulatorCorrespondence
    Tenement --> EvidenceItem
    StatutoryObligation --> ObligationEvidence
    Tenement --> VariationApplication
    Tenement --> ExemptionApplication
    Tenement --> Renewal
    Tenement --> Relinquishment
    Tenement --> ComplianceRisk
    StatutoryObligation --> ComplianceRisk
    Tenement --> Decision

(Tenement is the hub of the model — 16 of the 40 relationships touch it. It is where tenure, obligations, commitments, permits, access, submissions, applications, risk, evidence and decisions all meet, which is exactly the domain's intent: the licence, not the project, is the unit of compliance.)

Compliance Overview — Tenure

Where tenure sits: a jurisdiction grants tenements, a project holds them, and the project rolls up to a periodic snapshot.

erDiagram
    Jurisdiction ||--o{ Tenement : "jurisdiction_id"
    ExplorationProject ||--o{ Tenement : "project_id"
    ExplorationProject ||--o{ ComplianceSnapshot : "project_id"

Obligations & Commitments

The unit of compliance and its two measured commitment kinds. An obligation is scoped to a tenement (and its project); the work-programme and expenditure commitments are what a regulator scrutinises, and eligible-expenditure line items are the audit trail beneath the spend.

erDiagram
    Tenement ||--o{ StatutoryObligation : "tenement_id"
    ExplorationProject ||--o{ StatutoryObligation : "project_id"
    StatutoryObligation ||--o{ ObligationAction : "obligation_id"
    Tenement ||--o{ WorkProgrammeCommitment : "tenement_id"
    Tenement ||--o{ ExpenditureObligation : "tenement_id"
    ExpenditureObligation ||--o{ EligibleExpenditure : "expenditure_obligation_id"
    Tenement ||--o{ LicenceCondition : "tenement_id"

Approvals & Access

The obligations of the ground: who is a party to the tenement, what permits it holds, and the land-access deals that let work happen.

erDiagram
    Tenement ||--o{ TenementParty : "tenement_id"
    Tenement ||--o{ ApprovalPermit : "tenement_id"
    Tenement ||--o{ LandAccessAgreement : "tenement_id"

Reporting & Evidence

How compliance is proven. A submission is built from validated requirements and answered by two-way regulator correspondence; evidence items are linked back to the specific obligations they discharge through the ObligationEvidence join.

erDiagram
    StatutoryObligation ||--o{ StatutorySubmission : "obligation_id"
    Tenement ||--o{ StatutorySubmission : "tenement_id"
    StatutorySubmission ||--o{ SubmissionRequirement : "submission_id"
    StatutorySubmission ||--o{ RegulatorCorrespondence : "submission_id"
    Tenement ||--o{ RegulatorCorrespondence : "tenement_id"
    Tenement ||--o{ EvidenceItem : "tenement_id"
    StatutoryObligation ||--o{ ObligationEvidence : "obligation_id"
    EvidenceItem ||--o{ ObligationEvidence : "evidence_item_id"

(ObligationEvidence is the join that makes obligations auditable — without it an evidence register is just a document pile; with it, every obligation can be traced to the receipts, approvals and reports that satisfy it.)

Licence Changes

When the commitment or the licence itself must move. Every application type is scoped to the tenement it changes.

erDiagram
    Tenement ||--o{ VariationApplication : "tenement_id"
    Tenement ||--o{ ExemptionApplication : "tenement_id"
    Tenement ||--o{ Renewal : "tenement_id"
    Tenement ||--o{ Relinquishment : "tenement_id"

Assurance & Reference

The register that ties threats to the exact obligation, tenement and project they endanger, the decision record, and the jurisdiction reference at the root of it.

erDiagram
    ExplorationProject ||--o{ ComplianceRisk : "project_id"
    Tenement ||--o{ ComplianceRisk : "tenement_id"
    StatutoryObligation ||--o{ ComplianceRisk : "obligation_id"
    ExplorationProject ||--o{ Decision : "project_id"
    Tenement ||--o{ Decision : "tenement_id"
    Jurisdiction ||--o{ Tenement : "jurisdiction_id"

Application Flow — Obligation to Right-to-Continue

The order in which the system is actually used, and what gates each step.

flowchart TD
    A["🪨 Tenement granted<br/><i>minimum annual expenditure set</i>"] --> B["📋 Statutory obligation<br/><i>type · period · due · materiality</i>"]
    B --> C["🛠️ Obligation actions<br/><i>owners, planned/due/completed</i>"]
    C --> D{"Measured commitment?"}
    D -->|"work programme"| E["📐 Committed vs actual metres/$<br/><i>variance computed</i>"]
    D -->|"expenditure"| F["💵 Required vs eligible actual<br/><i>shortfall = req − eligible − exemption − carry-fwd</i>"]
    E --> G{"On track?"}
    F --> G
    G -->|no| H["⚠️ Compliance risk raised<br/><i>residual rating, trend</i>"]
    H --> I["🧭 Decision recorded<br/><i>vary · exempt · renew · escalate</i>"]
    I --> J["🔄 Variation / exemption lodged"]
    G -->|yes| K["📤 Statutory submission<br/><i>requirements validated Pass/Warning/Fail</i>"]
    J --> K
    K --> L{"Regulator response"}
    L -->|"query"| M["✉️ Correspondence in → out<br/><i>submission → QueryRaised</i>"]
    M --> K
    L -->|"accepted"| N["✅ Obligation Accepted<br/><i>evidence linked via ObligationEvidence</i>"]
    N --> O["📊 Compliance snapshot<br/><i>project rolled up to one status</i>"]
    H --> O

Application Flow — Why the Project Reads "At Risk"

The single most important thread in the demo, drawn out: an expenditure shortfall becoming an exemption.

flowchart TD
    S(["EXPO-Y3 · 250k minimum expenditure"]) --> R["💵 Eligible actual accrues<br/><i>drilling invoice, assays</i>"]
    R --> Q{"Forecast ≥ minimum?"}
    Q -->|"no — ~20k short"| K1["📉 Shortfall recorded on EXPO-Y3"]
    K1 --> K2["⚠️ CR-01 raised<br/><i>likelihood 4 × consequence 3 → High</i>"]
    K2 --> K3["🧭 DEC-EL-01 vary · DEC-EL-02 exempt"]
    K3 --> K4["🔄 VAR-01 defers 1450 m to year 4"]
    K3 --> K5["📄 EXM-01 seeks 20k partial relief · Draft"]
    K4 --> K6["📊 Snapshot: AtRisk · 84% coverage · 1 high/critical risk"]
    K5 --> K6
    Q -->|yes| M["✅ Obligation Met — no exemption needed"]

Reading the Diagrams

  • A ||--o{ B means one row of A is referenced by many rows of B (the label is the foreign-key column on B).
  • These static diagrams show principal links only — the tenure/project columns (tenement_id, project_id) that appear on nearly every model are shown here only where they carry the story. The interactive viewer's Full ERD shows all 40, with the Tenement / ExplorationProject fan-out toggleable.
  • Tenement is the hub of the model — the viewer's Focus mode is the fastest way to see its 16 links. ExplorationProject has the next most (15) because every major record is scoped to both the licence and the project it belongs to; several models (StatutoryObligation, StatutorySubmission, WorkProgrammeCommitment, ExpenditureObligation, ComplianceRisk, EvidenceItem, Decision, ApprovalPermit, and the four change applications) carry both foreign keys.
  • No FK was dropped in translation and there are no self-references — every reference in elwpm.dsl points at an already-defined table, so the model is acyclic. ComplianceRisk is the widest child, carrying three parent references at once (project_id, tenement_id, obligation_id) so a risk can be pinned to the exact obligation it threatens.
  • The *_code columns that appear throughout (project_code, tenement_code, obligation_code, submission_code …) are denormalised business keys, not foreign keys — they carry the human-readable code alongside the numeric FK so list columns read E29/1234 rather than an id. The real edges are the *_id columns.

Diagrams are derived from the generated schema metadata (apps/elwpm/generated/json/elwpm_relationship_metadata.json). If the DSL schema changes, regenerate the metadata (python -m codegen.cli all elwpm), rebuild the viewer (python apps/elwpm/scripts/build_diagram_viewer.py) and update this page.