DCF Test Battery v1.0 — Cycle-1 Results

First-cycle reconciliation of the Afrimintel DCF tool against published Kamoa-Kakula NPV targets. Reference DCF (Python implementation) + platform DCF (v1.0.37 js/app.js calcDCF() ported verbatim to Python and run against the same battery).

Headline findings — five

Cycle-1 results — dual column populated

Three columns: Reference DCF (Python implementation, 4 May AM), Platform DCF (v1.0.37 calcDCF() ported, 4 May PM), Published Kakula target.

Category 1 — Monotonicity tests

Category 2 — Boundary tests

Category 3 — Sensitivity tests

Category 4 — Reconciliation tests

Category 5 — Pre-specified failure mode tests

Platform DCF — math anatomy

Verbatim translation of calcDCF() from js/app.js:

cashflows = [-capex_dollars]
for yr in 1..mineLife:
    ebitda = annualRevenue - annualOpex - annualRoyalty
    nopat  = ebitda × (1 - tax_pct/100)
    cashflows.append(nopat)
NPV = Σ cf / (1+rate/100)^t
IRR via bisection on (-0.5, 10)

And runDCF() upstream:

productionTonnes = production_kt × 1000          # math requires CONTAINED metal
annualRevenue    = productionTonnes × price × recovery_pct/100
annualOpex       = productionTonnes × opex_per_tonne
annualRoyalty    = annualRevenue × royalty_pct/100

Five structural omissions vs a properly modelled DCF

1. No depreciation tax shield. Tax applied to raw EBITDA. A real DCF computes tax on (EBITDA − depreciation), giving a cash-flow boost worth ~3-7% of NPV in most contexts. Platform tax burden is therefore overstated; this works against over-crediting.
2. No sustaining capex. Annual cash flow is just NOPAT — no deduction for ongoing capex. For a 21-year mine this is materially missing; reference deducts $50M/yr × 21 = $1.05bn nominal (~$500M PV). Platform over-credits by this amount.
3. No production ramp-up. Steady-state from year 1. Reference ramps [50%, 75%, 100%]. Front-loading 100% production into the highest-PV year is a major over-credit.
4. No state participation. Reference computes attributable cash flow but reports project-level NPV (Ivanhoe convention); platform is project-level by default — same outcome at NPV level for this jurisdiction. But a user evaluating an asset in a state-participation jurisdiction (DRC 20%, Botswana 15%, Zambia 15%, Tanzania 16%) would not see this captured.
5. Uniform LoM opex. No first-5-years cost trajectory, no late-life cost rise. The $0.48/lb DFS figure is published as first-5-years; using it as LoM constant systematically under-states cost.

Effects 1, 4 reduce NPV vs a fuller model. Effects 2, 3, 5 increase NPV. Net: 2+3+5 dominate, and the platform over-credits relative to both the reference and published targets.

Implied reconciling LoM cost — three-way table

The 45-cent spread between reference and platform reconciling costs is exactly the dollar value of the three structural omissions. If the platform added ramp-up, sustaining, and tax shield, its reconciling cost would converge toward the reference's $1.06/lb.

Recommendations — cycle 2 spec amendments and platform engineering

For DCF spec v1.1 (test battery)

1. Add LoM cost trajectory as required input with both first-5-years and LoM-average values. v1.1 amendment is drafted and integrates into the master spec when editorial sign-off completes.
2. Solve C4.2, C4.3, C4.4 reconciling LoM costs in cycle 2. Each study has different scope/grade/throughput.
3. Document the unit conventions explicitly — the spec should state whether "production" means contained or recovered metal, and whether OPEX is per-contained or per-recovered tonne.

For platform DCF tool (v1.0.38 patch or Q3 reviewer scope)

1. Clarify input units in form labels. Either "Annual production (kt/yr CONTAINED, i.e., ore × grade)" or restructure to take ore tonnes + grade as separate inputs (the mining-engineer mental model), removing ambiguity. Same for OPEX — either explicit "$/t-contained" labelling or convert internally from per-recovered-pound or per-tonne.
2. Add ramp-up profile input. Even a 2-year ramp [50%/100%] would meaningfully improve realism without UX bloat.
3. Add sustaining capex input. Single $/year line item separate from initial capex.
4. Add depreciation tax shield. Either let users input depreciation directly, or default to straight-line over mine life on initial capex and document the convention.
5. Document the five structural omissions explicitly on the tool page, mirroring the spec's "Known limitations" pattern.

For Q3 paid-reviewer scope

The reviewer should now scope to: (a) audit, expand, and reproduce the v1.0 battery; (b) co-author v1.1 spec amendment with cost-trajectory specification; (c) assess whether platform v1.0.38 should add the five structural elements above, or whether documenting limitations is sufficient at Day 30 + 90.

What this cycle does NOT establish

Per Quality Standard three-state discipline:

• The platform's actual rendered output in the browser was not directly executed (Node.js with full DOM not run). The Python port reproduces the exact calcDCF() and runDCF() math line-by-line; any divergence between this Python port and the actual JavaScript runtime would itself be a finding worth investigating, but is not expected since the math is straightforward arithmetic with no DOM dependencies inside calcDCF().
• The "true" LoM cash cost trajectory of Kamoa-Kakula is still Derived (back-solved against published NPV), not Sourced from a published Ivanhoe DFS cash flow ladder. Two reconciling costs ($1.06 reference, $1.51 platform) are documented as Derived values with stated methodology.
• C4.2, C4.3, C4.4 reconciling costs at the platform level are not yet computed. Same approach applies to all four.

Cycle 2 should reduce the absence list, not add to it.

Why this is published

Three reasons:

1. The Quality Standard requires it. Afrimintel's three-state model (Sourced / Derived / Absent) does not allow undocumented Derived outputs. The platform's DCF tool produces Derived NPVs; the methodology that connects inputs to outputs must be auditable. Publishing cycle-1 results closes a documentation gap that the Quality Standard explicitly requires closed.
2. Institutional readers will run their own checks. A senior credit committee analyst evaluating the platform's DCF tool will reach for a reference asset and reconcile. Publishing the cycle-1 results in advance — including the failures — is the discipline equivalent of a full disclosure document. The reader sees the gaps Afrimintel sees, rather than discovering them and concluding the platform was hiding them.
3. The pattern is what matters. What this published cycle-1 demonstrates is not that the DCF tool is finished — it is not — but that the platform's discipline architecture catches its own gaps and publishes them with the same rigour as the methodology. This pattern is the institutional credibility artifact, regardless of which cycle is being run.

Cycle 2 will reduce the absence list. Cycle 3 will reduce it further. Each cycle is published. Each cycle is dated. Each cycle is signed.

Cycle-1 reference run: 4 May 2026 (morning). Cycle-1 platform run: 4 May 2026 (afternoon, post v1.0.37 build access). Reference: dcf_reference.py. Sensitivity: dcf_sensitivity.py. Platform: dcf_platform.py (verbatim port of js/app.js calcDCF() lines 3501–3617). Editorial responsibility: Nikesh Patel. Publication date: 9 May 2026 (companion document to DCF Test Battery v1.0).