SubstrateIndex

The substrate category collects the platform's foundational mechanism concepts. Each substrate names a structural property the platform relies on — not a specific service or system, but a pattern that composes services, systems, and content into a coherent whole.

The category answers questions like: what makes the platform improve continuously without surrendering data ownership? what makes citations machine-auditable? what makes disclosures structurally compliant? what makes contributor work feed back into model training? The articles here describe the mechanisms; the architecture, services, and systems categories describe how they're realised in concrete components.

Start here: read Compounding substrate first — it is the canonical pattern PointSav stewards and the frame that makes the other substrates legible. Then read Apprenticeship substrate (how editorial verdicts feed continued pretraining), Citation substrate (how every claim resolves to an authoritative source), and Disclosure substrate (how forward-looking statements remain BCSC-compliant by structure).

Core named substrates

The nine named substrates: each names a structural property the platform depends on.

• Compounding substrate — Five structural properties that make every operational interaction a compounding training event across all tenant deployments.
• Apprenticeship substrate — Routes work through a local SLM, captures signed senior verdicts, and uses the resulting preference pairs as continued-pretraining signal.
• Citation substrate — Platform-wide YAML citation registry with drift detection; makes provenance machine-auditable from regulatory instrument to published claim.
• Disclosure substrate — Version-controlled Markdown with signed authorship chains and cryptographic content hashes produces structurally BCSC-compliant continuous-disclosure records.
• Trajectory substrate — Converts operational work — commits, sessions, operator feedback — into structured JSONL training tuples for continued pretraining.
• Language-protocol substrate — Four adapter families and eighteen genre templates encoding register, brand voice, and target audience as reusable prompt scaffolding.
• Design-system substrate — Self-hosted design-system engine storing tokens and components in the customer's own git repository; W3C DTCG token format; machine-readable MCP endpoint.
• Location intelligence substrate — Flat-file open-GIS architecture: Apache-licensed open data, Rust-aligned rendering stack, retail co-location analysis as the first deployed surface.
• Retail co-location tier methodology — The four-tier (Regional/District/Local/Fringe) gate system that scores retail co-location clusters — composition, catchment rank, civic support, non-overlap.
• Brief queue substrate — Durable file-backed queue that makes idle-shutdown Yo-Yo compute viable without losing apprenticeship corpus capture data.

The compounding Doorman and AI boundary

The single AI gateway that enforces the Ring 3 boundary, routes inference, and accumulates training signal.

• Compounding Doorman — The single service mediating every external compute call: sanitise-and-rehydrate discipline, audit ledger, accumulated training signal.
• MCP as substrate protocol — Every Ring 1 and Ring 2 service exposes a Model Context Protocol server interface as its primary external contract; the Doorman is the MCP gateway.
• Adapter composition algebra — The OS metaphor for AI in PointSav: Doorman as kernel, adapters as processes, service-content as filesystem; composition algebra for per-request intelligence from versioned LoRA layers.
• Knowledge-graph-grounded apprenticeship — The Doorman consults the per-tenant knowledge graph before every inference request; graph and adapter co-evolve as training tuples accumulate.
• Single-boundary compute discipline — Every AI inference request routes exclusively through the Doorman; bypass is structurally prevented at the kernel level.

Small Language Model stack

How the SLM tier is structured, selected, and trained.

• LLM substrate decision — OLMo 3 family — The rationale for OLMo 3: the only fully open model family — training data, training code, and checkpoints included — satisfying a Canadian public-company procurement posture.
• Four-tier SLM substrate ladder — A graduated sovereignty path from a lightweight API gateway with no local model up through a domain-specialist service trained on the vendor's aggregated corpus.
• Yo-yo compute substrate — The three-ring compute substrate that lets service-slm spin GPU inference capacity up and down while retaining state and producing an audit ledger of every compute event.
• Yo-yo #1 nightly LoRA training pipeline — The nightly two-phase pipeline: entity extraction for the business DataGraph (Phase 1) and LoRA adapter training against engineering and apprenticeship corpora using QLoRA on a single L4 GPU (Phase 2).
• TUI as corpus producer — Every terminal interaction with service-slm through the operator TUI is a curated training corpus contribution for the per-tenant adapter.
• Nightly DataGraph rebuild — The scheduled process that reconstructs the platform's knowledge graph from canonical flat-file sources each night, producing a fresh queryable substrate from deterministic inputs without AI involvement.
• Organizational knowledge graph — ontological memory for business operations — The organizational knowledge graph of people, companies, projects, and relationships — persistent semantic memory injected as context before every AI inference request.
• Tiered inference gateway — local-first AI routing — The tiered inference gateway that routes AI requests through a local model first, escalating to burst GPU nodes and external APIs only when needed.

