Tokenisation

Typed, deterministic, reversible. The primitive everything else builds on.

Typed: the class survives

A Salus token is the entity label, an underscore and six lowercase letters: PERSON_kxmrqa, IBAN_hwtdmp, PHONE_qzvtrn. The external model knows it is looking at a person, an account, a phone number. It just does not know which one. For most tasks that is all the reasoning needs: summarise the complaint, draft the reply, classify the ticket.

Deterministic: relationships are preserved

The six letters are derived from a keyed hash of the tenant, the context, the class and the normalised value. Within a context the same subscriber number produces the same token throughout the workload the context represents: a conversation, a document, a batch job. If a customer appears five times in a support thread, the model sees the same token five times and can connect the references exactly as it would with the real value.

Normalisation folds case, whitespace and Turkish diacritics, so “AYŞE DEMİR” and “Ayşe Demir” are one entity with one token. A bare surname is linked to the one full name in the same text that contains it.

Across unrelated contexts, and across tenants, the same value gets different tokens. That is a privacy property: a token from one case tells you nothing about another.

Reversible: the vault closes the loop

The token-to-value mapping is held in a PostgreSQL store you run. Each row holds a hash of the value, the token, the value encrypted with AES-256-GCM under your vault key, and a flag saying whether the value may be restored. When the provider’s answer comes back containing tokens, a restore call looks them up in the same context and puts the original values back, inside your perimeter.

The vault is deliberately the most sensitive asset in the system, which is why it lives on your infrastructure, under your key, with no vendor access path. See Vault.

What tokenisation costs the model

The model loses the value itself. Operations that need the real characters degrade: arithmetic on a tokenised amount, validating a checksum, spell-checking a name. Three things bound this in practice.

  1. Only sensitive classes are tokenised. Amounts, dates that are not birth dates, and ordinary text pass through untouched.
  2. Agent workloads compute inside anyway. Tools run inside your perimeter on restored values; only the reasoning trace crosses the boundary, tokenised.
  3. Format-preserving mode exists for the rest. Where a pipeline needs a value of the right shape, FPE mode replaces an identity number with another valid-looking identity number instead of a token. See Contexts and restore.

All example values in this documentation are synthetic.