Skip to main content
  1. The Investment Architecture/

The 40/40/20

·1798 words·9 mins

Grace Pemberton retired from aerospace engineering at 64. She spent thirty-one years designing propulsion control systems for commercial aircraft. Her expertise is specific, deep, and valuable to the small number of organizations that build or maintain turbofan engines. In retirement, she consults occasionally, charging $300/hour through her former employer’s alumni network. She works approximately ten hours per month. The rest of her knowledge sits idle.

When her financial advisor mentioned BlueMirror’s BGO marketplace, Grace’s first question was about the economics. Not whether she could participate. Whether the economics made participation worth her time. She had spent three decades in an industry where the revenue split determined whether a subcontractor survived or starved. She wanted to see the numbers before she built anything.

What the 40/40/20 means
#

The BGO Context Shard revenue model splits every transaction three ways. When Grace creates a propulsion methodology Context Shard and a regional airline’s maintenance division deploys it, the revenue distributes: 40% to Grace (the knowledge holder), 40% to the airline’s maintenance team (the knowledge receiver, in operational value and reduced training cost), and 20% to BlueMirror (the platform fee).

The 20% platform fee funds matching (connecting Grace’s expertise with organizations that need it), quality assurance (validating that the Context Shard delivers what it promises), marketplace operations (billing, dispute resolution, licensing management), and the infrastructure that hosts and distributes the Shard.

Grace’s deployment path does not affect her revenue share. A Path F subscriber whose inference runs entirely in Zone 3 earns the same 40% as a Path A subscriber with a full Local Pane and Zone 2 node. The BGO marketplace is path-independent because the value is in the expertise, not the hardware. Grace’s propulsion knowledge is worth the same whether her personal BlueMirror service runs on a dedicated device in her home or on a cloud instance. The Context Shard itself is hosted in Zone 3 marketplace infrastructure regardless of the Sage’s personal deployment path.

The transaction model is straightforward. An organization discovers Grace’s Shard through the BGO marketplace, reviews the quality metrics and peer assessment data, and licenses it for a defined period or a defined number of deployments. Each deployment generates a transaction. Grace receives 40% of each transaction automatically. The earning concierge tracks her cumulative earnings, manages tax reporting, and coordinates with the financial concierge to model benefits interactions before routing earnings to her chosen savings instrument.

Two savings instruments
#

BGO earnings flow into one of two purpose-built savings vehicles.

The Aging Savings Account is modeled on the structure of a Health Savings Account. Tax-advantaged contributions from BGO earnings accumulate over time and can be withdrawn for qualifying expenses: healthcare costs, home modifications, long-term care premiums, technology and connectivity expenses, and subscription costs including BlueMirror itself. The account provides financial durability. A Sage who earns $8,000/year through Context Shards and deposits $5,000 into her Aging Savings Account builds a reserve that compounds over her retirement.

For younger BGO participants (the 50–64 pre-retirement cohort who may begin building Context Shards before they are subscribers themselves), a 529-style career fund allows pre-tax earnings to accumulate toward career transition, continued education, or retirement preparation. The fund recognizes that BGO participation can begin before retirement and that the financial planning horizon extends in both directions. A 58-year-old corporate trainer who begins building Context Shards while still employed accumulates earnings that compound for years before she retires and becomes a full-time Sage.

Both instruments interact with existing benefits programs. The financial concierge (BMT-01.04) models the impact of BGO earnings on IRMAA brackets (which could increase Medicare Part B premiums), Medicaid asset limits, and other means-tested benefits before the subscriber activates earnings. The subscriber sees the net benefit, not just the gross earning.

Three compensation channels
#

Not every Sage works the same way. The BGO marketplace offers three channels that match different expertise levels and formality requirements.

Contributors work at state-funded rates through community organizations. The retired teacher who creates a literacy methodology Shard deployed by three school districts earns at a rate comparable to substitute teaching or community college adjunct compensation. The work is structured, the rates are known, and the administrative overhead is minimal. This channel serves Sages whose expertise is valuable but not specialized enough to command consultant rates.

Consultants work through former employers or professional networks. Grace’s propulsion methodology Shard, deployed through her former employer’s alumni consulting program, earns at rates set by the consulting relationship. The employer manages the client relationship. BlueMirror provides the Context Shard infrastructure. The Sage earns her 40% of each deployment.

Experts work through a BGO boutique firm structure for highly specialized, high-value expertise. The retired orthopedic surgeon whose joint replacement recovery protocol Shard is licensed by fifteen physical therapy practices earns through a formal professional services arrangement. The boutique firm structure provides liability coverage, quality certification, and professional credentialing that clinical and medical applications require.

Each channel serves a different formality level. The contributor channel is low-barrier, high-volume. The consultant channel is medium-barrier, medium-volume. The expert channel is high-barrier, lower-volume but higher per-transaction value.

Why 40/40/20
#

The split is calibrated against three requirements.

The knowledge receiver must capture enough value to justify engagement. An FQHC that deploys a medication review Context Shard from a retired nurse practitioner needs the operational value (reduced pharmacist consultation time, improved medication reconciliation accuracy) to exceed the licensing cost. At 40% of the transaction value going to the receiver as operational savings, the receiver’s return is positive. If the receiver captured less value, engagement would fall and marketplace liquidity would decline.

