Beatrice Mensah runs a four-person software company in Nairobi that builds accessibility software for users with motor impairments. The company’s flagship product is a kitchen-task assistant for people with essential tremor and Parkinson’s. The software adapts food preparation guidance, kitchen automation, and ingredient handling techniques to the user’s specific tremor pattern, dominant-hand state, and fatigue progression across the day. Her team’s clinical advisors are an occupational therapist and a movement-disorder neurologist who consult on the adaptation algorithms.
Beatrice has spent two years selling the product as a standalone application. The sales have been good in the technology-comfortable segment of the target population. The product has not reached the larger segment, which is older users with movement disorders who do not adopt standalone applications easily. Distribution is the bottleneck. The product needs to reach users through a platform they already use, not through an app store they have to discover.
The BlueMirror SDK is one of the platforms her team is evaluating. The SDK promises distribution through BlueMirror’s subscriber base. The certification framework promises a credibility signal her customers can rely on. The revenue-sharing model promises a sustainable economic relationship rather than a one-time sale. What Beatrice is verifying is whether the platform’s technical and governance commitments match the promises, and what the boundary is between the SDK skill her team would build and the BGO Context Shards her clinical advisors might create separately.
The Developer SDK#
The SDK provides the tools and the integration interfaces for third-party developers to build skills that operate within BlueMirror’s deployment. A skill is a unit of capability that the agent layer can call: a kitchen-task assistant, a medication interaction reviewer, a church directory connector, a financial planning module, a language interpretation service.
Skills integrate at the L-layer (described in BMT-02.01). The architecture’s separation of the H-layer (one slow, deliberative brain per subscriber holding the full context) and the L-layer (many fast, specialized hands executing one task each) is the integration’s load-bearing pattern. The developer’s skill operates as an L-layer hand: it receives a structured request from the H-layer, executes its task, and returns a result. The developer’s skill does not see the subscriber’s full MoC context. It does not interact with the H-layer’s reasoning. It receives a privacy-filtered context package that contains exactly what the skill needs for the task and nothing more.
The skill declares three things in its manifest. The context requirements (what categories of context the skill needs to perform its task), the privacy classification (what sensitivity tier the skill operates at), and the target-zone preferences (where the skill prefers to execute given the three-zone architecture).
The context requirements are specific. Beatrice’s kitchen-task assistant skill would declare requirements for the subscriber’s tremor profile, current dominant-hand state, fatigue indicators, dietary constraints, and kitchen-layout context. The H-layer’s context packaging fulfills the request from the MoC, the privacy gate validates the release, and the package is delivered to the skill. The skill does not see the subscriber’s medication list (because the skill did not declare medication as a requirement and would not be granted it). The skill does not see the subscriber’s location history (same reason). The skill receives exactly what its declared scope requires.
The privacy classification governs the skill’s certification level (described below) and the audit treatment of its interactions. Skills handling clinical context are classified differently from skills handling routine context.
The target-zone preferences are how the skill participates in the three-zone deployment architecture. A skill that handles privacy-critical context (cognitive state, emotional state) targets Zone 1 execution where present. A skill that requires heavy inference but not the strictest residency targets Zone 2 where available. A skill that benefits from the deepest reasoning targets Zone 3. The actual zone selection at runtime depends on the subscriber’s deployment path and the skill’s compatibility with each zone. Some skills can run in any zone; some are constrained.
The Certification Program#
Skills are certified at three levels. The level reflects the stakes of the skill’s domain and the rigor of its validation requirements.
Basic certification covers skills in low-stakes domains: information retrieval, scheduling, content curation, hobby and interest support. The certification requires functional testing (the skill performs its declared function correctly on a battery of test cases), safety testing (the skill does not produce outputs that violate the platform’s safety filters), privacy testing (the skill respects its declared context scope and does not exfiltrate context beyond the scope), and bias testing (the skill performs comparably across subscriber demographic segments). The certification process is six to eight weeks for a typical skill and is conducted by BlueMirror’s certification team with automated and manual review.
Clinical certification covers skills in health-adjacent domains: medication tracking, symptom logging, care coordination support, nutrition planning, accessibility adaptation. Beatrice’s kitchen-task assistant would seek clinical certification because the recommendations the skill produces affect food safety for users with motor impairments. The certification adds clinical validity testing (the skill’s recommendations align with established occupational therapy and movement-disorder management guidance), expert panel review (a panel of three clinicians in the relevant specialty reviews a sample of skill outputs), and an extended observation period during initial deployment. The certification process is twelve to twenty weeks.
Medical certification covers skills that constitute clinical decision support meeting the FDA software-as-medical-device threshold. These skills require pre-market FDA clearance or de novo authorization in addition to BlueMirror’s certification. The certification process integrates with the regulatory submission and is twelve to thirty months depending on the FDA pathway. The skill cannot deploy until both certifications are complete. Few skills are in this category at platform launch; the category is reserved for skills whose function genuinely crosses the medical-device threshold.
The certification levels are not optional commercial tiers. The level is determined by the skill’s domain and function, not by the developer’s preference. A skill that operates in a clinical-adjacent domain cannot ship at basic certification by self-classification. The certification team’s domain review establishes the appropriate level.
Revenue Sharing#
The revenue split for SDK skills is calibrated to the certification level. The split reflects the platform’s cost of certification, the platform’s cost of supporting the skill, and the developer’s commercial economics.
Basic skills earn the developer 70% of the subscriber-attributable revenue from skill use; BlueMirror retains 30%.
Clinical skills earn the developer 60% and BlueMirror 40%. The additional 10% to the platform reflects the higher certification cost, the extended clinical support requirement, and the post-deployment observation cost.
Medical skills earn the developer 50% and BlueMirror 50%. The additional 10% reflects the shared regulatory cost, the ongoing post-market surveillance the medical category requires, and the higher liability exposure.
The revenue is attributable to the skill when the subscriber’s use of the skill is the proximate cause of the value delivered. The attribution model is documented in the SDK guide and audited annually. Developers receive monthly revenue statements showing the skill usage, the attributable revenue, and the split calculation.
The split applies across deployment paths. A skill that serves a Path A subscriber (with a Local Pane device) earns the same split as a skill that serves a Path F subscriber (Zone 3-only). The path determines the skill’s execution location, not the developer’s economics.
The Marketplace#
The subscriber experiences the SDK’s skills through the marketplace. The marketplace presents skills as capabilities: “kitchen-task assistance for users with tremor,” “Spanish-language genealogy research,” “Catholic parish directory and event scheduling,” “accessible home gardening guidance for low-vision users.” The subscriber browses, reviews recommendations, reads peer feedback from other subscribers in similar circumstances, and adds skills to her deployment.
The marketplace does not present skills as revenue models. The subscriber does not see the certification level or the revenue split. She sees the capability, the reviews, and any clinical credentials the skill carries (a clinical-certified skill displays its certification credential; a medical-certified skill displays both the BlueMirror certification and the FDA authorization). The financial relationship between the developer and the platform is the platform’s concern, not the subscriber’s.
The marketplace is path-aware. A skill that declares target-zone Zone 1 (and that requires Zone 1 for its function, not just preference) is presented only to subscribers whose deployment includes a Local Pane. A skill that can operate across all zones is presented to all subscribers. The path-awareness prevents the marketplace from offering a skill to a subscriber whose deployment cannot execute it; the subscriber does not encounter the disappointment of installing a skill that cannot function.
The discovery surface combines automated recommendation (based on the subscriber’s MoC and her current concerns) and explicit search. The recommendation engine respects the same privacy boundaries as the rest of the system: the H-layer reasons about which skills might serve the subscriber and presents them; the developer of a recommended skill does not learn that the subscriber considered the skill until the subscriber installs it. The recommendation is a private decision until the subscriber acts on it.
The BGO and SDK Boundary#
The marketplace presents both SDK skills and BGO Context Shards to the subscriber. The two categories serve different developer populations and follow different economic models. The boundary between them is the question Beatrice’s team has been working through.
A BGO Context Shard is the captured expertise of an individual practitioner. The retired oncology nurse who creates a clinical trial navigation Shard from her twenty-three years of practice is a BGO Sage. The retired aerospace engineer who creates a compressor stall diagnostic Shard from his thirty-one years of propulsion experience is a BGO Sage. The Shard embodies one person’s methodology in a structured, validated, portable form. The BGO economic model is forty-forty-twenty: 40% to the Sage, 40% to the platform, 20% to a viability fund that subsidizes subscribers who cannot pay retail (described in BMT-10.07).
An SDK skill is a software product built by an organization. Beatrice’s kitchen-task assistant is an SDK skill. Her company employs four people, contracts with clinical advisors, ships software updates on a release cycle, and operates a business around the product. The skill embodies the company’s collective work; no single individual is the methodology source. The economic model is the 70/30 to 50/50 split described above.
The distinction is entity type and intent, not content domain. A medication review function could be a BGO Shard (created by a retired pharmacist deploying her clinical methodology) or an SDK skill (created by a health technology company building a medication-interaction product). The function looks similar to the subscriber. The economics, the build process, the certification path, and the relationship to the platform differ.
The marketplace presents both without requiring the subscriber to understand the distinction. The subscriber searching for medication review support sees the available options, reads the reviews, considers the credentials, and chooses. The classification is the platform’s internal organization, not the subscriber’s decision burden.
For developers, the question of whether to build a BGO Shard or an SDK skill is answered by entity type and product structure. An individual practitioner deploying her personal methodology is a Sage. An organization building a software product is a developer. A developer whose product is essentially the packaging of one person’s expertise is, on review, often classified as a Sage with platform support rather than a developer. The classification decision happens at onboarding. The criteria are documented in the partner onboarding materials.
For Beatrice’s team, the classification is clear. Her company is a developer. Her clinical advisors, if they wished to deploy their personal occupational therapy methodologies through Shards, would be Sages with separate Shard agreements. The two categories could coexist in the marketplace and could even be composable: a future subscriber’s deployment could include Beatrice’s kitchen-task assistant skill (SDK) and an occupational therapist’s energy conservation Context Shard (BGO) working together on the subscriber’s morning routine.
The Platform Transition#
BlueMirror starts as a product. The thirteen concierge agents, the thirty domain models, the architectural substrate are all internal builds. The product works as a self-contained offering. The transition to platform happens when external developers build skills the internal team did not imagine.
The kitchen-task assistant for users with tremor is one example. The internal team did not have the clinical expertise or the product specialization to build it well. The genealogy skill that helps subscribers record family history with culturally appropriate prompts is another. The church directory skill that connects the subscriber to her parish community is another. The energy conservation Context Shard the occupational therapist might author is another. Each of these comes from a developer or a Sage who knows a domain better than BlueMirror’s team.
The transition is gated by the certification program. The platform does not accept any skill that can be built. It accepts skills that pass the certification bar. The bar is set by the platform’s commitment to safety, quality, and equity. A skill that does not meet the bar does not enter the marketplace, regardless of how compelling the developer’s product is in isolation.
Beatrice’s evaluation, when she finished it, concluded that the SDK was the right distribution path for her company’s product. The certification process would be longer than her team’s previous regulatory work but would be manageable within the company’s runway. The revenue model would scale better than the standalone application’s per-unit-sale economics. The platform’s commitments to safety, equity, and certification rigor were ones her company could live with, because they aligned with the commitments her clinical advisors had been making about the product all along. The decision her team made was to commit to the SDK as the primary distribution path and to retire the standalone application within eighteen months of skill certification. The platform transition was, for her company, a commitment to be part of the infrastructure rather than to compete with it.
Cross-References#
The Brain and the Hands (BMT-02.01). The H-layer and L-layer architecture that the SDK builds against.
The Partner Integration Guide (BMT-03.05). The trust and integration framework the SDK extends to third-party developers.
Where BGO Meets the Platform (BMT-08.04). The BGO architecture whose marketplace presence is alongside the SDK and whose economic model is the basis for the BGO-SDK boundary.
The 40/40/20 (BMT-10.07). The BGO revenue model that the BGO-SDK boundary connects to.
The Three-Zone Architecture (BMT-09.01). The compute deployment that the SDK targets through its target-zone preference declarations.
Technical Appendix BMT-12.05-A is available to partners and investors at partners.bluemirror.tech.