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

Security-relevant events are recorded to a per-tenant audit log (queryable within the tenant scope, never across it), 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.cc. placeholder: add disclosure process