The consent form Margaret signed at onboarding was twelve pages long. She read the first paragraph and the summary at the end. This is not a criticism of Margaret. It is a description of how consent forms work. They are written to be comprehensive, which makes them unreadable. They are signed to enable the service, not because the person has meaningfully reviewed them. The form covers everything and protects nothing, because its granularity does not match the decisions it authorizes.
BlueMirror cannot replicate this model. A system that asks “do you consent to everything?” has not asked a meaningful question. A system that asks four hundred specific consent questions across thirteen concierge agents, thirty-one infrastructure agents, and dozens of external integrations has made consent a burden that defeats the product’s core purpose of simplifying life. The architecture needs something between the HIPAA form and a daily approval queue.
Contextual consent is that something.
Why static consent fails
Static consent ignores three realities that the system’s actual operation makes unavoidable.
The first reality is that context changes. The system’s capabilities evolve. New concierge agents activate. New external integrations come online. New data sources become available. Consent given for “medication reminders” does not cover “medication interaction checking using the full medication list cross-referenced against the pharmacy’s formulary data and the person’s grocery purchases.” Each new capability has implications the person did not anticipate when she signed the original form. Treating the original consent as covering the new capability is not consent. It is convenience dressed up as consent.
The second reality is that capacity changes. The person who gave informed consent at onboarding may have different cognitive capacity six months later. Consent given during full lucidity may not be revocable during reduced capacity, but it also cannot be extended indefinitely. The scope of consent established when the person fully understood what she was agreeing to cannot be expanded without capacity commensurate with the expansion. A person who consented to health summaries for her daughter when she was fully lucid has consented to health summaries. She has not consented to adding cognitive assessment scores to the health summary at a future date when she may not understand what she is agreeing to.
The third reality is the granularity paradox. Consent granular enough to be meaningful is too complex to manage at scale. A question like “do you consent to sharing your metformin dosage with your pharmacist’s scheduling agent for the purpose of timing your refill reminder?” is precise but unmanageable across hundreds of interactions per month. Consent simple enough to manage, something like “do you consent to the health concierge managing your medications?”, is too coarse to protect the specific decisions that matter. The architecture needs to provide meaningful protection without burdening the person with decisions she cannot realistically make at the required frequency.
The layered consent architecture
Three tiers of consent solve the granularity paradox by matching the level of specificity to the level of risk.
Tier 1 is foundational consent. Set at onboarding. Covers the system’s core functions in general terms: “I consent to BlueMirror managing my health, finances, home, and daily life using AI agents that learn my preferences and act on my behalf within the autonomy levels I set.” This is the foundation. It does not cover specific actions. It establishes the system’s right to exist and operate in the person’s life. Updated only when the system’s fundamental nature changes, not when an incremental feature is added.
Tier 2 is domain consent. Set when each concierge agent activates. Updated when its capabilities meaningfully change. “I consent to the health concierge monitoring my vital signs, managing my medication schedule, and coordinating with my healthcare providers.” Specific enough to be meaningful. Broad enough to be manageable. The person reviews thirteen domain consents, not four hundred transactional ones. When new capabilities appear within a domain, the system surfaces a clear notification: “The health concierge now offers food-drug interaction checking. This requires access to your grocery purchase history. Would you like to enable this?” The new capability is not activated by default. It requires an affirmative response.
Tier 3 is transactional consent. Requested in the moment for sensitive, novel, or high-risk actions. “The financial concierge needs to access your bank balance to check whether the property tax payment cleared. Allow this?” Not every interaction triggers this tier. It fires for new data types not covered by existing domain consent, new external parties not previously authorized, irreversible actions, or actions that cross domain boundaries in ways the domain consent did not anticipate. In practice, this fires perhaps two or three times per month per person, not multiple times per day.
The three tiers interact as a system. Foundational consent authorizes the system’s existence. Domain consent authorizes each concierge agent’s scope. Transactional consent handles the edge cases. Most daily interactions operate entirely within domain consent. The person’s cognitive load from the consent architecture is minimal under normal conditions, and meaningful when a decision genuinely warrants her attention.
Consent and cognitive capacity: four scenarios
The relationship between consent and cognitive capacity is the most complex part of the architecture because it involves four distinct situations that require different responses.
Scenario A is full capacity, stable. The standard model. All three consent tiers operate normally. The person can modify, expand, or revoke consent at any tier. Domain consent is reviewed periodically through natural check-ins embedded in regular interactions. The person is in full control of her consent architecture and can adjust it in any direction at any time.
Scenario B is full capacity at consent, declining now. Consent given during full capacity holds. The scope it established remains in effect. But the system cannot expand that scope without capacity-appropriate confirmation. If Margaret consented to health summaries for her daughter when she was fully lucid, that consent holds. The health summaries continue. But adding cognitive assessment scores to the health summary goes beyond what Margaret originally consented to, and it requires new consent for the addition. If Margaret’s capacity has declined to the point where she cannot give informed consent to the expansion, the expansion does not happen. The existing consent scope holds. The new scope waits for a lucid window or for a formal decision-maker to authorize it within their legal domain.
Scenario C is fluctuating capacity. The Cognitive State Estimator detects lucid windows: periods of higher cognitive function within the fluctuating baseline. The system uses these windows for consent review, not for new consent requests. The distinction is addressed in the next section. During lucid windows, the system confirms that existing consent still reflects the person’s wishes. It does not use the window to request expansion of the consent scope.
Scenario D is advanced decline. Consent management partially transfers to a designated decision-maker when a legal instrument authorizes the transfer. The system does not automatically transfer consent authority based on its own assessment of the person’s capacity. The legal instrument must be verified. The transfer is domain-specific: a healthcare proxy receives healthcare consent authority, not financial consent authority, unless the legal document specifies otherwise. The person’s prior consent settings are preserved as baseline. The decision-maker can maintain or narrow the consent scope. Expanding it beyond the baseline requires the decision-maker to document the justification, and the system logs it for potential review.
Lucid window consent
The Cognitive State Estimator identifies periods of higher cognitive function within the fluctuating baseline. These windows have a specific and limited role in the consent architecture.
Lucid windows are used to confirm existing consent. “You asked me to share your weekly health summary with Sarah. Still good?” A simple yes or no. The person is not presented with new options, new capabilities, or new opportunities to expand what the system does. She is given the opportunity to revisit decisions she previously made and either reaffirm or change them.
Lucid windows are not used to obtain new consent. Using a period of higher cognitive function to request permissions for new capabilities, new data types, or new external sharing would be manipulative: timing consent requests to moments of favorable condition to secure permissions that might not be obtainable at baseline. The architecture explicitly prohibits this. The timing of consent requests is governed by when the new capability or action type arises, not by when the person’s cognitive state is most favorable.
Lucid window confirmations are logged with the cognitive state estimate at the time of confirmation. The record shows that the confirmation occurred during a period of higher-than-baseline function. If consent is later disputed, the audit trail provides evidence about the conditions under which it was given.
Consent propagation
When Margaret revokes consent for health data sharing, the revocation propagates through the entire system immediately, not eventually.
External propagation is synchronous: no health data leaves the system after revocation takes effect, even if internal processing continues. The pharmacy agent’s access is revoked. Dr. Patel’s office access is revoked. The family coordination concierge stops including health information in daughter-directed updates. External propagation is immediate because the protection the person is invoking is primarily about what leaves the system.
Internal routing is eventually consistent: the buying agent may continue using cached dietary restrictions for the current active session but does not receive updated health data after the revocation. The eventual consistency window is bounded: no agent maintains access to revoked data through more than one session cycle.
The person can observe the propagation in real time: “Your health data sharing revocation has been applied. The following external parties have been notified: CVS Pharmacy, Dr. Patel’s office, Sarah (daughter). Internal agents have been updated.” The action is complete and visible. The person does not need to trust that the revocation occurred. She can see that it did.
Consent as ongoing relationship
Consent is not a moment. It is a relationship, and the system treats it as one.
The system periodically confirms that consent still reflects the person’s wishes, not through a re-consent form but through natural check-ins embedded in interactions the system is already having with her: “I have been sharing your weekly health summary with Sarah for six months. Still good?” The frequency of these check-ins is calibrated to the domain’s sensitivity: healthcare consent confirmed every ninety days, financial consent annually, entertainment consent at a much lower frequency or not at all.
The goal is that the person always knows what the system does on her behalf, who it shares information with, and why. Not because she has read a privacy policy, but because the system tells her in the course of serving her. Consent given at onboarding and never revisited becomes invisible over time. Invisible consent does not meaningfully protect anyone, because the person cannot modify what she cannot see and cannot revoke what she has forgotten she granted.
The consent architecture is designed to keep consent visible. Not intrusive. Visible. The person who is aware that her health summary goes to her daughter weekly, that the system accesses her bank balance for bill payment, and that her pharmacy receives her medication list for refill coordination has meaningful control. The person who signed a form three years ago and has not thought about it since does not, regardless of what the form said.
Cross-References#
Cognitive Capacity and Consent (BMT-04.05). The deeper treatment of Scenarios B through D and the decision-maker transition that this article introduces.
The Human Agency Scale (BMT-04.01). Autonomy settings as the operational expression of domain consent, governing how much the system acts within its authorized scope.
The Consent Architecture (BMT-05.05). The technical implementation of consent propagation in the memory and personalization layer.
The Audit Trail (BMT-07.04). How consent grants, revocations, modifications, and lucid window confirmations are logged and made accessible to the person.
Technical Appendix BMT-04.03-A is available to partners and investors at partners.bluemirror.tech.