Index of record

• About PointSav Knowledge

  PointSav Knowledge is the engineering documentation wiki for the PointSav platform, serving engineers, architects, and institutional readers.

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

• AI routing and the linguistic air-lock

  AI routing in the PointSav platform processes language model requests through a local sanitization step before any data reaches external models, ensuring that internal structured data never travels to third-party servers in identifiable form.

• Anti-homogenization discipline

  Anti-homogenization discipline is the architectural posture that resists AI writing assistants pulling contributors toward a single voice, by defaulting to flagging potential issues rather than silently rewriting text.

• API key boundary discipline

  The rule that all external LLM API credentials belong exclusively at the gateway service and never at inference engines.

• app-console-email — communications cartridge

  app-console-email is the F3 communications cartridge for os-console. It provides inbox listing, message reading, and compose-and-send, operating through service-email as the Comm Diode between the operator and external correspondents.

• app-console-keys — console chassis and F-key framework

  app-console-keys is the always-installed base chassis of os-console. It provides the Cartridge trait that all console modules implement, the F-key navigation strip, the status bar, and the machine-based authorization client.

• app-console-slm — inference infrastructure monitoring console

  Terminal console cartridge showing live AI inference infrastructure state — model health, GPU nodes, queue depth, and daily spend — with per-tier kill switches.

• app-mediakit-marketing — WordPress-leapfrog marketing landing server

  app-mediakit-marketing is a Rust web server that delivers marketing landing sites using the WordPress vocabulary over a sovereign, flat-file architecture. Two live deployments serve home.woodfinegroup.com and home.pointsav.com.

• Application Programming Interface

  Defined interface that lets software systems communicate by specifying the available calls, how to make them, and the data formats exchanged.

• Apprenticeship substrate

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

• Archetypes and chart of accounts

  The Chart of Accounts and eleven archetypes are the two-part institutional taxonomy at the core of service-people and service-content, classifying personnel and documents by structural position and functional role rather than by volatile job-title strings.

• Architecture decisions

  Twelve binding architecture decisions — recorded commitments that govern how the PointSav platform is built and constrain all future engineering work on data handling, human oversight, system separation, and deployment custody.

• Architecture Overview — PointSav Platform

  A map of the PointSav platform's major architectural surfaces: compute substrate, software distribution, GIS intelligence, and the editorial pipeline.

• BCSC continuous-disclosure posture

  The operating discipline that treats every published artifact as potentially reviewable under Canadian securities continuous-disclosure obligations.

• BIM and real property surfaces

  BIM and real-property surfaces describes how PointSav treats Building Information Modelling as a first-class operational domain, with dedicated design-system tooling, ISO 19650 record-keeping discipline, and Totebox archive patterns.

• Brand typography and print standards

  The PointSav typography system separates web interface system fonts from institutional print typography, reserving open-licence serif typefaces for PDF generation and formal disclosures while the UI defaults to platform system fonts.

• Brand-family swatch

  The brand color families assigned to retail and institutional anchor categories in the platform's co-location GIS surface, providing consistent color-coded identifiers for map visualization and tabular data across accessible and standard display modes.

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

• Browser developer workbench

  Browser-based file editor in os-privategit presenting a three-column file tree, viewer, and editor for working across the cluster archive tree without a terminal.

• Business clustering service

  Parent-child spatial schema turning raw retail points into commercial clusters, so the GIS engine receives one entity per physical site instead of overlapping points.

• Canadian-simple copyright posture

  The platform's intellectual property vests in a single Canadian parent holding company by operation of Canadian Copyright Act § 13(3), without inter-company assignment, and is designed to be evolved incrementally as the corporate structure matures.

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

• Capability-based security

  Capability-based security is the access-control model PointSav uses at the hardware and operating-system layers, where each software component must hold a mathematically verified cryptographic token to communicate with any other component.

• Citation substrate

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

• Co-location methodology

  A structured approach for ranking hardware co-location candidates across jurisdictional, network, infrastructure, and cost dimensions, constrained first by regulatory requirements before other optimization occurs.

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

• Collaboration via passthrough relay — substrate pattern

  The passthrough relay pattern holds no document state on the server and forwards CRDT updates directly between clients, keeping the canonical git tree as the sole authoritative record of content at every point in time.

• Command ledger

  os-console is the human-facing surface of the PointSav platform — a Command Ledger that connects to a Totebox and renders its state to the operator via a keyboard-driven, F-key-structured interface.

• Compliance and continuous disclosure

  Compliance and continuous disclosure describes the regulatory frameworks the PointSav architecture addresses and the structural approach it takes to expose audit evidence continuously rather than through annual point-in-time certification cycles.

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

• Compute substrate

  os-infrastructure is the compute substrate that hosts PointSav operating systems across on-premises, leased, and cloud hardware. It creates the PointSav Private Network and bootstraps isolated fleets through the Genesis Protocol.

• Computer Appliance

  Computing device pairing hardware and software engineered for one well-defined function, deployed as a sealed unit that cannot be repurposed for general computing.

• Console input application

  app-console-input is the F12 surface in os-console — the structured input gate through which raw external files enter a Totebox before being sealed into the verified ledger.

• Contact

  Contact information for PointSav Digital Systems and Woodfine Capital Projects Inc.

• Contributing to PointSav Knowledge

  How to propose additions, corrections, and new articles for PointSav Knowledge.

• Crypto Payment and License Issuance Architecture

  The payment and license architecture behind software.pointsav.com — a custodian-free flow from on-chain USDC transfer to Ed25519-signed download token, with no customer accounts and no payment intermediary.

