Governance GISTM Accountability

Engineer of Record under GISTM: Accountability That Doesn't Dilute

The Engineer of Record (EoR) is the single most consequential accountability role in tailings governance. GISTM reinforces it, but implementation often dilutes it. Here is what we see in the field, and how to fix it.

Engineer of Record reviewing monitoring data at a tailings dam

What the EoR actually owns

The EoR is not a signatory. The EoR is the engineer who stays with the facility, who integrates design, construction records, monitoring data, operational reality and change controls into a single technical narrative, and who is professionally accountable for the statement "this dam is safe to operate today". Remove any of those four verbs — integrate, interpret, intervene, or sign — and the EoR role collapses.

Under GISTM, this is reinforced by Principles 4, 10 and 11. Together they say: give the EoR the authority, the information, and the audience (up to the board if needed) to do the job.

The dilution patterns we keep seeing

  1. The "reviewer" EoR. The EoR is reduced to reviewing documents produced by others. They never touch the instrumentation, never walk the crest. They sign off on decisions they didn't really own. This is not accountability — it's approval theatre.
  2. The rotating EoR. A new EoR every 2–3 years, with no continuity of memory. Each new EoR inherits a facility they don't yet know, at the exact moment stakeholders demand decisive judgment.
  3. The off-site EoR. The EoR is in another country, getting monthly reports. GISTM Principle 11 explicitly demands an empowered Responsible Tailings Facility Engineer and a clear chain to the EoR — the distance, literal and organizational, kills that chain.
  4. The silenced EoR. The EoR flags a deviation; it gets softened by two layers of management before reaching the accountable executive. By the time it reaches the board, it's a risk line item, not a warning.

People-first reminder: An AI system cannot be the EoR. AI can strengthen the EoR's field of vision, reduce their reporting burden, and accelerate anomaly detection — but it cannot hold professional accountability. A human signs. Always.

What a well-supported EoR looks like

Where technology helps — and where it doesn't

We build AI agents — including GISTM.ai — that give the EoR a single pane of glass for monitoring data, documents, deviations and evidence. That's genuinely useful: it removes hours of manual reconciliation per week and puts the engineer back in the engineering.

But technology also has a failure mode: it can create an illusion that the facility is "covered" because the dashboard is green. The EoR's job is to know why the dashboard is green — and to spot the one instrument whose green is actually a frozen value. That judgment is human and must stay human.

Our stance, bluntly

Do not design an EoR function you cannot fund. Do not publish a GISTM commitment you cannot honour with real authority for a real engineer. If your organization cannot support an EoR in the way described above, the honest answer is not "we'll do our best" — it's "we are not yet GISTM-aligned, and here is our plan to get there".

Related reading and work

Is your EoR structure GISTM-ready?

We review EoR mandates, escalation paths and evidence chains — bluntly — for boards that don't want surprises.

Talk to Data Riders