Architecture
The path a request takes.
TrustLayer is not a box but a chain of steps in a fixed order. That order lives in the orchestrator; skipping a step from your application code is not possible.
- Steps
- 9
- Phases
- 2
- Can block
- 5
- Timed stages
- 6
Explorer
Inspect the steps one at a time.
Click a step to see what it does, whether it can stop the request, and what it writes to the audit log. Then switch the scenario to “blocked”.
Inbound: before it reaches a model
Outbound: before it reaches the user
Mask
can stop the requestPersonal data is caught and swapped for synthetic values. Both detection and action go through one approved surface; a lint rule prevents a second path from ever opening.
- class
- MaskStep
- timer key
- pii_mask
Click a step to select it; switch the scenario and you can see that everything after the block never runs.
The way back
The real work starts after the model call.
Before the answer reaches the user it passes this chain:
detokenize/unmask -> sanitize -> [VERIFY] -> authorised KB de-masking -> strip -> own PII
Why does the judge sit in the middle?
The outbound chain is deliberately split into two phases. Verification runs after the text is sanitised but before knowledge-base values are written back for an entitled user. So the judge never sees the raw values only that person is allowed to see; verification does not become a second place data can leak from.
Measurement
Each step is timed separately.
These keys are what the timings object on an audit event contains. “The answer took 1200 ms” is not enough; where that time went has to be visible.
| timer key | step | |
|---|---|---|
pii_mask | Mask | MaskStep |
shield | Prompt Shield | ShieldStep |
policy | Policy | PolicyStep |
rag_search | Retrieve | RetrieveStep |
llm | Dispatch | DispatchStep |
judge | Verify | VerifyStep |
See it with your own data.
In a technical session we run your prompts and your policy through it live.