<!-- Source: https://www.maestria-ops.com/cases/linmara/ . Publisher: Maestria OPS Ltd. Updated: 2026-10-07 -->

# Linmara: an AI soft sensor tested only in normal conditions

Linmara is an illustrative case, not a real incident. An AI soft sensor passes every acceptance test, because every test used normal operating data. Months later it reports sweet gas while hydrogen sulphide breaks through into the sales gas, and a technician opens a sample point the plant believes is sweet.

All names of companies, sites, equipment and people in this case are invented. Any resemblance to a real organisation, site or event is coincidental.

## What happened?

Linmara is a sour gas plant. Amine contactors remove H₂S to a sales gas limit of 4 ppmv, measured by an online analyser that needs frequent maintenance. To cut reboiler steam, the operator bought an AI soft sensor that estimates H₂S in the treated gas from flows, temperatures, pressures and amine conditions, and advises the lean amine circulation rate.

The vendor trained it on 18 months of plant history and tested it on data held back from that history. It matched the analyser closely and passed factory and site acceptance. After six months of good advice, operators let it adjust the circulation setpoint directly.

Then two things happened in the same week. The analyser failed and spares were three weeks away. A new well came online with a higher ratio of H₂S to CO₂ than anything in the training data. The soft sensor kept estimating 2 ppmv and reduced circulation further. The pipeline operator's analyser at the custody transfer point detected about 40 ppmv nine hours later, and the plant shut in.

During those nine hours a technician opened a sample point on the sales gas metering skid. The skid is classed as sweet service, so no breathing apparatus was required. His personal gas monitor alarmed and he withdrew. No one was hurt.

## Why did the tests not find it?

Every acceptance test used normal operation. None tested a failed analyser, a sensor drifting, a feed outside the training range or a start-up. DNV's recommended practice on AI assurance is direct about this: "For a safety-critical system, it is inadequate to perform only positive testing, in which only normal system conditions are tested" ([DNV-RP-0671](https://www.dnv.com/digital-trust/recommended-practices/assurance-of-ai-enabled-systems-dnv-rp-0671/)).

<!-- diagram:linmara -->
[Diagram: Linmara: with the analyser out of service, the soft sensor was the only measure of H₂S in the treated gas.]
<!-- /diagram:linmara -->

## What would M-OPS OMI have asked?

M-OPS OMI starts from the requirements Linmara already had. The acceptance test procedure applied but needed modifying to include abnormal conditions and failed inputs. Management of change applied as it stood to the move from advice to automatic control; it was not used. The change procedure for new wells needed modifying to ask what each new feed does to the models that rely on plant data. The operating procedure needed modifying to define a fallback, such as a minimum circulation rate, whenever the physical analyser is out of service. A new element was needed for the model's operating envelope, the feed compositions and instrument states it was validated for, so that a new well's gas or a failed analyser put it visibly outside.

If one of your soft sensors or models feeds a control loop, [contact me](https://www.maestria-ops.com/contact/).

