Application Overview

What the Exploration Programme Assurance app models, and the ideas behind it

Core Operating Chain

ExplorationProject                                    THE ROOT — one row per project
  │  (PRJ-CF Copperfield · InitialDrilling · Active)
  │
  ├─ Tenement                                         (the ground the licence holds)
  │
  ├─ CAPITAL ──────────────────────────────────────────────────────────────────
  │   FundingFacility → CapitalCall                   (where money comes from, drawn in tranches)
  │   BudgetPeriod → BudgetLine → Expenditure         (what it was allocated to, and spent on)
  │
  ├─ PROGRAMME (the plan) ──────────────────────────────────────────────────────
  │   WorkProgramme → ProgrammeActivity               (planned vs actual work)
  │   WorkProgramme → ProgrammeMilestone              (the dated checkpoints, some investor-material)
  │   WorkProgramme → ExplorationCampaign             (delivery on the ground)
  │                     ExplorationCampaign → CampaignProgress   (period reports: metres, cost, downtime)
  │                     ExplorationCampaign → AssayBatch         (samples out to the lab, QAQC back)
  │
  ├─ EVIDENCE & LEARNING (what we now know) ────────────────────────────────────
  │   ExplorationTarget → ExplorationHypothesis       (a testable claim about the target)
  │   ExplorationTarget → EvidenceItem                (a fact — drill result, assay, geophysics…)
  │        ExplorationHypothesis ─┐
  │                               ├─ HypothesisEvidence   (does this fact SUPPORT or WEAKEN the claim?)
  │        EvidenceItem ──────────┘                        carries confidence_before → confidence_after
  │   ExplorationTarget → UncertaintyDimension        (a named doubt: cover thickness, grade tenor…)
  │        UncertaintyDimension → UncertaintyAssessment   (re-score after a spend: score_before → after,
  │        EvidenceItem ─────────┘                          reduction_per_million = doubt bought down per $M)
  │
  ├─ DECISIONS ─────────────────────────────────────────────────────────────────
  │   DecisionGate → GateCriterion                    (the pass/fail tests for the gate)
  │   DecisionGate → Decision ← ExplorationTarget     (the investor-material call: fund / redirect / stop)
  │
  └─ ASSURANCE (keep everyone sighted) ─────────────────────────────────────────
      ProjectRisk                                     (what could derail it, likelihood × consequence)
      ExplorationCampaign → ProjectIssue              (what already has — raised against a campaign)
      InvestorUpdate                                  (the outward report, per audience)
      KpiSnapshot                                     (the dashboard row — variance, runway, $/uncertainty-point)

Every arrow means one row on the left owns many rows on the right. The ExplorationProject is the root of almost everything; ExplorationTarget is the second hub, the thing that evidence, hypotheses, uncertainty and target-level decisions all hang off.

Where This Sits — App 2 of 3

The Exploration Assurance Suite runs three apps across the exploration lifecycle:

  1. eis — screening. Which opportunities are worth funding at all? It scores and shortlists raw opportunities and produces a go decision.
  2. epa — this app. Execution assurance, after capital is committed. The opportunity eis approved is now a live project; epa governs the spend, tracks the learning, and decides what to fund next.
  3. (the third continues the story downstream — resource/feasibility governance.)

The demo makes the hand-off explicit. Copperfield's target-defining magnetic anomaly enters epa as EV-CF-10, an EvidenceItem whose evidence_origin is ScreeningTransferred — the fact that eis screened on, carried forward so the chain of reasoning is unbroken across the two apps.

Key Concepts

Capital is governed on two axes at once — source and purpose. A FundingFacility answers where the money came from (equity placement, grant, JV, debt) and a CapitalCall draws it down in tranches against a required-by date. A BudgetPeriod → BudgetLine → Expenditure chain answers what it was allocated to and actually spent on, by cost category. The two axes are separate on purpose: the demo's FAC-CF-EQ placement has 2.0M approved / 1.2M drawn / 0.8M remaining, while BUD-CF-FY26 shows 1.85M approved against 0.54M actual — the facility tracks liquidity, the budget tracks burn, and they are reconciled through capital calls like CC-CF-01 (funded) and CC-CF-02 (approved, not yet received).

Programme, activity and campaign are three altitudes of the same work. The WorkProgramme (WP-CF-FY26) is the annual plan and its budget envelope; ProgrammeActivity rows (ACT-CF-RC RC drilling, ACT-CF-MAG infill magnetics) are the planned-vs-actual line items inside it; and the ExplorationCampaign (CMP-CF-RC1) is the actual field mobilisation, with its contractor, its metre-by-metre CampaignProgress reports and its AssayBatch submissions. The same drilling shows up at all three altitudes, each with its own planned and actual quantities — that is how a programme that is "32% complete" can still be read down to which hole is turning.

