Application Overview

What the Exploration Licence & Work Programme Management app models, and the ideas behind it

Core Operating Chain

Jurisdiction → Tenement ← ExplorationProject        (the tenure, and who grants/holds it)
  Tenement → TenementParty                           (holder · JV partner · Traditional Owner)

  Tenement → StatutoryObligation ← ExplorationProject   THE UNIT OF COMPLIANCE
    StatutoryObligation → ObligationAction           (the tasks that discharge it)

  Tenement → WorkProgrammeCommitment                 (committed metres/$ vs actual + variance)
  Tenement → ExpenditureObligation → EligibleExpenditure   (minimum spend vs eligible line items)
                                    └ shortfall / carry-forward / exemption

  Tenement → LicenceCondition                        (what the grant obliges)
  Tenement → ApprovalPermit                          (PoW, clearing, heritage, water)
  Tenement → LandAccessAgreement                     (pastoral, Traditional Owner)

  StatutoryObligation → StatutorySubmission ← Tenement   (what is lodged to the regulator)
    StatutorySubmission → SubmissionRequirement      (validated line items — Pass/Warning/Fail)
    StatutorySubmission → RegulatorCorrespondence ← Tenement  (query in, response out)

  Tenement → VariationApplication                    ─┐
  Tenement → ExemptionApplication                     │  changing the licence or
  Tenement → Renewal                                  │  the commitment on it
  Tenement → Relinquishment                          ─┘

ComplianceRisk ← StatutoryObligation / Tenement / ExplorationProject   (the risk register)
EvidenceItem ← Tenement / ExplorationProject
  StatutoryObligation → ObligationEvidence ← EvidenceItem   (evidence tied to an obligation)
Decision ← Tenement / ExplorationProject             (why a course was taken, on the record)
ExplorationProject → ComplianceSnapshot              (the whole project rolled up to one status)

Key Concepts

One question, asked of tenure. The whole app exists to answer "are tenure, expenditure, reporting and work-programme obligations being met?" for each exploration licence. The Tenement is the hub — 16 of the model's 40 relationships hang off it — because every obligation, commitment, permit, submission and application is scoped to a specific licence. The demo carries a single project, PRJ-CF Copperfield, holding tenement E29/1234 Copperfield East (granted, renewal approaching) and E29/1299 Copperfield West (still an application), so the chain is visible end to end for a live licence while a second one sits at an earlier tenure stage.

Tenure and the parties on it. A Tenement records the licence type, number, grant and expiry dates, area, the minimum annual expenditure it commits to, and a licence_status that walks Application → Granted → RenewalPending → …. Its TenementParty rows keep every interested organisation with a party_role (Holder, JVPartner, TraditionalOwner, Landholder, Agent) and an interest percentage — the demo pairs Meridian Exploration as 100% Holder with the Goldfields Land Aboriginal Corporation as a TraditionalOwner party.

Statutory obligations are the unit of compliance. A StatutoryObligation carries an obligation_type (Expenditure, AnnualReport, WorkProgramme, Rent, Renewal, DataSubmission …), a period, a due_date and a grace_date, a materiality (Routine / Important / Material) and a status that runs NotDue → Planned → InProgress → AtRisk → Overdue → Submitted → Accepted. Each obligation is worked off through ObligationAction tasks with their own owners, planned/due/completed dates and blocking reasons. The demo's two obligations — OBL-EXP-Y3 (year-3 minimum expenditure) and OBL-REP-Y2 (annual Form 5 report) — are both Material, and each carries the actions that move it forward.

Work-programme and expenditure commitments are measured, not asserted. These are the two obligation kinds a regulator scrutinises, so they get dedicated structures. WorkProgrammeCommitment stores committed quantity and expenditure against actuals and computes variance_quantity / variance_expenditure; the demo's WPC-Y3-DRILL has committed 2500 m of drilling but delivered only 1050 m, leaving it AtRisk. ExpenditureObligation tracks required_amount against eligible_actual_amount, forecast_eligible_amount, carry_forward_amount, exemption_amount and the resulting shortfall_amount, itemised by EligibleExpenditure transactions each with an eligibility basis. The year-3 expenditure shortfall is the worked example of the whole app: EXPO-Y3 forecasts ~20k below the 250k minimum, which opens a High compliance risk and drives a draft exemption application — exactly the licence.obligation.at_risk signal the suite is built to surface.

