A developer approached me to build a financial model because he did not have confidence in the model he had inherited.

‍

It produced outputs, but he could not trace them — could not see how the assumptions flowed through the calculations, or whether the results reflected the project underneath. With funding ahead, the model would face scrutiny it had not been built to withstand. He needed more than another spreadsheet. He needed a model he could understand, interrogate and trust.

‍

That engagement brought into focus a problem I had encountered for more than 15 years across the resources sector: the gap between how mining projects operate and how they are financially evaluated.

‍

I saw it in financial modelling, operational management, corporate strategy and business improvement alike: the financial model was treated as a financial output rather than an integrated representation of the project. The calculations might have been correct, the assumptions supported by technical studies, the detail impressive. But the model did not always reflect how the project really worked — or show decision-makers what was driving its economic outcome.

‍

The Gap between the Project and the Model

‍

Mining projects are inherently interconnected. The mining schedule determines the volume and grade of ore delivered to the plant. Throughput and recovery convert that feed into saleable product, while plant capacity shapes the scale of capital investment. Equipment, maintenance, labour, consumables and logistics drive operating costs. Product sales generate revenue; the funding structure and level of leverage influence financing cash flows and equity returns. Change one assumption and the effects flow through the entire project.

‍

These relationships are fundamental to project economics, yet they are not always visible in the model. Technical inputs are developed by different disciplines, for different purposes and at different times, and the model becomes the place where they are assembled — but assembling information is not the same as integrating it.

‍

When those connections are not properly modelled, the outputs can appear more certain than the project warrants. Management cannot identify the levers that matter most. Boards struggle to see the range of credible outcomes. Investors and lenders cannot test what happens when the assumptions move.

‍

The model produces a result — but not necessarily insight.

‍

That first client’s concern was not that the model might contain an error, but that he could not follow its structure and logic, and therefore could not depend on the outputs. Trust in a financial model should not require blind acceptance. It should be earned through transparency, disciplined design and a clear line from assumption to outcome.

‍

Built from Operational Experience

‍

My approach to modelling was shaped as much by operational experience as by finance.

‍

Margin is not created in the financial statements. It is created — or lost — in operating decisions: what to mine next, when to take a circuit down for maintenance, how to deploy the workforce, where to commit capital. The model should make those relationships visible, tracing an operational decision through to its commercial consequence and showing why an outcome changes rather than simply reporting that it has.

‍

Throughout my operational career, I have consistently found that principle holds. I have faced decisions I lacked confidence in — not because I was afraid to decide, but because the information I had was incomplete. Whether the decision turned on operating margins, production aligned to export requirements, a development pathway or a project heading for funding, the requirement was the same:

‍

Connect the technical and operational reality of the project to a clear financial outcome.

‍

The model built for that first client applied this directly: structured around the project rather than inherited conventions, with clearly identified assumptions and calculation logic that could be followed. It was completed and adopted as the project’s funding model. The objective was not to replace an old model with a new one, but to restore confidence in the information behind the decision.

‍

‍

Designing around the Decision

‍

That engagement aligned with my own experience: the problem was broader than one project. In my own case it was never a single failure — gaps in the inputs, poor quality data, and models that could not answer the question in front of me. More than once I rebuilt them myself to reach a decision. The answer had to be a disciplined approach.

‍

Orecast was founded in 2025 to consolidate that experience into a specialist practice — not generalist advice or standard templates, but transparent, integrated financial models built around the decisions they must support.

‍

No two mining projects present the same challenge. Commodities carry their own production constraints. Development pathways, infrastructure, offtake arrangements and funding structures vary project by project. An operating asset asks different questions from one heading into feasibility. So Orecast models are bespoke — built around the strategic question and the critical value drivers, not around a structure decided in advance.

‍

A bespoke model is one source of confidence. Independence is another: it brings objectivity, and objectivity allows assumptions to be challenged constructively. Above all, it creates room for a fundamental question, asked before the modelling begins:

‍

What decision does this model need to inform?

‍

That question opens every engagement, and CORE-5 with it — Scope, Build, Model, Analyse and Optimise. The framework formalises the discipline Orecast was built on, from assumptions to outcomes.

‍

What a Model Has to Earn

‍

No mining project offers certainty — which is precisely why confidence matters. It comes from knowing what the answer rests on, which assumptions carry it, and how far they can move before the decision changes.

‍

The work may support an early evaluation, a feasibility study, a funding process, an investment decision or an operating improvement program. The context changes; the requirement does not. What matters is what remains afterwards — a model the team can run, interrogate and defend.

‍

Mining decisions deserve more than a number at the end of a spreadsheet. They require a model that shows the economics beneath it — so the people who have to decide can see what they are deciding on.

‍

Underlying Economics. Decision Confidence.