Building Blocks

• Adapter composition algebra

  The operating-system metaphor for AI in PointSav — the Doorman as kernel, adapters as processes, service-content as filesystem — and the composition algebra that assembles per-request intelligence from versioned, customer-owned LoRA adapter layers.

• Apprenticeship substrate

  Platform mechanism routing work through a local Small Language Model first, capturing signed senior verdicts as preference pairs for continued pretraining.

• Brief queue substrate

  A durable file-backed queue that makes idle-shutdown Yo-Yo compute viable without losing apprenticeship corpus capture data — the durability layer of the three-tier SLM substrate.

• Capability Geometry: seL4 Capability Authorization in Totebox Orchestration

  Capability Geometry is PointSav's term for seL4-based authorization that replaces mutable access-control policy with a formally proven, kernel-enforced capability DAG.

• Capability ledger substrate

  The Capability Ledger Substrate is the mechanism by which every access-control decision in a platform deployment becomes a cryptographically auditable event anchored to a log the customer controls.

• Citation substrate

  Platform-wide YAML citation registry with drift detection that makes provenance machine-auditable from regulatory instrument to published claim.

• 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.

• Compounding Doorman

  The operational pattern at the heart of sovereign AI substrates: a single service that mediates every external compute call, enforces sanitise-and-rehydrate discipline, logs every event to an audit ledger, and accumulates training signal that compounds the substrate over time.

• Compounding substrate

  Architectural pattern pairing open platform code and a deterministic AI-free data layer with an optional intelligence layer whose interactions compound as training signal.

• 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.

• Design-system substrate

  The design-system substrate is a self-hosted, customer-owned design-system engine that stores tokens and components in the customer's own Git repository, serves them through a machine-readable MCP endpoint, and uses the W3C DTCG token format to remain editor-agnostic.

• Disclosure substrate

  Mechanism making a version-controlled Markdown wiki the primary continuous-disclosure record, with signed authorship chains and cryptographic content hashes.

• Four-tier SLM substrate ladder

  A graduated sovereignty path for AI deployment: four customer tiers from a lightweight API gateway with no local model up through a domain-specialist AI service trained on the vendor's aggregated corpus, each tier adding capability without breaking the lower-tier guarantee.

• Knowledge commons and service commerce

  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.

• Knowledge-graph-grounded apprenticeship

  The Doorman consults the per-tenant knowledge graph before every inference request, producing training tuples where the graph and the model adapter co-evolve.

• Language-protocol substrate

  Editorial infrastructure encoding register, brand voice, document sub-type, and audience as reusable prompt scaffolding across four replaceable services.

• LLM substrate decision — OLMo 3 family

  The rationale for selecting OLMo 3 as the local and GPU-burst language model substrate: the only fully open model family — training data, training code, and checkpoints included — that permits continued pretraining and satisfies a Canadian public-company procurement posture.

• Location intelligence substrate

  A flat-file, open-GIS architecture enabling customers to own geographic datasets end-to-end using Apache-licensed open data and a Rust-aligned open-source rendering stack, with retail co-location analysis as the first deployed surface.

• MCP as substrate protocol

  Every Ring 1 and Ring 2 service exposes a Model Context Protocol server interface as its primary external contract, with the Doorman as the MCP gateway.

• Merkle proofs as a substrate primitive

  Merkle proofs are the cryptographic mechanism that lets the platform substrate guarantee — to any third party, without trust — that a specific record is part of an append-only log and that the log has not been rewritten between two observed points in time.

• moonshot-toolkit build orchestrator

  Rust-only build orchestrator for seL4 unikernel images — TOML spec to content-addressed manifest to bootable AArch64 elfloader, replacing Python and CMake.

• 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

  Organizational knowledge graph of people, companies, projects, and relationships — persistent semantic memory for answering business-state queries without re-reading sources.

• 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.

• 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.

• 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 environment.

• seL4 microkernel substrate

  Formally verified seL4 microkernel adopted as the L1 kernel for all PointSav operating systems, guaranteeing memory isolation and capability-based permissions structurally.

• seL4 Unikernel Substrate for os-console

  os-console is intended to run as a seL4 Microkit unikernel image in its final production form, compiling application code directly with a formally verified kernel to eliminate general-purpose OS attack surface.

• Single-boundary compute discipline

  Every AI inference request in a platform deployment routes exclusively through the Doorman, with bypass structurally prevented at the kernel level.

• Sovereign AI commons

  PointSav's market positioning as a steward of shared, open AI infrastructure for regulated small-to-medium businesses: five structural properties that large-scale cloud providers cannot offer without dismantling their own billing models.

• 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

  Establishes structural compatibility with MediaWiki reader and integrator conventions while deliberately declining API mimicry, maintaining substrate-native interfaces that reduce maintenance burden and avoid disclosure obligations tied to compatibility guarantees.

• System substrate architecture

  The kernel-level architecture beneath every PointSav service — a customer-rooted capability ledger that is the audit log, a two-bottoms sovereign OS strategy, and three mechanisms for time-bound capabilities, reproducible verification, and boot-anywhere recovery.

• Tier 0 customer-side sovereign specialist

  The Tier 0 Totebox is a sovereign specialist deployment running on the customer's own hardware with no required cloud dependency and a 1 GB total footprint.

• Tiered inference gateway — local-first AI routing

  A tiered inference gateway that routes AI requests through a local model first, escalating to remote GPU nodes and external APIs only when the local tier cannot serve — minimizing latency, cost, and data exposure while preserving full capability on demand.

• Trajectory substrate

  The platform mechanism that converts operational work — commits, sessions, operator feedback — into structured JSONL training tuples, routing them into a continued-pretraining corpus that improves the OLMo base model over time.

• 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.

• Yo-yo #1 nightly LoRA training pipeline

  The nightly two-phase pipeline on Yo-Yo #1: Phase 1 runs entity extraction for the business DataGraph; Phase 2 trains a LoRA adapter against engineering and apprenticeship corpora using QLoRA on a single L4 GPU.

• Yo-yo compute substrate

  The three-ring compute substrate that lets service-slm spin GPU inference capacity up and down while retaining state, accumulating skill, and producing an audit ledger of every compute event.