Mining's Kodak Moment.

Eastman Kodak employed the engineer who built the first digital camera. Steve Sasson demonstrated the prototype internally in 1975, and management's guidance was to keep quiet about it.^[1] At the time the company held roughly 90% of the US film market and owned the phrase "Kodak moment".^[2] The company filed for Chapter 11 on 19 January 2012.^[3]

The case is usually taught as a failure of foresight. It was closer to a failure of capital allocation under a defended margin structure. Kodak's leadership understood digital imaging perfectly well; they declined to fund the cannibalisation of a high-margin consumables business with a low-margin hardware business, and they made that judgement repeatedly across three decades. Each individual decision was defensible against the incentives in front of it. The aggregate destroyed the firm.

Engineering, procurement and construction management in mining now faces a structurally similar decision, and the technology in question is already producing project deliverables in commercial settings.

The billable hour is our film business

The EPCM model monetises effort. Study-phase engineering is priced, staffed and forecast in hours: hours to build a mechanical equipment list, hours to size and select equipment, hours to write specifications, hours to populate datasheets, hours to roll all of it into a CAPEX estimate, and then hours again when the flowsheet changes and the whole chain has to be re-cut.

Now consider what happens when a system compresses an eight-week MEL and datasheet cycle into an afternoon. If your revenue is hours, that is not an opportunity on the P&L — it is a 99% cut to a line item you are measured on. The incentive to call it "cute" and move on is exactly the incentive Kodak had.

The difference is that this time the technology is not a 0.01-megapixel prototype. It already works.

The exposure is broader than the equipment list alone. Across scoping, PFS and FS work the automatable deliverable set covers equipment sizing and selection calculations, materials of construction decisions, mechanical and electrical datasheets, technical specifications, requisition packages, MTOs, and the CAPEX estimate assembled from all of it. Rework compounds the hour count, because a single flowsheet revision propagates through the entire chain and forces a re-cut of the equipment list, the affected datasheets, the pricing basis and the estimate.

Automation that collapses a multi-week MEL-plus-datasheet cycle into hours therefore reduces recoverable revenue on a fixed-scope study while leaving the fixed cost of a senior engineering bench largely intact. Under reimbursable hourly terms, efficiency transfers value directly to the owner. That is a rational reason for an EPCM firm to move slowly, and it is worth naming plainly rather than attributing inaction to technical scepticism. Kodak's reluctance had the same origin.

Two conditions determine whether that defensive posture holds. The first is whether the technology is mature enough to produce auditable, standard-compliant deliverables. The second is whether owners begin pricing the capability into tenders. Both conditions are now moving.

Already in commercial deployment

Vendors are building directly against the study-phase mechanical scope. OreNova, founded in Perth by mineral processing engineers, sells AI automation to EPCM firms and engineering consultants covering equipment calculations, materials of construction selection and document generation, configured to each firm's own documentation standards, delivered in familiar formats, and explicitly positioned to reduce the engineering hours required for complex mechanical design while producing auditable outputs.^[4] Their stated target deliverables include material and equipment selection, datasheet development and mechanical equipment lists, with emphasis on projects carrying frequent flowsheet updates, multiple revisions and trade-off studies.^[5]

The document and data layer is being addressed in parallel. The iEng^TM platform digitises standards, specifications and datasheets across process, equipment, instrumentation, electrical, BoM and MTO scopes, extracting both content and the relationships between data items, then transferring structured output into design tools, asset management systems and databases, recreating deliverables for a new project, standardising formats, and identifying conflicts between documents.^[6]

I have also worked directly with companies operating their own internally built systems across this same scope, covering MELs, specifications, datasheets and the CAPEX build-up. These were production tools applied to live project work, developed by engineers inside engineering organisations rather than by software vendors selling in from outside. That distinction matters for the competitive read: the capability can be built privately, at moderate cost, without market visibility, which means the adoption picture is almost certainly further advanced than public announcements suggest.

The technical reason this scope yields to automation is that most study-phase mechanical deliverables are deterministic transformations of a small number of upstream inputs. Duty, throughput, slurry properties, corrosion and abrasion service, layout constraints and vendor envelopes determine equipment selection and the majority of datasheet fields. The engineering judgement is concentrated in a handful of decisions; the remaining work is transcription, unit management, cross-referencing and revision control. That is a favourable profile for automation and an unfavourable one for continued manual production.

The capital case is stronger than the efficiency case

Framing this as a cost-reduction opportunity understates it considerably. The binding constraint in mining capital delivery is estimate reliability, and estimate reliability is set at the front end.

McKinsey's review of 80 global mining projects found cost and schedule problems in 83% of recent major mining and metals projects, with capital expenditure overruns exceeding 40% and schedule delays of 20% to 30%. On projects of $1 billion or more, average overruns run at least 79% above the initial budget and delays at 52% beyond the original timeframe.^[7] Research modelling overrun risk at the FEED stage reports construction cost overruns in mining rooted in front-end engineering design of between 25% and 37%.^[8]

The capital programme those numbers will be applied to is substantial. New metals and minerals supply could require on the order of $1 trillion in growth capital expenditure over the next decade, with copper and nickel together requiring $250 billion to $350 billion by 2035 to grow supply and offset depletion.^[7] The sector arrives at that programme with productivity growth of approximately 1% over the past 25 years, against 15% to 25% in manufacturing and business services over the same period.^[9]

