Verifier Distribution

This document names the offline verifier artifacts that third parties should receive or build for Mandate Companion and Receipted Memory. Verifier results are evidence about signed bytes and local chains only; they are not safety, privacy, confidentiality, legal-compliance, or provider-behavior guarantees.

Shared release rules

• Ship verifier artifacts with the extension release, the static export package, and any npm package. Do not require a Flow Memory server to verify an export.
• Verification must work with local files only. Do not fetch schemas, scripts, styles, fonts, telemetry endpoints, or remote assets during verification.
• `VALID` means the verifier accepted the supplied signed evidence under its local rules. It does not prove the action or disclosure was appropriate, confidential, or complete outside the supplied artifact.
• `issued_at` and similar timestamps are client-asserted unless an export contains a separately verifiable time anchor. Absence of an anchor means time-unanchored evidence, not trusted time.
• Keep the package version, extension version, schema version, and fixture set together in release notes so reviewers can identify the verifier used for an export.
• Current release docs do not claim a trusted timestamping service. If `anchor_ts`, `anchor_sig`, or future anchor fields are absent or null, render the export as time-unanchored.

Mandate Companion verifier

Artifact paths

• Package root: `mandate/verifier/`.
• npm package name in metadata: `@flow-memory/mandate-verifier`.
• Programmatic entry after build: `mandate/verifier/dist/src/verify_bundle.js`.
• CLI entry after build: `mandate/verifier/dist/src/cli.js`.
• CLI bin name in package metadata: `mandate-verify`.
• Static offline verifier: `mandate/verifier/web/index.html`.
• Extension export UI: Mandate Companion ledger page, which copies a redacted `mandate-bundle/1` JSON bundle.
• Sample bundle: `mandate/spec/sample-bundle.json`.
• Public schemas and fixtures: `mandate/spec/`.

The Mandate npm package `files` list includes `dist/src` and `web`. A publishable npm release must include built `dist/src` files and the static web verifier; do not publish an empty source-only verifier package. If the package remains marked `private`, treat npm distribution as not released and use the static or repository artifact instead.

For offline npm-style distribution, hand reviewers a prebuilt tarball such as `flow-memory-mandate-verifier-0.0.0.tgz` generated from `mandate/verifier` after build. Reviewers can install from that local tarball without network access and run the package bin:

```bash

npm install --global ./flow-memory-mandate-verifier-0.0.0.tgz

mandate-verify bundle path/to/mandate-bundle.json

```

Do not describe the npm package as publicly published while package metadata still contains `private: true`.

Export contents to preserve

A third-party Mandate review needs the redacted bundle JSON exactly as exported. The bundle root is `mandate-bundle/1` and includes the keyring public key, evaluator version, verifier reference, mandates, receipts, and revocations. Redacted action payloads may omit sensitive fields; when omitted evidence is needed to decide a rule, the verifier must report a gap rather than green.

The extension also keeps signed local `ledger-head/1` pointers for receipt and revocation logs. The public `mandate-bundle/1` export is the verifier artifact; if a release later exports signed heads or checkpoints, the verifier must understand them before they are relied on. Without a prior trusted head, count, or last hash, a third party cannot prove that an otherwise valid supplied bundle is not a tail-truncated subset of local history.

Offline CLI steps

From a machine that already has the built verifier files:

```bash

node mandate/verifier/dist/src/cli.js bundle path/to/mandate-bundle.json

```

Or, for the checked-in fixture:

```bash

node mandate/verifier/dist/src/cli.js bundle mandate/spec/sample-bundle.json

```

Expected vocabulary:

• `VALID within_scope=N outside_scope=0 gap=0`: signatures, canonical bodies, chains, revocation evidence, and scope re-evaluation accepted for the supplied bundle.
• `INVALID ... outside_scope=N`: at least one receipt records or replays as outside the grant.
• `INVALID ... gap=N`: evidence is missing, unreadable, unsupported, non-canonical, or insufficient to decide.

Offline static steps

1. Save the exported Mandate bundle as a local `.json` file.

2. Disconnect networking if the review requires a no-network check.

3. Open `mandate/verifier/web/index.html` from disk in Chrome or Edge.

4. Paste or load the bundle JSON and run verification.

5. Record the full status, counts, and reasons. Do not summarize a gap as valid.

Receipted Memory verifier

Artifact paths

