> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rotascale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Personal data

> Eleven checksummed identifier families, verified rather than pattern-matched. We detect and do not tokenise, and the difference is deliberate.

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.

| Family                            | How it is verified                                  |
| --------------------------------- | --------------------------------------------------- |
| Bank account (IBAN)               | mod-97 over the rearranged string                   |
| EU VAT number                     | per-state check digit where the state publishes one |
| National identifier (PL, BE, NO)  | scheme-specific weighted checksum                   |
| US Social Security Number         | structural rules only, reported as **asserted**     |
| US bank routing number            | ABA weighted checksum                               |
| US Employer Identification Number | issued prefix set                                   |
| Singapore NRIC/FIN                | weighted sum, prefix-dependent check letter         |
| Singapore UEN                     | entity-type check letter                            |
| Australian Tax File Number        | ATO weighted modulus                                |
| Australian Business Number        | modulus 89 after the documented subtraction         |
| Australian Medicare number        | weighted check digit                                |

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

<Warning>
  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.
</Warning>

## 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.