A county's property-valuation model joins a parcel table with a separate tax-assessment table using a parcel ID. Some parcel IDs in the assessment table don't correspond to any parcel in the parcel table, likely due to an upstream data-entry error. Which check would catch this before the join corrupts the training set?

Mechanism: a referential-integrity check validates that every parcel ID appearing in the assessment table actually exists as a real parcel in the parcel table, catching orphaned foreign-key references from upstream data-entry errors before the join silently produces unmatched or corrupted rows that could mislead the property-valuation model. Why the wrong options fail by concept: a schema check confirming matching column data types verifies structural compatibility, like ensuring both columns are stored as strings, but it says nothing about whether the actual ID values on one side correspond to real records on the other. Comparing total row counts between the two tables is a coarse sanity check that can't detect this specific problem, a difference in row counts is expected between a parcel table and an assessment table that may have multiple assessments per parcel, and even matching counts wouldn't guarantee the IDs themselves line up. Checking for null values in the parcel ID column catches missing IDs, but the scenario describes IDs that are present and non-null yet simply don't correspond to any real parcel, a different failure mode entirely. Scope caveat: referential-integrity checks only catch IDs that fail to match, they don't validate that a correctly matching ID points to the right parcel if the upstream data-entry error assigned a valid-but-wrong ID. Operational check: run the referential-integrity rule and review the count of orphaned assessment records before allowing the join to proceed into the training dataset.