Tailings Storage Facility Monitoring Software Problems: The 5 That Hide Real Risk, and How to Avoid Them

Why does a monitoring project become a charting project?

The most common scope failure in tailings is that the build is specified as a dashboard. Someone writes a requirement list that says ingest instrument data, plot trends, alarm on exceedance, and every developer who reads it produces exactly that, because it is a well understood piece of work. Six months later the site has attractive plots, the geotechnical engineer has muted the alarm email, and a trigger breach still gets discovered in a monthly report.

The reason is that the deliverable in tailings is not the chart, it is the response. A trigger action response plan already specifies who is notified, within what period, what inspection follows and who authorises a return to normal. That is a workflow with named roles, timers and mandatory sign-off, and it is the half that reviewers, insurers and lenders actually examine. A monitoring front end with no response engine behind it changes nothing, because the site already had plots. They were in the consultant's portal.

Scope the first release around one facility, its instruments and its response loop: multi-source ingestion with instrument identity, versioned trigger levels, evaluation that handles rate of change and not only thresholds, missing data alarms, and an append-only acknowledgement and escalation record. That is $90,000 to $200,000 over 14 to 20 weeks in our delivery experience. Water balance, deposition, survey-derived freeboard, document registers and portfolio reporting are the second phase, and they are much easier to justify once the response loop has caught something.

What goes wrong when historic readings are loaded into the new system?

Instrument identity is where tailings migrations quietly corrupt themselves. The same vibrating wire piezometer is P14 to the site, VWP-2021-014 to the installing contractor, and node 3 channel 2 to the logger. Load readings against a sensor name plus a value and the day a logger was replaced becomes a step change in your ten year trend that looks like real ground behaviour.

The second problem is that raw values are not comparable across eras. Vibrating wire readings need barometric compensation, and whether it was already applied depends on which contractor processed them. Survey coordinates arrive on different datums after a resurvey, and manual standpipe dips are recorded to a different reference elevation than the automated instruments on the same section. Load all of that as numbers on a timeline and you have a plausible looking history no geotechnical engineer can rely on, which is worse than no history at all.

What works: model the physical instrument, its installation with depth, coordinates and reference elevation, the logger channel it currently reports through, and the reading, as four separate things. Carry an installation history so a reinstalled instrument keeps its identity and its discontinuity is explicit. Store the raw value and the processed value with the correction applied, so a compensation error can be fixed without reloading. Then have your engineer of record review the migrated series for the two or three most important instruments before you accept the load. That review takes a day and it is the only real test of whether the migration worked.

Why do the consultant and contractor feeds break after launch?

A tailings facility is monitored by parties who do not work for you in the same way. The logger network pushes automatically. The survey contractor emails a coordinate file when the survey is done. The InSAR provider delivers monthly. The laboratory sends results on its own schedule. Each is a data contract with an organisation, and a data contract with a human step in it fails the way humans fail: someone leaves, a scope of work is renewed with different deliverables, a file format changes after a software upgrade.

The break is rarely announced. The feed simply stops, and because the plots still show data from other sources, nothing looks wrong.

The fix is to treat expected arrival as a monitored condition at every level. Set an expected reporting interval per instrument and raise a fault when it is missed. Set an expected delivery cadence per external source and raise a fault when a survey file or an InSAR product does not arrive. Validate the file on receipt against its expected structure and reject it loudly rather than importing a partially parsed version. And write the format, the cadence and the named contact into the consultant's scope of work at the next renewal, because the integration you cannot fix in code is the one where the other organisation never agreed to send you anything in particular.

What happens when the trigger action response plan is not modelled?

Most systems evaluate a reading against a number. Real trigger action response plans are richer than that, and the gap between the two produces both misses and noise. A genuine trigger can be a rate of change over a rolling window, a response relative to rainfall, or a reading crossing amber while another instrument in the same section is also elevated. Build only threshold comparison and you will either miss the pattern that matters or raise enough nuisance alarms that the geotechnical engineer mutes the system, which is the worst outcome available.

