Representative scenario — the seal and receipt mechanics are real VAC system output. Scenario data is illustrative and labeled as such.
VAC Protocol
VERIFIABLE AUTHORITY CHAIN
WATER NETWORK · PREVIEW
Smart water management · Digital twin operations

The digital twin runs the what-if. VAC seals who accepted the recommendation — and proves it, years after the moment has passed.

Smart water networks run on what-if decisions made in seconds and audited over years. When a Smart Water Management digital twin recommends a DMA pressure reduction during a scarcity window, the operational and regulatory question is not what the twin proposed — it is who held authority to act on it, under which conditions, and whether that record has been altered since. VAC is the trust layer on top of the twin: it proves acceptance, authority, and provenance with a sealed, independently-verifiable receipt.

Representative scenario
District 14 — Northside DMA · 04:17 AEST

Fixed-network smart metering across District 14 (Northside DMA) detects an elevated minimum night-flow during the 02:00–04:00 low-demand window: 4.2 L/s above the 7-day baseline, a signal consistent with real-loss infrastructure leakage. The Smart Water Management digital twin runs a what-if — if inlet pressure is reduced by 12% and held for 30 minutes, what is the projected impact on water-loss reduction versus supply continuity? The twin's recommended action emerges from that scenario run: Stage 1 DMA pressure reduction.

A Network Operations Centre engineer receives the digital twin's recommendation, reviews the SCADA telemetry confirming the metering signal, and accepts Stage 1. VAC is the mechanism that seals which scenario was accepted, by whom, under what authority, and at exactly what time — producing a regulator-grade audit receipt that anyone with the JTI can verify against the production backend, without needing to trust VAC's word for it.

Sealed authorisation walkthrough

LIVE SEAL MECHANICS

"The part of the system that checks the work is never the part that did the work." The AI that flagged the anomaly does not authorise the response. The engineer who authorises does not operate the seal. The regulator who audits holds a receipt that neither party can alter after the fact.

1

Scenario — digital twin runs the what-if

Smart Water Management twin · automated what-if scenario run · no human authority required at this stage
Digital twin recommendation · 04:17:03 AEST
District 14 (Northside DMA) — water-loss risk detected via fixed-network smart metering.

Minimum night-flow index: 18.7 L/s (baseline 14.5 L/s; +4.2 L/s, +29% above low-demand threshold).
Signal sustained: 02:03–04:14 AEST (131 minutes). Real-loss confidence: High.

What-if run complete. Scenario modelled: reduce District 14 DMA inlet pressure by 12%, hold for 30 minutes. Projected outcome: water-loss reduction of 8–14% with no supply-continuity breach at current demand levels.

Recommended action: Accept Stage 1 DMA pressure reduction. If minimum night-flow does not return within 1.5 L/s of baseline after the hold, escalate to Stage 2: field crew dispatch to Zone 14-C.

The digital twin's what-if and recommendation are automated outputs — no authority is exercised here. Authority begins the moment a human reviews the scenario and decides to act on it. That is the step VAC seals.

DMA: District 14 signal: min-night-flow what-if: pressure −12% confidence: high action pending human authorisation
2

Decision — NOC engineer reviews the what-if and accepts

Human decision · identity not yet verified · authority not yet sealed

The on-call Network Operations Centre engineer reviews the digital twin's what-if — checks the scenario inputs, the projected water-loss reduction, the fixed-network smart metering telemetry confirming the overnight signal — and accepts Stage 1 of the recommended DMA pressure reduction.

At this point a decision has been made — but no authority has been verified and no record has been sealed. If the decision were logged only in the NOC system, the audit trail would rest on that system's integrity. VAC replaces that assumption with a cryptographic proof: not just who clicked accept, but who held authority to accept this class of scenario, under what conditions, at what time.

decision: accept Stage 1 action: DMA pressure reduction 12% identity not yet verified
3

Authority — VAC verifies the engineer holds operational authority

VAC identity gate · policy-encoded conditions · authority chain minted

VAC checks that the engineer is:

  • A verified, present human — not a bot, not a replay, confirmed by live biometric at the moment of authorisation.
  • Holding operational authority for District 14 DMA network actions (encoded in the engineer's VAC credential, not asserted by the NOC system).
  • Acting within permitted conditions — action type, pressure-reduction magnitude, and time window all within the encoded operational rules for this DMA and scarcity scenario class.

The policy conditions — DMA scope, pressure-reduction bounds, permissible action types — travel with the authority chain. Not stored separately in a policy server that must be trusted; not asserted by the engineer. The part of the system that checks the work is never the part that did the work.

identity: live biometric authority: District 14 ops conditions: within bounds policy: embedded in token
4

Seal — VAC seals who, what, and when

Ed25519 signed token · live production backend · independently verifiable

VAC mints a signed token (Ed25519 + JWT) that binds together:

  • Who — the verified engineer identity (biometrically confirmed at the moment of acceptance, not just account-authenticated)
  • Which scenario — the specific digital twin what-if accepted: Stage 1 DMA pressure reduction, District 14, −12%, 30-minute hold, water-loss reduction scenario
  • Under which rules — the operational policy conditions encoded in the token at the moment of mint (DMA scope, action-type bounds, permissible magnitude)
  • When — the exact timestamp, immutable, signed into the token — queryable in a regulator-grade audit years after the event

The token is signed by the VAC production backend. No party — not the engineer, not the NOC system, not VAC — can alter this record after the fact without the signature failing verification. The twin proposes; VAC proves who accepted.

algorithm: Ed25519 format: JWT sealing now...
5

Receipt — Regulator-grade sealed receipt, queryable after the fact

Live token · verifiable by JTI · tamper-evident

The sealed receipt is queryable by anyone who holds the JTI — the regulator, an auditor, a water authority compliance team — against the live VAC backend. No trust in VAC required: the Ed25519 signature either verifies or it does not.

What a regulator-grade audit looks like with this receipt: the auditor queries the JTI — months or years after the scarcity event. The backend returns the signed token. The auditor verifies the signature against VAC's public key. The token's claims show the verified engineer identity, which digital twin scenario was accepted, the DMA and pressure-reduction parameters, the policy conditions that authorised it, and the immutable timestamp. No internal NOC system access required. No trust chain back to the SCADA log. The twin proposed; the record proves who accepted, and under what authority.

Authorisation sealed & lodged

Honest scope. The scenario above — District 14, the digital twin what-if, the fixed-network metering readings, the engineer identity — is representative and labeled as such. The seal and receipt mechanics are real VAC system output: the token is genuinely minted, Ed25519-signed, and independently verifiable at the URL shown in the receipt. The operational rules and engineer authority encoded in this token are illustrative placeholders; encoding the actual SCADA policy rules, DMA authority hierarchy, and digital twin integration for a specific water utility is the integration build done with that utility's operations and compliance team.
See how VAC applies across legal trust & tribunal matters
The same two primitives — verified human authority and a sealed, auditable decision trail — applied to six NSW trust & tribunal scenarios, with the live biometric identity gate.
See the trust & tribunal demo →
What the seal proves: a verified, living engineer held authority under the encoded operational rules and accepted this specific digital twin scenario at this specific time — with a tamper-evident record the regulator can query independently, years after the event.
Honest scope · VAC is the trust layer on top of the digital twin: it proves acceptance, authority, and provenance. It does not operate the twin and does not move physical infrastructure. The DMA pressure reduction in this scenario is authorised by a human; execution remains with the SCADA system. The digital twin proposes — VAC seals who decided to act. Cryptographic seal = tamper-evident provenance + regulator-grade audit trail, not operational control.