• Cryptographic ledgers

  Cryptographic ledgers are the immutable-state storage pattern used in the PointSav platform, enforcing mathematical immutability so that any alteration to a recorded fact breaks a verifiable cryptographic hash chain rather than requiring trust in administrative access controls.

• Cryptographic payload attestation

  Mechanism by which PointSav edge nodes prove published text integrity to any viewer via client-side SHA-256 hashing, independently verifiable by any auditor.

• Customer hostability

  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.

• Customer-first ordering

  The principle that a software vendor building something a customer will install should build it in the same order the customer will install it, on the same substrate the customer will use.

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

• Customer-tier catalog pattern

  Catalog-versus-instance discipline at the customer tier — reusable deployment definitions tracked in git, tenant-specific instances kept out of shared repositories.

• Data sovereignty and zero-state telemetry

  The platform collects only anonymized, IP-masked geospatial telemetry with no personally identifiable information retained, appending mandatory regulatory disclosure to public-facing interfaces.

• Data vault bookkeeping substrate

  An SMB bookkeeping and accounting architecture built on an immutable source vault, append-only journal, and structural separation between the bookkeeping record and any accounting tool.

• DataGraph Federation: From app-orchestration-slm to app-orchestration-graph

  How the PointSav platform federates sovereign per-archive DataGraphs through a single auditable gateway, and the conditions under which that gateway transitions to a dedicated service.

• Decode-time constraints

  Decode-time constraints are structural rules applied to a language model's output at each token-emission step, making banned vocabulary or structurally invalid responses mathematically impossible to produce rather than catching them after the fact.

• Deployment patterns

  Deployment patterns describes the six canonical configurations in which the PointSav substrate is deployed — each built on the same five primitives and OS surface, with the Chart of Accounts and compliance surface adapted per segment.

• Design color foundations

  Color token foundations for the PointSav design system — primitive palette, semantic aliases, and dark-mode pairings in DTCG format.

• Design motion foundations

  Motion token foundations for the PointSav design system — duration scale, easing curves, and reduced-motion variants in DTCG format.

• Design spacing foundations

  Spacing token foundations for the PointSav design system — base unit, geometric scale, component gap tokens, and layout margin tokens in DTCG format.

• Design system philosophy

  The PointSav design system is a self-hosted, customer-owned substrate running at design.pointsav.com that publishes design decision research alongside token values in DTCG format, prioritizing editor-agnostic interoperability and structured rationale.

• Design system — primitive vocabulary rationale

  Rationale for the primitive token layer's structural patterns — numeric color scales, semantic aliasing, and type splits — using PointSav-specific naming and values.

• Design typography foundations

  Typography token foundations for the PointSav design system — type scale, font stacks, fluid type variables, and reading rhythm tokens in DTCG format.

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

• Deterministic parser

  service-extraction is the Ring 2 central traffic controller that strips proprietary formatting from raw payloads, constructs structured Entity Bundles, assigns transaction IDs, and routes data to deterministic services or to service-slm for AI-assisted extraction.

• Developer Guide Index

  Developer guide index for the PointSav platform — task-oriented how-to guides organised by concern, from toolchain setup to session lifecycle.

• Diode standard

  Foundational security topology of the PointSav OS family — unidirectional command flow from authority to subject that removes lateral-movement attacks by design.

• Direct-payment settlement

  Payment for marketplace transactions is planned to flow directly from buyer to the customer-tenant; PointSav's share is a transaction fee at settlement, not a recurring subscription.

• Disclaimer

  Last updated: June 2026

• Disclaimers

  Disclaimer and terms of use for PointSav Knowledge, the engineering documentation wiki for the PointSav platform.

• Disclosure substrate

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

• Doctrine Invention #7 — The Integrity Anchor

  How Foundry's anchor-emitter binary posts a signed ledger checkpoint to Sigstore Rekor each month, providing independently verifiable, third-party evidence of workspace state.

• documentation.pointsav.com goes live — 2026-04-27

  The April 2026 TLS launch of documentation.pointsav.com: serving stack, placeholder posture, BCSC disclosure rationale, and verification commands.

• Doorman protocol

  The Doorman is the sole AI request boundary through which every inference call routes — enforcing sanitise-and-rehydrate discipline once, logging every call to an immutable audit ledger, and capturing the training signal that compounds the platform over time.

• Economic model — community and SMB customer tiers

  PointSav's two-tier commercial structure: a free Community tier that serves as an adoption funnel, and a paid SMB Customer tier targeting regulated small-to-medium businesses that hyperscale billing models cannot serve economically.

• Edge Computing

  Distributed computing paradigm that places computation and storage near data sources, cutting latency and bandwidth versus centralized cloud data centers.

• Edge deployment and boundary ingest

  The platform routes all external network connections through Ring 1 boundary-ingest services at the system edge, sanitizing incoming payloads before they reach core processing rings and recording clean, validated events to the audit ledger rather than raw network traffic.

• Editorial draft routing protocol

  Metadata classification layer that routes editorial drafts by their language_protocol declaration — which gateway processes an artifact and which vocabulary rules apply.

• Editorial language registers

  Three distinct language registers matching the PointSav wikis to their audiences: financial-press, developer-platform, and regulatory-specification prose.

• Editorial philosophy

  Every article is a learning resource that teaches understanding rather than retrieving facts, structured with encyclopedic lead paragraphs, internal linking, and consistent heading hierarchy suited to both human and machine readers.

• Egress service

  The data sovereignty service that physically transfers cloud-stored payloads to local cold storage, executing flow-through protocols that eliminate vendor-side data retention and cloud storage dependency.

• Elastic Compute #1 nightly LoRA training pipeline

  Nightly two-phase pipeline on Elastic Compute #1 that rebuilds the deployment DataGraph and trains LoRA adapter weights for the workspace language model.