The mechanism connecting automation to estimate quality is iteration economics. Under manual production, each flowsheet or basis-of-design change carries a rework cost measured in engineer-weeks, so teams ration revisions, freeze scope earlier than the technical work justifies, and carry allowances in place of resolved design. Trade-off studies get deferred to the next phase or dropped. When the marginal cost of a full re-cut of the equipment list, datasheets and estimate falls by an order of magnitude, the design can be converged rather than frozen, and contingency can reflect genuine residual uncertainty rather than unexamined scope. Overrun distributions narrow because fewer unknowns survive into execution, not because the drafting was cheaper.

There is a second-order effect worth as much. Systems of this kind produce structured, queryable engineering data as a by-product, rather than a folder of terminal PDFs. Equipment registers, materials decisions and specification content become machine-readable and traceable across revisions, which supports estimate benchmarking across projects, feeds asset management and maintenance strategy at handover, and creates the dataset any subsequent AI work depends on. Firms automating deliverables are accumulating a proprietary data asset; firms that are not are accumulating documents.

A Bluebeam survey of 1,000 architecture, engineering and construction professionals found 27% using AI in operations, while 52% still use paper during design, 49% during planning, and 43% still rely on physical signatures and approvals. Among those who had adopted, 94% planned to increase usage the following year.^[10]

That distribution describes a compounding minority and a waiting majority. The stated barriers are substantive: 42% cite data-sharing security, 33% cost and complexity, and 69% report that regulatory uncertainty has affected implementation plans.^[10] Each is manageable with deliberate architecture and governance, and none of them changes the direction of travel. Kodak's objections were substantive too.

Tier-one contractors are already moving. Bechtel has been applying AI to the documentation volume associated with equipment across its jobsites, and Worley has partnered with Dell on AI infrastructure for its energy, chemicals and resources business.^[10],[11]

Build verification capability before dependency

The following sequence is deliberately ordered to build verification capability before dependency, and to move commercial terms in step with technical capability.

1. 01

   Instrument the current baseline. Before evaluating any tool, measure the existing state on two or three completed studies: hours by deliverable type, rework hours attributable to flowsheet or basis-of-design changes, revision counts per datasheet, and the interval from flowsheet issue to a re-cut estimate. Without this baseline there is no defensible way to assess a vendor claim or an internal build, and no way to price the change.

2. 02

   Select one bounded, high-repetition scope for a pilot. Mechanical equipment lists and mechanical datasheets for a single process area are a suitable first target, because inputs are well constrained, output quality is objectively checkable against existing issued deliverables, and volume is high enough to show a signal. Avoid starting with estimating or specifications, where the judgement content is higher and failure is harder to attribute.

3. 03

   Run the pilot as a back-test, not a live trial. Reproduce deliverables from a completed project where the issued, checked versions already exist. Compare field by field. This produces a quantified error profile with no project risk, and it converts an internal debate about trust into a measurement. Retain the discrepancy log; it becomes the specification for guardrails.

4. 04

   Fix the data foundation before scaling. The constraint on automation quality is usually the reference data, not the model. Consolidate equipment class libraries, materials of construction rules, standard specification clauses, tag conventions, unit and precision standards, and vendor envelope data into a single governed source with ownership and a change process. Firms that skip this step automate their inconsistencies.

5. 05

   Define the verification and accountability model explicitly. Establish which fields are machine-generated, which are engineer-set, and which require independent check; require every output to carry provenance back to its input basis and the rule or calculation applied; and confirm that the professional sign-off chain, insurance position and standard-of-care obligations are unchanged. Auditability is a procurement requirement, not a feature.

6. 06

   Address the security architecture on its own terms. Given that data-sharing concerns are the leading barrier for 42% of the sector, decide deliberately between tenanted vendor platforms, private deployment and self-hosted models, and document handling of client-confidential design data, vendor pricing and third-party standards under their licence terms.^[10]

7. 07

   Redesign the commercial model in parallel with the technical rollout. Automation is incompatible with pure reimbursable-hours pricing over the medium term. Move the automated scope toward fixed-price or deliverable-based fees, price outcomes such as revision turnaround and estimate accuracy class, and consider gain-share tied to estimate performance. Redeploy the freed senior capacity into trade-off studies, constructability, operability and risk work, which is where the overrun distribution is actually set.

8. 08

   Restructure the team composition, not just the toolset. Study teams built around large drafting and document control populations shift toward fewer, more senior engineers supported by data and automation specialists. Plan the recruitment, training and career-path implications ahead of the capability, because the transition is slower than the software.

9. 09

   For owners: put the questions into the tender. Ask what proportion of study-phase deliverables is machine-generated, how outputs are verified and by whom, what error rates were measured in back-testing, whether structured engineering data is delivered to the owner as a contractual asset in a defined schema rather than as terminal PDFs, what the committed turnaround is for a full re-cut of the MEL, datasheets and estimate after a flowsheet change, and how the fee basis reflects the automation. Once these appear consistently in tenders, the internal adoption debate on the contractor side resolves quickly.

10. 10

    Set a decision date. Kodak's failure was not a single refusal; it was the absence of a forcing function over thirty years of individually reasonable deferrals. Fix a board-level date by which the pilot results are reviewed and a scale-or-stop decision is made, with the pricing model change explicitly on the same agenda.

The prototype is on the table, it is producing checkable deliverables, and the decision in front of the sector is the one Kodak's board took in 1975.