The audit chain

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

When you seal a workfile in North Star, it 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 honestly 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 workfile, 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.

What the seal attests: side by side

The Decision Record is sealed in Assemble, when you seal a workfile you built inside North Star. These are the six things that seal attests, and the six things it intentionally does not. The framing is consistent everywhere North Star surfaces a sealed record — in the web UI, in the offline-verify output, and in our Terms of Service.

Evaluate (the $25 check for a finished report) does not seal anything — it returns findings and an Evaluation Report you act on, with no permanent record to verify. Everything on this page is about the Assemble seal.

What the seal attests

  • The exact bytes you submitted. The SHA-256 hash of your canonical workfile. Any change to the JSON — even a whitespace difference — produces a different hash.
  • The exact moment it was sealed. The seal time is recorded in the record and bound into the hash chain, so a record can't be quietly reordered or re-dated after the fact.
  • 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. An ECDSA P-256 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 workfile 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 Assemble extension: Custodial Provenance Witness

At its core, the Assemble seal is an Evaluation Event Witness — it attests what we ran rules against, when, and with what result.

But because we witnessed every source as it entered the workfile — engagement letters you bring in from email, photos from the inspection, sketches and voice notes from the field — the same Decision Record is also a Custodial Provenance Witness. It can attest substantially more about the evidence behind the workfile.

What the Assemble seal additionally attests

  • The source of every input. Each file that enters the workfile — an email, an uploaded document, a photo, a field capture — is hashed and recorded the moment it arrives, so its origin is witnessed.
  • The timestamp of every input. Photo at 10:14 AM, voice note at 11:02 AM, sketch finalized at 2:34 PM. Each capture is witnessed the moment it arrives — its bytes hashed and its arrival recorded.
  • Photo and capture integrity. Each photo, sketch, and field capture is hash-witnessed the moment it arrives, so a later-altered version no longer matches the sealed record.

What the Assemble 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 a comparable-sale figure was wrong upstream, the chain proves the workfile recorded the figure as it was supplied — 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 SHA-256, ECDSA P-256, and JCS-canonicalized JSON (RFC 8785). The Assemble seal just has more to attest, because we witnessed the inputs. See the Assemble page for the full custodial walkthrough.

What's inside the seal

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

{
  "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",
  "predecessor_hash":    "sha256:c8d4e2f1a3b8c9d4e2f1a3b8c9d4...",
  "public_key_id":       "northstar-prod-2026-Q3",
  "signature":           "3045022100f3b7e9c2a4d6f8e0b1c3d5e7f9a1..."
}

The signature is bare hex, with no algorithm prefix. An ECDSA P-256 signature is DER-encoded and runs about 70 bytes; an Ed25519 signature is exactly 64. Their lengths tell them apart, which is why the record format never needed a tag.

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: ECDSA P-256 (FIPS 186-4). Elliptic-curve digital signature on the NIST P-256 curve (secp256r1), with keys held in AWS KMS so the private key never leaves the hardware security module. Compact, fast to verify, and supported by standard crypto libraries.
  • Timestamp. The seal records the time it was created and binds it into the hash chain, so records can't be quietly reordered or re-dated after the fact.
  • Canonical form: JCS-canonicalized JSON (RFC 8785). JSON has many valid serializations of the same logical object (whitespace, key ordering, etc.). JCS specifies exactly one, so two independent verifiers serializing the same logical record produce byte-identical canonical bytes — the input the hash and signature are computed over.

How to re-verify, independently

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.

Open the browser verifier at verify.athenanorthstar.com and drop in your Decision Record. There's nothing to install and no account to create. The verifier runs entirely in your browser — your record file never leaves your machine — and checks it against the published public-key registry.

It reports one line per check:

trust_anchor     OK  (record's public_key_id is on the registry; published key matches)
record_hash      OK  (SHA-256 of JCS-canonicalized canonical block matches)
signature        OK  (ECDSA P-256 verified with the pinned registered key)
trace_hash       OK  (SHA-256 of JCS-canonicalized trace matches)
chain            OK  (predecessor hash matches)
=> verified: true

If any of those five lines comes back FAIL, the record has been altered, the signature is wrong, the trust-anchor check rejected the signing key, or the chain has been broken upstream of the record you're checking. The verifier shows which line failed and why.

The authoritative public-key registry is served as JSON at /v1/audit/public-keys (no auth required). Each registered key id is the canonical trust anchor for records that carry that id in their public_key_id field. Because the record format and primitives are open standards, an auditor can re-implement the check independently.

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 browser verifier at verify.athenanorthstar.com — no download, no account, and your record never leaves your browser.

Your declaration looks like this:

On 2026-04-15 at 14:22 UTC, I sealed the attached workfile in Athena Systems North Star, having checked it against the us-multi.appraisal.2026-Q4-approved rule set (407 rules, identified by hash sha256:b366cca8e2f1a3b8c9d4e2f1a3b8…). The resulting Decision Record (attached as Exhibit A) is cryptographically sealed with North Star's ECDSA P-256 signing key northstar-prod-2026-Q3, and records the time it was sealed, bound into the audit chain. The record can be re-verified by anyone, with no account, using the browser verifier at verify.athenanorthstar.com against the published public-key registry. The record witnesses that I checked and sealed the workfile before delivery; it does not, and is not offered as, an attestation that my underlying valuation is correct.

The attorney opens the browser verifier and drops in the record. The verification passes. They now have mathematical proof of three things: (a) you ran the evaluation, (b) you ran it on that exact workfile, (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?

Each record carries the time it was sealed and binds it into the hash chain, and every record links to the one before it. Slipping a record in earlier, or re-dating one after the fact, breaks the chain at the next verify — so the ordering can't be quietly rewritten.

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 browser verifier — or their own implementation of it. 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 ECDSA P-256 instead of RSA?

ECDSA on the NIST P-256 curve (FIPS 186-4) gives compact signatures and fast verification, and it's supported directly by AWS KMS — so our production signing key lives in a hardware security module and the private key never leaves it. An RSA-2048 signature is four times the size for no added assurance at this security level.

Why JCS-canonicalized 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. JCS (RFC 8785, JSON Canonicalization Scheme) specifies exactly that. We picked it over CBOR because the records stay human-readable JSON at rest, so an auditor can inspect a record in any text editor and the verifier re-canonicalizes the same bytes for the hash.

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 workfiles, or archive them however your retention policy requires. They remain verifiable from any storage location.

What's in the verifier?

A small, focused verifier that does exactly one thing: re-derive the seal from a Decision Record and a public key, and compare. It runs entirely in your browser at verify.athenanorthstar.com — your record file never leaves your machine. The cryptographic primitives (SHA-256, ECDSA P-256, JCS-canonicalized JSON) are industry standards, so a skeptic can write their own implementation from the data-format spec and get the same result.

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 built and sealed a workfile. 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 Evaluation Report PDF, in the offline-verify output, and in our Terms of Service.

Ready when you are.

North Star covers Washington and Oregon appraisers today. Create an account and start your first assignment whenever you're ready.

Sign up