Making a model's recommendation arguable

MIRA predicts impurity concentrations in the molybdenum leach circuit at Sierrita, outside Tucson, and recommends changes to throughput, fresh ferric addition, decant bleed, and digester runs. The open question was whether an operator on shift would act on it.

Operators already had a legacy bleed calculator and years of judgment. A screen that prints a number and offers a green button would ask them to replace both with blind trust. The design problem was to make the prediction arguable: show what the model expects under the recommendation, what it expects under the current setting, and where both sit against the spec limit.

The interface's job was not to be believed. It was to be verified.

I spent a day at the plant with operators and metallurgists. Two findings changed the structure of the product.

The first is that assays lag. Lab results arrive hours after the material they describe, so every recommendation rests on a slightly stale picture, and everyone on the floor already knows it. The second is that the decision is not made by one person at one moment. It crosses a shift handoff, and the person who acts is frequently not the person who reviewed.

Neither is visible from a model output or a stakeholder workshop. Both became structural. Data recency is printed on the home screen rather than implied. Any calculator run can be shared by URL or locked in as the committed strategy, with an author and timestamp attached, because the decision has to survive a shift handoff even when the reviewer changes.

Review is a five-step flow with one recommendation type per step. The alternative was a dashboard asking for four decisions at once, which is how you get all four accepted without any of them being read.

On the fresh-ferric step, six impurity elements are drawn as small multiples on one shared axis under one shared spec line. Solid to the left of today, dashed to the right, which encodes the actual-to-forecast boundary with no legend to look up. The recommended setting and the current setting are both forecast, in two colors, on the same chart. When the current setting breaks spec and the recommendation does not, that reads as a shape before it reads as a number.

The interface offers three choices: accept the recommendation at its setpoint, adjust to a custom value, or reject and keep the current setting. Both setpoints are printed on the buttons, so the consequence of disagreeing is as legible as the consequence of agreeing. A metallurgist who wants to investigate rather than act can expand any chart or switch it to a table.

The home screen carries two figures most ML products keep in a status deck: the share of recommendations operators approved, and the share of days anyone reviewed at all. Publishing a model's rejection rate to the people accountable for acting on it is uncomfortable and useful. A model nobody reviews is not a model in production; it is a model in a database.

The blend calculator's results screen follows the same instinct in reverse. It leads with the constraint violation—the number of days beyond target in red—above every positive number on the page. Then it shows the arithmetic underneath so the result can be checked rather than accepted.

Over one monitored week, internal tracking put MIRA-recommended fresh-ferric addition roughly 20% below what the legacy bleed calculator would have called for. The team's note said savings still needed month-by-month validation, so this site does not convert that comparison into an annual or dollar claim.

The home screen and blend calculator do not share the same chrome. The design system caught up mid-project, and I chose not to rework a surface already in use by people on shift. I would unify them now.