Diff: architecture/foundry-doctrine-architecture.es
From 9fe89f6 to 9fe89f6
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "PointSav platform — architectural overview" | title: "PointSav platform — architectural overview" |
| slug: foundry-doctrine-architecture | slug: foundry-doctrine-architecture |
| short_description: "The PointSav platform constitutional charter encodes six foundational commitments governing engineering decisions: plain text and open source, structural sovereignty, optional AI, vendor-to-customer-to-deployments flow, continuous model training, and mandatory human checkpoint. Fifty-four numbered structural claims define the competitive position through properties that hyperscaler economics structurally forecloses." | short_description: "The PointSav platform constitutional charter encodes six foundational commitments governing engineering decisions: plain text and open source, structural sovereignty, optional AI, vendor-to-customer-to-deployments flow, continuous model training, and mandatory human checkpoint. Fifty-four numbered structural claims define the competitive position through properties that hyperscaler economics structurally forecloses." |
| category: architecture | category: architecture |
| type: topic | type: topic |
| quality: complete | quality: complete |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-25 | last_edited: 2026-05-25 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: foundry-doctrine-architecture.es.md | paired_with: foundry-doctrine-architecture.es.md |
| references: | references: |
| - id: 1 | - id: 1 |
| text: "NI 51-102 Continuous Disclosure Obligations — BCSC" | text: "NI 51-102 Continuous Disclosure Obligations — BCSC" |
| - id: 2 | - id: 2 |
| text: "OSC Staff Notice 51-721 Forward-Looking Information Disclosure" | text: "OSC Staff Notice 51-721 Forward-Looking Information Disclosure" |
| - id: 3 | - id: 3 |
| text: "OLMo 3 — Allen Institute for AI. allenai.org/blog/olmo3" | text: "OLMo 3 — Allen Institute for AI. allenai.org/blog/olmo3" |
| - id: 4 | - id: 4 |
| text: "seL4 Microkernel — Data61/CSIRO. sel4.systems" | text: "seL4 Microkernel — Data61/CSIRO. sel4.systems" |
| - id: 5 | - id: 5 |
| text: "Overture Maps Foundation. overturemaps.org" | text: "Overture Maps Foundation. overturemaps.org" |
| --- | --- |
| The [[pointsav-overview|PointSav]] constitutional charter encodes the principles, commitments, and structural claims that govern every engineering, operational, and editorial decision across the platform. The current release is v0.1.0 ALPHA, ratified 2026-04-30 under the `ps-administrator` signing identity. See [[foundry-doctrine-overview|the doctrine overview]] for the introductory framing. | The [[pointsav-overview|PointSav]] constitutional charter encodes the principles, commitments, and structural claims that govern every engineering, operational, and editorial decision across the platform. The current release is v0.1.0 ALPHA, ratified 2026-04-30 under the `ps-administrator` signing identity. See [[foundry-doctrine-overview|the doctrine overview]] for the introductory framing. |
| ## The Six Pillars | ## The Six Pillars |
| The platform is built on six foundational commitments that take precedence over any specific design decision or engineering convenience: | The platform is built on six foundational commitments that take precedence over any specific design decision or engineering convenience: |
| **Plain text, flat file, open source.** Every artifact produced by the substrate — knowledge graphs, audit ledgers, documentation, configuration, training data — is plain text. No binary-only stores, no proprietary formats that require a running service to read. | **Plain text, flat file, open source.** Every artifact produced by the substrate — knowledge graphs, audit ledgers, documentation, configuration, training data — is plain text. No binary-only stores, no proprietary formats that require a running service to read. |
| **Sovereignty is structural, not procedural.** Customer data and compute stay inside the customer's boundary by construction. Firewall rules, bearer-token confinement, and WORM append-only ledgers enforce sovereignty at the infrastructure level; no policy document is load-bearing. | **Sovereignty is structural, not procedural.** Customer data and compute stay inside the customer's boundary by construction. Firewall rules, bearer-token confinement, and WORM append-only ledgers enforce sovereignty at the infrastructure level; no policy document is load-bearing. |
| **Ring 3 is optional.** The AI inference ring ([[service-slm]] and the [[yoyo-compute-substrate|Yo-Yo compute substrate]]) is structurally optional. The deterministic substrate — knowledge graph, search, ingest, egress — functions completely when AI is disabled or unavailable. Optional Intelligence is a design constraint, not a marketing framing. | **Ring 3 is optional.** The AI inference ring ([[service-slm]] and the [[yoyo-compute-substrate|Yo-Yo compute substrate]]) is structurally optional. The deterministic substrate — knowledge graph, search, ingest, egress — functions completely when AI is disabled or unavailable. Optional Intelligence is a design constraint, not a marketing framing. |
| **Vendor → Customer → Deployments is the only flow.** Engineering source lives in `pointsav/*` canonical repos. Customer runbooks live in `woodfine/*`. Runtime instances are numbered and local-only. No reverse writes. No shortcuts through the layer boundary. | **Vendor → Customer → Deployments is the only flow.** Engineering source lives in `pointsav/*` canonical repos. Customer runbooks live in `woodfine/*`. Runtime instances are numbered and local-only. No reverse writes. No shortcuts through the layer boundary. |
| **Every session trains the model.** Every contributor session that produces output — diffs, briefs, editorial refinements, sysadmin interactions — generates a training tuple that accumulates in the [[apprenticeship-substrate|apprenticeship corpus]]. The substrate sharpens monotonically with use. | **Every session trains the model.** Every contributor session that produces output — diffs, briefs, editorial refinements, sysadmin interactions — generates a training tuple that accumulates in the [[apprenticeship-substrate|apprenticeship corpus]]. The substrate sharpens monotonically with use. |
| **Human checkpoint at F12 is mandatory.** [[architecture-decisions|SYS-ADR-10]] — the final human checkpoint before any state is committed to a verified ledger — is never bypassed. Automation serves the human; no automated path exists around F12. | **Human checkpoint at F12 is mandatory.** [[architecture-decisions|SYS-ADR-10]] — the final human checkpoint before any state is committed to a verified ledger — is never bypassed. Automation serves the human; no automated path exists around F12. |
| ## The Fifty-Two Leapfrog Claims | ## The Fifty-Two Leapfrog Claims |
| The doctrine enumerates 54 numbered structural claims that together constitute the platform's competitive positioning relative to hyperscaler software-as-a-service. Each claim identifies a structural property of the platform substrate that hyperscaler economics or architecture structurally foreclose — not a feature advantage, but a property that cannot be replicated without changing the underlying business model. | The doctrine enumerates 54 numbered structural claims that together constitute the platform's competitive positioning relative to hyperscaler software-as-a-service. Each claim identifies a structural property of the platform substrate that hyperscaler economics or architecture structurally foreclose — not a feature advantage, but a property that cannot be replicated without changing the underlying business model. |
| Representative clusters from the full claim set: | Representative clusters from the full claim set: |
| **Sovereignty and data ownership (claims #1–#11, #48, #54).** The customer's knowledge graph is the customer's [[customer-owned-graph-ip|intellectual property]]. The per-tenant [[worm-ledger-architecture|WORM ledger]] is customer-rooted. Export formats are open at day zero. The substrate runs fully — queries, audit, search, transfer of ownership — with no platform-side dependency. No hyperscaler SaaS can offer this without abandoning per-tenant hosting economics. | **Sovereignty and data ownership (claims #1–#11, #48, #54).** The customer's knowledge graph is the customer's [[customer-owned-graph-ip|intellectual property]]. The per-tenant [[worm-ledger-architecture|WORM ledger]] is customer-rooted. Export formats are open at day zero. The substrate runs fully — queries, audit, search, transfer of ownership — with no platform-side dependency. No hyperscaler SaaS can offer this without abandoning per-tenant hosting economics. |
| **Compounding substrate (claim #18).** [[compounding-substrate|Each unit of work]] — a commit, a session, an editorial pass, a training run — increases the capability of the next unit. Engineering work trains the engineering adapter; editorial work trains the [[language-protocol-substrate|language-protocol adapter]]; sysadmin interactions train the sysadmin adapter. The capability curve is monotonically increasing with work volume; the marginal cost of capability declines over time. | **Compounding substrate (claim #18).** [[compounding-substrate|Each unit of work]] — a commit, a session, an editorial pass, a training run — increases the capability of the next unit. Engineering work trains the engineering adapter; editorial work trains the [[language-protocol-substrate|language-protocol adapter]]; sysadmin interactions train the sysadmin adapter. The capability curve is monotonically increasing with work volume; the marginal cost of capability declines over time. |
| **Adapter composition algebra (claim #22).** At inference time the [[doorman-protocol|Doorman]] composes up to three [[adapter-composition|adapters]]: `base ⊕ tenant ⊕ protocol`. The resulting inference is tuned simultaneously to the base model's general capability, the tenant's domain vocabulary and operational patterns, and the current request's genre requirements. Per-tenant continued pretraining (claim #15) deepens the tenant adapter monotonically as the corpus accumulates. | **Adapter composition algebra (claim #22).** At inference time the [[doorman-protocol|Doorman]] composes up to three [[adapter-composition|adapters]]: `base ⊕ tenant ⊕ protocol`. The resulting inference is tuned simultaneously to the base model's general capability, the tenant's domain vocabulary and operational patterns, and the current request's genre requirements. Per-tenant continued pretraining (claim #15) deepens the tenant adapter monotonically as the corpus accumulates. |
| **Apprenticeship substrate (claim #32).** Code-shaped and prose-shaped work routes through the [[doorman-protocol|Doorman]] as a structured brief. The apprentice (local SLM) produces a candidate diff with cited reasoning. A senior identity issues a signed verdict. The (brief, attempt, verdict, final-diff) tuple lands in the [[apprenticeship-substrate|apprenticeship corpus]] and feeds the next training cycle. Shadow routing on every commit exercises the apprentice continuously. | **Apprenticeship substrate (claim #32).** Code-shaped and prose-shaped work routes through the [[doorman-protocol|Doorman]] as a structured brief. The apprentice (local SLM) produces a candidate diff with cited reasoning. A senior identity issues a signed verdict. The (brief, attempt, verdict, final-diff) tuple lands in the [[apprenticeship-substrate|apprenticeship corpus]] and feeds the next training cycle. Shadow routing on every commit exercises the apprentice continuously. |
| **Capability ledger substrate (claim #33).** Every kernel-mediated capability invocation emits a signed entry to a customer-rooted [[merkle-proofs-as-substrate-primitive|Merkle log]]. Revocation is a log entry. Ownership transfer is an apex-cosigning ceremony — no state migration, no service interruption. The deployment IS the [[capability-ledger-substrate|ledger]]; the running system is the materialization of the ledger state. | **Capability ledger substrate (claim #33).** Every kernel-mediated capability invocation emits a signed entry to a customer-rooted [[merkle-proofs-as-substrate-primitive|Merkle log]]. Revocation is a log entry. Ownership transfer is an apex-cosigning ceremony — no state migration, no service interruption. The deployment IS the [[capability-ledger-substrate|ledger]]; the running system is the materialization of the ledger state. |
| **Two-bottoms sovereign substrate (claim #34).** The platform runs on two kernel bottoms: [[sel4-microkernel-substrate|seL4]] (native, formally verified, AArch64-first) and NetBSD (compatibility, BSD 2-clause, boot-anywhere). The same `os-*` binaries run on either bottom via a thin shim. The customer boots the same substrate on a leased laptop today and on a verified production appliance for regulated records tomorrow, without re-provisioning. | **Two-bottoms sovereign substrate (claim #34).** The platform runs on two kernel bottoms: [[sel4-microkernel-substrate|seL4]] (native, formally verified, AArch64-first) and NetBSD (compatibility, BSD 2-clause, boot-anywhere). The same `os-*` binaries run on either bottom via a thin shim. The customer boots the same substrate on a leased laptop today and on a verified production appliance for regulated records tomorrow, without re-provisioning. |
| **Four-tier SLM ladder (claim #40).** Customers move through [[four-tier-slm-substrate|four product positions]] — Community (pure API gateway), Tier 1 (local 7B specialist), Tier 2 (vendor-hosted [[yoyo-compute-substrate|Yo-Yo]] 32B), Tier 3 (PointSav-LLM continued-pretrained specialist) — as their corpus accumulates and their compute appetite grows. The ladder is designed for breakout: every tier is customer-portable; no lock-in accrues at any rung. | **Four-tier SLM ladder (claim #40).** Customers move through [[four-tier-slm-substrate|four product positions]] — Community (pure API gateway), Tier 1 (local 7B specialist), Tier 2 (vendor-hosted [[yoyo-compute-substrate|Yo-Yo]] 32B), Tier 3 (PointSav-LLM continued-pretrained specialist) — as their corpus accumulates and their compute appetite grows. The ladder is designed for breakout: every tier is customer-portable; no lock-in accrues at any rung. |
| **Reverse-flow substrate (claim #52).** The same [[doorman-protocol|Doorman]] gateway and audit ledger that enforce inbound discipline also enforce outbound commercial flows — [[reverse-flow-substrate|data marketplace and ad exchange]] — as tenant-selectable, opt-in configurations. Monetization configuration is a contract decision, not an architectural rebuild. | **Reverse-flow substrate (claim #52).** The same [[doorman-protocol|Doorman]] gateway and audit ledger that enforce inbound discipline also enforce outbound commercial flows — [[reverse-flow-substrate|data marketplace and ad exchange]] — as tenant-selectable, opt-in configurations. Monetization configuration is a contract decision, not an architectural rebuild. |
| ## The Eight Cross-Industry Inventions | ## The Eight Cross-Industry Inventions |
| Beyond the structural claims, the doctrine draws on eight process inventions borrowed from established industries: | Beyond the structural claims, the doctrine draws on eight process inventions borrowed from established industries: |
| **Workspace Passport** (maritime) — every deployment carries a `MANIFEST.md` declaring origin, owner, and current state. **NOTAM** (aviation) — time-sensitive warnings read at every session start. **Recall Procedure** (pharmaceuticals) — defective vendor commits trigger recall notices into every downstream deployment inbox. **Bill of Lading** (shipping) — cross-realm handoffs generate append-only log entries. **Time-Vested Operation** (banking) — destructive operations post to a queue with a vesting date; execution is blocked until the date passes. **Apprentice Mode** (aviation/medicine) — new model versions run in shadow mode; graduate after N approved actions. **Integrity Anchor** (notarization) — monthly workspace state hashes posted to Sigstore Rekor public transparency log. **Constitutional Convention** (IETF/constitutional amendment) — doctrine major-version bumps require 30-day public comment in `factory-release-engineering`. | **Workspace Passport** (maritime) — every deployment carries a `MANIFEST.md` declaring origin, owner, and current state. **NOTAM** (aviation) — time-sensitive warnings read at every session start. **Recall Procedure** (pharmaceuticals) — defective vendor commits trigger recall notices into every downstream deployment inbox. **Bill of Lading** (shipping) — cross-realm handoffs generate append-only log entries. **Time-Vested Operation** (banking) — destructive operations post to a queue with a vesting date; execution is blocked until the date passes. **Apprentice Mode** (aviation/medicine) — new model versions run in shadow mode; graduate after N approved actions. **Integrity Anchor** (notarization) — monthly workspace state hashes posted to Sigstore Rekor public transparency log. **Constitutional Convention** (IETF/constitutional amendment) — doctrine major-version bumps require 30-day public comment in `factory-release-engineering`. |
| ## Workspace Structure | ## Workspace Structure |
| The workspace is itself a deployment of the substrate — `vault-privategit-source-1`. Three tiers flow in one direction: | The workspace is itself a deployment of the substrate — `vault-privategit-source-1`. Three tiers flow in one direction: |
| - `vendor/` — engineering source (`pointsav/*`) — GitHub-tracked | - `vendor/` — engineering source (`pointsav/*`) — GitHub-tracked |
| - `customer/` — guide catalog (`woodfine/*`) — GitHub-tracked | - `customer/` — guide catalog (`woodfine/*`) — GitHub-tracked |
| - `deployments/` — numbered runtime instances — local-only, gitignored | - `deployments/` — numbered runtime instances — local-only, gitignored |
| Three session roles operate the workspace: the hub session (workspace control plane, single at a time), the archive session (per engineering-repo plane, one per repo), and the project session (per project-cluster, multiple concurrent). The `.git/index` constraint — one session per index — is the hard race condition that determines this structure. | Three session roles operate the workspace: the hub session (workspace control plane, single at a time), the archive session (per engineering-repo plane, one per repo), and the project session (per project-cluster, multiple concurrent). The `.git/index` constraint — one session per index — is the hard race condition that determines this structure. |
| ## Continuous Disclosure Posture | ## Continuous Disclosure Posture |
| Every artifact written to the workspace — documentation, commit messages, code comments — is treated as potentially reviewable under continuous-disclosure obligations. Forward-looking statements about future capability, timeline, or customer outcome carry "planned"/"intended"/"may" framing, a stated reasonable basis, cautionary language, and material assumptions. This is not a compliance statement; it is the operational practice that makes compliance a byproduct.[^1][^2] | Every artifact written to the workspace — documentation, commit messages, code comments — is treated as potentially reviewable under continuous-disclosure obligations. Forward-looking statements about future capability, timeline, or customer outcome carry "planned"/"intended"/"may" framing, a stated reasonable basis, cautionary language, and material assumptions. This is not a compliance statement; it is the operational practice that makes compliance a byproduct.[^1][^2] |
| ## See also | ## See also |
| - [[compounding-substrate]] — the Compounding Substrate claim in detail | - [[compounding-substrate]] — the Compounding Substrate claim in detail |
| - [[three-ring-architecture]] — Ring 1, Ring 2, Ring 3 service composition | - [[three-ring-architecture]] — Ring 1, Ring 2, Ring 3 service composition |
| - [[single-boundary-compute-discipline]] — the Doorman as single boundary | - [[single-boundary-compute-discipline]] — the Doorman as single boundary |
| - [[system-substrate-doctrine]] — the capability ledger and two-bottoms claims | - [[system-substrate-doctrine]] — the capability ledger and two-bottoms claims |
| - [[slm-stack-architecture]] — the Rust stack that implements the Doorman | - [[slm-stack-architecture]] — the Rust stack that implements the Doorman |
| - [[yoyo-compute-substrate]] — Tier B cloud GPU burst substrate | - [[yoyo-compute-substrate]] — Tier B cloud GPU burst substrate |