The audit chain

What the seal proves — and what it deliberately doesn't.

Every North Star evaluation produces a cryptographically sealed Decision Record. The seal is an evaluation-event witness, not a content attestation. That framing matters — both for what you can defensibly say about the record, and for what we'd never claim on your behalf.

Why this matters

Three years from now, a borrower's attorney is going to want to know when you checked your work, what you checked it against, and whether the report they're holding is byte-for-byte identical to the one you signed.

A regulator might want the same. A reviewer audit, a CFPB examiner, an insurance carrier defending a claim — same set of questions. The Decision Record exists to answer those questions without anyone needing to take our word for it (or yours).

It does that by being mathematically tamper-evident. Any change to the work file, the rules, the findings, the timestamp, or any prior record in the chain breaks the next verify.

It does not claim your appraisal is accurate. We're not in a position to certify your valuation conclusions, and we'd be misleading you and your clients if we tried. The seal witnesses the evaluation event — that we ran our rules against your content on the recorded date. Everything beyond that is your professional judgment.

The Evaluate framing: side by side

These are the six things the seal attests, and the six things it intentionally does not, in Evaluate (Evaluate — the secondary product for already-finished work files, where you submit the file and we run rules against it). The framing is consistent everywhere North Star surfaces an Evaluate record — in the report PDF, in the web UI, in the offline-verify CLI output, and in our Terms of Service.

In Assembly (the primary product, in active development), the seal attests considerably more, because we captured the inputs as they entered the work file. See the section below on the Custodial Provenance Witness for the Assembly extension.

What the seal attests

  • The exact bytes you submitted. The SHA-256 hash of your canonical work file. Any change to the JSON — even a whitespace difference — produces a different hash.
  • The exact moment of evaluation. An RFC 3161 third-party timestamp authority counter-signs the time. Not back-datable, not forward-datable, not falsifiable from our side.
  • The exact rule set applied. Every rule's predicate, citation, severity, and applicability gate is version-controlled and pinned by hash. Change one comma in one rule and the rule-set hash changes too.
  • The exact findings the engine produced. Same engine + same content + same rule set produces bit-identical findings, every time. Reproducibility is a CI gate on every engine release.
  • The signing identity. Ed25519 signature over the canonical record bytes. Verifying with our published public key is mathematical proof North Star sealed the record and it has not been modified since.
  • Continuity of evidence. Every record links to the prior one via the predecessor hash. Flipping a single byte of any historical record breaks the chain at the next verify — visibly, computably, undeniably.

What the seal does not attest

  • That your work file is accurate. We didn't independently source-verify the comparable-sale data, the condition observations, the GLA measurement, or any other content. Garbage in, garbage out — the seal does not transmute it.
  • That your valuation is correct. Our rules evaluate structural compliance against published regulatory surfaces. They do not opine on the value conclusion. A passing evaluation does not mean a defensible valuation.
  • That observed condition matches reported. If a report says C3 condition and the property is physically C5, our C-rating rule still passes the report. The seal witnesses what was reported, not what was physically observed.
  • That comparable-sale source data is accurate at source. MLS, recorded deeds, prior-sale histories — all taken from your submission as given. We do not warrant the upstream data sources.
  • That the report passes any standard outside our rules. A passing evaluation means the specific rules that fired against your submission, in the rule set in force at evaluation time, came back green. It is not a blanket statement of regulatory conformity.
  • That the evaluation is legal advice or professional opinion. North Star is software. Use it as a tool, not as a substitute for professional judgment.

The Assembly extension: Custodial Provenance Witness

In Evaluate, the Decision Record is an Evaluation Event Witness — it attests what we ran rules against, when, with what result. That's a real protection, but it's narrow on purpose: we didn't help create the content, so we can't honestly attest more.

In Assembly, the same Decision Record is also a Custodial Provenance Witness. Because we captured every source as it entered the work file — engagement letters from email, MLS comps from the public records database, photos from the inspection, sketches from the tablet — the seal can attest substantially more about the evidence underlying the report.

What Assembly's seal additionally attests

  • The source of every input. Each data point in the work file links back to a witnessed source (an email, a database query, a photo, a sketch measurement). The chain proves where each fact originated.
  • The timestamp of every input. Photo at 10:14 AM, MLS comp at 11:02 AM, sketch finalized at 2:34 PM. Each capture moment is sealed with a third-party timestamp.
  • The transformations applied. Every rounding, unit conversion, narrative draft, manual edit, override — logged with author and reason. The chain shows the path from raw input to final field.
  • Photo and sketch integrity. Photo EXIF metadata sealed at capture; later retouching breaks the seal. Sketch measurement log shows it wasn't fabricated after the fact.
  • The chain-of-custody narrative. A regulator can ask “show me how you arrived at this GLA figure” and the chain produces the audit trail automatically.

