Reading a Decision Record for the first time

If you’ve never opened a sealed Decision Record before, the first thing you’ll notice is that it doesn’t look like an appraisal report. It looks like a structured data file — a few dozen fields, some long hexadecimal strings, a timestamp, a signature. It’s not designed for human reading the way a URAR or a 1004D is. It’s designed for verification — for a downstream reader to confirm, mathematically, that the evaluation happened the way the record says it did.

That distinction matters, so let me walk you through what’s actually in the record and what it means in practical terms.

The submission summary

The first block tells you what was evaluated. Subject property address, assignment type, lender, AMC, the effective date of the appraisal. Nothing surprising here. This is the same information that would be on Page 1 of the URAR itself.

The findings list

This is the part that takes some getting used to. Each rule in our catalog that fired on the evaluation is listed with:

• The rule identifier (something like WA-RCW-18.140-140-CREDENTIAL-NUMBER-IN-REPORT)
• The citation (the underlying statute, administrative code, or handbook section)
• The severity (critical, material, or advisory)
• The finding text (what the evaluator concluded, in plain English)

If a rule passed, it’s listed too — not just the failures. That’s intentional. Reviewers want to see what was checked AND what wasn’t, not just what fell over. A clean report has zero failures and the full list of rules that fired and passed.

The rule-set hash

This is one of the more important fields and it’s easy to overlook. It’s a long hex string that uniquely identifies which version of the rule library was in force when your report was evaluated. Six months from now, when North Star has added more rules to the library, the hash will be different. But the hash on your Decision Record will still point to the exact rule set the report was checked against. That means a reviewer can look at your record and verify “yes, this report was evaluated against rule-set version X-Y-Z, here’s exactly what was in that version.” No drift, no ambiguity.

The signature and timestamp

Two long hex strings near the bottom. The first is the cryptographic signature — the proof that the record was created by North Star and hasn’t been altered since. The second is an independent RFC 3161 timestamp from an external timestamping authority that countersigns “this record existed at this exact moment.” Neither of these is signed by you, and neither needs to be. They’re our seal on the evaluation event.

What the record actually proves

This is where the framing gets careful. A verified Decision Record proves four things:

1. What was evaluated. The hash of the work file you submitted is in the record. If anyone later tries to claim you submitted a different file, the hash won’t match.
2. When the evaluation happened. The RFC 3161 timestamp gives you a court-defensible moment in time.
3. What rule set was applied. The rule-set hash pins which exact version of our library ran on your file.
4. What the findings were. The findings list is in the record, signed and timestamped along with everything else.

It does not prove that the underlying appraisal is correct. It doesn’t prove the value opinion is right, or that the comps were the best available, or that the adjustments are defensible. Those are still your professional judgment. What the record proves is that an evaluation event happened, that we evaluated this specific file against this specific rule set at this specific moment, and that the findings were as listed. Reviewers years later can re-verify all of that against a freely-available public key.

That’s a narrower claim than some compliance products make, and it’s a narrower claim on purpose. We’d rather tell you exactly what the cryptography proves and exactly what it doesn’t than overstate the seal and lose your trust the first time the distinction matters.

What to do with one in practice

A few practical notes from working with Decision Records day-to-day:

• Keep the JSON file. It’s the artifact. The PDF Evaluation Report is for humans; the JSON is for verification. Anyone who needs to verify your seal will need the JSON.
• Note the signing key id. It’s the field labeled signing_key_id in the record. If you’re ever in a verification conversation years out, you’ll want to point the verifier at the matching public key. The key id makes that one-step.
• Forward records confidently. A reviewer or lender asking to verify your work can do it themselves with the JSON file plus the public key from our registry. You don’t need to be in the middle of that conversation. The whole point of the audit chain is that you don’t have to mediate trust.

The Decision Record is the part of our product I’m most proud of, because it’s the part that does what compliance tools usually fail to do: it doesn’t ask you to trust the vendor. The math does the trusting. Open the file, look at it once, and you’ll see what I mean.