Methodology

Detection approach

PII Checker does not attempt to detect PII by pattern-matching values directly against every file in a package. Instead it works in two stages:

Candidate screening. Every column of every supported file is evaluated against rule-based criteria — data type, cardinality, string length, whether values resemble coordinates, and similar structural signals — to decide whether a column is plausibly PII-bearing at all. This step is deterministic and does not use a language model; the large majority of columns in a typical dataset (numeric codes, indices, categorical responses) are screened out here and never reach classification.

Model classification. Columns that pass screening have their values tabulated — a compact summary of the distinct values present and their frequency, not the raw column — and this tabulation, together with the column's name and label, is given to a language model with instructions to classify it into one of four categories:

• direct_pii — directly identifies an individual (names, email addresses, phone numbers, precise locations, IP addresses)
• internal_id — a unique identifier linking to external records (respondent ID, household ID, case number) without being human-identifying on its own
• possible_indirect — could contribute to identifying an individual in combination with other data (fine-grained geography, detailed demographic characteristics, rare occupations)
• not_pii — categorical, coded, or otherwise non-identifying

A column identified by name/label pattern as a likely crowdsourcing-platform participant ID (for example, a Prolific or MTurk identifier) is checked against that possibility specifically before falling through to the general classification above.

Model and prompting

Classification is performed by a large language model, given the column's name, label, row count, and value tabulation, and asked to return a category and a stated reason. The reasoning text returned by the model is included in the downloaded report so a reviewer can see why a column was flagged, rather than only the label.

Limitations

• Classification is model-based and probabilistic; it is a screening aid, not a certification. Reviewers should treat flagged columns as findings to check, not a substitute for review.
• A column can only be evaluated on the information available to the model — its name, label, and observed values. Context that would change the correct classification (for example, a code column that maps to identifying values in a codebook not included in the package) is not visible to the tool.
• Detection quality depends on column naming and labeling conventions in the source file; an unlabeled, cryptically-named column is harder to classify correctly than a well-documented one.

Candidate-count limit

A package with an unusually large number of candidate columns is rejected before classification begins, rather than partially processed. This is a deliberate design choice, not a technical ceiling on accuracy — see the guide for what this looks like in practice.