• Favicon matrix and tab identity

  The platform uses inline SVG data URIs for browser-tab favicons — eliminating a network call, scaling without pixelation on every display, and assigning two distinct vendor and customer marks to make the entity behind every tab unambiguous at a glance.

• Federation via content mounts

  The pattern for combining curated editorial content with declarative mounts from domain-specific repositories into a single wiki surface — intended for Phase 6 of the knowledge engine.

• Five-stage sovereign supply chain

  Code path from contributor environment to production in five stages, with a double-blind air-gap keeping production credentials and data out of contributors' reach.

• Fleet aggregator

  os-orchestration is the commercial-tier operating system that lets a single operator see, query, and command many Totebox archives at once — the Fleet Aggregator for multi-entity portfolios and enterprise deployments.

• Fog Computing

  Distributed architecture placing compute, storage, and network services between edge devices and the cloud, defined by Cisco in 2012 and standardized as IEEE 1934-2018.

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

• FS anchor emitter

  Signed hourly checkpoints of the Write-Once-Read-Many ledger prepared for monthly anchoring to Sigstore Rekor, making ledger state auditable from outside the platform.

• FS architecture and the WORM backbone

  A per-tenant Write-Once-Read-Many immutable ledger serving as the tamper-evident backbone for all platform records, designed as a four-layer decoupled stack with a Linux runtime envelope today and a planned seL4 microkernel envelope.

• FS data lake

  service-fs is the foundational storage layer for the platform's GIS pipeline — a flat-file data lake that stores raw geospatial points ingested from open sources in separate retail and civic landing zones, available immediately to every downstream service without an ETL step.

• FS security and compliance posture

  Structural Write-Once-Read-Many storage posture where the engine itself denies record modification, satisfying SEC Rule 17a-4(f), eIDAS, and SOC 2 by architecture.

• Genesis protocol

  The Genesis Protocol is the fleet-bootstrapping sequence run by every os-infrastructure node at first boot, allowing nodes to reach a secure claimable state without any prior configuration or control plane dependency.

• Getting Started with the PointSav Platform

  An orientation to the PointSav developer platform: what it is, who it is for, and where to start.

• GIS orchestration application

  Stateless spatial analytics engine producing the Woodfine co-location rankings and interactive map — a pure function holding no canonical data.

• Gravity engine

  Synthesis engine reading raw Totebox payloads against an institutional taxonomy to generate structured documents, with human review on every verified ledger.

• Hardware reference

  Reference hardware profiles for developer workstations and fleet devices, specifying CPU architectural requirements including Haswell-generation x86_64 and fsgsbase support, and defining three infrastructure deployment patterns from on-premise to cloud.

• How app-orchestration-command publishes archive changes

  Publication mechanics under app-orchestration-command — how tested code crosses from archive branches into signed canonical history, with code-only filtering.

• How service-* Become seL4 Protection Domains on os-totebox

  Explains how os-totebox maps Rust service binaries to seL4 Protection Domains, covering the seven-PD stack, capability confinement model, startup ordering, and the two-bottom development path.

• How this knowledge base is organized

  A reader's map of the platform knowledge base: fourteen areas covering what PointSav builds, how it is built, why it can be trusted, and how customers run it — written so both engineers and financial readers can navigate it.

• How to add a node to a running fleet

  Adds a node to a running PPN fleet without restarting existing nodes, covering controller health checks, choosing a non-conflicting node ID, and starting its heartbeat agent.

• How to authenticate binary downloads

  Verifies an Ed25519-signed release from the PointSav distribution endpoint using a licence token, the detached signature, and the pinned publisher key before the binary runs.

• How to build a co-location map

  Renders tier-coloured co-location cluster markers on a MapLibre GL map by authenticating against the GIS API and fetching the cluster GeoJSON layer.

• How to configure a tenant namespace

  Configures an isolated tenant namespace: registers the tenant, sets quota limits, issues the root capability token, and verifies isolation and quota enforcement.

• How to configure the Doorman gateway

  Configures a single-instance Doorman gateway — tier upstream addresses, circuit-breaker thresholds, and verifying tier state through the health endpoint and console F9 dashboard.

• How to connect to the OSM data pipeline

  Ingesting a new retail or service chain from OpenStreetMap: write the ingest YAML, run the Overpass query, register the chain in the taxonomy, and rebuild the cluster layer.

• How to deploy a knowledge instance

  Deploys an instance of the app-mediakit-knowledge wiki server from a local content path: build the binary, write knowledge.toml, start the service, and verify it serves pages.

• How to enroll a PPN node

  Enrolls a machine into a PPN compute fleet by verifying the controller, starting the heartbeat agent, and confirming the node in the fleet inventory and WORM ledger.

• How to explore the console for the first time

  Orients a first-time operator to the console — the three-zone layout, status bar fields, Doorman health at F9, and the mandatory F12 input checkpoint.

• How to export structured data from the platform

  Exports platform data through four paths — DataGraph entity records, wiki Markdown, GeoJSON datasets, and tamper-evident ledger tiles — matched to the right layer and format.

• How to federate archives via content mounts

  Federates one knowledge instance's articles into another by declaring a mount in knowledge.toml, restarting the engine, and confirming they resolve without copying files.

• How to install the development toolchain

  Installs the pinned Rust toolchain with rustup, runs a baseline build and tests, and verifies the commit helper and SSH signing key needed before working in a monorepo archive.

• How to issue a capability token

  Issues an Ed25519-signed, time-bounded capability token for a device or service, from selecting the access scope to delivering and verifying the signed credential.

• How to navigate the console TUI

  Navigates the os-console terminal interface by keyboard — switching between F-key slots, reading the status bar for identity and SLM tier, and tracking which slot is active.

