James Okafor needed a cardiology referral. His primary care physician, Dr. Adeyemi, identified an irregular rhythm during a routine visit and recommended evaluation by a cardiologist. The health concierge scheduled the appointment. The question that the Expert Exchange Layer had to answer was not a routing question. It was a privacy question. What does the cardiologist need to know about James to help him? And what does the cardiologist have no business knowing?
The cardiologist needs the cardiac history. The current medication list, complete, because drug interactions span the entire formulary, not just cardiac medications. The allergy list. The recent vital signs, particularly the heart rate variability and blood pressure trends from the wearable and home sensors. The symptoms James reported conversationally over the past three weeks, structured and time-stamped.
The cardiologist does not need James’s financial situation. She does not need his family dynamics, his grocery preferences, his entertainment habits, or his home maintenance schedule. She does not need his cognitive assessment scores unless the referring physician has flagged cognitive status as clinically relevant to the cardiac evaluation. She does not need to know that James is a BGO Sage with deployable propulsion engineering expertise. None of this information helps the cardiologist. All of it is personal. The system’s job is to draw the line.
Minimum viable context#
The context packaging architecture begins with a computation: what is the minimum information this expert needs to help this person with this specific query? The computation is called the Minimum Viable Context, and it runs through a five-step process for every expert interaction.
Step one is query classification. The infrastructure agent that manages routing classifies the incoming query by domain, urgency, and complexity. James’s cardiology referral is classified as healthcare, non-urgent, moderate complexity.
Step two is expert matching. The routing engine identifies the target expert and retrieves her capability schema, which includes her declared domain, her required context fields, and her optional context fields.
Step three is consent intersection. The system compares the expert’s required and optional context fields against the person’s active consent grants for this expert type, this domain, and this specific expert if a relationship already exists. Fields where the expert’s requirements and the person’s consent overlap enter the package. Fields where they do not overlap are flagged.
Step four is gap analysis. If required fields are blocked by missing consent, the system escalates to the person before the interaction proceeds. If optional fields are blocked, the system proceeds without them and notes their absence in the expert’s context package so she knows what was unavailable.
Step five is package assembly. The system extracts the approved data from the MoC, formats it for the target expert’s interface (FHIR for clinicians, structured JSON for AI agents, readable summary for personal circle experts), and stages it for transmission through the membrane.
The computation has two primary inputs.
The first input is the expert’s declared requirements. Every expert in the system, whether human or AI, has a capability schema that includes a required_context field and an optional_context field. The cardiologist’s required context includes cardiac history, medication list, allergy list, and current vital signs. The cardiologist’s optional context includes recent lab results, family cardiac history, and exercise tolerance data. Required context is what the expert cannot function without. Optional context is what improves the expert’s effectiveness but is not strictly necessary.
The second input is the person’s consent settings. The person has defined, through the consent architecture described in Series 04, which data categories she permits to be shared with which expert types. James has consented to sharing health data with his healthcare providers. He has not consented to sharing financial data with healthcare providers. He has consented to sharing his complete medication list, including over-the-counter supplements, with any clinician.
The minimum viable context is the intersection of these two inputs. The expert’s required context, filtered by the person’s active consents. If the expert requires data that the person has not consented to share, the system escalates. It tells the person: “Dr. Park (cardiologist) needs your cardiac history and medication list to prepare for your appointment. You’ve already consented to sharing this. She also requests your recent lab results, which you haven’t consented to share with specialists. Would you like to grant access for this appointment?” The person decides. The system does not override.
Three packaging levels#
The context package comes in three configurations, and the person’s agency level for the relevant domain determines which configuration is used.
At the minimal level, the expert receives only the query itself. No supporting context. The person asks a question. The expert answers based on whatever information the question contains. This level is used when the person is at FULL_HUMAN agency and has not explicitly authorized context sharing for this interaction. A person who asks her personal circle neighbor an electrical question at FULL_HUMAN gets no automatic context packaging. She tells the neighbor what she wants to tell him. The system routes the question. It does not supplement it.
At the standard level, the expert receives the query plus the required context from the capability schema, filtered by consent. This is the default for most professional interactions and AI agent queries. The cardiologist appointment described above uses standard packaging. The system assembles the context, presents it to the person for review if the agency level requires it, and transmits it through the membrane.
At the full level, the expert receives the query, the required context, and the optional context, all filtered by consent. This level is used when the person is at TRUSTED_DELEGATION for the relevant domain and has broadly consented to context sharing with the expert type. A person who has been seeing the same primary care physician for twenty years and has her healthcare at TRUSTED_DELEGATION may have full packaging enabled for that physician. The physician gets everything that helps, automatically.
The three levels are not fixed per expert. They are computed per interaction based on the current agency level and the current consent state. The same person may have standard packaging for a new specialist and full packaging for her longtime PCP. The system computes the appropriate level each time.
What the expert never sees#
The architecture defines explicit exclusions that apply regardless of packaging level.
The full MoC context is never exposed to any external expert. The Map of Context is the system’s internal representation of everything it knows about the person. No expert, human or AI, receives the raw MoC. Experts receive curated context packages derived from the MoC, shaped by the capability schema and consent filters. The distinction is not cosmetic. The raw MoC contains cross-domain correlations, temporal patterns, cognitive trajectory data, and preference models that would reveal far more about the person than any single expert needs. A cardiologist who received the raw MoC would learn about the person’s financial anxiety, her strained relationship with her son, and her declining interest in activities she once enjoyed. None of this helps the cardiologist treat her cardiac rhythm. All of it exposes her to judgment she did not consent to.
Medical conditions not relevant to the query are excluded. A cardiologist does not receive the person’s dermatology history. A psychiatrist does not receive the person’s dental records. Relevance is determined by the expert’s declared domain and the query’s classification. The system’s query classification engine, an infrastructure agent, tags each query with domain identifiers that drive context selection.
Financial information is excluded from all non-financial expert contexts. A physician does not learn the person’s income, savings, or debt status. The exception is when financial information is clinically relevant and the person has consented: medication affordability discussions, where the physician needs to know whether cost is a barrier to adherence, require the person’s explicit consent to share financial constraints with a clinician.
Cognitive assessment scores are excluded from all expert contexts unless the expert is the clinician managing cognitive care. The cognitive concierge’s evaluation of the person’s cognitive trajectory is sensitive information that could be used against the person in legal, financial, or social contexts. A financial advisor who learns that the person’s cognitive scores are declining might change his recommendations in ways the person has not authorized. The architecture prevents this by treating cognitive scores as a restricted data category with an explicit allowlist of recipients.
A worked example#
James’s cardiology referral produces the following context package. The system assembles it, presents it to James for review (he is at ADVISED for healthcare), and transmits it after his confirmation.
The package includes: cardiac history (no prior cardiac diagnoses, the irregular rhythm finding from the referring physician dated last week, family history of atrial fibrillation in his mother). Current medications (lisinopril 10mg, atorvastatin 20mg, aspirin 81mg, fish oil supplement, vitamin D supplement). Allergies (penicillin, documented reaction: rash). Recent vital signs from wearable and home sensors (heart rate trend for the past 30 days, blood pressure readings for the past 30 days, heart rate variability data for the past 14 days, flagged irregular rhythm detections with timestamps). Symptoms reported conversationally (shortness of breath during stairs on three occasions in the past month, episode of lightheadedness while gardening two weeks ago).
The package excludes: financial situation (pension income, Social Security, savings). Family dynamics (daughter relationship, grandchildren visit frequency). Grocery preferences. Entertainment habits. Home maintenance history. Cognitive assessment scores (within normal range, but excluded regardless). BGO Sage status and propulsion engineering expertise. Buying agent spending patterns. Social connection data.
James reviews the package on his phone. He sees a plain-language summary: “For your appointment with Dr. Park, we’re sharing your heart health history, medications, allergies, recent vital signs, and symptoms you mentioned. We’re not sharing your financial, personal, or cognitive information. Want to change anything?” James approves. The package transmits through the membrane with audit logging of the transmission.
Dr. Park receives a structured clinical summary formatted for her workflow. She does not interact with the BlueMirror system directly. She receives a FHIR-formatted document or, if her system does not support FHIR inbound documents, a structured PDF. The document contains the curated context, labeled as patient-authorized data from a personal health monitoring system. She reads it as she would read any referral packet, but this one includes 30 days of continuous vital signs that no referral packet has ever contained before.
What context packaging cannot do#
The system cannot guarantee that the expert uses the context appropriately. A physician who receives James’s medication list and shares it with a pharmaceutical sales representative has violated professional ethics and possibly HIPAA, but the BlueMirror system cannot prevent actions taken outside the membrane. The architecture controls what the expert receives. It does not control what the expert does after receiving it.
The system also cannot perfectly determine relevance for novel queries. The capability schema covers standard interactions. An unusual query that crosses domain boundaries (a cardiac question with nutritional implications that requires both the cardiologist’s input and the nutrition concierge’s context) may require the system to assemble a context package that does not fit neatly into any single expert’s declared requirements. The routing engine handles this by composing a hybrid context package, but the composition logic is imperfect for edge cases that the capability schema does not anticipate.
The architecture handles these limitations through the audit trail (every context transmission is logged and reviewable) and through the person’s ongoing ability to adjust consent settings based on her experience. If James discovers that his cardiologist seems to know something he did not intend to share, he can review the audit trail, verify what was transmitted, and adjust his consent settings for future interactions.
Cross-References#
BMT-03.03 Bounded Exploration. The membrane architecture that governs how external agents access person data, including the exploration bounds that context packaging operates within.
BMT-05.01 The Map of Context. The five-layer MoC hierarchy from which context packages are derived.
BMT-04.03 Contextual Consent. The consent architecture that governs what can be shared with which expert types.
Technical Appendix BMT-08.03-A is available to partners and investors at partners.bluemirror.tech.