What Assembly's seal still does not attest

  • That the valuation conclusion is correct. Even with end-to-end provenance, value opinion is your professional judgment. The chain documents what you considered.
  • That you observed the property accurately. Photos prove what was captured, not that your inspection notes are complete or your condition rating is right.
  • That third-party source data is accurate at source. If an MLS comp's reported sale price was wrong upstream, the chain proves we retrieved the wrong figure — not that the figure is correct.
  • That the appraisal complies with rules outside our library. Same as Evaluate.
  • Legal advice or professional opinion. Still software.

The cryptographic primitives are the same across both products — SHA-256, Ed25519, RFC 3161, CBOR. Assembly just has more to attest because we witnessed the inputs. See the Assembly page for the full custodial walkthrough.

What's inside the seal

Every Decision Record contains six independently-verifiable pieces of evidence. Anyone with the published North Star public key can re-derive and validate each one. 

{
  "decision_record_id":  "decrec_2026-04-15T14-22-08Z_a4f2c1e8",
  "content_hash":        "sha256:7c1f6a8b9d4e2c5f1a3b8c9d4e2f...",
  "rule_set_id":         "us-multi.appraisal.2026-Q4-approved",
  "rule_set_hash":       "sha256:b366cca8e2f1a3b8c9d4e2f1a3b8...",
  "engine_version":      "0.1.0",
  "findings_hash":       "sha256:5e3a9c2b7f1d4a8c5e3a9c2b7f1d...",
  "timestamp":           "2026-04-15T14:22:08Z",
  "timestamp_tsa":       "timestamp.digicert.com",
  "timestamp_signature": "MIIDtjCCAp4CAQEwgYowdjELMAkGA1UEBhMC...",
  "predecessor_hash":    "sha256:c8d4e2f1a3b8c9d4e2f1a3b8c9d4...",
  "signing_key_id":      "north-star-prod-2026-Q2",
  "signature":           "ed25519:f3b7e9c2a4d6f8e0b1c3d5e7f9a1..."
}

Cryptographic primitives

  • Hashing: SHA-256 (FIPS 180-4). Used for content, rule set, findings, and chain links. Industry standard, NIST- approved, no known practical preimage or collision attacks.
  • Signature: Ed25519 (RFC 8032). Elliptic-curve digital signature. Smaller and faster than RSA, deterministic (no per-signature randomness needed), and the algorithm of choice for new systems.
  • Timestamp: RFC 3161. Third-party TSA counter-signs the record's hash with a trusted time. We use a commercial CA's TSA in production. The TSA's signature is included in the record and independently verifiable.
  • Canonical form: deterministic CBOR. JSON has many valid serializations of the same logical object (whitespace, key ordering, etc.). CBOR with deterministic encoding rules has exactly one. The hash inputs are the canonical bytes, so verification is order-independent.

How to re-verify, offline

The verification works without North Star's service running. That's intentional — if our company disappeared tomorrow, every record we ever sealed would still be verifiable indefinitely with two files: the record itself, and the public key in force when it was sealed.

Install the verification CLI (Rust binary; macOS / Linux / Windows builds available): 

# Install the verifier. Open source, free, no North Star account needed.
cargo install athena-verify

# Verify a Decision Record against the public key.
athena verify --record decrec_2026-04-15T14-22-08Z_a4f2c1e8.json \
              --public-key north-star-public-key-north-star-prod-2026-Q2.pub

Expected output:

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 any of those six lines comes back FAIL, the record has been altered, the signature is wrong, the timestamp is invalid, or the chain has been broken upstream of the record you're checking. The CLI prints which line failed and why.

Public keys are published at verify.athenanorthstar.com/keys. Each key carries an effective-from date; verify a record against the key in force at the record's timestamp.

A worked example

Concrete scenario: it's 2029. You're an appraiser. A borrower from a 2026 transaction is suing the lender, and the lender's attorney has forwarded a subpoena. They want to know — under oath — whether you checked the report against current rules before submitting it.

You have:

  • The Decision Record JSON file (one file, ~15 KB).
  • The North Star public key for the signing identity in force in 2026 (downloadable from the public-key registry — no account required, no payment required, no continued relationship with us required).
  • The athena-verify CLI (free download, installs in a minute, runs entirely locally with no Athena Systems service required).