• How to open your first Totebox session

  Opens a first Totebox session from a paired device — selecting an archive, reviewing the inbox, starting a BRIEF task, and completing the shutdown sweep before closing.

• How to pair a new device

  Pairs a new device through machine-based authorization — generating a pairing code, cross-checking the hardware fingerprint on a trusted device, and assigning its access tier.

• How to query the DataGraph

  Queries the DataGraph for current entity state with query_datagraph and get_entity_context, navigating relationships, filtering by type, and handling a Tier A circuit outage.

• How to read and write Totebox archives

  Reads a Totebox archive's state at session start — inbox, session context, git status, NEXT.md — and writes changes through the staging-tier commit flow.

• How to read the command ledger

  Reads the append-only command ledger in the F12 Input Machine — interpreting entry types, verifying an entry against its checkpoint hash, and exporting entries as C2SP tlog-tiles.

• How to rotate keys and capability tokens

  Replaces an Ed25519 keypair and its capability token — generating a new keypair, issuing and verifying the new token, then revoking the old one after the transition window.

• How to run local SLM inference

  Starts the local SLM service, verifies Doorman health, and submits inference requests from the console or the API, with all prompt data staying on the deployment.

• How to run your first SLM query

  Opens the F9 SLM cartridge, confirms a live Doorman circuit, and submits a first prompt to the on-premises language model without sending data off the host.

• How to scale user access tiers

  Promotes users across the READ, USER, and INPUT access tiers by issuing new capability tokens and revoking the old ones, including a bulk pass for a whole team.

• How to self-host a deployment

  Provisions a self-hosted deployment instance — installing the verified gateway binary, writing the manifest, starting the gateway, and confirming it reports healthy.

• How to use declarative knowledge mounts

  Adds a secondary content repository to a running knowledge instance through a knowledge.toml mount, serving its articles under a URL prefix after a restart.

• How to use the F-key cartridge model

  Navigates the os-console F-key cartridge model — F3 email, F9 SLM inference, F12 Input Machine — where each compiled-in cartridge owns its slot's rendering and input.

• How to verify a WORM ledger entry

  Verifies a WORM ledger entry by checking its hash chain against the tile files and, where present, a signed checkpoint — using only a standard SHA-256 toolchain.

• Identity ledger

  service-people maintains the Totebox's deterministic identity ledger — the F2 surface in os-console and the source of truth for who appears in any payload across the Totebox, using an Anchor-Claim-Socket data model that never overwrites state.

• Identity ledger schema design

  The identity ledger defines three record types — Person, Anchor, and Claim — that together represent who is known to the system, how that identity was observed, and what attributes have been recorded, all persisted through WORM discipline with no AI involvement at any stage.

• Immutable storage and secure backup

  The platform enforces hardware-level append-only writes to provide an unalterable, tamper-evident record while supporting legal deletion through cryptographic key destruction and backup protection via cryptographically paired secondary drives.

• Input machine

  The Input Machine is the mandatory document ingest gate in os-console, bound permanently to F12 and backed by service-input on the Totebox Archive.

• Institutional small language model

  service-slm is the language-model service of the PointSav family — a quantised, narrow Small Language Model that translates institutional intent into deterministic outputs and routes every AI inference call through the Doorman audit boundary.

• Inverted index

  service-search is the Ring 2 full-text search service built on the Tantivy Rust library, providing microsecond retrieval across millions of files through a static binary inverted index that requires no active database process.

• Just Enough Operating System

  Operating system philosophy that reduces the OS to the minimum components a specific application needs, shrinking attack surface, memory footprint, and maintenance.

• 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 flow: training loop and ontological DataGraph

  Quality framework for the Totebox knowledge flow, asking whether LoRA adapters measurably improve the model and whether the DataGraph is an accurate ontology.

• Knowledge wiki home page — design intent

  How the documentation.pointsav.com home page inherits Wikipedia's structural conventions and extends them for engineering and financial-community readers.

• Knowledge wiki leapfrog architecture

  Wiki engine strategy serving flat Markdown from git with Wikipedia-shaped chrome, reaching muscle-memory parity before adding a citation and provenance layer.

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

• Leapfrog 2030 architecture

  Structural positioning thesis pairing customer-owned hardware, data, and adapter weights with transactional rather than subscription revenue.

• Learning Datagraph — SLM trajectory loop and apprenticeship queue

  Four-leg training loop turning operator interactions into training tuples — trajectory capture, apprenticeship queue, editorial DPO pairs, and correction distillation.

• Legal and IP structure

  The three-corporation topology governing intellectual property transfer from contributors to vendor to customer, with squash-and-merge as the atomic IP-transfer event and strict separation preventing unaudited code or operational-record exposure.

• Lightweight Linux Distribution

  Linux distribution engineered to use far less RAM and processor capacity than full-featured distributions, suited to constrained, embedded, and legacy hardware.

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

  Customer-owned flat-file GIS application for retail cluster analysis and strategic site selection, pairing an analytics engine with a rendering layer.

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

• Location intelligence UX design philosophy

  Conclusion-First interface philosophy rendering ranked tier conclusions rather than individual data points, so defensible commercial nodes surface immediately.

• Location Intelligence: Data Collection

  Ingesting VWH and PKS chain and infrastructure data into the location-intelligence pipeline from OpenStreetMap — runbook for re-ingesting or extending to new chains and countries.

• Machine-based authorization

  Machine-based authorization replaces username and password structures with the cryptographic pairing of physical hardware — the pair is the permission, and an entire class of remote credential theft is eliminated by structure.

