Tenant isolation

A plain-language description of how Rootd keeps each operator's data separate. This complements the Security page and the Data processing terms.

commitment summary — confirm specifics with your security & legal teams before publishing

1. Overview

Rootd is multi-tenant: many operators share the platform, but each operator's data is logically isolated. Isolation is enforced at the query boundary rather than left to application-level convention — there is no supported path that reads across tenants.

2. What's isolated

Ingested telemetry, the derived digital twin, forecasts, projections, and audit records all belong to a single tenant and are only addressable within that tenant's scope. A valid identifier from one tenant cannot resolve data in another.

3. The query boundary

Every request carries a tenant context, and every query is bound to it at the boundary. The effect is that cross-tenant reads are not expressible through the platform's interfaces — isolation holds by construction, not only by policy.

4. Audit & monitoring

Reads against the twin carry an audit trail — who read what, when, and in which tenant scope — and ingestion, freshness, and twin state are monitored end to end. Connectivity loss is recorded as a modeled state, never silently dropped.

5. Residency & retention

Data residency and retention follow the customer's order and the Data processing terms. specify regions & retention windows

6. Reporting a concern

To report a suspected isolation or security issue, contact security@rootd.io. placeholder — add disclosure process