A county wants every parcel ID to match an established cadastral pattern. Which family of data quality rules does this requirement represent?
Select an answer to reveal the explanation.
Short Explanation
Pattern rules are the ID badge checker—'does this look like a real parcel ID?' Format and correctness rules encode what 'valid' means for the domain. Matching the cadastral pattern is that kind of rule, not a freshness check.
Full Explanation
Correctness and format-style rules validate values against expected patterns, domains, or reference formats used in cadastral operations. A county requirement that every parcel ID match an established cadastral pattern is therefore a correctness or format-style rule, not a timeliness check or a dashboard aesthetics preference. A timeliness rule that only checks overnight load completion times does not verify whether identifiers conform to the cadastral pattern the assessor and GIS teams rely on. A uniqueness rule that forbids any two parcels from sharing a street name addresses a different concept—identity cardinality of addresses—and may even be business-false in dense blocks. A usability rule about whether analysts like dashboard colors is unrelated to cadastral identifiers and does not protect joins to tax or permitting systems. Exam caveat: pattern rules should be versioned with the cadastral standard; overly rigid patterns can reject legitimate legacy exceptions that need stewarded overrides rather than silent mass rejection. Operational check: encode the official parcel-ID regex or check-digit rule, measure fail rate on the current extract, quarantine failures, and escalate pattern exceptions to the assessor steward before the next tax cycle. Civic GIS and finance integrations should reject nonconforming IDs at API boundaries so bad keys never enter billing, noticing, or public open-data extracts.