• Mailbox atomicity — flock-based prepend and msg-id idempotency

  flock-guarded prepend and msg-id idempotency for flat-file mailboxes — how concurrent sessions serialize writes instead of silently losing messages.

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

• MediaKit knowledge application

  Single-binary Rust wiki engine serving documentation.pointsav.com — a view over a markdown tree where git commits are canonical and the running binary is disposable.

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

• Message courier service

  The message courier service is a headless web-automation engine that bridges internal identity ledgers with external web portals using runtime-injected adapters, keeping proprietary operational logic out of the open-source monorepo.

• Model tier discipline

  The discipline for routing work to the appropriate AI model tier — deep-think, implementation, or mechanical — to match model capability to work shape and control inference cost.

• Moonshot initiatives

  Moonshot initiatives are active engineering programs that build native replacements for quarantined third-party dependencies, with the goal of eliminating vendor lock-in and reducing the platform's external attack surface over 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.

• Multi-engine session coordination — session locks, boot_id, and role guards

  Session-lock protocol for concurrent AI engines on one host — boot_id staleness detection and role locks that keep two sessions off the same .git/index.

• News release typography and layout standards

  Enforces strict formatting rules for corporate news syndication: left alignment, title case discipline, geographic precision, and standardized header and dateline structures ensuring institutional authority across physical and digital mediums.

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

• Ontological governance

  Ontological governance describes the four self-healing control ledgers that govern how service-content classifies and accumulates knowledge, and the human-verification loop that keeps extracted identity data accurate before it is permanently committed.

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

• OS family — eight operating systems, one substrate

  PointSav builds eight purpose-built operating systems that share a common seL4 + Rust substrate. Each does one job, contains no features it does not need, and communicates through a common Diode-based protocol discipline.

• OS Mediakit

  Guest OS image for the vm-mediakit tier — isolates knowledge wikis, marketing sites, proofreader, and BIM orchestration from the vault and orchestration tiers.

• OS Network Admin

  os-network-admin is the control plane for a PointSav Private Network — providing WireGuard mesh routing, the node-join ceremony surface, and Diode-standard enforcement, without holding any archive-tier cryptographic authority.

• os-console Internal Architecture

  os-console hosts multiple independent TUI workspaces — cartridges — within a unified keyboard-navigation chassis. This article covers the Cartridge trait, capability negotiation, and the OSC 8 hyperlink protocol.

• os-console platform and cartridge architecture

  os-console is a single Rust binary with a cartridge architecture that provides keyboard-native access to Totebox Archive workflows through F-key-navigated modules.

• os-console: The Totebox Orchestration Browser

  os-console is the keyboard-native operator terminal for Totebox Orchestration, structurally analogous to a browser: it renders views from Totebox services without storing data on the operator's machine.

• os-infrastructure and os-network-admin: Distribution Model

  Two products are planned/intended for software.pointsav.com: os-infrastructure ($19 USDC, bare metal or cloud VM) and os-network-admin ($1 USDC, mesh control plane including Linux daemon mode). Each ships as three signed artifacts per version.

• os-infrastructure — PPN Node Operating System

  os-infrastructure is the operating system layer for PointSav Private Network nodes — its sole purpose is to set up, operate, and maintain a PPN node: managing WireGuard tunnels, hosting guest virtual machines, and exposing the operator control plane.

• os-orchestration: The Stateless Aggregation Layer

  os-orchestration coordinates work across Totebox Archives without storing customer data, keys, or audit records, acting as a stateless routing and brokering surface above the per-archive capability layer.

• os-privategit browser workbench

  app-privategit-workbench is a browser-based file editor included in os-privategit that provides a three-column interface for working with archive files without a terminal session.

• os-totebox: The Sovereign WORM Data Vault

  os-totebox is a Type I bare-metal operating system built on a formally verified seL4 microkernel, providing a WORM data vault whose storage immutability is enforced by a compiled capability graph rather than administrative policy.

• Pairing as permission

  PairingAsPermission is the Object Capability access-control model used in Totebox Orchestration: a cryptographic pairing between two nodes is the permission, and the absence of a pairing makes the connection structurally impossible — not access-denied, but no pathway.

• Per-archive branch model in app-orchestration-command

  Isolated per-archive branches under the app-orchestration-command coordinator — contamination prevention and independent pace ahead of publication to canonical.

• Per-user build cache discipline — preventing cross-user Cargo races

  Per-user partitioning of the shared Cargo build cache — why a per-developer CARGO_TARGET_DIR eliminates cross-user lock races and permission errors.

• Personnel and permissions

  Contributor identity and permissions expressed through cryptographic pairings rather than database roles — reachability requires a paired os-console.

• Places filtering service

  service-places filters raw civic and institutional infrastructure data to retain only regional-grade facilities — hospitals, universities, and major transport hubs — so GIS tier rankings reflect institutional-level concentration rather than local-service density.

• Platform architecture overview

  The platform is designed around distributed cryptographic consistency and sovereign bootability, with the capability to collapse a federated archive into a self-contained bootable image transferable across environments.

• PointSav architecture 2030 — an overview

  A faithful public summary of the PointSav constitutional charter — six pillars, fifty-two structural claims, eight cross-industry inventions, a three-tier compute model, three-ring service architecture, and the economic model that sustains it.

• PointSav encyclopedia — glossary and lexicon

  A canonical A-to-Z lexicon bridging standard industry terminology with PointSav platform concepts, providing authoritative definitions across technical, operational, and financial domains.

• PointSav GIS engine

  The PointSav GIS Engine is a customer-owned location intelligence platform built in Rust for offline-first, flat-file operation — a structural departure from geographic information systems that rely on centralised database instances and continuous network connectivity.

