VERIFIEDSUBSTATION
The claim boundary

What verified means here — and where it stops.

Our name carries the word verified, so this page says exactly how far that word reaches. Nothing here is new writing for a website: every line is taken from the offline verifier your own auditor runs, and the browser check on the verify page is held to that same program by a test.

What a pass proves

Twelve checks, in this order, on the bytes in front of it.

1
The export is the one that was sealedIts own hash recomputes, and its signature verifies. In the browser, the signing key must also be the key the tenant published, for the tenant the export names.
2
Every definition is the definition citedEach embedded definition hashes to the hash the data refers to it by — a term cannot have been quietly redefined after the fact.
3
The definitions bundle is complete and signed to thresholdIts manifest hashes recompute, it meets its signing threshold against the embedded roots, and it names exactly the objects embedded — no more, no fewer.
4
Every reading is the reading recordedEach source event hashes to its stated content hash and derives its own identifier from its identity.
5
Every batch is intactIts merkle root and its control total recompute from its own rows, and the sender's signature over the manifest verifies against the embedded gateway key.
6
Every receipt sits where it says it sitsEach receipt recomputes both chain hashes it carries — the tenant chain and its gateway stream — and its backfill marker is the one its batch manifest signed, as is every state row's.
7
The ledger recomputes end to endEvery entry commits to the one before it, and the chain agrees with its anchors and with the head the cut names.
8
The state at the cut recomputesThe state hash recomputes from the embedded rows, and each row is among the embedded events.
9
Every horizon certificate is well-formed OFFLINE ONLYThe limits a field gateway was operating under are present and structurally valid.
10
Every grant-checked act re-checks from the ledger alone OFFLINE ONLYThe grant it cites was issued earlier on the same ledger, unchanged, in force at the act's instant, covering the act, naming its principal, and not revoked.
11
A witnessed tree head holds OFFLINE ONLYOnly when one is supplied: it is signed by the export's own control-plane key or a key it delegated to, its ledger commitment matches the export's ledger, at least one countersignature by a key that is not the cell's verifies over that exact head, and every receipt in the export is inside the head by an RFC 9162 inclusion proof.
12
Nothing was reached forThe offline verifier imports the file system and the canonical primitives only; a test fails if it or any module it pulls in reaches for the network. The browser check fetches only the published registry and demo exports from this site, and never sends what you paste.

Checks 9–11 run only in the offline verifier; the browser reports them as NOT_RUN and says so. The source of this list is the header of tools/ua-verify.js, which states the checks in the same order.

What a pass does not prove

Eight things, printed by the verifier on every run — a passing one included.

The verifier returns this list in its machine-readable report as notProven. In English it is quoted verbatim; the Arabic is a translation.

that any value is physically true

that a source was calibrated or honest (a signature proves authorship, never meaning)

that a human approved anything (approval is a separate, recorded act)

that a grant was legitimate beyond what the ledger records: the grant re-check shows each grant-checked act cites a grant issued earlier on this same ledger, in force, covering the act and naming its principal — not who the people behind the pseudonyms are, nor that a grant's stated basis was sound

that an act recorded before any grant on this ledger covered its kind was authorised: such events predate the act being grant-checked and are counted, not re-checked; nor that an act whose whole Ledger Event was removed and the chain rebuilt ever happened (that is the chain's and the witness's to show)

that nothing outside the declared scope was omitted

without a witnessed tree head (--witness): that the cell did not rewrite its own history before this export — whoever holds the store can rebuild every chain above consistently

with one: that the witness is independent of the operator, or checked consistency before countersigning — a countersignature proves which key signed a head, never who holds that key; nor anything about receipts appended after that head

The chain is tamper-evident under controlled administrative access — not tamper-proof. An altered, reordered or missing entry breaks verification at a sequence number you can name. Whoever holds the store could rebuild every chain consistently; only a witnessed tree head, countersigned by a key that is not the cell's, shows that history was not rewritten after an outsider saw it.

On the demo pages

What "verified history" means on a demo asset.

Each reading on a demo asset page is embedded in a sealed export the demo tenant signed, and that export passes the checks above in your browser against the key published in /data/tenants.json. That is the whole of the claim.

It does not mean the reading is physically true — the demo data is synthetic by construction — and it does not mean anyone approved anything. A real utility's exports are not on this site at all: you receive one from the utility and open it on the verify page, where it is checked in your browser and never uploaded.

The words

Five words, used the same way on every page.

VERIFYTo recompute every hash and signature in a record and compare each with what the record claims. A check, not an opinion.
VERIFIEDEvery check above held, and the signing key is the one the tenant published. Says nothing about the physical world.
RECEIPTThe signed answer to one batch: its hashes, row count, control total and position in the tenant's chain. Never the readings themselves.
SEALED EXPORTOne file the tenant signed at a cut: readings, batches, receipts, ledger, definitions and state, each recomputable on its own.
WITNESSA party outside the cell that countersigns a tree head it was shown. A countersignature proves which key signed — never who holds it.
Where every line comes from

No claim on this page exists only on this page.

The twelve checks, in orderua-backend-v1/tools/ua-verify.js — the file header and the body of verifyCapsule
The eight things not provenua-backend-v1/tools/ua-verify.js — the exported NOT_PROVEN list
The browser check equals the referenceverifiedsubstation-site/_build/verify-web.test.mjs — every published export and every tampered one must give the same verdict in both
The verifier reaches for no networkua-backend-v1/test/verifier.test.js — scans the verifier and every module it imports

All data under Demo is synthetic and labelled as such. We hold no certification, and say so before any other claim.