Steel and mining
An integrated works generates millions of records per shift, and the questions worth asking cross the areas that hold them. Reduction, steelmaking, casting and rolling sit in separate systems, so the valuable question is the one nobody asks.
If you recognise these questions, this page is for you
Why has metallic yield from melt to coil fallen in the second half of the year?
Did the rise in coil surface defects coincide with the change in the sponge-iron-to-scrap charge ratio that same week?
How many kilowatt-hours per tonne of crude steel did we use last month, and how does that compare with the year's average?
How much tonnage did we lose to power restriction last summer, and how was that loss distributed across the areas?
Which equipment failed most often in the last six months, and did those failures coincide with parts from one particular supplier?
What was each area's total downtime by cause over the last three months, and which area was the bottleneck of the chain?
What has consumption of graphite electrode, refractory, lime and oxygen per tonne done, and what did last month's stoppages do to cost per tonne?
Every area is an information island
An integrated works produces millions of records a shift: reduction gas temperature, melt analysis, casting speed, furnace power draw, coil thickness. And when a manager asks why metallic yield fell this month, the answer does not come out of that data. It comes out of a human chain — a request logged, two or three days of gathering from several systems, a report on day five or seven.
The reason is structural rather than cultural. Reduction, steelmaking, casting, rolling and the support functions each hold their own system, and every question actually worth asking crosses at least two of them.
"Did the rise in coil surface defects coincide with the change in charge ratio that same week?"
No single system contains that answer. Which is precisely why the question is not asked.
What that costs
- Static reports. A shift report and a monthly area report answer the questions somebody defined in advance. A new question has nowhere to go.
- Analysis after the fact. Root-causing a yield drop or an energy-intensity rise happens weeks later, by which point the tonnage is already gone.
- Knowledge that is personal, not organisational. The ability to diagnose these problems sits in the heads of a few specialists and leaves with them.
In energy the arithmetic is unusually direct. Electricity, gas and electrode consumption dominate cost per tonne, and a few per cent of intensity is a large number. In a restriction period the decision about which area to shed load from has to be made that day. Both cases need the same thing: to see the deviation in time, not in next month’s report.
How the work changes
The hard part is not running the query. It is framing the question.
Why has steelmaking efficiency fallen? cannot be answered as asked — efficiency meaning heats per day or metallic yield, over which period, against the prior period or against the approved plan. So the system asks, agrees a scope, and confirms it before anything runs. Then it proposes the axes a process engineer would examine: charge mix, stoppages and operating conditions, refractory and equipment state, shift-to-shift variation.
For questions whose answer is not a number, a research run dispatches an orchestrator and a fleet of workers — three to twenty per run — each testing a different angle against the relevant source, returning one documented report with the numbers attached. A user with the right permission sees the exact query that ran. Where the data will not support an answer, the system says so: a data-plane circuit breaker turns eight consecutive failures into an honest error rather than a confabulated one, and charted numbers are computed by executing code against the result set rather than written into a sentence by a model.
What it connects to
Nothing is migrated and nothing is copied out. MES, ERP, LIMS, CMMS, the Historian’s reporting store and the weighbridge records stay where they are and are read. One adapter layer covers thirty database engines behind a single interface — including the time-series and analytical engines process data tends to live in — and a single user can hold several connections at once. That last property is the whole point: it is what makes a cross-system question answerable at all.
The step that decides answer quality is schema documentation, not installation. A drafting assistant proposes a description for every table and column; the works’ own process and IT specialists edit and approve them. Once the system knows how metallic yield and valid heat are calculated in your plant, the answers agree with the planning department’s figures.
Upstream, in mining
The same argument holds over exploration data, and it is where our other product lives: ZetaMine analyses regions from satellite imagery to narrow where to look before anyone puts a drill in the ground. What exists today is the corpus and the protocol underneath it — 10,348 Landsat-7 ETM+ scenes composited into 9,732 clean images, deduplicated by content hash, with a two-of-two overlap and deterministic arbitration annotation protocol. Full annotation is pending and there is no trained model yet. We would rather write that down than imply otherwise.
Where this is the wrong fit
- If you want process control or optimisation in the loop, this is not it. The system reads reporting databases. It never touches the control network and cannot command equipment, by design.
- If the data has not left the control layer, there is nothing to query. Getting process data into a Historian reporting store or a warehouse is the prerequisite project.
- If each area’s definitions differ — what counts as a stoppage, a valid heat, countable tonnage — that argument comes before the tool, and it surfaces in week one.
- If the questions are fixed, build a report. A number forty people need every morning is a dashboard.
- If you need writes — work orders, corrections, scheduling — this is the wrong layer. Read-only is a design decision.
- It is deployed in production for two organisations today. Early, deeply engineered, and better said before the first meeting than after it.