• Package root: `receipted-memory/verifier/`.
• npm package name in metadata: `@flow-memory/receipted-memory-verifier`.
• Programmatic entry after build: `receipted-memory/verifier/dist/src/verify_receipt.js`.
• CLI entry after build: `receipted-memory/verifier/dist/src/cli.js`.
• CLI bin name in package metadata: `receipted-memory-verify`.
• Static offline verifier: `receipted-memory/verifier/web/index.html`.
• Built extension offline verifier page: `receipted-memory/extension/dist/app/public/offline-verifier.html`.
• Compliance ZIP verifier: `verifier.html` inside each exported compliance ZIP.
• Sample receipt: `receipted-memory/spec/sample-receipt.json`.
• Public schema: `receipted-memory/spec/receipt-schema.md`.

The Receipted Memory npm package `files` list includes `dist/src` and `web`. A publishable npm release must include built `dist/src` files and the static web verifier; do not publish an empty source-only verifier package. If the package remains marked `private`, treat npm distribution as not released and use the static, ZIP, or repository artifact instead.

For offline npm-style distribution, hand reviewers a prebuilt tarball such as `flow-memory-receipted-memory-verifier-0.0.0.tgz` generated from `receipted-memory/verifier` after build. Reviewers can install from that local tarball without network access and run the package bin:

```bash

npm install --global ./flow-memory-receipted-memory-verifier-0.0.0.tgz

receipted-memory-verify chain path/to/receipts.jsonl

```

Do not describe the npm package as publicly published while package metadata still contains `private: true`.

Export contents to preserve

A compliance ZIP contains these offline artifacts:

• `receipts.jsonl`: one portable receipt JSON object per line.
• `public_key.txt`: base64 X9.63 P-256 public key used to verify signatures.
• `README.txt`: export contents and limitations.
• `verifier.html`: standalone offline verifier copied into the ZIP.

Preserve the whole ZIP when possible. If files are extracted, keep `receipts.jsonl` and `public_key.txt` together and compare the public key with the signer key expected for the user or organization through a separate trusted channel.

No checked-in compliance ZIP sample is currently present. The checked-in verifier fixture is the single receipt at `receipted-memory/spec/sample-receipt.json`; reviewers should use a real exported compliance ZIP for end-to-end ZIP review.

Offline CLI steps

Verify one receipt, using the receipt's embedded public key or an explicit key from the ZIP:

```bash

node receipted-memory/verifier/dist/src/cli.js receipt path/to/receipt.json

node receipted-memory/verifier/dist/src/cli.js receipt path/to/receipt.json --public-key BASE64_X963_PUBLIC_KEY_FROM_PUBLIC_KEY_TXT

```

Verify an exported chain:

```bash

node receipted-memory/verifier/dist/src/cli.js chain path/to/receipts.jsonl

```

For the checked-in fixture:

```bash

node receipted-memory/verifier/dist/src/cli.js receipt receipted-memory/spec/sample-receipt.json

```

Expected vocabulary:

• `VALID signed_canonical_receipt receipt_hash=...`: the single receipt signature and canonical body verify.
• `VALID signed_canonical_chain count=N last_hash=...`: every supplied JSONL line verifies and links to the previous supplied line.
• `INVALID reason=...`: parsing, schema, signature, canonicalization, public-key, or chain evidence failed.

Offline static steps

1. Export a compliance ZIP from Receipted Memory and keep it local.

2. Disconnect networking if the review requires a no-network check.

3. Extract the ZIP and open its `verifier.html` from disk, or open `receipted-memory/verifier/web/index.html` from the release artifact.

4. Paste a receipt and the public key from `public_key.txt`, or use the page's chain flow if available for that release.

5. Record the full status and reason. A valid receipt does not prove confidentiality after the user sent released values to Claude, ChatGPT, or another provider.

Release checklist for verifier artifacts

• Mandate sample bundle verifies with the release CLI and static verifier.
• Receipted Memory sample receipt verifies with the release CLI and static verifier.
• Static verifier HTML files contain no remote asset URLs and can be opened from disk.
• npm package metadata names the correct `main`, `types`, `bin`, and `files` entries for the built verifier and static web verifier.
• Extension export UI names the same verifier path documented here.
• Third-party security review has the exact extension package, verifier package, schemas, samples, and coverage-gaps document.
• Web Store submission has hosted privacy, terms, support, reviewer smoke steps, and permission rationale ready before submission.