Priya Raghavan has audited data architectures for eleven years. She started at Deloitte, moved to a healthcare compliance consultancy, and now runs her own practice specializing in HIPAA technical safeguards. When a health technology company says “your data is secure,” Priya asks a question that most companies cannot answer clearly: where, physically, does the data live right now?
She asked this question of the BlueMirror architecture team on a Tuesday morning in March 2026. The answer she received was different from any she had encountered before. Not because it was vague. Because it was specific in a direction she did not expect. The system organizes data residency into three physical zones, each with distinct security characteristics and distinct privacy boundaries. Where any given subscriber’s data lives depends on which zones she has. The architecture starts by defining what each zone can hold, then describes how a subscriber’s data flows across the zones she has access to.
The three-zone residency model#
Data residency in BlueMirror is a physical fact, not a policy statement. The three zones correspond to the three compute tiers described in BMT-06.03, because where data is processed determines where data must live.
Zone 1: the home. When a subscriber has a Local Pane device, the device stores the data that must never leave. Raw sensor signals from wearable devices. Raw audio from voice interactions. Cognitive state assessments derived from behavioral patterns. Emotional state classifications derived from voice and text. MoC Layers 0 and 1 (identity core and daily patterns) are cached here for offline access. The Zone 1 Tiny LMs (Safety Filter, Privacy Filter, Cognitive State Estimator, Emotion Detector, Speech-to-Intent) process this data locally and transmit only processed signals upward, never raw data.
The distinction between raw and processed is architectural, not semantic. The Cognitive State Estimator sends “cognitive state: normal” or “cognitive state: fluctuating, confidence 0.73” upward. It does not send the behavioral observations that produced that assessment: the response latency measurements, the linguistic complexity scores, the error rate calculations. The Privacy Filter validates every outbound transmission before it leaves the device. The system cannot leak what it does not transmit.
For subscribers without a Local Pane, Zone 1 does not exist. Raw audio, raw cognitive signals, raw emotional data, and the other sensitive categories that Zone 1 would have processed locally instead route to Zone 2 or Zone 3 for processing, under the consent the subscriber has granted and the DPA governing the cloud reasoning layer. The data still exists in the subscriber’s possession (on her phone, her wearable, her sensors); the inference that processes it runs in a different zone.
Zone 2: the region. When a Community Pane node has been deployed in the subscriber’s region, that node stores her working data. The full MoC (all five layers). The P-RLHF individual preference model that learns how the person prefers to interact. Session history. Domain-specific context: medication lists (mapped to drug class categories rather than stored as free text), financial account metadata (account types and status, not balances or credentials), social connection maps, care plans. For subscribers with a Local Pane, Zone 2 receives only privacy-filtered data from Zone 1, never raw audio, raw cognitive signals, or raw sensor streams. For subscribers without a Local Pane, Zone 2 receives data directly from the subscriber’s client devices under her consent grants.
Zone 2 data residency is regional. A subscriber in Phoenix who is served by a Phoenix-area Community Pane has her MoC on that regional node, not in a data center in Virginia. The regional residency is a meaningful privacy property: the person’s data stays within a geographic boundary she can understand: “your data is processed at a facility forty miles from your home, not in a data center across the country.”
For subscribers in regions where no Community Pane has deployed, Zone 2 does not exist. The MoC for those subscribers resides in Zone 3 infrastructure. The data still exists. It just lives in a different place.
Zone 3: the cloud reasoning layer. Always present. Zone 3 is the cloud-hosted infrastructure that performs deep inference, complex multi-domain reasoning, and orchestration that exceeds Zone 2’s capacity. Zone 3 holds the data needed for the inference it performs: the MoC context for any subscriber whose query routes to Zone 3, the working data for subscribers who do not have a Zone 2 node in their region, and the complete data residency for Zone 3-only subscribers who have neither a Local Pane nor a regional node.
Zone 3 is governed by a healthcare data processing agreement that prohibits retention beyond the inference request lifecycle for transit queries, prohibits use of subscriber data for the provider’s own model training, requires HIPAA technical safeguard compliance, supports audit rights, and constrains geographic processing to contracted regions. For subscribers whose data routes through Zone 3 only for specific deep-reasoning queries (because they also have Zone 1 and Zone 2), Zone 3 sees the context for those queries during processing and discards it afterward. For Zone 3-only subscribers, Zone 3 hosts the persistent MoC and is the residency tier for their data full-time.
Zone 3 also handles cross-cutting infrastructure that does not depend on subscriber-specific inference: encrypted backup archives for subscribers who opt into cloud backup, federated FSSVA deviation signals (scalar values, not raw data or model weights), anonymized population metrics for equity monitoring (BMT-11.04), and BGO marketplace metadata. These categories of data are present in Zone 3 in addition to the inference workload, not instead of it.
The three deployment paths#
A given subscriber’s data residency depends on which zones she has.
The full-stack subscriber (Zone 1 + Zone 2 + Zone 3) has the strongest residency. Raw signals stay in Zone 1. Working MoC lives in Zone 2 within her geographic region. Zone 3 handles only the queries that exceed Zone 2’s capacity, and the context for those queries transits to Zone 3 during processing and is not retained.
The Zone 2 + Zone 3 subscriber (regional node, no Local Pane) has her MoC in Zone 2 and her raw signals processed by Zone 2 directly. Zone 3 handles deep-reasoning queries on the same transient basis as for the full-stack subscriber. The privacy posture is weaker than the full-stack path because raw signals are seen by Zone 2 (under contractual protection within BlueMirror’s regional infrastructure) rather than processed entirely locally. But Zone 2’s residency is still regional, still under BlueMirror’s operational control, and still bounded by the consent architecture.
The Zone 3-only subscriber has her MoC and her ongoing inference workload in Zone 3 infrastructure. The privacy posture relies on the DPA rather than on architectural data residency: the cloud provider does not retain her data beyond the inference lifecycle for transit queries, but for the persistent MoC and the ongoing inference workload, her data lives in Zone 3 as the residency tier. The geographic residency is bounded by the DPA’s contracted regions, not by her city. The product is the same product as the full-stack path, and the same deep reasoning is available to her. Her privacy depends on contract rather than on architecture, which is the trade-off the system makes to ensure that subscribers who cannot afford a Local Pane and who do not live in a regionally-served area are not excluded from the product.
The phased rollout#
At Phase 1 (launch), Zone 1 and Zone 2 do not yet exist for anyone. Every subscriber is on the Zone 3-only path, regardless of whether she will eventually acquire a Local Pane or move to a region with a Community Pane. The launch architecture is single-zone. The DPA governing Zone 3 is the entire privacy architecture during this phase.
At Phase 2 (months 12 to 18), subscribers who acquire a Local Pane gain Zone 1. The privacy-critical Tiny LMs deploy locally for those subscribers, and the raw signals those models process stay in Zone 1 from the moment Zone 1 comes online for that subscriber. Subscribers who do not acquire a Local Pane remain on the Zone 3-only path. Zone 2 regional nodes have not yet deployed in this phase, so all subscribers, including those with Zone 1, still route everything beyond the local Tiny LMs through Zone 3.
At Phase 3 (months 18 to 36), Zone 2 regional nodes deploy in served regions. Subscribers in those regions with a Local Pane gain the full-stack path. Subscribers in those regions without a Local Pane gain the Zone 2 + Zone 3 path. Subscribers outside the served regions, or who never acquire a Local Pane, remain on the Zone 3-only path. Zone 3 continues to handle every query for those subscribers and to handle the deep-reasoning queries that exceed Zone 2’s capacity for the other two paths.
The residency model evolves over time for any subscriber whose deployment path changes. A subscriber who joins on the Zone 3-only path and later acquires a Local Pane migrates from Zone 3-only to Zone 1 + Zone 3 (or Zone 1 + Zone 2 + Zone 3 if her region has a Community Pane). The data flow shifts accordingly: raw signals that previously routed to Zone 3 now process in Zone 1 from the migration forward. Historical data that resided in Zone 3 either migrates to the new residency tier or remains in Zone 3 with the subscriber’s consent, depending on her preference at the time of migration.
Stored versus accessible#
The distinction between data that exists and data that is accessible matters for regulatory analysis and is worth stating precisely. Health data exists in whichever zone the subscriber’s deployment path places it: Zone 2 for subscribers with regional coverage, Zone 3 for Zone 3-only subscribers. The pharmacy agent, when it needs to check a medication interaction, can access that health data through the Blue Pane membrane. These are two separate facts. The data’s existence is a storage question. The data’s accessibility is a permission question.
The membrane (BMT-03.01) governs all access. An internal agent requesting MoC data for a task the person has authorized receives the data. An external agent, even one the person trusts, receives only what the membrane’s contextual disclosure rules permit. The Four Access Tiers define the boundaries: Emergency access opens full context for life-threatening situations. Deep access opens Layers 0 through 3 for care coordination. Enhanced access opens Layers 0 through 2 for standard healthcare interactions. Basic access opens Layers 0 and 1 for low-trust or casual interactions.
The access tier varies by who is asking, why they are asking, what they need, and the current context. A cardiologist agent in a scheduled consultation gets Enhanced access. The same cardiologist agent during an emergency escalation gets Deep access. A grocery delivery agent gets Basic access, always. High trust in one domain does not automatically confer high trust in another.
Encryption as architecture#
Encryption at rest covers every byte of MoC data in every zone. AES-256-GCM for bulk storage. Zone 1 encryption keys, when Zone 1 exists for a subscriber, are derived from the device’s hardware-backed secure enclave. Zone 2 encryption keys are managed by the Community Pane’s hardware security module. Zone 3 encryption keys are managed by the cloud reasoning layer’s HSM under BlueMirror’s operational control, with key material that the cloud provider cannot access without an active inference request authenticated against the subscriber’s consent grants. Data in transit between zones uses TLS 1.3 with certificate pinning. For subscribers with a Local Pane, the Privacy Filter in Zone 1 validates that outbound data is appropriately classified and consented before any cross-zone transmission. For subscribers without a Local Pane, the equivalent validation runs at the client-to-Zone-2-or-Zone-3 boundary.
Backup encryption uses a two-layer scheme. The outer layer is AES-256-GCM with a key derived from the person’s passphrase using Argon2id. The inner layer uses the originating zone’s hardware-backed key. Restoring from backup requires both the person’s passphrase and a hardware key escrow token. Neither alone can decrypt the backup. Recovery is harder than a password reset. But recovery hardness is the cost of genuine encryption. A backup system where the provider can decrypt for “convenience” is a backup system where the provider can be compelled or breached.
The person’s data map#
The system can show the person, at any moment, where each type of data lives and which services have access. The display is not technical. It is a visual representation calibrated to the person’s deployment path. A full-stack subscriber sees: your cognitive and emotional data is on your Local Pane device, your medication list and health context are on your regional Community Pane, your encrypted backup is in cloud storage, no external service has your data right now, Dr. Patel’s office received your blood pressure trend last Tuesday at your request. A Zone 3-only subscriber sees: your cognitive and emotional data is processed in the cloud reasoning layer under your data processing agreement, your medication list and health context are stored in the same cloud infrastructure, the agreement governing this storage prohibits use beyond your inference requests, no external service has your data right now, Dr. Patel’s office received your blood pressure trend last Tuesday at your request.
The data map updates in real time. When the person grants a new consent, the map reflects it. When the inference for any query completes, the map shows the data flow and its completion. When the person revokes a consent, the map confirms the data flow has stopped. The map is generated from the same permission system that governs the actual data flows. It cannot show one thing while the system does another, because the display and the enforcement share the same underlying state.
What the residency model does not solve#
The residency model does not solve the problem of device loss for subscribers with a Local Pane. If the person loses her Local Pane device, the Zone 1 data is gone until the device is replaced and restored from encrypted backup. The system is designed to be resilient to single-device failure: Zone 2 (where deployed) retains the full MoC context, and Zone 3 handles the inference that the Local Pane would have run, so the person can continue interacting through a phone or tablet with the privacy posture of her remaining zones until the Local Pane is restored.
The residency model does not eliminate the inherent privacy difference between deployment paths. A Zone 3-only subscriber has her MoC and her ongoing inference workload in Zone 3 infrastructure. No amount of architectural design can convert that into the same residency posture as the full-stack path. The contractual protections in the DPA are strong; they are not identical to architectural data residency in the subscriber’s home or region. The system serves Zone 3-only subscribers under contract rather than under architecture, which is the right design choice for subscribers who would otherwise be excluded from the product.
The residency model also does not solve the question of what happens after the person dies. Digital estate planning for MoC data is a Series 04 topic that the data architecture supports but does not define. The architecture provides the mechanism: time-limited access grants, conditional delegation, and permanent deletion. The policy decisions live elsewhere.
Priya completed her audit with a finding she had not written before. The system’s privacy claim is verifiable not because the company says it is private, but because the data physically resides where the company says it resides, the person can see it there, and the residency differences between subscribers who have a Local Pane, subscribers who have only a regional node, and subscribers who have neither are visible in the architecture rather than buried in marketing.
Cross-References#
BMT-06.03 Edge Intelligence. The three-zone compute distribution that determines what processing happens alongside the data that resides in each zone, and the three deployment paths that subscribers may follow.
BMT-06.04 The Training Philosophy. The pipeline that produces proprietary SLMs whose deployment to Zone 1 and Zone 2 expands the privacy options available to subscribers over 24 to 36 months.
BMT-04.07 Privacy as Architecture. The ethical framework that treats privacy as a structural property rather than a compliance checkbox.
BMT-03.01 The Membrane. The Blue Pane architecture that governs all access to data regardless of which zone stores it.
Technical Appendix BMT-07.01-A is available to partners and investors at partners.bluemirror.tech.