THE MAPPING STAYS HOME
Customer-controlled environment
Vault — token ↔ original value

[PHONE_8f3a1d]  ↕  +90 543 417 88 21

held per Context · customer-controlled · replaceable storage
Restoration authority

Restore = the mapping + access authorization + the restore path — all three live here.

tokens → ← response
Outside world
External AI

Sees [PHONE_8f3a1d]. Does not receive the vault, the keys, or any path to the mapping.

The contract#

Each vault entry relates a typed token to the original value it replaced, together with its data class and the Context it belongs to. That mapping is the single piece of information that can turn [PHONE_8f3a1d] back into a phone number — which makes it, deliberately, the most sensitive asset in the system. The design question is not whether such a mapping exists (reversibility requires it) but where it lives and who can use it. The Salus contract is fixed on this point: the mapping lives inside the customer-controlled environment, and no external party — including the AI provider and including Salus, the vendor — has an access path to it.

The current implementation#

Restoration state is held in an in-memory Context Store behind a thin, replaceable storage interface. State is scoped per Context, expires with it, and stays within the process that serves your deployment. This is the profile the current validation architecture runs on: it keeps the entire restoration surface inside one auditable boundary and adds no external storage dependency to a pilot.

The interface is the point: the store behind it can change without the contract moving. Token behavior — assignment, aliasing, expiry — is identical whichever storage sits underneath.

Deployment evolution#

Persistent deployments place the same interface over storage the customer controls and hardens: durable databases under existing backup and recovery practice, encryption at rest under customer key custody, HSM/KMS-held wrapping keys where the security posture requires them. These are deployment decisions layered under the contract, not changes to it — the boundary, the token grammar, and the restoration semantics stay exactly the same.

Retention follows the same pattern: Context expiry is the current mechanism, and per-class retention policy is a deployment-evolution control.

Separation is the point#

The pseudonymization discussion in Tokenization vs. Pseudonymization turns on "additional information kept separately." The vault is that additional information, and its separation is architectural: the external provider operates on the other side of the boundary with no route to it. Deployment choices never move the vault outside the customer-controlled environment — they only change what surrounds it, as covered in Deployment Options.