ADR-0005: Data Classification and Control Plane Residency

Context

CEREBRAL STRATUM runs across three ROSA HCP regions (us-east-2, eu-west-2, ap-southeast-2), targeting AU/NZ primarily and US/EU secondarily. Regional data sovereignty — a customer's data staying within their region — is a stated non-negotiable principle. But "data sovereignty" is easy to satisfy only superficially by focusing on where the database lives, while missing several less obvious paths data can take across a region boundary: observability pipelines, session state replication, distributed trace span attributes, and any control-plane component that touches per-customer data even transiently.

This ADR exists to make the classification of data explicit (what counts as regionally-bound customer data vs. what can legitimately be global/control-plane) and to name the specific transit-layer paths that have historically been the easiest to overlook. It also formalises compliance posture against GDPR (EU region) and the Australian Privacy Act (AU/NZ, the primary market).

Decision

Control plane is routing and orchestration only. The control plane — whatever coordinates across regions (deployment orchestration, global configuration, cross-region routing decisions) — must never cache, aggregate, or replicate user data globally. It may know that a tenant is assigned to a region and route accordingly; it must not hold or transit the tenant's actual data.

Data classification (two tiers):

• Regionally-bound customer data — location history, device telemetry, tenant PII, anything tied to a specific customer or device. This data is created, stored, processed, and purged entirely within the customer's assigned region. It does not cross region boundaries in any form, including transiently.

• Global/control-plane data — tenant-to-region assignment records, platform-wide configuration, aggregate (non-attributable) operational metrics used for capacity planning. This is the only category permitted to be global.

Named hidden transit-layer risks (each must have an explicit regional-boundary answer, not an assumed one):

• Observability egress. Metrics, logs, and traces must not carry per-customer identifying data across region boundaries. Aggregate/anonymised operational metrics may flow to a central observability plane (e.g. Grafana Cloud); anything with tenant-identifying content stays regional. This is an open cross-region observability egress boundary requiring explicit review of what Grafana Alloy actually ships centrally versus what stays region-local.

• Session state. Authentication/session state must not be silently replicated or cached across regions as a side effect of infrastructure design (e.g. a shared cache layer spanning regions for convenience). Session state for a tenant stays associated with that tenant's region.

• Distributed trace span attributes. W3C TraceContext correlation is used platform-wide; trace span attributes can easily end up carrying tenant-identifying or even payload-adjacent data (a device ID, a request path with an identifier embedded) that then crosses regions if traces are centrally aggregated. Span attribute content must be reviewed and constrained specifically for cross-region trace aggregation, not assumed safe because tracing is "just observability."

• Token contents. Per backend ADR-0005, lean tokens (minimal claims) are both a scalability control and a sovereignty control — token contents that cross regions (e.g. a token issued in one region but validated against a cross-region service call) are a transit-layer sovereignty risk if they carry more than strictly necessary claims.

Purge execution: Purge jobs (part of the four-state data lifecycle: Active → Cancelled/Grace → Cancelled/Purged → Account Deleted, with a 7-day grace period post-cancellation) execute within the regional instance holding the data. There is no central purge orchestrator that reaches into regions to delete data on their behalf beyond scheduling/triggering — the actual deletion happens locally, keeping the control plane's "routing and orchestration only" boundary intact even during data deletion.

Alternatives Considered

• Central data lake / aggregated analytics store spanning all regions. Rejected — directly violates regional sovereignty regardless of how convenient it would be for cross-region reporting; any cross-region insight needed must be built from independently-computed regional aggregates, not raw data replication.

• Treat observability/tracing as exempt from sovereignty concerns since it's "just infrastructure telemetry." Rejected — this is precisely the blind spot this ADR exists to close; telemetry can carry identifying content and must be held to the same boundary as primary data.

• Central purge orchestrator that directly deletes data in each region. Rejected in favour of trigger-locally/execute-locally — keeps a clean boundary where the control plane only ever schedules or signals, never directly operates on regional data itself.

Consequences

• Requires an explicit audit of every current and future cross-region data flow (observability, tracing, session state, tokens) against this classification — this is nontrivial ongoing governance work, not a one-time check, since new integrations (e.g. a future central analytics tool) could reintroduce a leak if not evaluated against this ADR.

• Aggregate/anonymised metrics remain centrally available for genuine platform-wide operational needs (capacity planning, cost management) without compromising the regionally-bound tier.

• Some conveniences that a fully global architecture would offer (single cross-region dashboard with per-tenant drill-down, for instance) are explicitly foregone or must be re-architected as region-local views stitched together at presentation time rather than backed by cross-region data replication.

• GDPR and Australian Privacy Act compliance posture is strengthened by having an explicit, reviewable classification rather than an implicit "we use regional databases so we're probably fine" posture.

Open Items

• ADR-0006 candidate: cross-region observability egress boundary. This ADR names observability egress as a risk category but does not fully specify what Grafana Alloy currently ships centrally versus region-locally — a dedicated follow-up ADR is needed to audit and formally decide the OTLP/metrics/logs egress boundary in detail.

• Formal review of current distributed trace span attribute content against this classification — needs a concrete audit pass, not just the principle stated here.

• GDPR Article 30 (records of processing) and Australian Privacy Act (APP 8, cross-border disclosure) documentation — this ADR establishes the technical architecture but the formal compliance documentation/register work is separate and still needs to be produced.

• Whether tenant-to-region assignment itself (control-plane/global data) needs any additional protection given it reveals which region a customer's data lives in — likely low risk but not yet explicitly assessed.