Architecture boundary
Population loop
New transactions append as events rather than overwriting history. Changed parcel facts create dated snapshots, and comparables expire or are re-scored as evidence changes.
Valuation evidence workflow
Connect recorded transfers, licensed listing data, assessor values, market indexes, property characteristics, and comparable selection into one reviewable valuation evidence workflow.
Representative implementation pattern. Illustrative records, not completed client work or a performance claim. Specialist outputs require appropriate qualified review.
Recorder, assessor, and FHFA references are United States examples. Australian evidence may come from state or territory land-title and Valuer-General sources, licensed sales feeds, and approved market indexes. Public availability, redistribution rights, transaction coverage, terminology, and appraisal requirements differ by jurisdiction; the workflow does not convert an evidence pack into a qualified valuation.
Why this workflow matters
No single source owns every field in a valuation evidence pack. The recorder may own a recorded transfer, the assessor may own parcel attributes, a licensed feed may own listing history, and the analyst owns the selected comparable set and adjustments.
Architecture boundary
New transactions append as events rather than overwriting history. Changed parcel facts create dated snapshots, and comparables expire or are re-scored as evidence changes.
Reference layer
Ownership is assigned field by field rather than forcing one system to own the entire evidence pack.
Recorded property transfers.
Parcel characteristics and assessed value.
Listing and sale details where available.
Broad market index movement.
Underwriting assumptions and approved criteria.
Reference layer
These sources and tools are selected according to authority, permission, technical fit, security, and client ownership.
PostgreSQL/PostGIS with property, transaction, listing, comparable, adjustment, valuation, and source records.
APIs and licensed feeds, plus county downloads or authorized portal retrieval where required.
Geospatial queries, normalized addresses, parcel IDs, and deterministic duplicate rules.
Model-assisted description extraction with Python or SQL calculations.
Map, timeline, comparable table, and sensitivity view.
Cited evidence
Last reviewed 16 July 2026
These direct links support the source and implementation patterns named on this page. Availability, licence, jurisdiction, version, account configuration, and professional-review requirements are confirmed again for each engagement.
Ten-stage operating path
Each stage establishes a distinct decision, record, handoff, or approval boundary. Exceptions remain visible instead of being silently forced through the process.
Identify the subject parcel and effective valuation date.
Load recorded, assessed, listed, and client-supplied facts.
Resolve duplicate addresses, units, parcels, and transfer records.
Filter comparables by geography, property type, size, age, date, and condition.
Score similarity separately from data confidence.
Apply approved analyst rules and visible formulas.
Compare area-level index movement without treating an index as a property appraisal.
Explain the evidence, exclusions, and sensitivity range.
Approve the comparable set and assumptions with a qualified reviewer.
Issue a versioned evidence pack with a complete source trail.
Required data layer
The implementation boundary should name each required record, relationship, source, status, permission, and owner before automation is introduced.
Property
Transaction
Listing Event
Comparable
Adjustment
Valuation Run
Source Evidence
Parcel Characteristics
Market Index Observation
Analyst Approval
Authority, source quality, permissions, uncertainty, and consequential external actions remain explicit throughout the workflow.
Acceptance measures
Acceptance measures test the reliability and governance of the workflow. They are evaluation criteria, not promised performance results.
Workflow diagrams, records, statuses, values, and measures on this page are illustrative unless explicitly identified as verified client work. They do not demonstrate completed delivery or guaranteed performance. The actual implementation depends on the agreed systems, access, data condition, security requirements, ownership, approval rules, and acceptance tests. Named tools are possible components, not required products. Property, planning, tax, valuation, safety, biometric, engineering, and legal outputs require appropriate qualified review.
Typical starting engagement
This is planning guidance for a bounded first implementation, not a quote. The Blueprint confirms systems, access, data condition, responsibilities, exclusions, acceptance, timing, and fixed price.
Workflow assessment
Confirm the current records, sources, permissions, owners, exceptions, approval points, and acceptance measures before selecting automation or AI tools.