Diff: architecture/customer-hostability
From 9fca6cd to 9fca6cd
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Customer hostability" | title: "Customer hostability" |
| slug: customer-hostability | slug: customer-hostability |
| category: architecture | category: architecture |
| type: topic | type: topic |
| quality: complete | quality: complete |
| short_description: "Customer hostability is the architectural commitment that every PointSav artefact can run on the customer's own hardware, against the customer's own keys, with the customer's own audit ledger — making self-hosted deployment the canonical pattern, not a tier." | short_description: "Customer hostability is the architectural commitment that every PointSav artefact can run on the customer's own hardware, against the customer's own keys, with the customer's own audit ledger — making self-hosted deployment the canonical pattern, not a tier." |
| 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: |
| - ni-51-102 | - ni-51-102 |
| - osc-sn-51-721 | - osc-sn-51-721 |
| paired_with: customer-hostability.es.md | paired_with: customer-hostability.es.md |
| --- | --- |
| **Customer hostability** is the architectural commitment that every artefact a customer adopts can be run on the customer's own hardware, with the customer's own data, against the customer's own keys, with the customer's own audit ledger. The customer can fork it on day one. | **Customer hostability** is the architectural commitment that every artefact a customer adopts can be run on the customer's own hardware, with the customer's own data, against the customer's own keys, with the customer's own audit ledger. The customer can fork it on day one. |
| This is not a pricing tier or a deployment option. It is the shape of the substrate. A platform variant that requires hosted-by-vendor infrastructure to function is not customer-hostable by construction. | This is not a pricing tier or a deployment option. It is the shape of the substrate. A platform variant that requires hosted-by-vendor infrastructure to function is not customer-hostable by construction. |
| ## What self-ownership means | ## What self-ownership means |
| Three concrete commitments, each operationally testable: | Three concrete commitments, each operationally testable: |
| 1. **Self-hostable bootstrap.** Every platform service ships with a `bootstrap.sh` that brings the service up on the customer's own machine — no SaaS dependency, no provider login, no metered API. The pattern is established by the `infrastructure/local-slm/`, `infrastructure/local-doorman/`, and `infrastructure/local-knowledge/` precedents. | 1. **Self-hostable bootstrap.** Every platform service ships with a `bootstrap.sh` that brings the service up on the customer's own machine — no SaaS dependency, no provider login, no metered API. The pattern is established by the `infrastructure/local-slm/`, `infrastructure/local-doorman/`, and `infrastructure/local-knowledge/` precedents. |
| 2. **Per-tenant adapters in the customer's filesystem.** When the customer's adapter trains on the customer's corpus, the resulting `.lora` lives at `data/adapters/` inside the customer's substrate. It never traverses the vendor's network. Loss-of-adapter risk falls on the customer's backup discipline, not on the vendor's continued operation. | 2. **Per-tenant adapters in the customer's filesystem.** When the customer's adapter trains on the customer's corpus, the resulting `.lora` lives at `data/adapters/` inside the customer's substrate. It never traverses the vendor's network. Loss-of-adapter risk falls on the customer's backup discipline, not on the vendor's continued operation. |
| 3. **Customer-anchored audit ledger.** The apprenticeship corpus that records every editorial action and verdict lives at `data/training-corpus/apprenticeship/<task-type>/<tenant>/` inside the customer's substrate. Tenant-private records never leave the customer's infrastructure. | 3. **Customer-anchored audit ledger.** The apprenticeship corpus that records every editorial action and verdict lives at `data/training-corpus/apprenticeship/<task-type>/<tenant>/` inside the customer's substrate. Tenant-private records never leave the customer's infrastructure. |
| ## Why hyperscaler economics preclude this | ## Why hyperscaler economics preclude this |
| Hyperscaler economics depend on central training, shared trust roots, and provider-rooted attestation. Per-customer continued pretraining does not pencil at SMB scale on those economics: | Hyperscaler economics depend on central training, shared trust roots, and provider-rooted attestation. Per-customer continued pretraining does not pencil at SMB scale on those economics: |
| - Central training requires central data; customer-on-metal training requires the opposite. | - Central training requires central data; customer-on-metal training requires the opposite. |
| - Shared trust roots concentrate the regulatory burden at the provider; customer-anchored attestation distributes it to the customer. | - Shared trust roots concentrate the regulatory burden at the provider; customer-anchored attestation distributes it to the customer. |
| - Provider-rooted attestation makes a customer audit a vendor audit; customer-anchored attestation lets the customer audit themselves. | - Provider-rooted attestation makes a customer audit a vendor audit; customer-anchored attestation lets the customer audit themselves. |
| The platform is built so the customer's regulatory posture does not depend on the vendor's. A BCSC reporting issuer per `[ni-51-102]` who deploys the platform inside their own substrate can satisfy continuous-disclosure obligations against records they own and control. A vendor outage does not impair their ability to respond to a regulator's request. | The platform is built so the customer's regulatory posture does not depend on the vendor's. A BCSC reporting issuer per `[ni-51-102]` who deploys the platform inside their own substrate can satisfy continuous-disclosure obligations against records they own and control. A vendor outage does not impair their ability to respond to a regulator's request. |
| ## Bootstrap pattern | ## Bootstrap pattern |
| Each service ships with three artefacts: | Each service ships with three artefacts: |
| | Artefact | Purpose | | | Artefact | Purpose | |
| |---|---| | |---|---| |
| | `bootstrap.sh` | Brings the service up on the customer's machine — installs systemd unit, configures storage paths, sets defaults. | | | `bootstrap.sh` | Brings the service up on the customer's machine — installs systemd unit, configures storage paths, sets defaults. | |
| | `bootstrap.es.sh` | Spanish-language operator-friendly variant where applicable. | | | `bootstrap.es.sh` | Spanish-language operator-friendly variant where applicable. | |
| | `MANIFEST.md` | Declares what this deployment provides, the substrate version it inherits from, and the operational state. | | | `MANIFEST.md` | Declares what this deployment provides, the substrate version it inherits from, and the operational state. | |
| Three already in production: | Three already in production: |
| - `infrastructure/local-slm/` — local OLMo-3 inference | - `infrastructure/local-slm/` — local OLMo-3 inference |
| - `infrastructure/local-doorman/` — Tier-A routing on the workspace VM | - `infrastructure/local-doorman/` — Tier-A routing on the workspace VM |
| - `infrastructure/local-knowledge/` — wiki-engine bootstrap | - `infrastructure/local-knowledge/` — wiki-engine bootstrap |
| Each was built to the same shape so a platform-shaped customer substrate is predictable: the customer reads one bootstrap runbook and applies it across services. | Each was built to the same shape so a platform-shaped customer substrate is predictable: the customer reads one bootstrap runbook and applies it across services. |
| ## What customer hostability is not | ## What customer hostability is not |
| It is not "open source under a permissive licence." Permissive licensing is necessary but not sufficient. A permissively-licensed service that requires a hosted control plane to function does not satisfy customer hostability — the customer cannot fork it without forking the control plane. | It is not "open source under a permissive licence." Permissive licensing is necessary but not sufficient. A permissively-licensed service that requires a hosted control plane to function does not satisfy customer hostability — the customer cannot fork it without forking the control plane. |
| It is not "the vendor will host it for you." Vendor-hosted deployment is one operational option among several. PointSav runs `documentation.pointsav.com` because PointSav itself is the canonical-tier customer of every package it ships. Customer-hosted deployment is the canonical pattern; vendor hosting is a convenience. | It is not "the vendor will host it for you." Vendor-hosted deployment is one operational option among several. PointSav runs `documentation.pointsav.com` because PointSav itself is the canonical-tier customer of every package it ships. Customer-hosted deployment is the canonical pattern; vendor hosting is a convenience. |
| It is not "you can export your data." Data export is a feature. Customer hostability is structural — the substrate does not have a data-export feature because the data was already on the customer's hardware from the moment it was written. | It is not "you can export your data." Data export is a feature. Customer hostability is structural — the substrate does not have a data-export feature because the data was already on the customer's hardware from the moment it was written. |
| ## Forward-looking — federated continued pretraining | ## Forward-looking — federated continued pretraining |
| Per `[osc-sn-51-721]`, the language describing the federated continued-pretraining trajectory is forward-looking. The shape is in place; the operational throughput matures over time. | Per `[osc-sn-51-721]`, the language describing the federated continued-pretraining trajectory is forward-looking. The shape is in place; the operational throughput matures over time. |
| The trajectory: a customer's adapter trains on the customer's corpus inside the customer's substrate (Tier B Yo-Yo or the customer's own GPU host). Aggregated improvements may feed back to a shared base model when the customer chooses to contribute, under explicit consent. Customers who do not contribute continue to benefit from base-model improvements driven by customers who do, with no leakage of corpus contents either direction. | The trajectory: a customer's adapter trains on the customer's corpus inside the customer's substrate (Tier B Yo-Yo or the customer's own GPU host). Aggregated improvements may feed back to a shared base model when the customer chooses to contribute, under explicit consent. Customers who do not contribute continue to benefit from base-model improvements driven by customers who do, with no leakage of corpus contents either direction. |
| This is the federated-LoRA pattern adapted to per-customer data ownership. Reasonable basis: the federated-learning literature 2024–2026 and the LoRA-aggregation research surveyed in the [[language-protocol-substrate]] article. | This is the federated-LoRA pattern adapted to per-customer data ownership. Reasonable basis: the federated-learning literature 2024–2026 and the LoRA-aggregation research surveyed in the [[language-protocol-substrate]] article. |
| ## Operational test for customer hostability | ## Operational test for customer hostability |
| A new platform service is customer-hostable if a customer can: | A new platform service is customer-hostable if a customer can: |
| 1. Clone the relevant repos. | 1. Clone the relevant repos. |
| 2. Run `bootstrap.sh` on a machine they own. | 2. Run `bootstrap.sh` on a machine they own. |
| 3. Generate, store, and serve adapters from local disk. | 3. Generate, store, and serve adapters from local disk. |
| 4. Operate the service against the customer's data without ever contacting a vendor endpoint. | 4. Operate the service against the customer's data without ever contacting a vendor endpoint. |
| 5. Audit every request, response, and adapter-update locally. | 5. Audit every request, response, and adapter-update locally. |
| Each of these is testable in CI. A service that fails any test is, by definition, not customer-hostable yet — and the gap is treated as a defect, not a feature. | Each of these is testable in CI. A service that fails any test is, by definition, not customer-hostable yet — and the gap is treated as a defect, not a feature. |
| ## See also | ## See also |
| - [[language-protocol-substrate]] — the language model research that underpins the federated pretraining path | - [[language-protocol-substrate]] — the language model research that underpins the federated pretraining path |
| - [[anti-homogenization-discipline]] — the complementary discipline that keeps federated training from homogenising tenants | - [[anti-homogenization-discipline]] — the complementary discipline that keeps federated training from homogenising tenants |
| - [[compounding-substrate]] — the five structural properties that customer hostability enables | - [[compounding-substrate]] — the five structural properties that customer hostability enables |
| - [[contributor-model]] — how contributors interact with the open-substrate artifact ecosystem | - [[contributor-model]] — how contributors interact with the open-substrate artifact ecosystem |