Detection rules & limits
Honest evidence requires honest limits. This is what detection does, how, and (just as important) what it does not guarantee. Reports link here so coverage is never overstated.
How detection works
Detection is column-aware: each column or field is classified by combining signals: the header/key name, a value validator, the value distribution, and surrounding context. The unit is the column, not a stray regex match, which is what makes it work on structured exports rather than just prose.
- Strong (checksum-backed): credit cards (Luhn), IBAN (mod-97), US ABA routing. These can classify on value alone.
- Header-assisted: US SSN (structural, no checksum), email, phone. These lean on the column name plus the value pattern.
- Header-only: date of birth. It has no validator at all, so it is found by the column name. A date sitting in a column we cannot recognise will be missed.
- Per-cell backstop: during a scrub, strong validators run on every cell (even in columns classified "clean"), so an outlier identifier is surfaced, not silently passed.
What it biases toward
The existential risk for a scrubber is a false negative: missed PII reported as clean. PrivHaven biases toward surfacing over silently passing: anything low-confidence, identifier-like-but-unknown, or free-text-suspect is flagged for your review and raises the report's risk score, rather than being quietly dropped.
What it does NOT guarantee
- Names and free-text PII. Identifiers embedded in prose (a name in a "notes" column) are not guaranteed without a separate NER pass, which the MVP does not perform. Such columns are flagged for manual review, never auto-cleared.
- Unlisted identifier types and locale-specific formats outside the ruleset.
- Context. Whether a detected value is actually sensitive in your setting is a judgment only you can make.
Overstating coverage destroys a report's value as evidence; understating it is safe. When in doubt, PrivHaven surfaces.