The knowledge holder must earn enough to sustain participation. Grace will not maintain, update, and refine her propulsion methodology Shard for a token payment. At 40%, her earnings are proportional to the value her expertise creates. The Sage who creates a high-demand Shard earns proportionally to its deployment. The incentive is to create valuable, well-maintained knowledge assets.

The 20% platform fee must cover the infrastructure that makes the marketplace work. Matching, quality assurance, billing, dispute resolution, licensing management, and the compute infrastructure for Shard hosting and distribution. The fee is a platform cost, not a tax. If the platform did not perform these functions, the marketplace would not exist, and the Sage would be back to charging $300/hour for ten hours per month through an alumni network. The alternative to the 40/40/20 split is not 100% to the Sage. The alternative is no marketplace, no matching, no passive income, and no scale.

The split was not chosen to maximize BlueMirror’s platform revenue. A 30/30/40 split would generate more platform income per transaction but would reduce marketplace participation on both sides. A 45/45/10 split would attract more participants but would not fund the matching and quality infrastructure that makes the marketplace trustworthy. The 40/40/20 split is the equilibrium point at which all three parties are adequately compensated and the marketplace sustains itself.

BGO versus SDK: the boundary
#

The BGO marketplace serves individuals deploying personal expertise. The SDK marketplace serves organizations building reusable tools. The distinction is entity type and intent, not content.

Grace, the retired aerospace engineer, creates a propulsion methodology Context Shard. She is a BGO Sage. Her revenue split is 40/40/20. The Shard represents her personal expertise accumulated over thirty-one years.

AeroTech Solutions, a small engineering firm, builds a turbine diagnostics skill that integrates with BlueMirror’s platform through the SDK. AeroTech is an SDK developer. Its revenue split is tiered: 70/30 for basic integrations, 60/40 for clinical applications, 50/50 for medical applications. The tiers reflect the increasing quality assurance, safety validation, and regulatory compliance cost that BlueMirror bears for higher-risk application categories.

A retired physician who creates a medication review Context Shard is a BGO Sage (40/40/20). A health technology company that builds a medication interaction checking tool is an SDK developer (50/50 medical tier). The retired physician’s Shard is her personal clinical judgment encoded as a knowledge asset. The company’s tool is a commercial product built for scale. Both create value on the platform. They operate under different economic models because their risk profiles, maintenance commitments, and quality assurance requirements differ.

The revenue split a person receives depends on which side of the boundary she is on. The boundary is clear because it follows entity type: individuals are Sages, organizations are SDK developers. A sole practitioner who incorporates does not become an SDK developer by filing articles of incorporation. The classification follows the nature of the expertise deployment (personal versus commercial product), not the legal entity.

The asset argument
#

For investors evaluating BlueMirror’s revenue model, the BGO marketplace creates a third asset alongside the technology platform and the services portfolio.

Subscription revenue is the first stream. Predictable, recurring, declining per-subscriber price offset by growing subscriber base. This revenue flows across all deployment paths.

Care coordination revenue is the second stream. Institutional payer contracts, provider-mediated billing, and value-based arrangements. This revenue is tied to the services portfolio and scales with the institutional channel. Also path-independent.

BGO marketplace revenue is the third stream. The 20% platform fee on Context Shard transactions. This revenue has a different growth trajectory (slower to start, dependent on marketplace maturity) and a different risk profile (dependent on Sage participation and buyer demand rather than subscriber count). It is also path-independent: a Sage’s earnings do not depend on her hardware, and a buyer’s purchase does not depend on the buyer’s deployment path.

Three revenue streams with different risk profiles, different growth trajectories, and different market drivers create a more resilient business than a single-stream subscription model. The subscription revenue is steady and predictable. The care coordination revenue is tied to institutional relationships. The BGO marketplace revenue is tied to knowledge marketplace dynamics. A downturn that affects one stream (an institutional payer reducing coverage) does not necessarily affect the other two (subscribers still subscribe, Sages still earn).

Grace’s propulsion methodology Shard was licensed by four organizations in its first year, generating $12,000 in annual income for her. Enough to cover her BlueMirror subscription at any rate tier, fund her Aging Savings Account, and replace the ten-hours-per-month consulting she had been doing through her alumni network with passive income that required occasional maintenance rather than active billing. The 40/40/20 split meant that the four organizations collectively captured $12,000 in operational value from her expertise, and BlueMirror earned $6,000 in platform fees from transactions it facilitated. Everyone earned. That was the point.

Cross-References
#

Where BGO Meets the Platform (BMT-08.04). The BGO-EEL integration architecture that enables Context Shard creation and distribution.

The Purpose and Deployment Concierge (BMT-01.13). The concierge agent that helps subscribers identify and develop their BGO participation.

The Earning Concierge (BMT-01.11). The concierge agent that manages BGO earnings, routing, and financial interaction modeling.

The SDK Marketplace (BMT-12.05). The organizational developer marketplace that operates alongside BGO under different revenue terms.