Insights
Notes from the melt floor.
What we are learning about recipe decisions, furnace behaviour and the practical work of putting AI in front of an operator on shift. Short, specific, and written for people who run plants.
Why Excel formulas stop short on the melt floor
Current systems calculate. They rarely understand live plant context or the business trade-offs behind a heat.
Excel, fixed formulas and small rule-based tools are useful for standard calculations. Most melt shops run on them, and most of the people using them are good at it. The problem is not the arithmetic. It is that a formula does not know what changed since it was written.
Scrap mix changes. Lot recovery drifts. The lab posts a sample. The furnace runs hot for a shift. Alloy prices move. Each of these should change the recipe decision, and each of them lives in a system the spreadsheet cannot see. So the operator fills the gap with judgement — and judgement varies by shift, by person, and by how the night is going.
Where the plant pays
Over-alloying against uncertainty. Chemistry corrections after the sample comes back. Delayed heat closure while someone reconciles numbers. And a decision quality that is different at 03:00 than at 11:00. The cost shows up as material, as rework and as time, but the underlying issue is predictability and governance of every heat decision.
What replaces it
Not a better spreadsheet. A decision layer that reads the live heat, recommends the action with a confidence score and the reasons behind it, and learns from what actually happened. The formula stays as a fallback. The operator stays in charge. The difference is that the decision is now assembled from live data, traceable, and improving.
420 to 775 kWh per tonne: what the spread says about furnace decisions
Physics does not vary that much between plants. Decisions do.
Furnace steelmaking typically consumes around 400–500 kWh of electricity per tonne of steel. Audits, however, have reported specific energy consumption ranging roughly from 420 to 775 kWh/t. That is not one number with noise around it. It is a spread wide enough to separate a profitable furnace from one that is quietly losing money on every heat.
Why the spread exists
Temperature variation. Unstable furnace conditions. Delayed response to abnormal states. Reactive rather than predictive maintenance. None of these are exotic. All of them are day-to-day furnace decisions, made by people watching a small number of signals under time pressure.
What a 5% improvement is worth
Even a 5% reduction in specific furnace energy represents a significant recurring saving at plant scale — and unlike a one-off project, it compounds every heat. A published stainless-steel furnace case using AI-based tap-temperature prediction reported a 13% improvement in MAE and 17% in RMSE, alongside measurable electricity and operating-cost savings. Better prediction leads to fewer thermal excursions, and fewer excursions lead to less energy.
The lesson is not that AI saves energy. It is that energy per tonne is a decision metric, and decisions can be supported.
Seeing the bed: what an industrial camera can tell you before the collapse
People cannot stand at the furnace mouth all shift. A camera can — and a model can read what it sees.
A high-resolution industrial camera installed near the furnace captures the bed continuously — temperature variation, material movement, electrode condition — in an environment of heat and dust where nobody can watch for long. The images stream to Furnace Copilot through direct integration or secure API upload.
What the model looks for
Bed collapse indications. Electrode width. Crust formation. Bed condition — depth and edge data that indicate a stable, compact bed versus one under stress. Activity homogeneity — whether heat is distributed evenly or concentrated centrally. Each detection comes with a classification and a plain-language reason, because a detection an operator cannot understand is a detection they will ignore.
Why pre-empting beats detecting
The point is not to raise an alarm when the bed has collapsed. It is to see the brightness pattern, the edge count and the acoustic signature that precede it, and to give the shift time to act. That is the difference between a monitoring system and a copilot — and it is the difference between an unplanned stop and a planned intervention.
AI recommends, the operator decides: designing decision support people actually accept
The best model in the world is worthless if the shift overrides it without reading it.
Every industrial AI project has a technical risk and an adoption risk. The adoption risk is usually larger. Operators have decades of hard-won judgement and a reasonable suspicion of systems that tell them what to do without saying why.
Three design rules
Show the why. Every recommendation carries its reasons and its confidence, and says how many similar heats it is based on. Keep the decision human. The operator approves, adjusts or overrides — with a reason code, so the override itself becomes learning. Fall back gracefully. When confidence is low, the system defers to the plant's existing rules rather than guessing.
Why it matters commercially
A spreadsheet can copy a formula. It cannot copy a closed-loop system trained on plant behaviour, connected to live constraints, and accepted by operators shift after shift. Acceptance is the moat. Design for it from day one.
Four moats: why a plant-trained copilot is hard to copy
The advantage compounds across data, models, process knowledge and plant integration — not just algorithms.
Algorithms are not a durable advantage; they are published. What is durable is everything around them once a copilot has been running on a plant for a year.
Domain. Heat-specific logic for chemistry, temperature, grade routes, additives and plant constraints, built with metallurgists. Data. Every heat outcome — actual additions, lab results, delays, corrections, operator decisions — becomes training data the plant owns. Integration. ERP, MES, LIMS, SCADA, inventory and cost data stitched into one operating view. Governance. Approvals, reason codes, audit trail, model confidence, fallback rules and change control.
Each moat on its own is copyable. All four, compounding on a live plant, are not.
Don't frame it as "replace Excel": how to run a 12-week recipe pilot
One high-value pilot, evidence-gated at every step, then a blueprint to scale.
The wrong pitch to a melt shop is "we will replace your spreadsheets." The right one is: keep your existing know-how, connect it to live plant systems, and convert recipe management into a controlled AI layer that improves every heat — explainable to operators, auditable for leadership.
The five steps
Weeks 1–2, data and recipe audit. Grade list, input quality, formula logic, gaps. Weeks 3–5, model and rules setup. Chemistry prediction, constraints, fallback logic. Weeks 6–7, operator workflow. Recommendation screen, approvals, reason codes. Weeks 8–13, live pilot. Selected grades or route, compared against baseline. Final two weeks, scale blueprint. ERP/MES rollout plan, SOPs, ROI sign-off.
Evidence at every gate
Each step ends with something measurable, and the pilot only proceeds if the evidence supports it. That protects the plant's time, and it means the ROI sign-off at the end is built from production records rather than a slide.
Want the detailed capability note?
We share the full Recipe Copilot and Furnace Copilot capability document with plants evaluating a pilot.