Verify a Decision Record.

Why this page exists

The cryptographic Decision Record's whole point is that you don't have to trust us to verify it. The verification math runs on your own machine — in your browser for the drag-and-drop verifier, or on your local file system for the command-line verifier — with open-source code you can read, against public keys we publish openly. If we said the math was sound and didn't give you a way to check, the whole story would unravel.

This page is the step-by-step. The audit-chain page covers the framing and the why; here we cover the how. Most users will want the browser verifier (next section); the command-line path is below that for technical and audit use.

The browser verifier — recommended for most users

No software to install. Drop the Decision Record file onto the verifier page; the seal check runs in your browser tab and the result appears in seconds.

1. Open the verifier: verify.athenanorthstar.com.
2. Drag the Decision Record JSON file onto the page. Roughly 15 KB. You'll have the file from whoever sent you the record — an appraiser, lender, AMC, attorney, or regulator. The file is read locally in your browser; it is NOT uploaded to any server.
3. The verifier fetches the matching public key automatically from verify.athenanorthstar.com/keys based on the signing_key_id field in the Record. No manual download needed.
4. The result appears in your browser: "✓ Verified" with the seal date, the rule-set hash, and the signing key id — or "× Verification failed" with the specific check that failed (signature mismatch, altered record, missing predecessor, etc.) and guidance on common causes.

Why you can trust a webpage to verify cryptographic seals

The verifier is a single-page WebAssembly application compiled from the same open-source Rust code that powers the command-line verifier. The cryptographic math runs entirely in your browser tab, on your machine, with no server-side verification step that we could tamper with. The WebAssembly bundle is downloadable and inspectable; we publish its SHA-256 checksum alongside the bundle so a skeptical auditor can verify the bundle hasn't been swapped for a fake.

Status note: the browser verifier launches with North Star in the first weeks of June 2026. Until it ships, the command-line verifier below works today and returns the same answer on the same input. If you receive a Record before the browser verifier is live and need a technical hand verifying it, email verify@athenadecisionsystems.com and we will verify it for you.

The command-line verifier — for auditors, regulators, and technical users

Same cryptographic verification as the browser verifier, packaged as a locally-installed binary. Use the CLI when:

• You're an auditor, regulator, or opposing-counsel expert who wants to verify against an inspectable open-source binary rather than a webpage.
• You need to verify offline with no network access to our public-key registry (download the keys ahead of time and run from disk).
• You're scripting bulk verification across many Records.
• You prefer terminal workflows.

What you need

1. The Decision Record JSON file. Roughly 15 KB. Same file the browser verifier reads.
2. The corresponding North Star public key. Each Record carries a signing_key_id field. Look up that key id in our public registry: verify.athenanorthstar.com/keys. Download the matching .pub file.
3. The athena-verify CLI. Small open-source binary published by Athena Systems at verify.athenanorthstar.com/cli. Install via cargo install athena-verify (requires Rust toolchain) or download a pre-built binary for your platform from the same page. Source code and build instructions are linked from the same page. The verifier runs entirely locally with no Athena Systems service required.

Run the CLI verification

One line:

athena verify --record YOUR_RECORD.json \
              --public-key SIGNING_KEY_ID.pub

Replace the placeholders with your actual filenames. For example:

athena verify --record decrec_2026-04-15T14-22-08Z_a4f2c1e8.json \
              --public-key north-star-prod-2026-Q2.pub

If the record is valid, you'll see:

record_hash      OK  (matches canonical bytes)
signature        OK  (Ed25519 over canonical CBOR)
timestamp        OK  (RFC 3161, timestamp.digicert.com)
chain            OK  (predecessor hash matches)
findings_hash    OK  (derived from canonical findings)
content_hash     OK  (derived from canonical work file submitted)
=> verified: true

If the record has been altered, you'll see something like:

record_hash      OK  (matches canonical bytes)
signature        FAIL  (signature does not verify against public key)
timestamp        OK  (RFC 3161, timestamp.digicert.com)
chain            OK  (predecessor hash matches)
findings_hash    OK  (derived from canonical findings)
content_hash     OK  (derived from canonical work file submitted)
=> verified: false  (failed at: signature)

The CLI tells you which of the six checks failed so you can investigate. Common causes:

• Wrong public key. You downloaded the wrong key for the record's signing_key_id. Check the id in the record and re-download the matching key.
• Record altered. The Record file has been edited (even an extra newline character). Find the original.
• Chain predecessor missing. The predecessor referenced by this Record isn't in your local chain copy. Most verifications work with the single Record + the public key; if you specifically want chain- continuity verification across multiple Records, the CLI supports a --chain flag pointing at a directory of all Records.

What a successful verification means

verified: true is mathematical proof of the following:

• The work file referenced by content_hash in the Record is exactly the file submitted at evaluation time. (You'd need the original work file to confirm the hash matches a specific file; without it, the Record proves only that some file was submitted whose hash is recorded.)
• The rule set referenced by rule_set_hash is exactly the rule set in force at evaluation time. (The rule set is inspectable on request by regulators, auditors, and customers under the customer agreement; the hash in the Record pins which version is being inspected.)
• The timestamp recorded by the Record is countersigned by an independent RFC 3161 timestamping authority, which you can verify independently against the TSA's public key.
• The Record was sealed by North Star using the signing_key_id in force at the timestamp, and has not been modified since.

What a successful verification does NOT mean: the underlying work file is accurate, the valuation is correct, or the appraisal conforms to any standard outside the rule set referenced. The Record is an evaluation-event witness, not a content attestation. See the audit-chain page for the full framing.

The public key registry

Every North Star signing key is published at verify.athenanorthstar.com/keys. Each entry includes:

• The key id (e.g., north-star-prod-2026-Q2)
• The .pub file (download)
• The effective-from and effective-until dates
• Algorithm (Ed25519, in current versions)
• Compromise notice (if ever applicable — empty for keys that have not been compromised)

We rotate signing keys on a quarterly schedule. Records sealed during a key's effective window remain verifiable with that key forever. If a key is ever compromised, we publish the compromise date; records sealed before that date remain trustworthy.

Verification is independent of us — in two ways

First: the verifier is open source. You can read the exact Rust code that does the verification, line by line, before you trust its output. The source and build instructions are at verify.athenanorthstar.com/cli. We open-sourced the verifier specifically because the verification math should never be a black box.

Second: the cryptographic primitives are public standards. SHA-256 (FIPS 180-4), Ed25519 (RFC 8032), RFC 3161 timestamping, and deterministic CBOR (RFC 8949) are independently documented and broadly implemented across the security industry. An auditor skeptical of our verifier source can write their own implementation from the data-format specification we provide, against the same primitives, and get the same result on the same input. Two independent paths to the same answer.

The data-format specification — the canonical Decision Record schema, the rule-set serialization rules, the chain-link protocol — is available on request to regulators, auditors, and customers under the customer agreement.

Scope note: only the verifier is open source. The engine that runs your evaluation, the rule library that defines the predicates, and the platform application stay proprietary. The open-source verifier is the part of our codebase that makes the “you don't have to trust us” claim mathematically defensible; the rest is our product.