The platform screens payloads for identifiers it can verify, and reports
what it found and what it did not look for.
Checksums, not shapes
Every family is a checksum. The claim is “this is a valid IBAN and the check
digits agree”, not “this looks like an IBAN”. That is what makes a count on a
screen citable rather than caveated.
The SSN row is the honest one. It carries no checksum, so it is reported as
asserted rather than observed, using the same distinction the rest of the
platform uses.
What is not looked for
Names, addresses and dates of birth in free text carry no checksum, and finding
them requires a model this deployment does not run. Neither are card numbers,
medical record numbers, or national schemes beyond the three listed.A clean screen means no verified identifier was found. It never means the
payload holds no personal data. That sentence is on the artefact as well as
this page.
We detect, we do not tokenise
Some governance platforms substitute personal data with a token and hold the
mapping. RotaGrant does not, and this is a design position rather than a gap.
Tokenising means holding the thing you are protecting. The platform runs
single-tenant inside your environment precisely so that no payload reaches us on
any path, and a tokenisation vault would be a store of exactly the data that
claim is about. Detection tells you an identifier is present and what obligation
attaches to it; substitution would make us custodian of it.
If you need tokenisation, it belongs in your own data layer, before the agent
sees the value.
What attaches to a finding
Each family carries the obligation that follows from it rather than just a
label. An IBAN is a financial identifier: erasure under GDPR Art. 17 reaches it,
and retention is usually set by financial regulation rather than by data
protection law. Those two clocks differ, and a screen that reported “PII found”
would have told you nothing about which one applies. 
