Offline verification

Correction (2026-11-04): The offline check harness (docker/local/offline-check/ and docker-compose.offline-check.yml) is not in this repository. It was removed with the Paytm connector on 2026-11-02 (ADR-0018). The steps below describe the check as it was run. They cannot be run from this repository as it stands. The verification steps further down apply to any Trust Record and its public keys, however it was produced.

The offline check runs the whole decision flow on a Docker network that has no route to the internet, then verifies the evidence with only your public keys. Run it before you rely on the deployment, and after every upgrade.

bash docker/local/offline-check/run.sh

It takes about two minutes after the image is built. It ends with:

14 of 14 checks passed

and exits with code 0.

The check grew from 12 to 14 steps on 2026-09-30, when it started adding a refund manager through maker checker (every refund needs a signed approval). Run the same day: 14 of 14 passed.

Any failed check makes it exit with 1 and print the API log.

What it does

Builds while online. It builds the API image and pulls postgres:16. This is the only step that needs a network.
Makes your keys, if needed. It runs setup, so ./parmana-local has your signing keys.
Starts an isolated copy. It starts a second copy of the deployment under the project name parmana-offline-check, with its own empty database, on a Docker network created with internal: true. No container on that network has a route to the internet or to Parmana.
Runs the checks below, from a container on the same network that holds your public keys and its own throwaway API keys, and no private key.
Cleans up. It removes the copy’s containers and database. Your deployment started with docker compose up is not touched, and your API keys are not changed.

The copy signs with your deployment’s own keys from ./parmana-local/keys, so the record it produces is signed exactly as your deployment would sign it.

The 14 checks

#	Check	What passing proves
1	no internet route from this network	`https://1.1.1.1` and `https://registry.npmjs.org` cannot be reached from the network the server runs on.
2	API reports READY	The server started and its database is reachable, with no internet.
3	policy change proposed by a verified human	Policy governance accepts a proposal (`201`).
4	the proposer cannot approve their own change	One person cannot make a policy take effect (`403 SAME_ACTOR_CANNOT_APPROVE_OWN_CHANGE`).
5	a different human approves it with a signed step up authorization	A second person’s signed approval makes the policy (`customer-refund` 1.2.0) take effect (`200`).
6	adding a refund manager key proposed by a verified human	Approver governance accepts a proposal to trust a manager’s Ed25519 key (`201`).
7	a different human approves the manager key with a signed step up authorization	The manager’s key is trusted from the next request on (`200`), with no deploy.
8	authorized refund executes	A refund of 500 with the manager’s signed approval for that order and amount is authorized and released (`200`).
9	authorized refund reached the downstream system once	The downstream system received it exactly once, and verified the Execution Gateway’s signature with only the public key.
10	refused refund is rejected by the policy’s rules	A refund of 50,000 with no manager approval is refused with `403 POLICY_DENIED`, for the policy’s own reason.
11	refused refund never reached the downstream system	A refused action is never released.
12	Trust Record stored	The authorized refund has a Trust Record.
13	Trust Record verifies with only the public keys	The record’s hash and signature are valid, checked with the public keys and nothing else.
14	a changed Trust Record fails verification	Changing the amount in the record makes verification fail, so check 13 is not vacuous.

No agent action is authorized without a signed human approval (Human approval), so the check adds a refund manager through maker checker, the same way an operator would, with a key it makes inside the isolated network. The image itself trusts no approver.

The stand in for your downstream system

The downstream system in the check was a stand-in for an external endpoint, paytm-agent-stand-in.mjs, which was removed with the harness. It took the place of that endpoint. It:

answers the connector route the way the real endpoint does;
refuses any request whose Execution Gateway signature does not verify with the gateway’s public key;
never calls any external system;
serves HTTPS with a certificate made for the run, because the server refuses a plain HTTP connector URL in production. The server trusts that one certificate for the run only.

Verify the record again, anywhere

The check leaves four files in parmana-local/offline-check/: trust-record.json, default.public.pem, default-secondary.public.pem and gateway.public.pem. Anyone can check the record on any machine with a clone of the repository, npm install and Node.js 24 or newer:

npx tsx scripts/verify-trust-record.ts parmana-local/offline-check/trust-record.json \
  default=parmana-local/offline-check/default.public.pem \
  default-secondary=parmana-local/offline-check/default-secondary.public.pem \
  gateway=parmana-local/offline-check/gateway.public.pem

Expected output, exit code 0:

{
  "valid": true,
  "hashValid": true,
  "legacySignatureValid": true,
  "algorithmsChecked": [
    "ed25519"
  ],
  "errors": []
}

The script makes no network call and needs no database. More on independent verification: Verify independently.

What it does not cover

Building offline. The image is built while online. The check proves running without the internet, not installing without it.
Your real downstream system. It uses the stand in. Your own connector is tested by your own requests.

Self hosted

Deploy

Security

Operate

Offline verification

What it does

The 14 checks

The stand in for your downstream system

Verify the record again, anywhere

What it does not cover

Where it has passed

​What it does

​The 14 checks

​The stand in for your downstream system

​Verify the record again, anywhere

​What it does not cover

​Where it has passed

What it does

The 14 checks

The stand in for your downstream system

Verify the record again, anywhere

What it does not cover

Where it has passed