Why streaming is the hard part#
Modern providers stream answers token by token, and users expect text to appear immediately. A restore step that buffered the whole response would turn every chat into a wait. The Salus restore pipeline works inline instead: it holds back only a small window of the stream — enough to recognize a Salus token even when the provider's chunking splits it in half — resolves the mapping, and releases restored text continuously. The stream stays live; the added delay is a bounded hold-back, not a full-response buffer.
This is also why the engine sits in the response path architecturally: something with vault access has to see the stream before the caller does, or restoration cannot happen at all.
Restore is an authorization, not a find-and-replace#
Each lookup passes through policy before the value is released: is this caller allowed to receive this data class, in this workflow, at this time? Classes can be marked restore-always, restore-with-approval, or never-restore — in the last case the token itself is delivered, deliberately. The result is that "reversible" means reversible for authorized paths, with every reversal audited.
When restoration cannot happen#
If the vault is unreachable or a mapping is missing, the default is conservative: a response marked for restore is held, and the caller sees a visible failure rather than an answer with unresolved tokens standing in for values it was promised. Behavior is configurable per data class — a low-risk surface can be allowed to deliver-with-tokens plus an alert — but the principle stands: open never means raw, and silent substitution failures are not an option.