How to read a validation report

A validation report is a to-do list in disguise, and a good one tells you four things about every item: how bad it is, exactly which rule you hit, where in the report to go, and which property it's about. Read those four in order and a wall of findings turns into an afternoon of fixes.

728

Total published H-1 edits

592

Fatal — block UCDP submission

136

Warning — flagged, not blocking

4

Things every finding tells you

Severity: Fatal is a wall, Warning is a flag

Of the 728 published edits, 592 are Fatal and 136 are Warning. Fatal blocks the file at UCDP — none of these are optional; every one must go before you deliver. Warnings don't block, but a human reviewer still sees them, and a report that's clean of warnings is a report nobody sends back with questions. Fix all Fatals, then clear Warnings if the schedule allows.

The message ID is your anchor — memorize a few

Every finding carries a stable ID like UAD1229. It's the same ID the whole industry uses, so it's searchable, it's what you paste to a colleague, and it links straight to the rule with its trigger, its Field ID, and a real example. The dozen or so IDs you hit most (address, estate type, living units, site value) become muscle memory fast.

Location speaks the form's language, not the data's

A finding points you to "Reconciliation › Appraisal Summary › Opinion of Market Value" and a Field ID — not to a MISMO xPath. That's deliberate: the appraiser navigating to the fix shouldn't have to read XML. The Field ID (the red number on the form) is the fastest way to land on the exact spot.

The use-type tag tells you which property

When the same field appears on the subject and five comparables, "address is malformed" isn't actionable — "address is malformed on the SubjectProperty" is. Every finding carries the role tag, so you go to the right property the first time instead of checking all six.