Raj Mehta had spent a decade building compliance systems for HIPAA-covered entities before he joined a health-tech startup evaluating BlueMirror’s consent model. He knew the standard pattern: a consent form signed once at intake, scanned into a document management system, referenced when someone filed a complaint. The form covered everything. The form governed nothing. Data flowed based on system permissions, not patient preferences. If the patient revoked consent verbally, the revocation might take days to propagate through the EHR, the pharmacy system, the billing platform, the referral network. In practice, patients did not revoke consent because revocation was so difficult that it felt impossible.
When Raj reviewed BlueMirror’s consent architecture, he found something structurally different: consent treated not as a document but as a real-time data flow governance mechanism. Every data movement in the system, every context package assembled by the MoC Router, every external sharing event, every internal routing decision passes through a consent evaluation. The evaluation is not a permission check against a static table. It is a live query against a consent state that can change at any moment and propagate immediately.
Consent is not a form Margaret signs. It is a system that runs every time her data moves.
Consent as data flow#
The consent layer sits between every data source and every data consumer in BlueMirror. Before the health concierge shares Margaret’s medication list with the pharmacy agent, the consent layer checks: does Margaret currently consent to medication data sharing with this pharmacy, at this trust tier, for this purpose? If yes, the data flows. If no, the data is blocked. If the consent status has changed since the last check, the change takes effect on this query, not the next one.
The distinction from traditional consent models is architectural, not philosophical. Traditional systems store consent as a record. BlueMirror implements consent as a gate. The record says “Margaret agreed to share health data with CVS on March 3, 2025.” The gate asks “does Margaret agree to share this specific health data with CVS right now?” The record is backward-looking. The gate is present-tense. The record can become stale. The gate cannot, because it evaluates at query time.
Every data flow in the system carries a consent context: the data type, the source domain, the destination (internal agent or external party), the purpose, and the trust tier of the destination. The consent layer evaluates all five parameters against Margaret’s current consent state. A change in any parameter can change the evaluation result. Margaret may consent to sharing her medication list with CVS for refill management but not for marketing. Same data type, same destination, different purpose, different result.
This five-parameter evaluation is what makes the consent architecture granular without being burdensome. Margaret does not need to specify consent for every possible combination of parameters. The system applies reasonable defaults based on domain privacy tiers (BMT-04.07): health data defaults to sharing-denied until explicitly granted, shopping preferences default to sharing-permitted within the system but denied externally, entertainment preferences default to broad sharing internally. Margaret overrides any default she disagrees with, and her overrides propagate through the same gate architecture. The defaults mean Margaret makes fewer decisions. The gate architecture means every decision she makes is enforced completely.
The consent state machine#
Each consent grant in the system has a lifecycle with five states.
Pending means consent has been requested but not yet given. The health concierge wants to share Margaret’s lab results with her cardiologist. The request is logged. The data does not flow. The system does not default to “yes” and does not treat silence as agreement. Pending requests surface in Margaret’s consent dashboard with the context she needs to decide: who is asking, for what data, for what purpose, and what happens if she says no.
Active means consent has been given. Data flows are permitted within the consent’s scope. The scope is specific: this data type, this recipient, this purpose, this trust tier. Active consent is not blanket permission. It is a precisely bounded authorization.
Suspended means consent has been temporarily paused. Margaret can suspend a consent grant without revoking it. The system can also suspend consent when a capacity change is detected (BMT-01.07) or when a system review identifies a potential concern. Data flows stop, but the consent relationship is preserved. Reactivation does not require re-consenting from scratch.
Revoked means consent has been withdrawn. Data flows stop immediately. External parties are notified of the revocation. The consent relationship is terminated. Reactivation requires new consent, which means a new Pending state, a new evaluation, and a new Active grant if Margaret chooses.
Expired means consent has reached its time limit. Every consent grant carries an expiration, set either by Margaret at grant time or by domain-specific defaults. Health data sharing consents expire every 12 months. Shopping preference sharing consents expire every 24 months. When a consent expires, the system treats it as Suspended: data flows stop, but reactivation is simpler than new consent. Margaret sees the expiration in her dashboard and can renew with a single confirmation.
The transitions between states are governed by explicit triggers. No state transition happens silently. Every transition is logged, timestamped, and attributable to a cause: Margaret’s action, a capacity-triggered suspension, a system-initiated review, or a time-based expiration.
Propagation architecture#
When consent changes, the change must reach every system that depends on it. The propagation model has three tiers matched to the urgency of each dependency.
Synchronous propagation governs external data sharing. When Margaret revokes consent for health data sharing with her insurance company, the revocation takes effect before the next query from that insurer can be processed. The target is under 100 milliseconds. Zero tolerance for data leaving the system after revocation. The pharmacy agent’s access is terminated, the insurer’s query returns an authorization failure, and the external party receives a revocation notification. This is the hardest engineering requirement in the consent system and the most important.
Eventually consistent propagation governs internal agent routing. When Margaret revokes health data consent, the internal agents that were using health-derived context do not instantly lose their cached information. The buying agent may have cached Margaret’s dietary restrictions (derived from her medication list) earlier in the session. That cache expires at session end or within five minutes, whichever comes first. The buying agent will not receive updated health data, and the cache will not be refreshed. The temporary inconsistency is bounded, brief, and architecturally acceptable because the data stays inside the system during the consistency window.
Cascading propagation handles cross-domain dependencies. A revocation of health data consent cascades to every downstream use of health data: the buying agent’s nutritional filtering (based on health data), the earning concierge’s cognitive-capacity scheduling (based on health data), the family coordination concierge’s health summary sharing (based on health data). Margaret does not need to identify each downstream dependency. She revokes once. The system traces the dependency graph and propagates the revocation to every affected flow. The cascade is automatic, complete, and auditable.
The three-tier model means that different parties experience consent changes at different speeds appropriate to the risk. The external party that should no longer have data loses access immediately. The internal agent that had cached data loses it within minutes. The downstream agents that were consuming derived data lose their upstream source and degrade gracefully to operating without it. The buying agent that was filtering groceries by dietary restrictions reverts to Margaret’s explicit grocery preferences without the health-derived nutritional constraints. The service degrades. The service does not break. And Margaret’s revocation is honored across every boundary in the system.
Consent for derived data#
The hardest consent problem is derived data. Margaret consents to sharing her medication list with the pharmacy. The pharmacy’s agent uses the medication list to infer that Margaret has hypertension and diabetes. Margaret did not consent to sharing her diagnoses. But the diagnoses are derivable from the medications.
The architectural position is clear: consent covers the data shared, not the inferences derivable from it. The system cannot prevent an external agent from making inferences inside its own processing. What the system can do is limit and enforce. The exploration bounds architecture (BMT-03.03) limits what the external agent can do with inferences by constraining the agent to its declared purpose. The pharmacy agent’s manifest declares that it processes medication data for refill management. If it uses medication data to infer diagnoses and acts on those inferences outside its declared scope, it has violated its manifest. Its trust tier drops. Its data access narrows or terminates. The violation is logged in the audit trail (BMT-07.04).
The honest limitation: enforcement works for agents within BlueMirror’s trust framework. For external systems that receive data through the pharmacy agent and operate outside the trust framework, the system’s control is limited to minimizing what data leaves in the first place and logging what was shared. This is why the synchronous revocation pathway matters so much: the less data that leaves, the less inference surface exists outside the system’s governance.
The derived data problem is not solvable by architecture alone. It is a problem that requires the combination of architectural enforcement (exploration bounds), contractual enforcement (the terms under which external agents receive data access), and trust management (the ongoing evaluation of whether external agents comply with their declared purposes). The system provides the infrastructure for all three. It does not pretend that any one of them is sufficient.
What Margaret sees#
Margaret’s consent dashboard is not a privacy policy. It is a control panel.
Active consents are listed by domain and external party. “CVS Pharmacy: medication list, delivery preferences. Active since March 2025. Expires March 2026.” Each entry has a toggle. One tap to suspend. A confirmation to revoke.
Pending consents await her decision. “Dr. Patel’s office requests access to your blood work results for referral to your cardiologist.” The request includes who is asking, what they want, why, and what changes if she says no.
Recent changes show what has happened. “You suspended health data sharing with UnitedHealthcare on April 15. Data flows are paused. You can reactivate or revoke.”
A consent review schedule tells her what is coming. “Your pharmacy data sharing consent is due for review in 45 days.”
The dashboard adapts to Margaret’s capacity. If the cognitive concierge (BMT-01.07) detects declining decision-making ability, consent reviews become simpler: fewer options presented at once, clearer language, larger confirmation targets. If Margaret has designated a trusted proxy, the proxy can view consent states and make recommendations, but cannot change consent without Margaret’s confirmation unless Margaret has explicitly granted proxy authority for specific domains. The capacity-sensitive consent model ensures that the people who need consent protection most are not the people least able to exercise it.
The dashboard is simple because the architecture is complex. The system handles the propagation, the cascades, the cache expiry, the external notifications, the audit logging. Margaret handles one thing: her decisions about who sees what. The complexity is behind the glass. The control is in her hands.
Cross-References#
BMT-04.03 Contextual Consent. The ethical framework for consent that this article implements as a technical architecture, including the three tiers, the granularity paradox, and the capacity problem.
BMT-03.03 Bounded Exploration. Exploration bounds as the enforcement mechanism for consent scope, constraining external agents to their declared purposes.
BMT-07.04 The Audit Trail. How every consent change, data flow, and propagation event is logged for regulatory compliance and person-accessible review.
BMT-07.01 Where Your Data Lives. Data residency as the physical substrate that consent governs, connecting logical consent decisions to actual storage and deletion.
Technical Appendix BMT-05.05-A is available to partners and investors at partners.bluemirror.tech.