The second half of the gap is versioning. Trigger levels change after a dam raise, after a design review, after the engineer of record reassesses a section. If the levels live in an issued PDF while the system holds a copy typed in at go-live, they drift, and a reviewer asking why a March reading was evaluated against a level set in a document issued in June will get an answer nobody wants to give.

What a build has to cover: trigger levels as versioned, dated data attached to each instrument, carrying the issuing document and the engineer who authorised the change, so a reading is always evaluated against the levels in force on its own date. Evaluation that supports rate, correlation and multi-instrument conditions. And the response as an append-only record: alarm raised, acknowledged by the responsible tailings facility engineer within the specified period, inspection completed with photographs, engineer of record consulted where the plan requires it, condition closed with a reason. Automatic escalation when an acknowledgement timer expires. That record is what turns a review board question into a single export.

Should you build custom or configure what you already own?

If you operate one facility on a single logger network with a straightforward instrument set, do not build. Vista Data Vision over your loggers, or the platform that shipped with your Worldsensing hardware, will plot readings and raise threshold alarms competently, and Seequent Central is a sensible way to manage geotechnical models with your consultants. That combination is genuinely adequate at that scale, and the money belongs in more instrumentation and a more frequent inspection regime rather than in software.

Before quoting anyone, do the configuration work you already own the licence for. Get every instrument you can onto the logger platform you have. Configure the alarms properly, including one for a missing reading, which most sites never set up because it is not the default. Ask your engineer of record to reissue trigger levels in a structured form rather than as a table inside a report. Those three cost consultant time rather than capital, they remove a meaningful share of the pain, and what is left is the specification for any build.

Build when two or more of these hold. You hold more than three facilities and cannot answer their status without asking people. A meaningful share of your monitoring comes from parties outside your logger network. Your trigger levels live in documents rather than in the system that evaluates them. Or your accountable executive is personally accountable for a conformance position that is currently assembled by hand once a year.

How do hidden costs get into the quote?

Four items account for most of the overrun in tailings builds, and none of them are engineering.

• Data contract negotiation. Each consultant and contractor feeding a facility is a relationship to be renegotiated before it is an integration to be built. Budget calendar weeks per party, not developer days, and start before design work.
• Taxonomy normalisation across facilities. Every consultant has classified, named and structured things differently. Agreeing one group model is a workshop exercise with your engineering partners, and groups that skip it discover they cannot roll anything up.
• Survey and geospatial processing. Converting between datums and deriving freeboard from point clouds is specialist work priced accordingly. Quoted as an import, delivered as a discipline.
• Offline field capture. If inspectors work where there is no coverage, offline capture with reliable synchronisation is a real piece of mobile engineering, not a setting.

The other quiet cost is your own people. The instrument register, the installation history and the current trigger levels have to be verified by someone who understands the dam.

What separates a build that works from one that fails here?

Ask a prospective developer to whiteboard the instrument model before anything else. The right answer separates the physical instrument, its installation, the logger channel it currently reports through and the reading. A developer who models a reading as a sensor name and a value will corrupt your history the first time a node is replaced, and you will not notice for a year.

Ask what happens when a reading does not arrive. If alarms only fire on exceedance, the system is silent in exactly the scenario that should worry you most. In our delivery experience, missing data alarms surface more genuine risk in the first month of operation than any analytics screen does.

Ask what they have built with a formal audit trail and a time-bound acknowledgement, in any regulated setting. This is a workflow product with a monitoring front end. Developers who treat it as a charting exercise miss the half your reviewers care about.

Then start with your highest consequence facility, prove the response loop there, and roll the same model outward. Settle ownership in writing before kickoff: the repository, the cloud accounts, the raw readings and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. For a record that may need to be produced decades from now, data portability is part of the risk management case.