Security · Privacy · Deployment
Triodian instruments decision streams without requiring member data, prompts, or outputs to leave your environment. What crosses the boundary is evidence about compliance, hashes, tokens, and aggregate measurements, never the decisions themselves.
What leaves, what stays
Raw prompts and model outputs; member, customer and employee data; the decisions themselves; the constraint envelope in its human-readable form.
Never transmitted · never retained by Triodian
Embeddings and semantic representations used for divergence measurement; aggregate statistics over the decision stream; the provenance ledger.
Your tenancy · your retention policy · exportable on exit
Cryptographic compliance tokens; tamper-evidence hashes; anonymised aggregate compliance metrics where the institution elects external verification.
Evidence about compliance · not the decisions
No Triodian component trains on customer data. Models used for semantic measurement run inside the deployment boundary or in a dedicated single-tenant environment, the institution chooses which at pilot design.
Where it runs
| Model | What it means | Fit |
|---|---|---|
| Inside your boundary | Full stack in the institution's own environment; Triodian supplies software and attestation tooling. | Regulated data, offshore-processing restrictions, APRA-supervised entities. |
| Dedicated single tenant | Isolated environment operated for one institution; contractual data-residency commitments. | Institutions wanting managed operation without shared infrastructure. |
| Shared control plane, local data plane | Measurement runs locally; only tokens and aggregate evidence reach the shared plane. | Lower-sensitivity streams, vendor-model oversight. |
A pilot can begin in any of the three. Data residency (including Australian residency) is a configuration decision, not a roadmap item.
What is enforced, against whom
Strong words like "non-bypassable" are only meaningful relative to a stated attacker. Below is the honest ledger: each assurance tier, the threats it defeats, and the threats that require the tier above it.
| Threat | Software tier | Hardware tier |
|---|---|---|
| Prompt injection / hallucinated tool call | Defeated, Mode B: out-of-set token unemittable | Defeated |
| Model attempting out-of-envelope output | Defeated (Mode B) / measured & routed (Mode A, validating) | Defeated / enforced |
| Compromised orchestration layer | Detected via tamper-evident ledger | Defeated, isolated execution domain |
| Malicious administrator / privileged insider | Not defeated, detectable after the fact via ledger | Defeated, no privileged software path |
| Compromised firmware / physical attacker | Out of scope | Hardware root of trust; residual risk stated in the appliance briefing |
| Alternate action path around the boundary | Out of scope for any tier, see complete mediation below | Same |
Complete mediation
Every guarantee on this page applies only where all meaningful action paths pass through the governed boundary. Any alternative network route, tool, database, filesystem, display or actuation path must be removed or separately controlled. Establishing complete mediation for the selected decision stream is step one of every deployment, and we will tell you if your architecture cannot yet provide it.
The full six-stage enforcement path, including what remains probabilistic and what is deterministic → DGA
Operating controls
Role-based access with institution-held keys.
All Triodian operator actions land in the same tamper-evident ledger the institution's own actions do.
Independent verifier access is grantable by the institution, not by Triodian.
Full export of ledger, constraints and evidence on contract exit, in documented open formats (Metamodel).
Retention and deletion follow the institution's schedule.
The honest boundary
This page is where Rules 3, 5 and 7 become operational: disinterested verification, retrospective checkability, and tamper evidence, scoped to a named threat model. The eight rules →