• PointSav Knowledge

  served as index.md per content-contract.md §1/§2/§7.

• PointSav Media Kit

  PointSav Digital Systems builds operating systems and services for regulated businesses

• PointSav platform — architectural overview

  Constitutional charter encoding six foundational commitments and fifty-four numbered structural claims that govern every PointSav engineering decision.

• PointSav Private Network

  The PointSav Private Network is the private WireGuard mesh that connects Woodfine's fleet nodes, providing encrypted transport without granting application-layer access to the services running on those nodes.

• PointSav Software Distribution Substrate

  A three-component system — release server, storefront, and payment watcher — that delivers compiled binaries against on-chain USDC payments, with no customer accounts and no subscription billing.

• PointSav — company overview and three-organisation structure

  PointSav Digital Systems is a technology vendor that builds sovereign, on-premise-capable operating systems for record-keeping and business administration. It sits within a three-organisation structure established by Woodfine Capital Projects Inc.

• PointSav-LLM

  The planned vendor-tier specialist AI model for substrate-sovereign SMBs — Tier 3 of the Four-Tier SLM Substrate Ladder, built by continued pretraining of OLMo 3 32B on the platform's federated apprenticeship corpus.

• PPN Architecture Overview

  Physical infrastructure plane of the PointSav stack, enrolling nodes into a cryptographically authenticated mesh and hosting the fleet's virtual machines.

• PPN command protocol

  The PPN Command Protocol is the 16-byte binary wire format used by os-network-admin to issue commands to os-infrastructure nodes across the WireGuard mesh, with no central broker and no session overhead.

• PPN Distributed VM Fabric

  The PPN Distributed VM Fabric is the planned extension of the per-node PPN hypervisor layer to a multi-node resource pool, intended to allow VMs to borrow compute from other mesh nodes and migrate across the fleet without per-move operator involvement.

• PPN Hypervisor Resource Pool

  The PPN hypervisor layer manages a per-node pool of CPU and RAM, dynamically allocating those resources across VMs using virtio_balloon for memory reclaim and cgroups v2 for CPU scheduling weights.

• PPN mesh architecture

  Hub-and-spoke WireGuard mesh connecting fleet nodes, with physical key custody on the operator's premises and Mesh Fusion node joining.

• PPN Tenant VM Isolation

  The PPN resource pool separates tenant workloads through namespace isolation, per-VM process isolation, and user-mode networking. Network-level subnet isolation is a planned milestone.

• PPN Three-Path seL4 Architecture

  Three sequential seL4 architecture options for PPN infrastructure nodes: Option B ships first (seL4 hypervisor + Linux guest), Option C adds WireGuard as a seL4 protection domain, and Option A targets a pure seL4 environment with no virtual machines.

• PPN VM Resource Pool Architecture

  The PPN VM resource pool is a three-service stack that provisions, places, and accounts for virtual machines across a heterogeneous WireGuard mesh spanning cloud and physical nodes.

• Pre-commit defense in depth — secret scan, size guard, helper-only gate

  Three-check pre-commit gate — helper-only commits, a 17-pattern secret scan, and a 2 MiB size guard — closing the incident classes behind leaked and mis-attributed commits.

• Privacy Notice

  Last updated: June 2026

• Private Binary Download Endpoint for Paying Customers

  The binary release server behind software.pointsav.com verifies Ed25519 license tokens and streams compiled binaries. Stateless by design — it holds no payment records, no customer data, and no signing keys.

• Private Git OS

  The operating system layer hosting the private Git infrastructure that underpins the development workspace, staging-tier commit flow, and canonical source repositories for all PointSav engineering repos.

• Private Platform Network: pooled compute from hardware you already own

  A Private Platform Network assembles machines a business already owns into a single encrypted compute pool. WireGuard network isolation is operating today; host-level isolation via seL4 is planned.

• Procurement overview

  What a regulated buyer acquires when deploying PointSav: hardware the customer owns outright, data the vendor never holds, no minimum-spend commitment, and compliance properties enforced by architecture rather than contractual promise.

• Proofreader console

  Operator-facing web interface for the service-proofreader pipeline, with two-tier design tokens for tenant branding and a pure-Rust apprenticeship distillation tool.

• Quick Start — First Session on the PointSav Platform

  A concise first-session guide for engineers and contributors evaluating the PointSav platform.

• Regional market definition

  Spatial containers on the location intelligence map — how settlements with co-location presence differ from Regional Markets, and why coverage is not market strength.

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

• Root files discipline

  The convention that every repository and project sub-clone keeps a small, explicitly enumerated set of canonical companion files at its root — and nothing else.

• Scaling coordinated development across many sovereign archives

  Coordination bottlenecks past twenty archives — publication serialization, message relay latency, operator load, and the path to per-archive process isolation.

• Scaling Coordinated Development Across Many Totebox Archives

  The app-orchestration-command topology is designed to grow. This article describes the coordination challenges that appear as the number of Totebox Archives increases, the mechanisms introduced to address them, and the planned trajectory toward per-archive process isolation.

• Security overview

  The platform's security posture: capability-based hardware isolation, the Diode unidirectional command-flow standard, the Doorman AI boundary, the WORM audit ledger, and how each property is enforced by architecture rather than by policy controls that can be misconfigured.

• Security Through Obscurity

  Reliance on secrecy of design or implementation as a primary security mechanism, rejected in professional practice since Kerckhoffs' principle of 1883.

• 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 Capability Topology

  In an seL4 system, security is determined by the shape of the capability graph — the topology. If component A has no capability path to component B, A cannot reach B by any means, a property proved by machine-checked formal verification.

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