Conditions, permits and access are separate obligations of the ground. A LicenceCondition is a standing term of the grant with its own compliance status; an ApprovalPermit is a discrete approval (Programme of Work, native-vegetation clearing, heritage, water) with an application/approval/expiry lifecycle; a LandAccessAgreement is the deal with the landholder or Traditional Owner that lets work happen at all. The demo keeps a Compliant rehabilitation condition, an approved drilling PoW plus a submitted clearing permit, and an active pastoral access agreement over the whole tenement.

Submissions are how compliance is proven, and correspondence is the answer back. A StatutorySubmission is a lodged package — an annual report, expenditure statement, technical report, work-programme or data package — built from SubmissionRequirement line items each carrying a validation_status (Pass / Warning / Fail). Once lodged, RegulatorCorrespondence records the two-way exchange with direction Inbound / Outbound. The demo's SUB-AR-Y2 annual report is QueryRaised: one requirement validates Warning because the regulator queried the expenditure apportionment basis (CORR-01 inbound), and the operator's methodology response (CORR-02 outbound) closes the thread.

Changing the licence is its own machinery. When the commitment or the licence itself has to move, four application types carry it: VariationApplication (defer work, adjust expenditure, change area or a condition), ExemptionApplication (relief from an expenditure or reporting obligation), Renewal (extend the term, often with a statutory relinquishment), and Relinquishment (hand back area). In the demo, ground-condition delays drive a work-programme VAR-01 to defer 1450 m into year 4, a draft EXM-01 seeks partial relief for the expenditure shortfall, REN-01 is planned against the 2028 renewal due-date carrying a 44 km² relinquishment, and REL-01 records that statutory 50% handback.

Compliance risk is the register that ties threats to obligations. A ComplianceRisk carries a risk_category (Expenditure, Reporting, Deadline, Permit, Renewal …), a likelihood × consequence pair, a residual_rating (Low → Critical), a trend and a status, and can point at the specific project, tenement and obligation it threatens. CR-01 is the year-3 expenditure shortfall — High, Mitigating — and CR-02 is the open annual-report query — Moderate, Improving. A High/Critical risk that is Worsening is precisely what the suite would emit upward as a material compliance threat.

Evidence is a register, and it is linked to obligations explicitly. An EvidenceItem is a receipt, approval, map, dataset, report or declaration held against the project or tenement; ObligationEvidence is the join that says this evidence supports / completes / partially satisfies that obligation. The demo links a drilling invoice to the expenditure obligation (Partial) and the approved PoW to the reporting obligation (Supports), so an obligation can be read back to the exact documents that discharge it.

Decisions and the snapshot are the assurance layer. A Decision records why a course was taken — vary, exempt, renew, relinquish, escalate, accept risk — with a legal basis and an evidence summary, so the reasoning is on file, not just the outcome. The ComplianceSnapshot rolls the whole project up into one dated row: open / at-risk / overdue obligation counts, expenditure required vs eligible actual and the coverage percent, submissions due in 30 days, renewals in 180, permits expiring in 90, high/critical risk count and an overall_compliance_status. The demo's snapshot reads AtRisk at 84% expenditure coverage with one high-critical risk — the shortfall, surfaced to the top.

This is app 3 of the Exploration Assurance Suite — the compliance chain. The suite runs Tenure → Obligations → Work/expenditure commitments → Submissions → Regulator response → Right to continue exploring. This app owns the detailed regulatory machinery; its sibling apps (eis exploration information and epa programme assurance) share the same canonical Copperfield project and E29/1234 tenement keys. Material compliance threats are emitted to the programme-assurance app rather than duplicated there — the boundary is deliberate.

What Is Phase 2

The proforma pack ships business_rules.yaml (nine rules: obligation due/overdue flags, shortfall and coverage calculations, renewal and permit lead-time warnings, submission validation gating, the material-non-compliance event emission, and work-programme variance), a compliance dashboard with a regulatory calendar, variance and risk-matrix panels, workflows.yaml, permissions.yaml and integrations.yaml. None of that is enforced by the schema — the demo data is consistent with those rules rather than validated against them. In particular, the variance columns on WorkProgrammeCommitment, the shortfall_amount on ExpenditureObligation and every count on ComplianceSnapshot are stored values populated by the seed; nothing rolls them up from the rows beneath. The suite-level event emission (licence.obligation.at_risk) is documented intent, not built.

See the header of apps/elwpm/schema/elwpm.dsl for the translation record: the pack's camelCase became snake_case, every FK got a display_template, each FK-target's own *_name field was marked [unique] so denormalised list columns show the entity name, and all enum values were kept verbatim. All references point at already-defined tables, so the model has no FK cycles and none had to be dropped.