THE ENGINE PIPELINE — VAULT ALONGSIDE, NOT ANOTHER STEP
1
Input. A request arrives from a person, application, or agent — through the Salus API or captured by Salus Desktop.
2
Detect & envelope. The self-hosted detection stack finds sensitive spans and builds a protection envelope around them — boundary cases are covered, not gambled on.
3
Verify. Candidates are checked before they are trusted — deterministic validators for structured identifiers, verification passes for free-text detections.
4
Resolve identity. Mentions resolve to entities on typed evidence; ambiguity yields a provisional identity rather than a guessed merge.
5
Context & tokens. Each entity carries its typed token — [PHONE_8f3a1d] — inside the Context, the boundary within which identity remains consistent. The mapping is written to the vault.
→
External AI. The tokenized request crosses the boundary; the provider writes its answer around the tokens.
6
Authorized restore. Tokens in the response are resolved against restoration state and restored inside the perimeter, for callers entitled to see the values.
Vault
token ↔ value
mapping
written at token
assignment · read at restore
customer-controlled
in your environment

One contract behind every surface#

The engine is the invariant part of the platform. Both product surfaces implement one protection contract: whether content arrives from an application calling the Salus API, from your AI gateway routing through it, or from Salus Desktop capturing a browser prompt on a managed laptop, it lands in the same conceptual pipeline — detect → envelope → verify → resolve identity → Context and token assignment → egress → authorized restore. That is why the token grammar, the Context semantics, and the fail-closed defaults are the same wherever traffic enters.

The components#

  • Engine service — receives content from both paths and orchestrates the pipeline end to end. The current profile runs as a single self-hosted service; scaling wider is a deployment-evolution step behind the same API.
  • Detection stack — the self-hosted detection models for free text, deterministic validators for structured identifiers, and optional visual detection for documents and images. Runs entirely inside the customer environment.
  • Identity resolution — evidence-based entity resolution inside a Context. Typed evidence establishes identity; ambiguous evidence yields a provisional identity rather than a guessed merge, and identities converge as evidence accumulates.
  • Tokenizer — typed, deterministic, HMAC-backed token generation scoped to the Context, as described in Tokenization.
  • Vault — restoration state, held per Context inside your environment behind a replaceable storage interface. Covered in Vault.
  • Dictionary, treatment, and evidence — part of the Salus product contract: administrators manage a standard and customer-defined data dictionary, assign per-class treatment (stop before egress, replace-and-restore, restoration authorisation), and rely on an evidence record of protection and restoration events. Today, governed classes and failure behavior are configured per deployment with fail-closed defaults; the management and audit surfaces are delivery evolution, being completed toward that contract. By design, the evidence record is metadata- and token-reference-based — never a second store of raw values.

Trust property#

The division of labor is deliberate: the local detection intelligence is allowed to see real values because it runs inside the customer environment; the external answer-writing model cannot see them because it receives tokens only. Everything that can re-identify a token — restoration state, identity evidence, the restore path — stays on the customer side of the boundary.