• service-input — Document Ingest

  service-input is the Ring 1 document-intake service that accepts files at the per-tenant boundary, routes them through format-specific parsers, and writes normalized output to the per-tenant WORM ledger via service-fs.

• service-pointsav-link

  service-pointsav-link is the hot-pluggable adapter that connects an os-* Subject node to a PointSav fleet, with a default state of not installed and a clean-severance failure mode.

• service-slm graph store migration

  service-slm migrated its graph store from LadybugDB to SQLite for fleet nodes and integrates a nightly DataGraph rebuild that processes the operator data corpus through the Doorman into the property graph used for inference context injection.

• service-vm-fleet

  The fleet controller maintains a global view of node capacity across the PPN WireGuard mesh and handles placement decisions for virtual machine spawns.

• service-vm-tenant

  The tenant proxy enforces authentication, namespace isolation, quota limits, and an immutable audit trail at the customer boundary of the PPN VM resource pool.

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

• Six-tier sovereignty matrix

  Six fixed directory prefixes organising the PointSav monorepo by purpose, making the repository self-documenting and enforcing dependency hygiene by convention.

• SLM and Yo-Yo operational state

  How service-SLM's three-tier inference router and the Yo-Yo GPU burst VM operate, including the Doorman boundary, Tier A/B configuration, apprenticeship brief queue, and idle-shutdown cost ceiling.

• SLM as Totebox sysadmin and support centre

  How service-slm becomes the operational assistant and support centre for Totebox Archive and Totebox Orchestration deployments — the training strategy, the ten operational task families, and the four-stage pipeline from corpus capture to per-tenant LoRA adapters.

• SLM operationalization plan

  The strategic and operational plan for transitioning from externally hosted language model calls toward a per-tenant small language model substrate that heals through a compounding feedback loop.

• SLM Rust stack architecture

  The full Rust dependency graph and binary architecture for service-slm, the Doorman service that mediates every inference call in the PointSav platform.

• Source-of-truth inversion

  Source-of-truth inversion designates one storage layer as canonical (the authoritative, committed, signed record), a second as a derived view (rebuilt deterministically on demand), and a third as session-ephemeral (collaborative state discarded until explicit commit).

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

• Sovereign airlock

  The sovereign airlock is the staged-commit protocol that enforces a hard separation between work-in-progress staging identities and canonical repository identities — two staging authors for all commits, two admin identities for canonical pushes, with no direct path between them.

• Sovereign compliance appliance

  os-mediakit is the public-facing operating system in the PointSav family, hosting a company's marketing website, internal wiki, and compliance newsroom on a single sovereign appliance the company owns outright.

• Sovereign desktop

  os-workplace is the free desktop operating system in the PointSav family — a native-Rust sovereign desktop that pairs with a Totebox archive, runs on deliberate reference hardware, and serves as the adoption gateway to the commercial PointSav product line.

• Sovereign Mesh

  The sovereign mesh is the application-level WireGuard overlay that connects every PointSav Private Network fleet node, carrying signed binary commands without relying on a centralised message broker.

• Sovereign replacement initiative

  The Sovereign Replacement Initiative is the engineering governance program that tracks third-party dependencies, isolates them in quarantined component directories, and coordinates the active moonshot programs that build native replacements.

• Sovereign vault and service host

  os-totebox is the archive layer of the PointSav family — one isolated, kernel-level vault per entity, storing records as inert flat files with no delete operation and exposing them only through the Diode on command from os-console or os-orchestration.

• Spot VM Lifecycle — Single Controller and Kill Switch Pattern

  Single-controller lifecycle for the Yo-Yo spot VM — why one timer owns both start and stop, plus the sentinel-file kill switch for immediate operator override.

• Structural positioning

  Structural positioning is the PointSav approach to market differentiation: articulating architectural commitments that are visible in the code and topology, rather than making named-competitor comparisons or performance benchmarks.

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

• SYS-ADR-07: Zero AI in Ring 1

  SYS-ADR-07 prohibits AI inference from all Ring 1 boundary-ingest services, enforcing deterministic-only operations at the WORM write path to guarantee auditability and composability.

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

• Telemetry architecture

  The platform collects web traffic analytics from production edge nodes and routes them to a locally controlled processing environment through an encrypted path without passing through third-party cloud services.

• Template ledger

  Distribution mechanism in service-email-template that syncs one authoritative copy of every approved template to the operator's mail environment, eliminating version drift.

• The Preprint Notice

  What the mandatory preprint notice on every research paper means: a working draft, not yet peer-reviewed, subject to revision, and not a final or authoritative account.

• Three-binary architecture: os-console, os-totebox, os-orchestration

  Totebox Orchestration is delivered through three distinct binary operating environments — os-console, os-totebox, and os-orchestration — each with a distinct role, deployment target, and hosted application set.

• Three-layer architecture

  Strict one-way flow of PointSav deliverables through three layers — vendor monorepo, customer showcase catalogue, and private running instances.

• Three-layer stack

  The Three-Layer Stack is the infrastructure decomposition pattern used across PointSav deployments, separating raw computing capability, isolated platform execution, and secure operator access into three distinct layers.

• Three-ring architecture

  The durable composition pattern for the PointSav platform: three concentric rings with strict one-way dependencies, where the AI ring is structurally optional and the deterministic data pipeline operates fully without it.

• Three-stage editorial pipeline

  Service-level view of the proofreading pipeline — stage ordering by cost, degradation paths when dependencies fail, and independently verifiable finding sets.

• Three-tier contributor model

  The Three-Tier Contributor Model organises PointSav substrate contributors into Core (4–7 salaried engineers), Paid (50–100 contracted project contributors), and Open (10,000-plus public participants), with explicit mobility paths between tiers.

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