Your declaration looks like this:

On 2026-04-15 at 14:22 UTC, I submitted the attached work file to Athena Systems North Star for evaluation against its us-multi.appraisal.2026-Q4-approved rule set (360 rules, effective 2026-10-01, identified by hash sha256:b366cca8e2f1a3b8c9d4e2f1a3b8…). The resulting Decision Record (attached as Exhibit A) is cryptographically sealed with North Star's Ed25519 signing key north-star-prod-2026-Q2 and carries an RFC 3161 timestamp from timestamp.digicert.com. The record can be re-verified offline by anyone holding the public key published at verify.athenanorthstar.com/keys, using the athena-verify CLI. The record witnesses that I evaluated the work file before delivery; it does not, and is not offered as, an attestation that my underlying valuation is correct.

The attorney runs the CLI. The verification passes. They now have mathematical proof of three things: (a) you ran the evaluation, (b) you ran it on that exact work file, (c) you ran it on that exact date against that exact rule set. Each of those is independently verifiable without trusting you, and without trusting us.

The last sentence of your declaration is the framing that keeps you safe. The seal proves you did the work; it does not pretend to be a valuation second opinion.

Technical FAQ

Can you back-date a record?

No. The RFC 3161 timestamp is counter-signed by an independent third-party TSA. We can't control its clock or its signature. Any record's timestamp can be cross-checked against the TSA's public key.

What if North Star goes out of business?

Every record sealed during our existence stays verifiable indefinitely. Anyone with the record file and the public key (both freely available) can re-derive the seal using the verifier CLI. We deliberately built the verification path to not require our infrastructure.

What if your signing key is compromised?

We rotate signing keys on a quarterly schedule. If a key is ever compromised, we publish the compromise date and you can verify whether your record was sealed before or after. Each key's effective-from / effective-until window is published alongside the key itself. Records sealed with a compromised key during its valid window remain trustworthy; records dated after compromise do not.

Why Ed25519 instead of RSA?

Ed25519 signatures are smaller (64 bytes vs RSA-2048's 256 bytes), faster to verify, deterministic (no per-signature randomness to mismanage), and resistant to side-channel attacks that affect some RSA implementations. It is the recommended signature algorithm for new systems per NIST SP 800-186.

Why CBOR over JSON for canonical form?

JSON has many valid serializations of the same logical object — whitespace, key ordering, number formatting. We need exactly one byte sequence for a given record so the hash is deterministic. RFC 8949 (deterministic CBOR) gives us that without inventing a custom canonical-JSON encoder.

Can I export records into our firm's permanent storage?

Yes. Records are JSON files. Download them, store them in your firm's records system, attach them to assignment work files, or archive them however your retention policy requires. They remain verifiable from any storage location.

What's in the verifier?

A small, focused, open-source Rust binary that does exactly one thing: re-derive the seal from a Decision Record and a public key, and compare. We publish the verifier's source so anyone can read it — regulators, auditors, opposing counsel, curious engineers. The cryptographic primitives (SHA-256, Ed25519, RFC 3161, deterministic CBOR) are industry standards, so a skeptic can also write their own implementation from the data-format spec and get the same result.

The verifier is the only part of our codebase that's open. The engine, the rule library, and the application stay proprietary. We open-sourced the verifier specifically because the “you don't have to trust us” story needs the verification math to be independently inspectable.

What does “chain continuity” mean in practice?

Each Decision Record carries the hash of the immediately-prior record in the same tenant's chain. If you have records #100, #101, and #102, and someone alters #100, the predecessor hash recorded in #101 no longer matches #100's new hash, so #101's verify fails. The same cascade hits #102. You cannot rewrite history selectively.

The plain-English summary

You submitted a work file. We ran our published rules against it on the date and time shown. The cryptographic seal proves we did exactly that, with exactly that content, against exactly those rules. It is a tamper-evident record of the evaluation event. It is not — and must not be presented as — a third-party attestation that the appraisal itself is accurate.

That sentence is the framing. Use it in declarations, in carrier correspondence, in workfile notes, anywhere you reference the Decision Record. We use it on our own pages, in the report PDF, in the offline-verify output, and in our Terms of Service.

Ready when you are.

We're rolling out to Washington and Oregon appraisers first. Join the waitlist and we'll reach out as soon as the platform is open for accounts.

Join the waitlist