Guide

This walkthrough assumes you already have an account. If not, see Get started first.

1. Upload a package

From your dashboard, choose a file and select Upload. A package is a single archive (.zip) or an individual data file. The uploaded file's name is shown immediately in your package list, with status Queued.

Supported data formats inside a package: Stata (.dta), SPSS (.sav), SAS (.sas7bdat, .xpt), Matlab (.mat), R (.rds, .rdata), CSV/TSV, Excel (.xls, .xlsx), and OpenDocument Spreadsheet (.ods).

2. What happens after upload

Processing has two phases, both visible in your package status without any action from you:

  1. Extraction and screening. The package is unpacked, duplicate files are identified, and every column of every data file is screened to decide which columns are worth checking. A package that has an unusually large number of candidate columns is rejected outright at this stage, with a clear message stating the count and the configured limit — this happens before any column is sent to the classification model, so you are never billed processing time for a package that will be rejected.
  2. Classification. Each candidate column's values are tabulated and classified. Your dashboard shows live progress as Running — X of Y columns processed… once the total is known.

A package with duplicate files inside it (the same file present more than once) is only classified once per unique file — duplicates are reported against the original automatically.

3. A complete worked example

Suppose you upload wave2_survey.zip, containing one Stata file with a respondent ID, a full-name field, and several coded response columns.

  1. You select the file and upload it. The dashboard shows wave2_survey.zip with status Queued — you're next…
  2. Within moments, the status changes to Running…, then to Running — 2 of 2 columns processed… as the two candidate columns (the name field and the ID field) are classified. The coded response columns were screened out automatically and never reached the classification step, since they aren't PII candidates.
  3. The status changes to Done — 2 column(s) checked, 1 flagged as direct PII.
  4. You select Download results (.xlsx). The report contains one row per checked column — see the sample below and the format description under Methodology.
  5. Satisfied with the report, you leave the job in your list for later reference, or select Delete to remove it and its files immediately.

Reading the report

Each row in the downloaded report corresponds to one column found somewhere in the package:

Column Meaning
file Path of the file the column was found in, relative to the package
sheet Sheet name, for multi-sheet formats (Excel, etc.)
col_name / label The column's variable name and, if present, its descriptive label
n_rows Number of non-missing values in the column
evaluation The classification: direct_pii, possible_indirect, internal_id, or not_pii
reasoning The model's stated reason for that classification
duplicate_of If this file was a duplicate of another file in the package, the original's path

4. Naming a package

By default a package is identified by the file name you uploaded. Select the pencil icon next to a package's name to give it a more memorable label — for example, naming a package after a specific paper or wave of data collection. The name you choose is also used to name the downloaded report file.

5. Cancelling a running job

Select Cancel on a package that is actively running to stop it. Cancellation is cooperative, not instant: the job stops at the next safe checkpoint (after the current file during extraction, or after the current column during classification), typically within moments. A cancelled job produces no report — there is no partial download.

6. Deleting a job

Select Delete on any package to remove its job record and any files still associated with it. Deleting a package that is currently running instead requests cancellation (see above); deleting it again once it has stopped removes it for good.

Limits

Reference deployments enforce a daily package limit per account, a maximum upload size, and a maximum number of candidate columns per package, to keep the service usable for everyone. Exact limits are configurable per installation — check with your administrator, or see the FAQ on the home page, if you are unsure what applies to your account.

Self-hosting

Institutions can run PII Checker on their own infrastructure, including their own model-serving endpoint. See the data policy for what that changes about data handling, and contact us (see contact) for deployment guidance.