Cryptographic and microkernel primitives

The formal verification and cryptographic foundations beneath every PointSav operating system.

• seL4 microkernel substrate — The mathematically formally verified seL4 microkernel as L1 kernel for all PointSav operating systems: structurally guaranteed memory isolation, zero buffer overflows, capability-based permissions.
• Merkle proofs as a substrate primitive — RFC 9162 Merkle proof primitives as the cryptographic floor of the platform's capability ledger; ledger validity verifiable without trust in any central authority.
• Capability ledger substrate — The mechanism by which every access-control decision in a Foundry deployment becomes a cryptographically auditable event anchored to a customer-controlled log; extends seL4's formally verified capability model with a Merkle transparency layer.
• System substrate architecture — The kernel-level architecture: a customer-rooted capability ledger that is the audit log, a two-bottoms sovereign OS strategy, and three mechanisms for time-bound capabilities and boot-anywhere recovery.
• Capability geometry: seL4 capability authorization in Totebox orchestration — PointSav's term for seL4-based authorization that replaces mutable access-control policy with a formally proven, kernel-enforced capability DAG.
• moonshot-toolkit build orchestrator — Rust-only build orchestrator for seL4 unikernel images — TOML spec to content-addressed manifest to bootable AArch64 elfloader binary, replacing Python and CMake.
• seL4 AArch64 QEMU substrate target — Hardware foundation for the unikernel platform — formally verified seL4 on AArch64 with QEMU's virt machine as the development, testing, and CI target.
• seL4 Unikernel Substrate for os-console — os-console's intended production form: a seL4 Microkit unikernel image compiling application code directly with a formally verified kernel, eliminating general-purpose OS attack surface.

Sovereignty and customer ownership

What the platform makes freely transferable, customer-owned, and vendor-independent.

• Sovereign AI commons — PointSav's market positioning as a steward of shared open AI infrastructure for regulated SMBs: five structural properties that large-scale cloud providers cannot offer without dismantling their own billing models.
• Knowledge commons and service commerce — The economic model that separates what PointSav publishes freely from what it sells: public knowledge artifacts under open licences, paid service at the point of multi-Totebox aggregation.
• Customer-owned graph IP — The per-tenant knowledge graph and trained adapter weights are the customer's intellectual property, portable and exportable without vendor approval.
• Tier 0 customer-side sovereign specialist — A sovereign specialist Totebox deployment running on the customer's own hardware with no required cloud dependency and a 1 GB total footprint.
• Substrate without inference — The base case — The Totebox Archive remains fully operational and freely transferable even when no AI inference tier is available; the deterministic substrate is the load-bearing foundation.
• Substrate-native compatibility — why the Action API shim was dropped — Structural compatibility with MediaWiki reader conventions while deliberately declining API mimicry, maintaining substrate-native interfaces.

Platform mechanics

Cross-cutting principles that apply across all substrate implementations.

• Code for machines first — Every inter-service contract, audit record, configuration, and ontology is machine-readable as a primary surface; human-facing interfaces are skins on machine-first APIs.
• Seed taxonomy as SMB bootstrap — Every tenant deployment provisions a four-part seed taxonomy — Archetypes, Chart of Accounts, Domains, Themes — as the knowledge graph bootstrap.
• Reverse-flow substrate — The Doorman gateway and audit ledger that enforce inbound data discipline are planned to also enforce outbound commercial flows — data marketplace and ad exchange — both opt-in per tenant.

See also

• Architecture — cross-cutting platform architecture
• Patterns — named design patterns realised on top of substrates