Evidence and hypothesis confidence is a first-class, auditable thing. An ExplorationHypothesis is a testable claim ("the magnetic high is a magnetite-rich IOCG system under 40–80 m cover") carrying an initial_confidence and a current_confidence. It moves only through HypothesisEvidence links, each of which pins one EvidenceItem to the hypothesis with a relationship (Supports / Weakens / Contradicts / Neutral / Pending), a strength, and — the load-bearing part — an explicit confidence_before and confidence_after. The demo walks HYP-CF-01 from 0.45 → 0.55 on the transferred geophysics and 0.55 → 0.62 on the first altered drill intercept, and its trend reads Strengthening. You can reconstruct exactly which fact moved the number and by how much.

Uncertainty reduction is measured per dollar. An UncertaintyDimension is a named doubt with an importance_weight, a current_uncertainty_score and a desired_uncertainty_score — the demo carries UNC-CF-COVER (cover thickness, 6.0 heading for 2.5) and UNC-CF-GRADE (copper grade tenor, 7.5 still open). An UncertaintyAssessment re-scores it after a spend and records reduction_score, expenditure_linked and reduction_per_million. That last field is the whole point of the app in one number: the cover assessment bought 2.0 points of certainty for $420k (4.76 per $M), while the grade assessment bought only 0.5 — because grade cannot be resolved until the assays return. Capital efficiency is the learning per dollar, and it is stored, not inferred.

Decision gates turn evidence into a fundable call. A DecisionGate (DG-CF-1, the Stage 1 Resourcing Decision) is a staged checkpoint carrying a recommended_outcome and an actual_outcome drawn from the same vocabulary (Proceed / ProceedConditional / Hold / Rework / Stop / Divest / NotSet). It is gated by GateCriterion rows — GC-CF-01 "confirmed copper grade" is NotAssessed and mandatory, so the gate is blocked; GC-CF-02 "funding runway" already Passes. The Decision record is the durable, often investor_material account of a call actually taken — DEC-CF-01 funded the RC campaign; DEC-KN-01 paused the Kalahari project pending better geophysics. A decision carries its evidence_summary, assumptions_summary and expected_learning, so a later reviewer can see not just what was decided but on what basis.

Risks are forward-looking, issues are live. A ProjectRisk (RSK-CF-02 barren alteration, likelihood 3 × consequence 4, residual High, trend Improving) is a thing that might happen, scored and owned. A ProjectIssue (ISS-CF-02 assay QAQC standard failure, Actioning) is a thing that has happened, raised against a specific campaign. Both carry an investor_material flag so the ones that matter to the market can be surfaced straight into an investor update.

The whole programme reduces to two outward views. An InvestorUpdate (IU-CF-Q1) is the narrative report — achievements, learning, material results, risk changes, decisions required, next funding requirement — scoped to an audience (Board, Investors, JV partners, Lenders, Public). A KpiSnapshot is the same reality as numbers on a date: budget variance, programme progress, milestone on-time %, assay turnaround, open critical risks, evidence-verified %, target confidence, an uncertainty index, and capital_per_uncertainty_point. One is for reading, the other is for trending.

What Is Phase 2

The pack from which this app was converted (app_config.yaml, 02_exploration_programme_assurance/) ships business rules, lifecycle workflows, permissions and integrations that are not enforced by the schema here. In particular:

  • The roll-ups are stored, not computed. ExplorationProject.spent_to_date, forecast_at_completion, runway_months and overall_confidence_score; BudgetPeriod.variance_amount / variance_percent; WorkProgramme.progress_percent; and every field on KpiSnapshot are populated by the seed to be consistent with the rows beneath them. Nothing recalculates them when a child changes.
  • Reference codes (PRJ-CF, WP-CF-FY26, CMP-CF-RC1, DG-CF-1…) follow the pack's numbering conventions by hand; there is no numbering engine.
  • Licence compliance is deliberately externalised. Detailed work-programme commitments and statutory compliance live in the separate Licence & Work Programme app; epa carries only Tenement.compliance_status as an assurance signal.

All 26 models convert cleanly with no FK cycles — every reference points at an already-defined table (see the header of apps/epa/schema/epa.dsl). Enum values are kept verbatim from the pack; the only mechanical changes were camelCase → snake_case, x_id foreign keys, a display_template on every reference, and each FK target's own *_name field marked [unique] so denormalised list columns show the entity name rather than an id.