Most compliance software I have seen is built around a dashboard. Green, amber, red. A score at the top. It looks good in a demo.

Then a regulator, or an engineer who has to sign their name to a certificate, asks a simple question: "Show me where."

That question is what I designed DamGuard around. DamGuard is dam-safety compliance software for New Zealand operators. It maps evidence to regulations, closes deficiencies, and produces regulator-ready reports with a 3D view of the asset.

Here is what building it taught me about compliance products in any regulated industry.

Start from the evidence people already have

Dam owners in New Zealand must certify dam safety every year. The evidence lives in PDFs, consultant reports, SCADA exports, Maximo work orders and spreadsheets. Each certificate is a manual stitch.

The tempting technical answer is integration first: connect to the monitoring systems and work order tools, and pull everything in automatically.

But most operators are not ready for systems integration. Their evidence is documents, procedures and logs.

So DamGuard starts document-first. There is an evidence hopper, a requirement-to-evidence mapping table, and the same regulator-ready report format whether evidence arrives by upload or, later, by connector.

The trade-off is manual mapping in the first cycle. In return, an operator with low data maturity can adopt it this year rather than after a long integration project.

What to take from this: meet your users at their current level of maturity, and make sure the output does not change as they grow. If the report is the same whether evidence was uploaded or connected, you can add integrations later without redesigning the product.

Build the workflow, not the prompt

Foundation models are going to make "map this PDF to regulation 14" a commodity. If your product is a prompt wrapper around that task, it has a short shelf life.

DamGuard is built as a multi-step pipeline instead:

  1. Ingest the evidence.
  2. Map it to requirements, with a rationale and a confidence level.
  3. An engineer accepts, rejects or overrides each mapping.
  4. A signatory signs off.
  5. The cycle is archived.

Every decision is appended to an immutable audit trail, and decisions from the previous cycle are suggested the next year.

That is slower to build than a chat box. It is also something a generic copilot cannot replace, because the value is in the workflow, the decisions and the history, not in one clever answer.

Keep people at every gate that matters

A regulator accepts a Recognised Engineer's signature, not an AI's. That one fact shapes the whole product.

In DamGuard, AI drafts and people sign:

  • Role-based access for engineer, signatory, viewer and admin.
  • Multi-factor sign-in for admins.
  • Row-level security, so each operator's data stays separate.
  • No automatic submission to the regulator.

DamGuard has five domain agents: regulatory, structural, hydrology, operations and emergency. They work only within the asset's evidence. Mapping suggestions carry a rationale and a confidence band, and nothing is certified without a person.

It means more steps per cycle. But every claim in a report traces back to a source and a reviewer, which is exactly what someone signing their name needs.

If a person has to sign for it, every claim needs a source and a reviewer behind it.

What to take from this: find the point in your domain where legal or professional accountability sits, and design so AI never crosses it. Make confidence and rationale visible so reviewers can work quickly without trusting blindly.

Give reviewers spatial context

One problem surprised me in discovery. Reviewers had trouble connecting piezometer, seepage and surveillance readings to the physical asset they were certifying. More tables and charts did not help.

So DamGuard has a portfolio globe with site drill-down, and a full-screen 3D Dam Monitor: boreholes, lithology, heatmap layers from each agent, and flow nets tied to place.

It is a heavy piece of 3D graphics to maintain. It is also the moment in every demo where the room goes quiet, because people finally see the data where it belongs.

What to take from this: if your users work with physical things, ask whether the data makes more sense in place than in a table. Sometimes the most useful screen is the one that shows where.

Set honest success measures

A discovery estimate put the share of engineering effort spent interpreting regulations and stitching evidence at around 80%. That is the time the product is built to remove, and I label it as an estimate, not a measured result.

For the pilot, the target is a report draft within two hours of upload, with 90% of requirements mapped before sign-off. Those are targets, not results yet.

Being clear about the difference between an estimate, a target and a measured result is part of building trust in regulated work. If a product's own claims are loose, nobody will believe its reports.

The pattern behind it

The lessons carry over to most regulated products:

  1. Start document-first if that is where your users are.
  2. Keep the output identical as inputs get more automated.
  3. Put the value in the workflow and the audit trail, not the model.
  4. Let AI draft, and keep people at every gate that carries accountability.
  5. Show data in the context people actually think in.

If you are building compliance or regulated software and want to talk through where AI should and should not sit in your workflow, email me.