How it works · in depth
Auto-detectSix detectors, and the check behind each.
A permissive expression finds candidates. A structural validator decides which of them are real. The validator is the entire reason this feature is worth shipping, so here is each one by name.
The six
| Detector | The validator | Why it matters |
|---|---|---|
| Credit card | Luhn check digit | A bare sixteen-digit expression matches order numbers, tracking codes and invoice IDs on nearly every business document. The check digit is what turns a digit-finder into a card detector. |
| IBAN | ISO 13616 mod-97 | Rotate the first four characters to the end, map letters to numbers, and the value mod 97 must equal 1. |
| Social Security number | The SSA's structural rules | Area is never 000, 666, or 900–999; group is never 00; serial is never 0000. |
| Email address | The expression is the whole test | Said rather than hidden: there is no structural check behind this one. |
| Phone number | The expression is the whole test | Locale-dependent, so it stays over-inclusive on purpose — and every match is reviewed before anything is written. |
| Date | The expression is the whole test | Off by default. Dates match every letterhead and footer, and a detector that cries wolf gets switched off — which costs more than the detector was worth. |
Driven on a real document, that difference is visible in a sentence: the card offered the valid Social Security number and not the one whose area is 000, the Luhn-valid card and not the order number sitting a line below it, the real IBAN and not the string of letters shaped like one.
Six named detectors, each with a stated check. Not “finds personal information”, not a recall rate, not a longer list next release without this page changing first.
It proposes rules. It never edits.
The sweep produces a card, not an edit. Accepting fills in the rules sidebar, and those matches then go through the same per-match review as a rule you typed yourself — same sentences, same checkboxes, same refusal if the document's matches drift before you run it.
The card says what it found, by kind — and says that adding them writes nothing.
Why the count on the card is the count the rules deliver
The sweep runs one matching pass per page over the whole rule list — including the rules you already wrote — rather than counting each detector on its own. Overlap is resolved across all of them at once, which matters because counting a detector in isolation promises matches that acceptance then loses to a neighbouring rule. The number you see is the number the rules will actually deliver.
For the same reason, a rule you already typed suppresses the
proposal that would duplicate it. A document already ruled for
415-555-0142 gets no phone proposal, because that proposal
would find nothing left to find.
The card says what it does not know
A sweep still running, a sweep that stopped, and a page nothing could read are all stated on the card in those words rather than quietly rolled into a total. A floor presented as a total is the same overclaim as an unchecked category reported clean.
The sweep runs once, on open. Editing rules afterwards does not re-propose, and accepting cancels a sweep still in flight — which is exactly what keeps the counts true rather than approximate.
What auto-detect is not
- It is not a way to skip the review. Proposals become rules, and rules go through the same review list as everything else.
- It is not a claim of completeness. Six detectors will not find a name, a case number, a licence plate, or an address — those are what rules and rectangles are for.
- It does not run on a schedule, a folder watch, or a server. It runs when you open a document, on your device.
Whatever the detectors propose, the receipt still reports what was actually found in the file that was written.
See launch details