Tailings Storage Facility Monitoring Software: Why a Trigger Breach Surfaces in a Monthly Report

Why a trigger breach is discovered three weeks after it happened

The monthly monitoring report lands on the 14th. On page 31 there is a plot of vibrating wire piezometer P14 in the downstream shell, and the phreatic surface has been climbing for eleven days. The reading crossed the amber trigger on the 3rd. Nobody acted on the 3rd because the data from that logger goes to the geotechnical consultant's portal, the consultant compiles the report monthly under their scope, and the trigger action response plan that defines amber for P14 is a table inside a PDF issued by a different engineering firm two years ago. The site was not ignoring the dam. The site had no mechanism to know.

This is the standard failure mode across tailings portfolios, and it is not a sensor problem. Instrumentation has become cheap and reliable. The problem is that a tailings storage facility is monitored by four or five separate parties on four or five separate schedules: an automated logger network reporting hourly, a survey contractor picking up prisms weekly, a drone survey monthly, manual standpipe dips read by a site technician, and laboratory results on materials from another firm entirely. Each party has a portal or a spreadsheet. None of them holds the trigger levels, and none of them owns the response.

The governance expectation moved faster than the tooling did. The Global Industry Standard on Tailings Management, published in August 2020 by ICMM together with UNEP and PRI, put named accountability on an accountable executive at the corporate level and a responsible tailings facility engineer at each facility, alongside the engineer of record. ICMM members committed to conformance on a published timetable, with facilities classified as extreme or very high consequence first. Whether or not you are an ICMM member, your lenders, insurers and largest customers are increasingly asking for the same evidence. Confirm your own obligations with your engineer of record and legal counsel rather than with a software vendor, including us.

Problem 1: readings arrive from four owners on four clocks

Loadsensing nodes push to one platform, the survey contractor emails a coordinate file, the technician records dips on a field sheet, and InSAR displacement products arrive as a monthly deliverable. Worldsensing hardware is genuinely good at getting readings off instruments in difficult places, and Vista Data Vision is a capable way to visualise and alarm on logger data. What neither is built to be is the single record of a facility across parties, because a large part of your monitoring is not on your loggers at all.

What a custom build must include is an ingestion layer per source with the awkward parts handled explicitly: unit conversion, barometric compensation for vibrating wire instruments, datum and coordinate system conversion for survey, and above all instrument identity. The same piezometer is P14 to the site, VWP-2021-014 to the installing contractor and node 3, channel 2 to the logger. If those are not reconciled to one instrument record with an installation history, every trend you plot is quietly wrong the day a logger is replaced.

Gaps matter as much as values. A dam safety system must alarm on missing data, not only on exceedances, because the most dangerous state is a sensor that stopped reporting during the wet season and nobody noticed. Set an expected reporting interval per instrument and raise a fault when it is missed. That single feature catches more real risk than any analytics screen.

Problem 2: trigger levels live in a PDF and change without anyone noticing

A trigger action response plan is a living document. Levels get revised after a dam raise, after a design review, after the engineer of record reassesses a section. The plan exists as an issued document, the levels exist as a table inside it, and the monitoring system usually has no idea any of it happened.

The build must hold trigger levels as versioned, dated data attached to each instrument, with the issuing document and the engineer who authorised the change, so that a reading from March is evaluated against March's levels and an auditor can see exactly why. Evaluation has to be richer than a threshold too. Real triggers include rate of change over a rolling window, response relative to rainfall, and a reading crossing a level while another instrument in the same section is also elevated. If your platform can only compare a number to a constant, you will either miss the pattern that matters or drown the geotechnical engineer in nuisance alarms until they mute the system, which is the outcome to avoid above all others.

Problem 3: the audit trail is a mailbox

When the amber level is crossed, the plan specifies who is notified, within what time, what inspection is triggered, and who authorises a return to green. Today that happens by phone and email, so the record of a genuinely well managed response is scattered across three organisations and cannot be reconstructed a year later when a reviewer asks.

This is where a build earns its money in tailings specifically. The response is a workflow with named roles, timers and mandatory sign off: alarm raised, acknowledged by the responsible tailings facility engineer within the specified period, inspection completed with photographs and a report attached, engineer of record consulted where the plan requires it, action recorded, condition closed with a reason. Make the record append only so nothing can be quietly edited after the fact, and make escalation automatic when an acknowledgement timer expires. An independent tailings review board or an insurer asking how you have managed triggers over the last two years should get a complete answer in one export, not a search of three inboxes.

