Fatima leads the privacy engineering team at a health data company. She has reviewed dozens of privacy frameworks and can identify their failure modes before reaching page three. Most fail in one of two ways: they treat all data as equally sensitive, producing a system so restrictive it cannot function, or they treat sensitivity as a spectrum without specifying what concretely changes at each level, producing a system where the “maximum protection” tier is procedurally indistinguishable from the “medium protection” tier in practice.
When she reviewed BlueMirror’s privacy architecture for a partner due diligence engagement, she was not looking for a tier taxonomy. She was looking for evidence that the tiers had distinct architectural implementations: different handling, different gates, different audit requirements. Not just different labels.
The tiers have different implementations. That is the point.
Four tiers with real consequences
Maximum protection covers healthcare data. Full HIPAA-grade protection with complete audit trails, human approval gates for any external sharing, and edge-only processing for the most sensitive health data: cognitive state assessments, medication adherence records, symptom reports. Raw health data in these categories is never sent to cloud servers for processing. The inference happens locally, on the GB10 device. The output travels, not the input.
External sharing of maximum-tier data requires per-interaction authorization, not a standing permission. The pharmacy that has been filling prescriptions reliably for two years does not receive blanket access to the medication list. Each interaction where medication data flows is authorized at the interaction level, with a record of what flowed, to whom, and why. The authorization is specific. The audit is complete.
High protection covers financial data. Strong authentication, commitment limits enforced at the infrastructure level, comprehensive interaction logging, and external sharing only through verified channels with explicit purpose. The financial concierge holds the complete financial picture: account balances, investment positions, insurance coverage, income and expense patterns. What any external agent receives is a carefully scoped subset specific to the interaction: the amount of a bill being paid, the price range for a procurement negotiation, the coverage question being verified. The full financial picture stays internal.
Medium protection covers shopping, home, and behavioral preference data. Preference protection with the Blue Pane membrane active. Raw behavioral data is not shared with vendors in its unprocessed form. What flows externally is the output of the context gate’s minimum viable packaging: the delivery preference for this order, the accessibility requirement for this trip, the dietary constraint for this meal plan. Not the behavioral history that produced those preferences.
Light protection covers entertainment, routine scheduling, and ambient data. Lighter gates, faster automation, minimal friction. These domains have low individual-decision stakes and high automation benefit. But the aggregation detection architecture is active here too, which is the critical design point.
The aggregation problem
Light protection domains create a specific risk that a tier system without aggregation controls cannot handle.
Shopping preferences reveal brand loyalties and price sensitivities. Location patterns reveal regular destinations: physician offices, community centers, family members’ homes. Entertainment choices reveal cognitive engagement patterns and interests. Communication frequency reveals social connection levels. Energy usage reveals daily routines. None of these, individually, belongs to a high or maximum protection tier. In combination, they reconstruct a behavioral profile that enables pricing discrimination, manipulation through known cognitive biases, and surveillance of daily life.
The privacy architecture includes cross-domain aggregation detection at the membrane. When the totality of data accessible to an external agent across all its permitted interactions enables the reconstruction of a profile equivalent to a high or maximum protection profile, the system escalates protection for the contributing domains. The individual data elements remain in their original tiers. The effective protection for the combination rises to the level of what the combination reveals.
This is not a theoretical concern. Consumer data brokers routinely combine individually innocuous data streams to produce sensitive profiles. The aggregation risk is the documented threat. The membrane’s cross-domain inference ceiling, described in the integration surface architecture, is the enforcement mechanism. The privacy tier system defines what constitutes an unacceptable aggregate. The context gate enforces it at each interaction.
Five privacy engineering principles
Five principles govern the implementation across all tiers.
Minimum necessary context: every external interaction receives the minimum data needed to fulfill its specific purpose. Not “all relevant data.” Not “data that might be useful.” The minimum that allows the interaction to complete as intended. A pharmacy refill interaction receives the medication name, dosage, and delivery preference. It does not receive the clinical diagnosis that produced the prescription, the other medications in the list, or the financial context that influences which pharmacy was selected.
Purpose limitation: data shared for one purpose cannot be repurposed. The pharmacy that receives the medication list for refill purposes cannot use it for marketing. The transportation provider that receives the accessibility requirement cannot use it to infer the medical condition behind the requirement. Purpose limitation is enforced through the agent trust system: an agent that uses data outside its declared purpose is a boundary violation, logged and scored against its trust tier.
Temporal limitation: shared data has a defined lifespan. The delivery service that received the address for today’s delivery does not retain it indefinitely. The interaction data shared through the membrane expires according to the interaction type’s retention schedule. Partners who want to retain data longer than the default must declare a purpose and meet the requirements for extended retention, which exist in the partner framework.
Inference limitation: protection against implicit disclosure extends the tier system into territory that explicit data rules alone cannot cover. The system that blocks explicit health data sharing must also prevent the inference of health status from non-health data patterns. An external agent that observes morning scheduling preferences, medication order timing, and specialist appointment frequency may not have received a single piece of health data explicitly, but the pattern reveals a health situation. The inference ceiling in the context gate addresses this by tracking the cumulative inference potential of all information accessible to each agent, not just the individual data elements.
Audit universality: every data access, every external sharing event, every context gate evaluation is logged regardless of the domain tier. Light domains have lighter gates but equal logging. The audit trail covers the full population of interactions, not just the ones that triggered a protection mechanism. This is what makes the privacy architecture verifiable: the person can request a complete account of what left the system, when, to whom, and for what purpose. The answer exists because everything was logged.
Privacy and personalization are not in tension
The common objection to rigorous privacy engineering is that it prevents personalization. If the system cannot share what it knows, how can it deliver services tailored to the person’s situation?
The architectural answer is that personalization happens inside the membrane. The Memory of Context hierarchy, the P-RLHF preference model, the domain knowledge accumulated across months of interaction: all of it lives inside the system, serving the person directly. External agents do not need the full context to serve her. They need the minimum necessary context for one specific interaction, packaged by the membrane and scoped to their declared purpose.
The grocery delivery service delivers a better order because the nutrition concierge provided the dietary constraints relevant to this delivery. Not because the grocery service has the person’s full dietary and medical history. The transportation provider selects the right vehicle because the system shared the accessibility requirement. Not because the provider knows the underlying medical condition. The personalization is real. It travels as the output of a context packaging process that gives each external agent exactly what it needs and nothing more.
Privacy and personalization are in tension only when personalization requires the person’s data to live outside the membrane. The BlueMirror architecture is designed so that personalization does not require this. The data stays inside. The benefit flows out.
The person’s control surface
The privacy architecture is not invisible to the person. She has a control surface that makes what the system does visible and adjustable.
The privacy dashboard shows who has accessed what data, when, and why. Current privacy tier settings per domain, which are modifiable within the architectural defaults. External parties with active data access, which can be revoked at any time with immediate effect. An aggregation risk indicator: a signal that shows whether cross-domain data sharing is approaching a threshold where the combination begins to resemble a higher-tier profile. The indicator is simple. It does not require the person to understand inference scoring. It tells her whether to pay attention.
The person can export everything the system holds about her: the complete MoC context, the preference model, the interaction history, the audit trail. The export format is portable. She can also delete: per-domain, per-partner, or completely. Deletion of a partner’s data access is immediate and propagates through the system per the revocation protocol described in the consent architecture.
The control surface exists not because the person will use every capability every day. Most people will use none of it most days, and that is fine. It exists because the person who wants to understand what the system does with her data can find out. That knowability is a prerequisite for the trust the system depends on.
Fatima’s due diligence finding was the one she had not expected to write: the tier system had real consequences. Different handling, different enforcement mechanisms, different audit requirements at each level. The labels corresponded to implementations. That, she noted in her report, was the first time she had been able to write that sentence about a health technology platform’s privacy framework.
Cross-References#
The Membrane (BMT-03.01). The Blue Pane membrane that enforces the privacy tiers at the integration boundary with external agents.
Contextual Consent (BMT-04.03). The consent architecture that governs the authorization layer for data sharing decisions across all tiers.
Where Your Data Lives (BMT-07.01). The data residency architecture that determines where different tiers of data are stored and processed.
Who You Are Is Not One Thing (BMT-05.04). The I-ICE intersectional context engine as a privacy-preserving approach to personalization.
Technical Appendix BMT-04.07-A is available to partners and investors at partners.bluemirror.tech.