The Impossible Electricity Figure Your Steel BOM Will Hide From You

One row in the coking process said the plant burned 6,649,140 万kWh of mixed-grid electricity. The whole plant — twelve processes, 2,093,927 t/yr of crude steel and billet — drew 95,503 万kWh. A single sub-process claimed seventy times the entire site — not a hot process, an impossibility. Nobody typed that number to deceive anyone. Somewhere during data entry, a figure landed in the wrong unit field at the wrong magnitude, and there it sat in the BOM, looking like data.

This is the mistake your spreadsheet won’t catch and your eye won’t catch on a fast read. Your auditor will — at the worst possible moment, after you’ve built the product system on top of it.

---

The error that survives every review

A magnitude error like this is invisible to the checks people actually run. It passes a format check: a number, right column, correct unit string beside it. The one test it cannot survive is the mass and energy balance — and that test is tedious enough that on a 12-process BOM with 85 purchased materials, almost nobody runs it by hand. The slip rides forward not because the number looks plausible. A sub-process at seventy times the whole site is not plausible to anyone who stops to add it up. It rides forward because nobody stops.

So the number travels. It gets matched to a grid-electricity emission factor, gets multiplied, and the coking stage of one crude-steel producer now reports an electricity burden that swamps the rest of the plant combined. Every result downstream — the per-tonne footprint, the contribution analysis, the precursor-input figure in your own carbon model — inherits the slip.

The only honest way to recover the true value is to back-calculate from the plant electricity balance: total draw, minus what the other processes account for. Do that here and coking lands near 9,838 万kWh. The entered 6,649,140 is roughly 676 times too high — two orders of magnitude past anything the balance can hold. The exact data-entry cause matters less than the fact that the balance flushes it out, where no eyeball and no format check ever would.

---

Where Cortex Cowork reads it

Cortex Cowork opened this producer’s Excel BOM in place — no re-keying, no import schema, no second database to populate. Twelve processes: six main smelting steps, six auxiliary. It matched purchased materials across fourteen LCA databases — HiQLCD, Ecoinvent, EF, CarbonMinds, and others — and reported the result plainly: 71 of 85 materials matched, 83.5%.

Then it ran the balance the reviewer rarely has time for. The coking figure didn’t reconcile with the plant total, so Cortex flagged it: this value exceeds the whole-plant electricity draw; here is the plant balance; here is the back-calculated figure of 9,838 万kWh; this reads as a magnitude error against the rest of the site. It did not overwrite the cell. It returned the anomaly, with its reasoning, to the project decision log, and left the correction to you.

Cortex flags the number and returns the decision. It does not quietly write 9,838 into the cell and move on.

That distinction is the whole point. A tool that silently “fixes” the value has made an unrecorded modeling choice on your behalf — the kind a verifier asks you to defend, and you will have no answer, because you never saw it happen. Cortex pauses where automation would break an audit. The practitioner decides; the decision is recorded in the reasoning chain.

---

The gaps are louder than the slip

The magnitude error is one of 45 data-quality issues Cortex surfaced in this BOM. The two that should worry you more than any single wrong number are the ones where the number is missing entirely.

Air emissions — SOx, NOx, particulates — were blank across all twelve processes. For a crude-steel system those aren’t optional fields; they separate a model that describes a steelworks from one that describes an idealized furnace. External transport distances were empty too, every process row. You can’t characterize upstream transport with no distance, and you can’t quietly assume one without inventing data.

A confident number is dangerous because it looks finished. A blank field at least announces itself — but a 100-row BOM holds enough blanks that the important ones hide among the harmless ones, and the human eye triages by what’s filled in, not by what’s absent. Cortex inverts that. It scores Completeness as one of its five DQI dimensions — Temporal, Geographic, Technology, Completeness, Reliability, in the Pedigree-Matrix lineage LCA practitioners already know — and weighs the empty SOx column as heavily as a wrong cell, because to the final result they cost the same.

---

Why a reasoning chain, not a corrected file

Picture a tool that takes the BOM, cleans it, and hands back a tidy version: coking figure fixed, emissions interpolated, transport distances estimated from plant location. Faster, certainly. Also useless to a verifier, because every one of those repairs is a judgment call with no author.

Cortex’s output is the opposite — the original cells, untouched, plus a record of what it questioned and why. The coking flag carries its arithmetic: plant total, other-process draw, residual, the magnitude gap it couldn’t reconcile. The blank-emissions flag names the affected processes and the DQI dimension it scored down. When your auditor asks how you handled the coking anomaly, you open the decision log and read back the reasoning — including the part where you, not the software, chose the corrected value.

The same discipline runs upstream of the model. Cortex prepares and screens the data, surfaces what fails the balance, and hands the modeling decisions back to you with their provenance attached. None of this is an audit certification. It is the data-quality discipline ISO 14044 requires and a CBAM verifier will expect — a reasoning chain you can walk, not a black box you have to trust. (A note on scope: this slip propagates through your own LCA and product carbon footprint. A CBAM declaration reports precursor emissions from installation-specific actual data, not a background-factor match — but the same data discipline is what keeps either defensible.)

When the model itself runs, Cortex connects to and operates the engine you already work in — openLCA, brightway, 积木LCA. It does not replace the engine; it drives it.

---

What to check on your own BOM tonight

Find your most energy-intensive sub-process and add up the electricity across every process. If one line rivals or beats the total, that’s a unit error, not a hot process. Then go after the blanks that matter — air emissions on combustion-heavy steps, transport distances on anything purchased — and ask whether a missing field has been quietly filled somewhere downstream.

Or open the BOM in Cortex Cowork and let it run the balance once. 2,093,927 tonnes of crude steel rode on a number nobody had added up. The arithmetic that catches it is not hard. It just never runs — until something runs it every time, and writes down what it found.

Ask Cortex about a BOM row → cortex.hiq.earth/chat