You are multi-tenant. Prove my data — and everything derived from it, embeddings, caches, insights — is isolated from your other customers, including inside the AI pipeline?

The full executive answer

Isolation is enforced by our application filtering every query to your organisation, and it does not depend on anyone remembering to: an automated cross-tenant test in our build pipeline fails if a tenant-table read loses its organisation filter. Every tenant-data table also carries row-level security as a second line, which refuses cross-tenant reads from anything connecting to the database directly, and a second static test fails the build if anyone adds a tenant table without that policy. The organisation identity used everywhere comes from the verified login token, never from anything a request claims about itself.

The derivatives follow the same rule, which is the part most vendors get wrong. Document chunks and their embeddings live in tenant-scoped tables. Cached insights are keyed by a fingerprint that includes your organisation’s identity, so one tenant’s cache can never serve another tenant’s question. Consensus runs, cost events, feedback, audit entries — all carry the tenant identity. And the prompt layer adds a belt to those braces: the model is instructed it has data for exactly one organisation, is forbidden to reference any other organisation by name, and — structurally — is only ever handed one tenant’s context anyway. Benchmarking across customers, where offered, runs on consented, aggregated statistics, never raw peer data in a prompt.

So the answer to "prove it" is: I can show you the security policy on the tables, the build gate that enforces policy coverage, and the tenant identity flowing from verified authentication — three artifacts, not assurances.