FactorHelm
Request access

Don't take our word for it

A record is only worth something if a stranger can check it hasn't changed. Edit the record below and watch the hash and the seal change.

Computed—
Published—
The seal of whatever is in the editor. It is drawn from the computed hash, so it matches the published seal only when the record is unchanged.

How the hash is computed

The record is serialised as canonical JSON: keys sorted, no whitespace, UTF-8. The SHA-256 of those bytes is the record's hash. Formatting in the editor doesn't matter; content does.

The outcome entry contains the decision record's hash in its prev_hash field. Change the decision and the outcome no longer points to it. That is the chain: later entries can be added, but earlier ones can't be changed without breaking every link after them.

These two records were made for this site to show the mechanism. They are not entries in the production manifest chain.

Verifying production manifests

Strict calls are grouped into one manifest per UTC day, each carrying the previous day's hash and signed with an AWS KMS key. Verification is offline and doesn't need access to our database or our cloud account.

With the pinned public key and the manifests in date order:

ne verify-manifest \
  --public-key narrative-edge-kms-public.der \
  2026-07-14.json 2026-07-15.json

Each signed envelope contains the public key, the signing algorithm, the key's fingerprint, the manifest digest and the previous manifest's digest. The verifier rejects a valid signature from any key other than the pinned one. A changed call, a changed manifest, a substituted key, an invalid signature or a broken chain all produce a non-zero exit code.

Design partners receive the public key and the verifier with their pilot. Request access to get them.