Multi-tenant SaaS
Your customers expect their data, their policy, and their audit trail to stay theirs.
What it does
- A SaaS platform serving N enterprise customers wraps every customer's AI calls with the customer's own Guardian.
- Each customer's Glass Box receipts live in their own ledger partition.
- Each customer's auditors only ever see their own events.
Where Trinitite plugs in
| Surface | What governs it |
|---|---|
| Per-tenant Guardian | LoRA hot-swap on the same model server — sub-millisecond per-call switch. |
| Per-tenant ledger | ledger_partition field on every receipt; reads filtered by partition. |
| Per-tenant retention | Configurable per tenant via POST /v1/organizations/:id/settings. |
| Per-tenant SLA | Per-tenant latency / availability targets surfaced via Reports. |
| Per-tenant SIEM export | Each tenant points the Trinitite sink at their own Splunk / Datadog / CloudWatch. |
| Per-tenant Trust Center artifacts | Customer-facing Trust Center page is auto-populated from the platform settings. |
Why this matters
- One platform engineering team can support N customers without N copies of the safety stack.
- One Trinitite tenant per SaaS customer is the right granularity — never less.
- Tenant isolation is enforceable, not just promised — the ledger partition is the audit story.
What's next
→ Cookbook: Multi-tenant Guardian fleet — the implementation steps.
→ Trust Center — what to show your customers about Trinitite.