Not found vs could not evaluate

DROP’s response file has four status codes: 2 exempt, 3 deleted, 4 opted out, 5 not found. A record your export could not check — a component field missing or unreadable — reports 5 exactly like a record that was checked and did not match. Two facts, one code. Keep them apart, or a broken export looks identical to clean data.

Why the code cannot tell you

Two of the six DROP list types are composites. NDZ hashes first name, last name, date of birth and ZIP; NameVIN hashes first name, last name and VIN. Each component is standardized and hashed on its own, and the composite is a hash of those hashes in a fixed order. A record with no ZIP has no ZIP hash, so it has no NDZ hash, so no NDZ work item can be evaluated against it — not “evaluated and found not to match”, but never evaluated at all.

The same applies to the single-field types when the field is missing or fails its length rule: a MAID that is not 32 characters, a VIN that is not 17, a CTVID outside 8 to 32. Nothing to hash means nothing to compare.

The response file has no code for that. Its four values (the published list) describe what you did with a match, or that there was none; nothing in the format says “I could not look”. So the file is correct to report 5 for those work items. The loss is not on the wire. It happens earlier, inside your own process, if the two states are merged before anything is written down.

The file is right to say 5. What goes missing is your own record of which 5s were ever checked.

The common causes are export artifacts

In practice the records that cannot be evaluated are rarely exotic. They are shapes an export produces:

• a column mapped to the wrong field, so the value under “ZIP” is a date or a phone number;
• a date of birth in a format other than the one the parser was told to expect — 04/07/1985 read as day-month when it was month-day, or a two-digit year with no century;
• ZIPs stored blank or as 0, which standardize to nothing and are reported as could not evaluate — unlike a placeholder such as N/A, which standardizes to na, hashes cleanly and matches no one: a 5 that was never really checked, and the quieter failure;
• a nine-digit ZIP+4 exported without its hyphen, a shape the published rules give no vector for, so how it splits is a choice you confirm rather than an outcome you assume.

Every one of these is fixable in the export or at the mapping. Fixing them changes what the next run matches: a record that had no NDZ hash now has one, and a work item that reported 5 last cycle can match this cycle. The same file, two rows, two different facts:

Id,Status
7f3a…,5   ← checked, no match
9c1e…,5   ← never checked: no ZIP in the export

Both rows are valid. Only one of them tells you anything.

Two buckets, not one

“Could not evaluate” is itself two states, and they have different repairs.

• Missing component. The field is absent — an empty cell, or no column mapped to it at all. The fix is the mapping or the export.
• Present but malformed. A value exists but standardization fails on it: a date that does not parse under the declared format, a MAID of the wrong length, a name that transliterates to nothing. The fix is the data, or the format you declared for it.

Both report 5 on the wire. Recording which one it was is what turns a count into a lead.

Where to catch it: at mapping, before matching

Standardization is the moment a record either yields a hash or does not, so coverage — per list type, how many records yielded a hash and how many did not, with the failing component named — is computable right there, before any comparison runs. That is also the cheap window: swapping a column or re-exporting costs minutes; a gap found after the response file is filed is found a cycle later, if at all.

One gate, and everything after it is display. A second acknowledgment at confirmation time would re-attest the same fact, and a mandatory checkbox on every cycle trains a reflex rather than a decision.

And no threshold. Any non-zero count is a warning, because a “low coverage” cut-off re-silences every gap that falls below it — which is the original problem, moved.

What to keep for the record

Keep the per-list-type coverage figures next to the code-5 count. With them, a 5 reads as “checked against the records that could be checked; no match”. Without them, it can later be read as “no match across all our records”, which is a larger claim than the run made.

Phrase the record as what it shows — how many records were evaluable for each list type, and how many were not — rather than as a conclusion about the data. A coverage figure is a fact about one run of one export.

How DROPAttest does it

Coverage is evaluated in the browser at the column-mapping step, per list type, before matching runs. Any non-zero could-not-evaluate count surfaces as a warning that must be acknowledged before matching is enabled, and the acknowledged figures ride into the cycle’s confirmed audit entry alongside the determinations, so the count and its context are recorded together. “Could not evaluate” is a state the software reports about what it could hash from the export in front of it — not a statement about the data behind it.

The regulator’s pages for brokers are the DROP for data brokers overview and the working-with-data specification, which lists the list types, the standardization rules and the four status codes.