Diff: substrate/compounding-substrate.es
From 87518ba to 87518ba
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "The compounding substrate" | title: "The compounding substrate" |
| slug: compounding-substrate | slug: compounding-substrate |
| category: substrate | category: substrate |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: "The Compounding Substrate is the architectural pattern PointSav builds and stewards, combining five structural properties to produce a platform where every operational interaction generates training signal that compounds across all tenant deployments." | short_description: "The Compounding Substrate is the architectural pattern PointSav builds and stewards, combining five structural properties to produce a platform where every operational interaction generates training signal that compounds across all tenant deployments." |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-04-30 | last_edited: 2026-04-30 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: | cites: |
| - ni-51-102 | - ni-51-102 |
| - osc-sn-51-721 | - osc-sn-51-721 |
| paired_with: compounding-substrate.es.md | paired_with: compounding-substrate.es.md |
| --- | --- |
| Every operational interaction on the PointSav platform generates training signal that compounds across all tenant deployments — producing an AI system that improves continuously without any tenant surrendering ownership of their data. **The Compounding Substrate** is the architectural pattern that makes this possible: open, forkable platform code; a deterministic data layer that functions independently of any AI compute; and AI added as an optional layer any tenant can compose in or out. A curator — PointSav — periodically rolls accumulated signal into improved base models that flow back to all deployments without disrupting customer data ownership. The pattern applies the open-source foundation model (Apache Software Foundation) combined with the commercial distribution model (Red Hat) to AI substrate: the platform becomes open commons, and value migrates up to operations, integration, and a federated marketplace. | Every operational interaction on the PointSav platform generates training signal that compounds across all tenant deployments — producing an AI system that improves continuously without any tenant surrendering ownership of their data. **The Compounding Substrate** is the architectural pattern that makes this possible: open, forkable platform code; a deterministic data layer that functions independently of any AI compute; and AI added as an optional layer any tenant can compose in or out. A curator — PointSav — periodically rolls accumulated signal into improved base models that flow back to all deployments without disrupting customer data ownership. The pattern applies the open-source foundation model (Apache Software Foundation) combined with the commercial distribution model (Red Hat) to AI substrate: the platform becomes open commons, and value migrates up to operations, integration, and a federated marketplace. |
| This article describes the pattern, names the five properties, and explains the value-chain inversion that makes the model durable. | This article describes the pattern, names the five properties, and explains the value-chain inversion that makes the model durable. |
| ## Substrate Definition | ## Substrate Definition |
| A Compounding Substrate is an AI-substrate architecture where: | A Compounding Substrate is an AI-substrate architecture where: |
| 1. The substrate code is open and forkable. | 1. The substrate code is open and forkable. |
| 2. The deterministic data layer functions independently of any | 2. The deterministic data layer functions independently of any |
| AI compute. | AI compute. |
| 3. AI is added as an **Optional Intelligence Layer** that any | 3. AI is added as an **Optional Intelligence Layer** that any |
| tenant can compose in or out. | tenant can compose in or out. |
| 4. Every operational interaction generates training signal that | 4. Every operational interaction generates training signal that |
| compounds across the substrate's deployments. | compounds across the substrate's deployments. |
| 5. A curator (PointSav) periodically rolls accumulated signal | 5. A curator (PointSav) periodically rolls accumulated signal |
| into improved base models that flow back to all deployments | into improved base models that flow back to all deployments |
| without disrupting customer data ownership. | without disrupting customer data ownership. |
| ## Structural Platform Properties | ## Structural Platform Properties |
| Each property is a structural claim. Each names a specific reason hyperscalers cannot replicate it without dismantling their own business model. | Each property is a structural claim. Each names a specific reason hyperscalers cannot replicate it without dismantling their own business model. |
| ### 1. Customer Stack Custody | ### 1. Customer Stack Custody |
| Every customer owns their full stack: data, compute, adapters, and deployment composition. The substrate (code plus base model) is open under permissive licence. Data and adapters are the customer's intellectual property. | Every customer owns their full stack: data, compute, adapters, and deployment composition. The substrate (code plus base model) is open under permissive licence. Data and adapters are the customer's intellectual property. |
| Hyperscaler structural gap: their business is monetising the substrate as rented service. Substrate ownership erodes lock-in — the foundation of their billing model. | Hyperscaler structural gap: their business is monetising the substrate as rented service. Substrate ownership erodes lock-in — the foundation of their billing model. |
| ### 2. Decoupled Intelligence Tier | ### 2. Decoupled Intelligence Tier |
| The data and deterministic-processing rings function fully without the AI ring. Customers, community members, regulated buyers, and air-gapped sites can deploy a fully-functional PointSav data platform with zero AI compute. AI is additive value, not table stakes. | The data and deterministic-processing rings function fully without the AI ring. Customers, community members, regulated buyers, and air-gapped sites can deploy a fully-functional PointSav data platform with zero AI compute. AI is additive value, not table stakes. |
| Hyperscaler structural gap: their AI products tightly couple AI compute to data services. Decoupling them eliminates AI-compute revenue from any deployment that opted out. | Hyperscaler structural gap: their AI products tightly couple AI compute to data services. Decoupling them eliminates AI-compute revenue from any deployment that opted out. |
| ### 3. Dynamic Compute Routing | ### 3. Dynamic Compute Routing |
| `service-slm` is the platform's sole access-control gateway (the Doorman) — transparently routing among three compute tiers: local OLMo 3 7B on the customer's machine, multi-cloud burst (Cloud Run / RunPod / Modal / customer GPU), and external API (Claude / Gemini / GPT). The customer does not pick the tier; request shape and budget caps do. | `service-slm` is the platform's sole access-control gateway (the Doorman) — transparently routing among three compute tiers: local OLMo 3 7B on the customer's machine, multi-cloud burst (Cloud Run / RunPod / Modal / customer GPU), and external API (Claude / Gemini / GPT). The customer does not pick the tier; request shape and budget caps do. |
| Hyperscaler structural gap: each tier in their world is a separate billing relationship; their ecosystem does not span competitors' frontier models. They cannot abstract this routing. | Hyperscaler structural gap: each tier in their world is a separate billing relationship; their ecosystem does not span competitors' frontier models. They cannot abstract this routing. |
| ### 4. Privacy-Preserving Federation | ### 4. Privacy-Preserving Federation |
| Customers opt in to a federated LoRA marketplace (privacy-preserving aggregation per the SDFLoRA / FedEx-LoRA / HeLoRA research lineage). Every customer's improvements lift the substrate. The customer's own data never leaves; only adapter weights and KV cache blocks (without source data) flow into the federation. | Customers opt in to a federated LoRA marketplace (privacy-preserving aggregation per the SDFLoRA / FedEx-LoRA / HeLoRA research lineage). Every customer's improvements lift the substrate. The customer's own data never leaves; only adapter weights and KV cache blocks (without source data) flow into the federation. |
| Hyperscaler structural gap: per-tenant billing and compliance posture make cross-tenant pooling structurally illegal in their model. They cannot operate a true federation. | Hyperscaler structural gap: per-tenant billing and compliance posture make cross-tenant pooling structurally illegal in their model. They cannot operate a true federation. |
| ### 5. Curated Substrate Advancement | ### 5. Curated Substrate Advancement |
| OLMo 3 base flows to a PointSav continued-pretraining variant, released as the substrate for subsequent deployments. Each year's curated commons feeds the next year's base. By 2030, the federation-trained base is intended to be competitive with frontier proprietary models on the federation's domains. | OLMo 3 base flows to a PointSav continued-pretraining variant, released as the substrate for subsequent deployments. Each year's curated commons feeds the next year's base. By 2030, the federation-trained base is intended to be competitive with frontier proprietary models on the federation's domains. |
| Hyperscaler structural gap: they cannot let customers' data train a base model the customer subsequently owns. That destroys the lock-in that justifies their margins. | Hyperscaler structural gap: they cannot let customers' data train a base model the customer subsequently owns. That destroys the lock-in that justifies their margins. |
| ## Structural Value-Chain Inversion | ## Structural Value-Chain Inversion |
| Hyperscalers' value chain depends on the customer remaining on the vendor's substrate. The Compounding Substrate's value chain depends on the customer compounding *off* the vendor's substrate. The two business models are mathematically opposed; one cannot adopt the other without dismantling itself. | Hyperscalers' value chain depends on the customer remaining on the vendor's substrate. The Compounding Substrate's value chain depends on the customer compounding *off* the vendor's substrate. The two business models are mathematically opposed; one cannot adopt the other without dismantling itself. |
| This is the asymmetry that makes the pattern durable. A hyperscaler that copied the substrate-ownership property would erode its own lock-in. A hyperscaler that copied the optional-intelligence property would lose AI-compute revenue on every deployment that opted out. A hyperscaler that copied the federated-compounding property would breach its own per-tenant compliance contracts. | This is the asymmetry that makes the pattern durable. A hyperscaler that copied the substrate-ownership property would erode its own lock-in. A hyperscaler that copied the optional-intelligence property would lose AI-compute revenue on every deployment that opted out. A hyperscaler that copied the federated-compounding property would breach its own per-tenant compliance contracts. |
| ## Platform Stewardship Role | ## Platform Stewardship Role |
| Not vendor. Not gatekeeper. **Steward.** | Not vendor. Not gatekeeper. **Steward.** |
| - Steward of the protocol (governs the Doorman specification, | - Steward of the protocol (governs the Doorman specification, |
| runs the Constitutional Convention process aligned with the fundamental physics of 2030 hyperscaler infrastructure). | runs the Constitutional Convention process aligned with the fundamental physics of 2030 hyperscaler infrastructure). |
| - Steward of the base model (publishes the continued-pretraining | - Steward of the base model (publishes the continued-pretraining |
| variant, contributes upstream to OLMo when relevant). | variant, contributes upstream to OLMo when relevant). |
| - Steward of the marketplace (operates the federated LoRA pool, | - Steward of the marketplace (operates the federated LoRA pool, |
| takes a percentage of revenue-share LoRAs). | takes a percentage of revenue-share LoRAs). |
| - Operator-of-record (sells appliances plus integration plus | - Operator-of-record (sells appliances plus integration plus |
| support). | support). |
| - Reference customer (the PointSav development environment plus Woodfine Management Corp. — proof the | - Reference customer (the PointSav development environment plus Woodfine Management Corp. — proof the |
| pattern works). | pattern works). |
| The substrate is open commons; value migrates to operations, integration, and the LoRA library marketplace. | The substrate is open commons; value migrates to operations, integration, and the LoRA library marketplace. |
| ## Continuous Compounding Cycle | ## Continuous Compounding Cycle |
| Every action produces data; every data produces knowledge; every knowledge improves future actions. The loop runs continuously, in every tenant deployment, federated through the commons. For an operator evaluating the platform: each month of production use makes the AI layer materially better — without additional investment or data sharing beyond what the operator chose at onboarding. | Every action produces data; every data produces knowledge; every knowledge improves future actions. The loop runs continuously, in every tenant deployment, federated through the commons. For an operator evaluating the platform: each month of production use makes the AI layer materially better — without additional investment or data sharing beyond what the operator chose at onboarding. |
| ``` | ``` |
| operator + assistant does work | operator + assistant does work |
| ↓ produces | ↓ produces |
| git commits + file edits + session logs + conversation turns | git commits + file edits + session logs + conversation turns |
| ↓ ingested by | ↓ ingested by |
| service-fs[tenant] ← WORM ledger | service-fs[tenant] ← WORM ledger |
| ↓ parsed by | ↓ parsed by |
| service-extraction[tenant] ← deterministic | service-extraction[tenant] ← deterministic |
| ↓ writes structured to | ↓ writes structured to |
| service-content[tenant] ← knowledge graph | service-content[tenant] ← knowledge graph |
| ↓ indexed by | ↓ indexed by |
| service-search[tenant] ← full-text index | service-search[tenant] ← full-text index |
| ↓ queried by (when AI active) | ↓ queried by (when AI active) |
| service-slm ← Doorman; routes among 3 compute tiers | service-slm ← Doorman; routes among 3 compute tiers |
| ↓ trains (periodically) | ↓ trains (periodically) |
| LoRA adapters ← per-tenant skill packs | LoRA adapters ← per-tenant skill packs |
| ↓ contributes (opt-in, federated) | ↓ contributes (opt-in, federated) |
| federated LoRA pool ← commons benefit | federated LoRA pool ← commons benefit |
| ↓ rolls into (annually) | ↓ rolls into (annually) |
| base-model continued-pretraining ← curated by PointSav | base-model continued-pretraining ← curated by PointSav |
| ↓ ships in | ↓ ships in |
| appliance update ← every customer benefits | appliance update ← every customer benefits |
| ↓ used by | ↓ used by |
| operator + assistant in next session ← loop closes, compounded | operator + assistant in next session ← loop closes, compounded |
| ``` | ``` |
| ## 2030 Operational Trajectory | ## 2030 Operational Trajectory |
| Per `[ni-51-102]` continuous-disclosure language and the forward-looking discipline of `[osc-sn-51-721]`, the trajectory described below is `planned` and `intended`, not declarative-future. The shape is in place; the operational throughput matures over time. | Per `[ni-51-102]` continuous-disclosure language and the forward-looking discipline of `[osc-sn-51-721]`, the trajectory described below is `planned` and `intended`, not declarative-future. The shape is in place; the operational throughput matures over time. |
| By 2030, the Compounding Substrate aims to produce: | By 2030, the Compounding Substrate aims to produce: |
| - A base model competitive with hyperscaler frontier on regulated SMB tasks. | - A base model competitive with hyperscaler frontier on regulated SMB tasks. |
| - A federation of one hundred-plus customers, each owning their full stack, each contributing to and benefiting from the commons. | - A federation of one hundred-plus customers, each owning their full stack, each contributing to and benefiting from the commons. |
| - A protocol stack versioned twice through Constitutional Convention and validated in production. | - A protocol stack versioned twice through Constitutional Convention and validated in production. |
| - A market position where regulated SMB industries — small clinics, mid-sized law firms, regional financial advisors, real-estate operators — have standardised on this pattern because their compliance posture requires it and the substrate's design delivers it. | - A market position where regulated SMB industries — small clinics, mid-sized law firms, regional financial advisors, real-estate operators — have standardised on this pattern because their compliance posture requires it and the substrate's design delivers it. |
| The pattern does not displace hyperscalers in volume; they retain the unregulated long tail of cloud AI. The trajectory captures the regulated SMB market that hyperscalers cannot economically reach. | The pattern does not displace hyperscalers in volume; they retain the unregulated long tail of cloud AI. The trajectory captures the regulated SMB market that hyperscalers cannot economically reach. |
| ## See also | ## See also |
| - [[apprenticeship-substrate]] | - [[apprenticeship-substrate]] |
| - [[3-layer-stack]] | - [[3-layer-stack]] |
| - [[worm-ledger-architecture]] | - [[worm-ledger-architecture]] |
| - [[sovereign-ai-routing]] | - [[sovereign-ai-routing]] |
| - [[language-protocol-substrate]] | - [[language-protocol-substrate]] |