• Tier c key wiring

  The operational procedure for managing external API keys in the Doorman service — where keys live, how they are provisioned, how they rotate, and how a breach is contained.

• Tiered Entity Extraction Architecture

  The PointSav entity extraction pipeline runs three tiers in sequence on each document: Tier 0 provides fast extractive detection via GLiNER; Tier A provides a generative fallback via OLMo on CPU; Tier B provides GPU enrichment and records improvements as training signal.

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

• Totebox Archive

  A Totebox Archive is a sovereign data vault assigned to a single entity — packaged as a freely transferable bootable disk image, storing data as WORM flat files, and accepting queries only via the Diode Standard and PointSav Protocol.

• Totebox orchestration

  Totebox Orchestration describes the coordination layer that manages multiple Totebox data-archive containers, keeping software execution engines isolated from passive corporate ledgers across deployments.

• Totebox orchestration as the development environment

  PointSav's development environment is itself deployed as a Totebox Orchestration instance — the workspace that builds the platform runs on the same architecture the platform delivers to customers.

• Totebox session

  A Totebox Session is an AI-assisted contributor session opened within a single Totebox Archive — scoped to the archive's declared repositories, unable to write outside them, and the standard entry point for all development work in Totebox Orchestration.

• ToteboxOS

  os-totebox is the sovereign vault and service host in the PointSav OS family — the operating system that runs on a Totebox archive node and manages an entity's data, services, and identity.

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

• User Experience Design

  Multidisciplinary design practice covering every aspect of a user's interaction with a company and its products, coined by Donald Norman at Apple in the early 1990s.

• User Interface Design

  Discipline of designing human-machine interfaces to maximize usability and user experience, governed by the dialogue principles of the ISO 9241 standard.

• Verification surveyor

  The Verification Surveyor is the human-in-the-loop component of service-people that presents extracted identity fragments to an operator for manual verification before they are permanently committed to the verified ledger.

• Vertical seed packs marketplace

  PointSav intends to distribute curated industry-specific seed packs as starter taxonomies, enabling tenants to contribute refinements back through a planned marketplace.

• Virtual Appliance

  Pre-configured virtual machine image combining a minimal operating system with a specific application, distributed as a self-contained unit for compatible hypervisors.

• VM-* Architecture and OS Family

  The PointSav platform organises its runtime deployments under five named VM types — VM-Totebox, VM-MediaKit, VM-Orchestration, VM-PrivateGit, and VM-Infrastructure — each corresponding exactly to one os-* source binary.

• Wallet settlement

  A per-tenant internal accounting ledger that records and settles reverse-flow revenue from the data marketplace as signed JSONL entries, with non-custodial withdrawal options to blockchain or fiat and platform-fee deductions applied at credit time.

• Wiki component library

  Nine reusable interface components that compose a complete wiki article page on the PointSav knowledge platform.

• Wiki dark mode

  Light and dark colour schemes for the PointSav wiki, with WCAG-verified palettes and theme-persistence via localStorage.

• Wiki provider landscape

  An audit of 25 wiki platforms across four groups documents structural reasons no competitor has closed Wikipedia's encyclopedic gap, and identifies the governance software, navigation primitives, and editorial culture required to do so.

• Wiki typography system

  Inter and Source Serif 4 type stack, heading scale, and spacing tokens for the PointSav wiki.

• Wikipedia leapfrog design — muscle memory and 5% headroom

  What the app-mediakit-knowledge wiki engine inherits from Wikipedia, what it adds beyond it, and what the 5% leapfrog headroom means for readers and engineers.

• Workspace services slice — cgroup partitioning for multi-developer environments

  systemd cgroup partitioning that gives production services twice the CPU weight of interactive build sessions — single-node isolation without Kubernetes.

• WORM ingest

  service-email is the Totebox's email server — it ingests SMTP and IMAP traffic, sanitises every payload, and writes raw text to an append-only Maildir on local block storage. Content interpretation is handled upstream by service-content.

• WORM ledger design

  Write-Once-Read-Many ledger substrate for PointSav Ring 1 services, designed toward a hash-chained, signed format that satisfies recordkeeping rules by structure.

• WORM ledger storage architecture

  The storage architecture specifies C2SP tlog-tiles as the target storage primitive; the current service-fs build persists a per-tenant JSON append log pending the tile backend, with structural immutability and long-term readability as the intended design.

• WORM ledger substrate: four-layer architecture and two boot envelopes

  The per-tenant WORM immutable ledger that all Ring 1 boundary-ingest services write through, built on C2SP tlog-tiles with cryptographic hash-chaining, monthly Sigstore Rekor anchoring, and a dual-envelope design spanning Linux daemon and seL4 unikernel targets.

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

• Yo-Yo Daily Enrichment Cycle

  Daily GPU batch window that enriches the DataGraph and accumulates training data — fixed schedule, hard cost cap, and guaranteed VM termination.

• Zero-container inference

  Planned Tier B GPU deployment pattern using native Linux binaries under systemd, with idle-shutdown timers halting GPU billing when inference queues are empty.

• Zero-container runtime

  The structural commitment that every PointSav deployment runs as a Linux binary under systemd on a plain virtual machine or bare-metal host, with no container runtime, container orchestrator, or managed-runtime platform.

• Zero-execution routing and presentation

  Presentation layers in the platform adhere to a zero-execution mandate, eliminating client-side JavaScript for core DOM manipulation by using structural determinism for bilingual routing and native CSS state machines for interactive elements.

• Zero-state telemetry architecture

  The zero-state telemetry architecture describes how the platform's V4 Intent Beacon collects behavioural and hardware signals from edge clients without cookies, session identifiers, or third-party analytics, using client-side compilation and asynchronous beacon transmission.