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.