Governance

Isolation, PII handling, and an audit trail built for scrutiny

The controls a risk or compliance leader needs to see before recommending this platform internally — how tenants are separated, what happens to personal data, how model calls are guarded, and what gets recorded. The same controls scope a network's member agencies from one another.

Isolation

A database for every agency

Tenancy is a database boundary, not an application-level filter.

Every agency's data lives in its own database. Nothing about that separation depends on a query remembering to filter by agency, because there is no shared table for a query to reach across. Every request that touches client data is resolved to a single agency's database before it runs.

For a large agency comparing this to a shared-schema competitor, the practical difference shows up on the day something goes wrong. A defective query cannot expose another tenant's book, because that book is not reachable from the connection the query is running on.

A database per agency

Tenants are separated at the database level, not by a filter on a shared table. Every query touching client data is scoped to one agency.

Each agency resolves to its own database, not a shared table with a filter.

Capture pending

Must show the per-agency database mapping without exposing real tenant names.

Networks and aggregators

A member is a database, not a row with a filter on it

The strongest isolation argument for a network serving member agencies, made explicit.

A member agency resolves to its own database. A defective query written against one member cannot reach another member's book, because that book is not reachable from the connection the query is running on — it does not depend on a filter being applied correctly.

Audit records and compliance status are scoped the same way, member by member. Each member also keeps its own guidance and authored prompts rather than inheriting another member's.

A database per member agency

Each member resolves to its own database. A defective query cannot reach another member’s book, because that book is not in the same database.

Credentials and ingestion per member

Each member gets its own ingest credentials, rate limits, and webhook destination, so one member’s integration cannot disturb another.

Onboard a member without a deployment

Adding a member is provisioning and configuration, not a release. Database, settings, branding, and users are created per agency.

Per-member audit and compliance

Audit records and compliance status are scoped to the member agency, so each one can answer for its own automated decisions.

Each member keeps its own rules

Appetite guides, procedures, and authored prompts belong to the member agency. Members do not inherit one another’s guidance.

PII handling

Identifiers are removed before the model sees the request

Scrubbing happens at the boundary, ahead of the call to the model provider.

Client identifiers are stripped out of a request before it crosses into the model call. The scrubbing step runs at the boundary between the platform and the provider, so personal data is not part of what leaves the system on that call.

This is a scoped guarantee about the model boundary specifically, not a claim about every path data can take through the platform. A compliance reviewer should read it as one control among several, alongside isolation and the audit trail on this page.

PII scrubbed before the model

Client identifiers are removed at the boundary, so personal data is not what reaches the provider.

Guardrails

One safety layer, applied on every call

Input validation, output validation, a tool allowlist, and a prompt registry sit in front of every model call.

The guardrail layer does not live inside individual features. It sits in the path every model call takes, so a new feature inherits input validation, output validation, and a tool allowlist rather than needing them re-implemented.

The same layer holds the prompt registry: the set of prompts a call is permitted to run and the tools that call is permitted to invoke. Both are enforced in code, ahead of the model, rather than left to the model's judgment.

Guardrails on every call

A safety layer validates inputs and outputs, enforces a tool allowlist, and holds the prompt registry.

Audit trail

Every AI action is on the record

Built for the moment a regulator or an internal auditor asks how a decision was made.

Each AI action is recorded with the prompt that produced it, the model that ran it, the tools it called, the tokens it used, and the result it returned. The record is written at the time the action happens, not reconstructed afterward.

When an auditor or a regulator asks why the system did something, the answer is a lookup against this trail rather than an attempt to reproduce the reasoning after the fact.

A complete audit trail

Every AI action is recorded — prompt, model, tools, tokens, and result — ready for a regulator or an internal review.

Every AI action, recorded with its model, tools, and token cost.

Capture pending

Needs a capture of the AI Compliance audit view. The previous asset was named audit-trail but showed a chat conversation list, so it was removed rather than published under this caption.

Compliance centre

A working surface for the compliance programme, not a policy document

Impact assessments, bias testing, retention, and consumer data requests are tracked in the product, not in a spreadsheet kept off to the side.

Impact assessments

Structured assessments per AI use case, exportable.

Bias testing

Recorded test runs with exportable results.

Retention and archival

Retention records with archive actions and reporting.

Consumer data requests

Intake and tracking for individual data requests.

Regulatory requirements

A tracked requirement set with status, deadlines, and per-rule checks.

Requirement status, deadlines, assessments, and bias tests in one place.

Capture pending