Diff: substrate/knowledge-commons.es
From cd006de to cd006de
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Knowledge commons and service commerce" | title: "Knowledge commons and service commerce" |
| slug: knowledge-commons | slug: knowledge-commons |
| category: substrate | category: substrate |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: The economic model that separates what PointSav publishes freely from what it sells — public knowledge artifacts under open licenses, paid service at the point of multi-Totebox aggregation. | short_description: The economic model that separates what PointSav publishes freely from what it sells — public knowledge artifacts under open licenses, paid service at the point of multi-Totebox aggregation. |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-15 | last_edited: 2026-05-15 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: [] | cites: [] |
| references: | references: |
| - id: 1 | - id: 1 |
| text: "Creative Commons. 'About the Licenses.' Creative Commons, 2024." | text: "Creative Commons. 'About the Licenses.' Creative Commons, 2024." |
| url: "https://creativecommons.org/licenses/" | url: "https://creativecommons.org/licenses/" |
| - id: 2 | - id: 2 |
| text: "GitHub. 'Open Source Guides.' GitHub, Inc., 2024." | text: "GitHub. 'Open Source Guides.' GitHub, Inc., 2024." |
| url: "https://opensource.guide/" | url: "https://opensource.guide/" |
| paired_with: knowledge-commons.es.md | paired_with: knowledge-commons.es.md |
| --- | --- |
| The **Knowledge Commons / Service Commerce** model is PointSav's economic architecture. Knowledge artifacts — architecture definitions, published specifications, training recipes, adapter weights, and sanitised training corpus — are published under open licenses and freely reusable. [^1] The commercial threshold is crossed precisely when two or more Totebox Archives must be operated as a single coordinated system. Solo Totebox operation is sovereign infrastructure; multi-Totebox aggregation is paid service. | The **Knowledge Commons / Service Commerce** model is PointSav's economic architecture. Knowledge artifacts — architecture definitions, published specifications, training recipes, adapter weights, and sanitised training corpus — are published under open licenses and freely reusable. [^1] The commercial threshold is crossed precisely when two or more Totebox Archives must be operated as a single coordinated system. Solo Totebox operation is sovereign infrastructure; multi-Totebox aggregation is paid service. |
| The line between them is bright and structural. It is not a pricing decision — it follows directly from the architecture. | The line between them is bright and structural. It is not a pricing decision — it follows directly from the architecture. |
| ## Open Artifact Ecosystem | ## Open Artifact Ecosystem |
| The following artifacts are published at every MINOR version bump under open licenses: | The following artifacts are published at every MINOR version bump under open licenses: |
| | Artifact | License | | | Artifact | License | |
| |---|---| | |---|---| |
| | Architecture definitions and amendments | CC BY 4.0 | | | Architecture definitions and amendments | CC BY 4.0 | |
| | Published governance specifications | CC BY 4.0 | | | Published governance specifications | CC BY 4.0 | |
| | Citation registry (`citations.yaml`) | CC0 | | | Citation registry (`citations.yaml`) | CC0 | |
| | Sanitised trajectory corpus shard | CC BY 4.0 with redaction | | | Sanitised trajectory corpus shard | CC BY 4.0 with redaction | |
| | Adapter recipes (training scripts, hyperparameters) | Apache 2.0 | | | Adapter recipes (training scripts, hyperparameters) | Apache 2.0 | |
| | Constitutional adapter weights | Apache 2.0 | | | Constitutional adapter weights | Apache 2.0 | |
| | Engineering adapter weights | Apache 2.0 | | | Engineering adapter weights | Apache 2.0 | |
| | Design-system tokens, components, guidelines | Apache 2.0 | | | Design-system tokens, components, guidelines | Apache 2.0 | |
| Each MINOR bump produces a signed, versioned bundle pushed to `pointsav/factory-release-engineering` with a stable ID. The bundle is itself a citable artifact. Downstream deployments and Customers can pin against a specific bundle version and know what they are running. | Each MINOR bump produces a signed, versioned bundle pushed to `pointsav/factory-release-engineering` with a stable ID. The bundle is itself a citable artifact. Downstream deployments and Customers can pin against a specific bundle version and know what they are running. |
| ## The Commercial Aggregation Boundary | ## The Commercial Aggregation Boundary |
| A single Totebox running its own platform deployment is sovereign infrastructure. The Customer owns the substrate, the data, the adapter, and the runtime. Nothing about a single Totebox crosses the commercial threshold. | A single Totebox running its own platform deployment is sovereign infrastructure. The Customer owns the substrate, the data, the adapter, and the runtime. Nothing about a single Totebox crosses the commercial threshold. |
| The threshold is crossed when two or more Totebox Archives — or a Totebox Archive plus an external system in coordination — must be operated as one. Examples include: | The threshold is crossed when two or more Totebox Archives — or a Totebox Archive plus an external system in coordination — must be operated as one. Examples include: |
| - Querying across two regional Toteboxes for a consolidated report | - Querying across two regional Toteboxes for a consolidated report |
| - Federating a Customer's Totebox with a partner's Totebox for joint research | - Federating a Customer's Totebox with a partner's Totebox for joint research |
| - Routing Tier B requests to PointSav's hosted LLM capacity | - Routing Tier B requests to PointSav's hosted LLM capacity |
| - Participating in the adapter marketplace for adapter sharing | - Participating in the adapter marketplace for adapter sharing |
| The line is structural because aggregation requires crossing trust boundaries, identity boundaries, and operational boundaries that a single sovereign Totebox does not have. Customers pay for the substrate that crosses those boundaries, not for access to knowledge that has no boundary. | The line is structural because aggregation requires crossing trust boundaries, identity boundaries, and operational boundaries that a single sovereign Totebox does not have. Customers pay for the substrate that crosses those boundaries, not for access to knowledge that has no boundary. |
| ## Strategic Open Documentation | ## Strategic Open Documentation |
| Publishing the recipe does not threaten the business. The reasoning: | Publishing the recipe does not threaten the business. The reasoning: |
| **Extraction economics for SMBs are poor.** A small customer who reads the documentation and attempts self-implementation was never the addressable customer. Service customers pay because operational implementation, integration, compliance, and aggregation represent real work, not because the knowledge is gated. | **Extraction economics for SMBs are poor.** A small customer who reads the documentation and attempts self-implementation was never the addressable customer. Service customers pay because operational implementation, integration, compliance, and aggregation represent real work, not because the knowledge is gated. |
| **Public knowledge increases substrate value.** When the documentation is public and citable, downstream Customers have a stable reference for their adapters, their compliance posture, and their contributor onboarding. The substrate's reliability is what they pay for. | **Public knowledge increases substrate value.** When the documentation is public and citable, downstream Customers have a stable reference for their adapters, their compliance posture, and their contributor onboarding. The substrate's reliability is what they pay for. |
| **The commons is a recruiting funnel.** Contributors find PointSav through public artifacts. They join because the substrate is one they can build on. The `factory-release-engineering` bundle is the entry point. | **The commons is a recruiting funnel.** Contributors find PointSav through public artifacts. They join because the substrate is one they can build on. The `factory-release-engineering` bundle is the entry point. |
| **Public architectural artifacts resist capture.** A publicly versioned, signed, citable architecture cannot be acquired and quietly altered. The versioning and signing are the durability mechanism. | **Public architectural artifacts resist capture.** A publicly versioned, signed, citable architecture cannot be acquired and quietly altered. The versioning and signing are the durability mechanism. |
| ## Tri-Tier Contribution Framework | ## Tri-Tier Contribution Framework |
| The Knowledge Commons model operationally produces three contributor tiers: | The Knowledge Commons model operationally produces three contributor tiers: |
| **Core (4–7 people, PointSav employees)** — day-to-day stewardship of the substrate. Architectural decisions, apprentice-mode oversight for new model versions, customer-service operations. Small by design; the substrate's structural properties are intended to allow this tier to remain small as scale grows. | **Core (4–7 people, PointSav employees)** — day-to-day stewardship of the substrate. Architectural decisions, apprentice-mode oversight for new model versions, customer-service operations. Small by design; the substrate's structural properties are intended to allow this tier to remain small as scale grows. |
| **Paid contributors (50–100 people, PointSav-funded)** — project-tier engineering work paid by PointSav and executed via GitHub pull requests against the public substrate repositories. Per-jurisdiction export adapters, LoRA adapter authoring, customer-specific deployment provisioning, multi-Totebox aggregation services. Outcome-based contracts tied to Customer service revenue. | **Paid contributors (50–100 people, PointSav-funded)** — project-tier engineering work paid by PointSav and executed via GitHub pull requests against the public substrate repositories. Per-jurisdiction export adapters, LoRA adapter authoring, customer-specific deployment provisioning, multi-Totebox aggregation services. Outcome-based contracts tied to Customer service revenue. |
| **Open contributors (10,000+, CC/Apache-licensed)** — contributions to the public substrate via pull requests to `pointsav/factory-release-engineering`, the design system, the wiki engine, MCP server adapters, and TOPIC content in the content wikis. No CLA required for open-core contributions. [^2] Reputation accrues via the Trajectory Substrate's per-contributor attribution. A path to the paid tier exists for contributors whose work demonstrates recurring quality and operational fluency. | **Open contributors (10,000+, CC/Apache-licensed)** — contributions to the public substrate via pull requests to `pointsav/factory-release-engineering`, the design system, the wiki engine, MCP server adapters, and TOPIC content in the content wikis. No CLA required for open-core contributions. [^2] Reputation accrues via the Trajectory Substrate's per-contributor attribution. A path to the paid tier exists for contributors whose work demonstrates recurring quality and operational fluency. |
| The leverage of this structure is that the Open tier sustains features and coverage that a Core of 4–7 people could not maintain alone. Most substrate features are intended to ship via Open contribution; Core reviews and accepts; Paid implements commercial-tier extensions. | The leverage of this structure is that the Open tier sustains features and coverage that a Core of 4–7 people could not maintain alone. Most substrate features are intended to ship via Open contribution; Core reviews and accepts; Paid implements commercial-tier extensions. |
| ## Cross-Tier Operational Mobility | ## Cross-Tier Operational Mobility |
| The model is not fixed. An Open contributor whose recurring work demonstrates operational quality may be offered Paid contracts. A Paid contributor may in time move toward Core. Any contributor can fork, take their adapters and tenant data, and operate independently — the substrate is designed to make graceful exit the default, not litigation. | The model is not fixed. An Open contributor whose recurring work demonstrates operational quality may be offered Paid contracts. A Paid contributor may in time move toward Core. Any contributor can fork, take their adapters and tenant data, and operate independently — the substrate is designed to make graceful exit the default, not litigation. |
| ## See also | ## See also |
| - [[compounding-substrate]] — the five structural properties that make the substrate compound over time | - [[compounding-substrate]] — the five structural properties that make the substrate compound over time |
| - [[disclosure-substrate]] — the substrate-substitution pattern applied to continuous-disclosure platforms | - [[disclosure-substrate]] — the substrate-substitution pattern applied to continuous-disclosure platforms |
| - [[apprenticeship-substrate]] — the training mechanism that makes per-tenant corpus contribution valuable | - [[apprenticeship-substrate]] — the training mechanism that makes per-tenant corpus contribution valuable |
| - [[adapter-composition]] — how per-tenant adapters are composed and versioned | - [[adapter-composition]] — how per-tenant adapters are composed and versioned |