Problem 4: a facility is more than its instruments

Instrument dashboards are the visible part, and they are not the whole risk. Freeboard and beach width, the water balance under a design storm, deposition against the plan, the current dam raise construction records and material placement quality, the emergency preparedness and response plan with its current inundation study, and the schedule of inspections and reviews all sit at the same level of importance and are typically held in a document folder.

A build that is worth doing brings the operational half in: deposition and pond position tracked against plan, freeboard computed from survey rather than estimated, water balance inputs including rainfall and pumped volumes, and a document register that knows which version of the emergency plan is current and when the next review is due. The value is that a single facility page tells the responsible engineer everything about that dam today. Without it, the assurance question is answered by a person assembling a pack for two weeks, which is why assurance in this sector is annual instead of continuous.

Problem 5: the accountable executive has no portfolio view

Corporate accountability landed on a named executive, and that person typically has 18 facilities across four countries, each with its own consultant, consequence classification and review cycle. Asking for status produces 18 emails and a slide pack assembled by a graduate.

The portfolio view is the reason groups fund these builds. It should answer, without anyone being asked: which facilities have an open trigger condition and for how long, which have overdue inspections or reviews, which have an engineer of record appointment lapsing, which have instruments that stopped reporting, and which have outstanding actions from the last independent review. Consistency across facilities is the hard part, because every consultant classifies and names things differently. Normalising that taxonomy at group level is a genuine piece of work and it is also the deliverable that makes disclosure to lenders and investors a report rather than a project.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape for tailings portfolios. A monitoring and trigger response layer, meaning multi source ingestion with instrument identity and installation history, versioned trigger levels, rate and correlation based evaluation, missing data alarms, and the acknowledgement and escalation workflow with an append only audit trail, runs $90,000 to $200,000 and ships in 14 to 20 weeks. A full platform adding water balance and deposition tracking, survey and drone derived freeboard, construction quality records, document and review registers, and the group portfolio and disclosure reporting runs $250,000 to $600,000 over 9 to 15 months.

What drives the price up specifically here: the number of facilities and the number of distinct consultants and contractors feeding them, because each relationship is a data contract to be negotiated as much as an integration to be built. Survey and geospatial processing, since converting between datums and deriving freeboard from point clouds is specialist work. Multi jurisdiction reporting, as a group operating across several countries faces several regulators with different formats. Offline field inspection capture, if inspectors work in areas with no coverage. And the taxonomy normalisation across facilities, which is a workshop exercise with your engineering partners rather than a coding task.

What keeps it down: start with your highest consequence facility, its instruments and its trigger response workflow. Prove the response loop works there, then roll the same model outward. Groups that try to onboard all facilities at once spend the first six months in data mapping meetings.

Build versus buy, and when buying is the right call

Buy if you operate one facility on a single logger network with a straightforward instrument set. Vista Data Vision over your loggers, or the platform that came with your Worldsensing hardware, will give you plots and threshold alarms, and Seequent Central is a sensible way to manage geotechnical and geological models with your consultants. That combination is genuinely adequate at that scale, and the money is better spent on more instrumentation and a more frequent inspection regime.

Build when two or more of these are true. You hold more than three facilities and cannot answer their status without asking people. Your monitoring data comes from parties who do not share a platform, which is nearly always the case once a survey contractor and an InSAR provider are involved. Your trigger levels live in documents rather than in the system that evaluates them. Your response record would take weeks to reconstruct for a review board. Or your accountable executive is personally accountable for a conformance position that is currently assembled by hand once a year. That last one is the argument that gets budget approved, and it is a fair argument.

How to choose a developer for tailings monitoring software

Ask them to whiteboard the instrument model before anything else. The right answer separates the physical instrument, its installation with depth and coordinates, the logger channel it currently reports through, and the reading itself, because instruments get reinstalled and loggers get swapped and your ten year trend must survive both. A developer who models a reading as a sensor name plus a value will corrupt your history the first time a node is replaced.

Ask how they handle a missing reading. If alarms only fire on exceedance, the system will be silent in exactly the scenario that should worry you most.

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

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. For a facility whose monitoring record may need to be produced decades from now, data portability is not a commercial preference, it is part of the risk management case.