Eleanor Briggs is seventy-eight years old. She lives alone in a one-bedroom apartment at a PACE facility in Providence, Rhode Island. She has congestive heart failure, mild cognitive impairment, and a daughter in Seattle who calls twice a week. On her kitchen counter sits a small device about the size of a hardcover book. She calls it “my helper.” It is a BlueMirror Local Pane running the Zone 1 model portfolio. The PACE facility three floors below her apartment houses a Community Pane node. Her daughter set up the family coordination dashboard on her phone. Eleanor does not know what a deployment path is. She is on Path A.
Margaret Huang is seventy-one. She lives in her own home in San Jose. Her son installed the BlueMirror app on her smartphone last month after she was discharged from a three-day hospital stay for a fall. Margaret is sharp, independent, and skeptical of anything her son describes as “for your safety.” She uses the app primarily for medication management and to check whether her insurance covers the physical therapy her doctor recommended. Her neighborhood is served by a Community Pane node hosted at a nearby home health agency. Margaret does not know the node exists. She is on Path C.
Doris Palmer is eighty-three. She lives in a small town in rural West Virginia. She does not own a smartphone. She has a landline, a television, and a microwave. Her niece, who lives forty minutes away, enrolled her in BlueMirror through a Medicaid HCBS waiver program. Doris interacts with the system through an IVR interface on her landline. Every query she makes travels to Zone 3. There is no Community Pane node in her county. She is on Path F.
All three women have the same concierge. The same thirteen user-facing agents coordinate on their behalf. The same Mixture of Concierges routes their queries. The same deep-reasoning models in Zone 3 analyze their medication interactions, evaluate their benefits eligibility, and generate their care coordination recommendations. The product is the same product.
What the system did last month#
Eleanor’s concierge processed 847 interactions in March. Most were routine: morning medication confirmations, afternoon check-ins, evening safety monitoring through the environmental sensors connected to her Local Pane. The system detected a potential interaction between her new diuretic dosage and her potassium supplement and flagged it to her PACE care team. It coordinated three family dashboard updates to her daughter. It processed her request to understand a benefits letter from Medicare and produced a plain-language summary. It noticed a gradual change in her speech patterns over a two-week period and noted it in the cognitive monitoring record available to her care team, per her consent.
Margaret’s concierge processed 312 interactions. She uses the system less frequently than Eleanor, and her usage pattern is different: she asks direct questions, gets answers, and closes the app. The system managed her post-discharge medication schedule (seven medications, three with timing dependencies), answered fourteen questions about her physical therapy coverage, and coordinated two messages to her son through the family contact system. It detected that she had not refilled her blood thinner on schedule and sent her a reminder, then flagged the gap to her primary care provider’s office after 48 hours with no refill confirmation.
Doris’s concierge processed 203 interactions. Her usage is concentrated in morning and evening calls through the IVR system. The system manages her four medications, provides daily weather and safety information (her town has no public transit and she walks to the post office), and coordinates monthly check-ins with her niece. It processed her question about whether Medicaid covers a dental procedure her dentist recommended. It noticed she had mentioned knee pain in three consecutive morning calls and flagged the pattern to her primary care provider with her consent. It also detected a change in her call timing pattern: over the last two weeks, she had been calling 45 minutes later in the morning than her typical time, which the system noted as a potential indicator of sleep disruption or reduced mobility and included in the pattern report to her care provider.
The numbers differ because the subscribers differ. The architectural substrate differs because their hardware situations differ. The product capability does not differ. Eleanor’s 847 interactions and Doris’s 203 interactions reflect different usage patterns, different lifestyles, and different comfort levels with the technology. They do not reflect different product capabilities. Doris could ask every question Eleanor asks and receive the same reasoning depth in return.
What the system did not do#
Eleanor’s cognitive monitoring data, processed by the Cognitive State Estimator and the Confusion Detector, never left her apartment. Those models run on her Local Pane. The raw speech data that feeds the Voice Tone Analyzer and the Emotion Detector was processed locally and discarded after inference. What left her apartment was the structured output: metadata, flags, summaries. Her PACE care team received alerts, not recordings. Her daughter received dashboard updates, not transcripts. The environmental sensor data from her apartment was processed by Zone 1 and summarized before any upstream transmission. Eleanor’s privacy posture is architectural. The data does not leave because the compute is local.
Margaret’s cognitive data was processed on her phone. The Tiny LMs running in the BlueMirror app handled the Speech-to-Intent, Voice Tone Analyzer, and Emotion Detector models locally. The raw audio stayed on the phone. Structured outputs traveled to Zone 2 and Zone 3 for coordination and deeper reasoning. Margaret’s phone stores the inference outputs in an encrypted app sandbox that is deleted if the app is uninstalled. Her privacy posture is architectural, bounded by the phone’s own security model and battery life. When her phone is off, there is no local monitoring.
Doris has no local compute. Every interaction travels to Zone 3. Her voice data is processed by the commercial API that serves Zone 3 inference, under a healthcare data processing agreement that prohibits retention beyond the inference request lifecycle and prohibits training on her data. The DPA requires deletion confirmation. Doris’s privacy posture is contractual. It is real, it is enforceable, and it is different from Eleanor’s and Margaret’s.
The architecture does not pretend these three privacy postures are identical. They are not. Eleanor has hardware-enforced data residency. Margaret has device-enforced data residency with a smaller compute footprint. Doris has contractual protections without local compute. All three postures are genuine protections against specific threat models. The difference is in mechanism and in what an adversary would need to compromise to access the raw data. For Eleanor, the adversary needs physical access to her apartment or a compromise of the Local Pane device. For Margaret, the adversary needs access to her phone. For Doris, the adversary needs to breach the API provider’s infrastructure or compel disclosure through legal process that overrides the DPA.
The privacy architecture also differs in what the subscriber controls. Eleanor can disconnect her Local Pane device and halt all monitoring instantly. Margaret can uninstall the app. Doris can stop calling the IVR number. All three have the same consent revocation rights, but the immediacy and completeness of the data cessation varies with the deployment path. Eleanor’s local data stops being processed the moment the device powers down. Doris’s data stops being collected the moment she stops calling, but the Zone 3 provider retains inference logs for the contractual retention period before deletion.
Series 11 will make the equity argument for why this differentiation is acceptable: because the alternative is not better privacy for Doris, but no service at all. The architecture chooses to serve Doris with contractual protections rather than exclude her for lacking hardware. That is a design decision, not a limitation to apologize for.
The architectural promise#
The deepest reasoning the system can perform is available to every subscriber. Eleanor’s complex medication interaction analysis goes to Zone 3. So does Margaret’s insurance coverage question. So does Doris’s dental procedure query. Zone 3 is not a fallback for subscribers who lack local compute. It is the reasoning ceiling for all subscribers. The subscriber with a full Local Pane and Community Pane coverage still routes her hardest questions to Zone 3, because that is where the largest models and the full cross-domain reasoning capability reside.
The deployment path determines where routine inference happens, how much offline resilience the subscriber has, and what privacy mechanism protects her data. It does not determine the quality of the answer to any question the system can answer. A Path F subscriber asking about a drug interaction gets the same reasoning depth as a Path A subscriber asking the same question. The latency may differ. The privacy mechanism differs. The answer does not.
This is the architectural promise the deployment model makes. Not that every subscriber’s experience is identical in every dimension, because it is not. Eleanor has offline resilience that Doris does not. Margaret has local cognitive monitoring that Doris does not. Doris has neither, and when her internet goes down, she has no service until it returns. The architecture is clear about these differences because pretending they do not exist would undermine the trust the system needs to earn. The promise is that the intelligence ceiling is the same, the product is the same, and the differences are in infrastructure posture, not in care quality. The subscriber who has less hardware gets the same concierge. She gets different resilience and a different privacy mechanism. She does not get a worse product.
What comes next#
The reader now has the deployment architecture: three zones, six paths, three phases, and the failure modes that test them. The architecture is not a diagram. It is a set of decisions about where compute lives, who pays for it, what breaks when components fail, and what the subscriber experiences through all of it.
Series 10 builds the business case on top of this architecture. It maps the unit economics across the deployment paths, models the revenue that follows from the institutional channels described in BMT-09.03, and answers the question that PE evaluators ask after they understand the architecture: does it make money, and for how long?
Series 11 makes the equity argument that the architecture has been encoding throughout this series. The deployment model was designed to serve subscribers across a wide range of hardware situations without excluding anyone from the product. Series 11 examines that design decision, its consequences, and the trust architecture that makes it credible.
Series 12 describes what the platform becomes after senior care. The three-zone model, the six deployment paths, and the concierge architecture were built for aging adults, but nothing in the infrastructure is age-specific. The final series examines where the architecture goes when it outgrows its first population.