Provenance & data quality

Every field answers where it came from, when it was true, and how much to trust it.

The provenance object

Core entity records (counties, taxing units, collectors, districts) embed a provenance object; parcel detail joins run-level provenance from the ingestion run that loaded it.

provenance

{
  "source_id": "…uuid of the source…",
  "source_record_ref": "…row reference in the source…",
  "as_of": "2026-07-25",
  "verified_at": "2026-07-25T14:02:11Z",
  "verification_method": "published",
  "confidence": "published"
}

confidence is one of published (straight from the source), derived (computed, e.g. spatial joins) or curated (human-verified research).

Data-quality rules the API follows

Conflicts are logged, never silently resolved. When two sources disagree, both facts are kept and the conflict is reported.
Null means unresolved, not missing. A taxing-unit code that could not be resolved stays null — it is never guessed or dropped.
Values carry status. value_status distinguishes preliminary, certified and supplemented rolls. "No notice issued" is a distinct state from "notice value unknown".
History is archived on receipt. Certified values change year-round via supplements; every value row carries as_of.
Restricted records are legally absent (§25.025/§25.026), not missing — they are never inferred.

Situs vs owner mailing address

Notices go to the owner mailing address; the situs address is the property location. They diverge constantly on commercial property — the API stores both, separately (situs/situs_city/situs_zip vs owner_mailing).

Refresh calendar reality

Texas property tax has a yearly rhythm (notices Apr–May, certification ~Jul 25, rate adoption Aug–Sept, bills Oct). The data reflects that rhythm — check as_of before relying on a value mid-cycle.