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 — and the algebra assembling intelligence from LoRA layers.

• Add a node to a running fleet

  Adds a second node to an already-running PPN fleet using service-vm-host's real env-var configuration — the same mechanism as the first node, since nothing about enrollment changes once a fleet exists.

• AEC interface conventions

  BIM authoring tools across the industry share a common interface vocabulary — a spatial hierarchy, an element properties panel, a 3D viewport, and saved views — because they build on the same underlying IFC data model. The Building Design System's planned interface layer reuses this vocabulary rather than inventing a new one, and is intended to extend it into facility-management workflows.

• AI and Inference

  Where AI sits and where it is not allowed: the boundary that keeps AI away from the authoritative record, the routing between models, and the small, customer-side models designed to learn a customer's own environment. The core runs fully without it.

• AI inference service

  service-slm is the platform's AI inference gateway — every request, local or remote, transits the Doorman's audit boundary and one of three compute tiers before a response returns.

• AI routing and the linguistic air-lock

  AI routing holds every external-model credential and audit-logs every request at a single boundary. It does not scrub PII from prompts, and Tier C external routing is not live yet.

• Anti-homogenization discipline

  Anti-homogenization discipline resists AI writing assistants pulling contributors toward a single voice, by 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, providing inbox listing, message reading, and compose-and-send via service-email.

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

  app-console-keys is the always-installed base chassis of os-console, providing the Cartridge trait, F-key navigation strip, status bar, and auth client.

• app-console-slm — inference infrastructure monitoring console

  Terminal console cartridge showing live AI inference infrastructure state — model health, the burst-GPU fleet, queue depth, and daily spend — read-only, with no controls of its own.

• app-mediakit-marketing — agent-authored marketing landing server

  app-mediakit-marketing is a Rust web server delivering marketing landing sites from typed page manifests — AI authors via MCP, a human approves before anything publishes. Serves 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.

• Applications

  User-facing and internal applications built on the PointSav platform substrate — the wiki engine, marketing surface, GIS analytics engine, the browser developer workbench, the structured-input gate, and the design-intent articles that frame how those surfaces are composed.

• 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 two reference taxonomies service-content loads into the knowledge graph, giving every classified entity a structural category and a functional signature.

• Architecture

  Cross-cutting platform architecture: the three-ring composition model, AI routing and inference boundary, security and identity substrate, customer ownership principles, and the location intelligence domain.

• Architecture decisions

  Twelve binding architecture decisions governing how the PointSav platform is built, constraining engineering work on data handling, oversight, 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.

• Asset-anchored BIM vault

  A building's authoritative digital record structured as plain-text and standardized-binary files in a git-versioned directory, qualifying as an ISO 19650-conforming Common Data Environment that travels with the property deed.

• Authenticate binary downloads

  Authenticates a release from software.pointsav.com: confirm the on-chain order, follow the download link that mints an Ed25519 token, and understand where verification actually happens.

• Background

  General computing concepts defined from first principles — appliances, edge and fog topology, interface design, and the security practice PointSav rejects — for a reader who wants the field vocabulary before the platform articles use it.

• BIM and real property surfaces

  How PointSav treats Building Information Modelling as a distinct operational domain — a separate customer-tier design system, a real Chart of Accounts placement, and BIM-specific console surfaces still at the research stage.

• BIM Object specification

  The platform's reusable building-element specification unit: a fixed set of primitive categories anchored to open standards (IFC, Uniclass, bSDD), each carrying three layers of information at once — what it is, what its jurisdiction requires, and what its climate requires.

• Brand typography and print standards

  PointSav's web surfaces render in Inter, Source Serif 4, and Playfair Display, self-hosted rather than loaded from a system font stack. A separate, documented OFL print-typography matrix exists but has no shipped generation pipeline yet.

• Brand-family swatch

  A taxonomy-agnostic component pairing a color-coded dot with a semantic label to identify anchor-family categories, with per-deployment colors resolved at runtime rather than shipped as a fixed taxonomy.

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

• Build a co-location map

  Renders tier-coloured co-location cluster markers in MapLibre GL by loading a PMTiles archive directly — the real flat-file architecture, since no bearer-token REST cluster API exists.

• Building Design System

  A planned coordination layer for the built environment: a canonical, machine-readable library of building-element specifications that independent BIM authoring surfaces consume by reference, the way a software design system keeps independent product teams consistent.

• Business clustering

  A parent-child spatial pattern that turns raw retail points into one commercial entity per physical site, so the GIS pipeline reasons about a location once instead of once per co-located tenant.

• Canadian-simple copyright posture

  The platform's IP vests in a single Canadian parent holding company by operation of Canadian Copyright Act § 13(3), without inter-company assignment.

• 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 becomes a cryptographically auditable event anchored to a customer-controlled log.

• Capability-based security

  Capability-based security grants each component an unforgeable, scoped token it must present to act, replacing ambient privilege. One software layer implements it today; kernel-level enforcement is planned.

• Citation substrate

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

• City code as composable geometry

  A composition-first pattern that encodes regulatory requirements into element specifications as geometric and numeric constraints rather than applying them post-design, so a non-compliant configuration cannot be placed in the first place.

• Close out a construction project

  Runs the two job-completion report binaries — a weighted six-category operational scorecard and a job-completion checklist and review pack — either of which can also be run as a live status check on a project still under construction.

• 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 — a removed substrate pattern

  A real-time collaborative editing design that held no document state on the server, forwarding CRDT updates directly between clients — implemented in the wiki engine, then removed.

• Compliance and continuous disclosure

  The regulatory frameworks the PointSav architecture addresses, and its structural approach to exposing audit evidence continuously, not via annual certification.

• Component recipes vs. raw tokens

  What the PointSav Design System's component tier adds beyond a token value: the recipe.json format — variants, markup, token references, CSS, ARIA guidance, and WCAG targets in one machine-readable artifact — demonstrated against the shipped Button recipe and the registry's real documentation state (53 components: 20 fully documented, 33 with a recipe plus at least a usage document).

• Compounding Doorman

  The operational pattern at the heart of sovereign AI substrates: a single service mediating every external compute call, logging events, accumulating training signal.

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

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

• Configure a tenant namespace

  Configures a tenant namespace on service-vm-tenant via environment variables and a restart — the real config-driven mechanism, since no runtime tenant-registration API exists.

• Configure the Doorman gateway

  Configures a single-instance Doorman gateway via environment variables — Tier A local endpoint, optional Tier B Yo-Yo burst compute, optional Tier C external providers — and verifies tier state through /readyz.

• Connect to the OSM data pipeline

  Ingests a new retail or service chain from OpenStreetMap using the real ingest-osm.py script and taxonomy.py's CATEGORIES/BRAND_FILL dicts, then rebuilds the servable cluster tiles.

• Console input application

  app-console-input is the F12 surface in os-console — a path, a confirm prompt, and a submission, 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.

• Content mounts and federation

  The wiki engine renders curated articles committed directly to its repository alongside content mounted from separate local directories, sharing one URL surface and search index.

• Contributing to PointSav knowledge

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

• Core Concepts

  The substrate category collects the platform's foundational mechanism concepts — the Compounding Substrate, Apprenticeship Substrate, Citation Substrate, Disclosure Substrate, Trajectory Substrate, Language Protocol Substrate, and the disciplines and primitives that compose them — each describing a structural property the platform relies on rather than a specific service or system.

• Crypto payment and license issuance architecture

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

• Cryptographic ledgers

  An append-only log where each entry's hash covers the one before it, closed by Ed25519-signed checkpoints and anchored monthly in a public transparency log. Implemented as a linear chain, one flat file per tenant.

• Cryptographic payload attestation

  Cryptographic payload attestation lets a reader recompute a hash of published content and compare it against a published value. Unwired, cosmetic prototypes exist in a few release templates; the knowledge wiki does not offer it.

• Customer hostability

  Customer hostability is the architectural commitment that every artefact runs on the customer's own hardware and keys, making self-hosted deployment the canonical pattern.

• Customer-first ordering

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

• 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

  Zero-state telemetry is the intended posture of measuring site usage without retaining identifying data. The pipeline running today writes full unmasked IP addresses to a plaintext file for up to a year; masking is not implemented.

• Data vault bookkeeping substrate

  An SMB bookkeeping and accounting architecture built on an immutable source vault and append-only journal, structurally separate from any accounting tool.

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

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

• Decode-time constraints

  The constrained-decoding technique, and a clear line between it and what PointSav has built today: an advisory post-generation linter, with the grammar-based mechanism itself planned, not shipped.

• Deploy a knowledge instance

  Deploys an instance of app-mediakit-knowledge from a local content path: write a knowledge.toml [site] + [[mount]] configuration, build the binary, and start it with the serve subcommand.

• Deployment patterns

  The six canonical configurations the PointSav substrate is deployed in — each built on the same five primitives and OS surface, adapted per segment.

• Design Patterns

  Named design patterns realised across the platform — source-of-truth inversion, pairing-as-permission, zero-container runtime, zero-execution routing, model-tier discipline, and the passthrough relay among them — each a recurring shape applied at the editorial, interface, or coordination layer.

• Design System

  The PointSav design system as a platform component — its foundational vocabulary, design philosophy, brand surface context, and the typographic, colour, spacing, and motion foundations that compose the visual identity carried across every operator surface.

• Design system philosophy

  The PointSav design system is a self-hosted, customer-owned substrate at design.pointsav.com publishing design decision research alongside DTCG-format token values.

• 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 tokens and accessibility conformance

  How the PointSav Design System expresses accessibility requirements — minimum touch targets, focus-ring color, contrast relationships — as named design tokens, so that WCAG conformance is enforced by the token graph's structure rather than checked ad hoc per component, demonstrated against the shipped Button accessibility specification.

• Design-system substrate

  The design-system substrate is a self-hosted, customer-owned engine storing tokens and components in the customer's own Git repo, served via a machine-readable MCP endpoint.

• 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

  The Diode Standard is the design rule that command and data flow in one direction only, from authority to subject. Several real mechanisms follow it; no component enforces it as a named standard.

• Direct-payment settlement

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

• Disclaimer

  Trademark notice and no-offer disclaimer for this wiki: the Woodfine and PointSav marks, the statement that nothing here offers or solicits investment units in a direct-hold solution, and where the full legal disclaimer lives.

• 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, holding every external-model credential and logging every call to an immutable audit ledger.

• Economic model — community and SMB customer tiers

  PointSav's two-tier commercial structure: a free Community tier as an adoption funnel, and a paid SMB tier targeting regulated businesses hyperscale billing can't serve.

• 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 external network connections through Ring 1 boundary-ingest services at the edge, sanitizing payloads before core processing and recording clean events.

• 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 leads and internal linking for readers.

• Egress service

  service-egress compresses and chunks local mail data for outbound transfer, and only deletes the local source once an external counterpart confirms receipt with a cryptographic proof — an outbound release valve, not a cloud-to-local import.

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

• Email ingest

  service-email pulls mail out of a Microsoft Exchange mailbox over EWS, writes the raw message to local storage, and deletes it from the source mailbox immediately after extraction — the cloud mailbox is a transit point, not a copy of record.

• Enroll a PPN node

  Enrolls a machine into a PPN compute fleet by setting service-vm-host's three required environment variables, running it under systemd, and confirming the node in the controller listing.

• Explore the console for the first time

  Orients a first-time operator to os-console — the status bar, the F9 inference-gateway dashboard, and the mandatory F12 input checkpoint that writes to the WORM ledger.

• Export structured data from the platform

  Exports platform data through three real paths — DataGraph entity records via MCP tools, wiki Markdown read directly from git, and paginated ledger entries over service-fs's HTTP API.

• Favicon matrix and tab identity

  The wiki serves a single static SVG favicon — a navy document-page glyph, linked from a static file, the same mark on every tab regardless of tenant.

• Federate archives via content mounts

  Federates a second knowledge instance's articles into a running instance through a knowledge.toml [[mount]] entry — a flat, merged namespace with no isolation, not a URL-prefixed federation scheme.

• Figma and Tokens Studio: consuming the design system's tokens in a design tool

  Explains how designers bring the PointSav Design System's published DTCG token export into Figma with the Tokens Studio plugin's URL sync — a read-only pull from the system's own hosted JSON, with no export/import step — and why the read-only direction is a governance feature, with an honest comparison to Penpot's native token support.

• Five-stage supply chain

  The path from a contributor's commit to a customer deployment crosses three repository tiers and two organisations, gated by a heavily guarded promotion script. There is no pull request and no second-party review.

• Flat-file BIM leapfrog

  The Building Design System is built on five architectural constraints — flat-file storage, open standards, Rust and Tauri, offline-first operation, and Apache 2.0 licensing. Asset-anchored ownership, offline field use, IoT ingestion, and convergence of the model with lease and financial records follow from the architecture rather than being added on top.

• Fleet aggregator

  os-orchestration is the commercial-tier OS letting a single operator see, query, and command many Totebox archives at once — the Fleet Aggregator for 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 up to a domain-specialist service, each adding capability without regressions.

• FS anchor emitter

  A one-shot binary that fetches a signed WORM-ledger checkpoint from service-fs, anchors it to the public Sigstore Rekor transparency log, and writes the resulting log entry back — making ledger state auditable from outside the platform.

• Full-text search

  service-search is a designed but unbuilt Ring 2 full-text search service — a README describes a Tantivy-based inverted index, but no source code exists yet.

• Generate a construction cost estimate report

  Runs the construction reporting binary against a CSV data directory to produce costing and schedule reports as HTML and PDF, with reconciliation and validation logs — the only interface that exists, since the tool has no console screen and parses no command-line arguments at all.

• Generate a construction draw workbook

  Runs the five report binaries in tool-accounting-tco-26's construction-industry extension — capital call request and schedule, statutory declaration, checks issued, and cash-flow calendar — covering an active build's statutory and payment-timing exposure.

• Generate a financial statement package

  Runs the statements binary for one fiscal year and one period to render a consolidated statement package as HTML and PDF, recomputed from journal CSVs on every run — the tool refuses to render rather than publish a figure that does not tie.

• Generate a payroll register

  Runs the payroll binary to aggregate budgeted labour hours by division into an HTML and PDF register — a narrow report that computes no gross pay, no pay frequency, and no remittance, and prints an em dash rather than a number wherever it has none.

• Genesis protocol

  The Genesis Protocol is the designed fleet-bootstrapping sequence for os-infrastructure nodes: ship with no prior configuration, boot on any network, and reach a secure, claimable state with no control-plane contact required.

• Getting started with the PointSav platform

  An orientation to the PointSav developer platform: what it is, who it is for, where to start, and how the pieces fit together before the first task.

• GIS as a BIM substrate

  What the co-location dataset offers a BIM composition pipeline: the cluster manifold and its joinable fields, region-resolution depth, civic context layers, and the stability guarantees a downstream consumer can rely on.

• GIS data lake

  The GIS pipeline's data lake is its foundational storage layer — a flat-file store holding raw geospatial points, available to every downstream step in the same pipeline. Distinct from service-fs, the platform's separate WORM ledger.

• GIS orchestration application

  The Python data pipeline that produces the Woodfine co-location rankings and interactive map — cluster geometry rebuilt on a nightly schedule from source datasets, published as static map tiles.

• Glossary and Reference

  The platform's lexicon and lookup material: the full glossary, orientation for a new reader, the catalogues other articles point to, and the standards this wiki holds its own writing to.

• Governance and Standards

  Formal decision records, licensing posture, contributor model, and compliance requirements that govern how the PointSav platform is built, licensed, and changed — including the twelve binding architecture decisions, the BCSC continuous-disclosure posture, and the licence matrix.

• Hardware co-location methodology

  A structured approach for ranking hardware co-location candidates across jurisdictional, network, infrastructure, and cost dimensions, regulatory requirements first.

• Hardware reference

  Reference hardware profiles for developer workstations and fleet devices, specifying CPU requirements including Haswell-generation x86_64 and fsgsbase support.

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

  How os-totebox is designed to map Rust service binaries to seL4 Protection Domains: the planned seven-PD stack, capability confinement, startup ordering, and the two-bottom development path — Phase H1 roadmap work, not the binary running today.

• How this knowledge base is organized

  A reader's map of the platform knowledge base: sixteen areas covering what PointSav builds, how it's built, and why it can be trusted, for every reader.

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

• Identity ledger schema design

  Three record types — Person, Anchor, Claim — separate who is known from how they were observed and what was asserted. Identity is a UUIDv5 of a lowercased email, so the same input always yields the same identifier.

• Immutable storage and secure backup

  The platform's tamper-evident record rests on filesystem read-only permissions and a cryptographic hash chain, not a hardware write-block — a privileged administrator can still bypass it, and any bypass is detectable, not prevented.

• Infrastructure

  Fleet deployment topology, cloud operational runtime, and physical infrastructure — the WORM ledger storage substrate, edge deployment patterns, the private WireGuard mesh, sovereign telemetry, key-wiring operations, and the bookkeeping vault that anchors the SMB accounting surface.

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

• Issue a capability token

  Issues an Ed25519-signed pairing token from service-content over plain HTTP, registers it with the receiving peer, and covers the separate X-Foundry-Capability request header.

• 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 separating what PointSav publishes freely from what it sells — public knowledge under open licenses, paid service at 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 looks up matching entities in the per-tenant knowledge graph before dispatching a request, grounding the model's response in facts the graph already holds.

• Language-protocol substrate

  The routing mechanism that carries a draft's declared register, document type, and destination between archives — a frontmatter field, a routing table, and a mailbox convention, not an AI adapter system.

• 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

  Training loop turning operator interactions into training signal — trajectory capture, an apprenticeship queue, and a GLiNER→OLMo distillation pipeline that generates entity-extraction DPO pairs.

• Legal and IP structure

  The three-corporation topology governing IP transfer from contributor to vendor to customer, with squash-and-merge as the atomic IP-transfer event.

• 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 substrate: the only fully open model family permitting continued pretraining and public-company procurement.

• Location intelligence platform

  Customer-owned flat-file GIS application for retail cluster analysis and strategic site selection, pairing a nightly scoring pipeline with an interactive rendering layer.

• Location intelligence substrate

  A flat-file, open-GIS architecture letting customers own geographic datasets end-to-end using open data and a Rust-aligned rendering stack, retail co-location as first 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

  How new retail and infrastructure chains get added to the location-intelligence pipeline's taxonomy, and how the pipeline ingests their location data from OpenStreetMap.

• Machine Authorization

  Pairing devices and nodes onto the network, issuing and rotating service-to-service capability tokens, and authenticating binary downloads.

• Machine-based authorization

  Access is granted to a device's key rather than to a person's password. A short-code pairing ceremony binds an SSH key fingerprint to a user record after operator approval, with no password stored anywhere.

• 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 and AI-agent-consumable design systems

  Explains why the PointSav Design System exposes a machine-readable surface — an on-prem Model Context Protocol endpoint, a token search API, and a DTCG token export — so AI coding agents can query current token and component data from the same registry that renders the human-facing documentation, without any query leaving the host's own infrastructure.

• 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 letting the platform prove to any third party that a record is part of an append-only log that has not been rewritten.

• Message courier service

  A deliberately thin engine that dynamically loads a customer's private adapter script and hands it execution control — keeping every operational detail of a client's web-automation logic out of the open-source codebase entirely.

• Model tier discipline

  The Doorman routes every inference request to one of three compute tiers — local, burst GPU, or external API — based on a complexity hint and live budget state, not a caller's direct choice.

• Monitor an active construction project

  Runs eight independent recurring-cadence report binaries — status, exceptions, cost-to-complete, change-order exposure, subcontract and equipment tracking, safety activity, and portfolio roll-up — against a project's data directory, plus the dashboard that confirms what actually landed on disk.

• Moonshot initiatives

  Moonshot initiatives are active engineering programs building native replacements for quarantined third-party dependencies, reducing vendor lock-in.

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

• Navigate the console TUI

  Navigates os-console by keyboard — the F-key strip at the top, the status bar's real fields at the bottom, and switching slots without losing state.

• News release typography and layout standards

  Strict formatting rules for corporate news syndication: left alignment, title case discipline, geographic precision, and standardized header and dateline structures.

• Nightly DataGraph rebuild

  The scheduled process that reconstructs the platform's knowledge graph from canonical flat-file sources each night. A human-approval checkpoint exists for AI-extracted entities, but it is opt-in — an operator must enable it; automated writes land without per-item review by default.

• Ontological governance

  Four reference vocabulary ledgers kept deliberately narrow, plus a human-verification loop that reviews extracted identity fragments before they enter the verified ledger.

• Open your first Totebox session

  Opens a first Totebox session in a single archive: read the manifest, check your inbox, understand what the session can and can't write, and complete the shutdown sweep before closing.

• Operating Systems

  The purpose-built operating systems that share a common seL4 and Rust substrate — Totebox, Console, Workplace, Orchestration, Infrastructure, Network Admin, MediaKit, and PrivateGit — each doing one job, holding no features it does not need, and communicating through a common Diode-based protocol discipline.

• 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, designed around a shared Rust discipline and a Diode-based protocol; a common seL4 microkernel substrate is a roadmap target, not the current state of every member.

• OS mediakit

  The public-web tier of the PointSav OS family — os-mediakit owns TLS, systemd lifecycle, and gateway-mediated data access; app-mediakit-knowledge/marketing/distribution own domain logic. Ubuntu 24.04 today; the planned end state is one seL4 VM per deployment instance, not a single combined appliance.

• OS network admin

  os-network-admin is the control plane for a PPN: WireGuard mesh routing, the node-join ceremony surface, and Diode-standard enforcement, without archive-tier authority.

• os-console — the Command Ledger

  os-console is the human-facing surface of the PointSav platform — a single-binary, keyboard-native Command Ledger that connects to a Totebox and hosts independent TUI cartridges through a unified chassis.

• os-console: The Totebox Orchestration Browser

  os-console-totebox-browser has been folded into os-console's own 'Why this design: the browser analogy' section — this article is now a short pointer, not a separate deep dive.

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

  os-network-admin distributes today at software.pointsav.com at $0 USDC (beta); os-infrastructure's bare-metal/cloud-VM distribution model is planned but not yet catalogued. Both ship as signed artifacts, licensed and delivered on-chain.

• os-infrastructure — PPN node operating system

  os-infrastructure is the OS layer for PPN nodes — its sole purpose is to set up and maintain a node: WireGuard tunnels, guest VMs, and 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 — a stateless routing surface above the capability layer.

• os-totebox: the sovereign WORM data vault

  os-totebox is designed to become a Type I bare-metal OS built on a formally verified seL4 microkernel, with a WORM data vault enforced by a compiled capability graph — the intended end state, not the software running today.

• Pair a new device

  Pairs an unpaired os-console device onto the PPN mesh: read the pairing code from the startup screen, have an administrator approve it, and confirm network admission.

• Pairing as permission

  The Object Capability access-control principle — a cryptographic pairing is the permission, and its absence means no pathway exists to ask for one — as embodied in the platform's machine-based node admission.

• 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

  Four permission tiers, P1 through P4, are implemented as a typed enumeration and served over an HTTP endpoint that reads a workspace configuration file. That file currently declares no contributors, so the endpoint resolves nothing for any real user.

• Places filtering

  A filtering step that keeps only regional-grade institutions from raw civic data, so GIS tier rankings reflect institutional concentration rather than every clinic and community facility.

• Platform architecture overview

  The platform's cryptographic consistency rests on a real Merkle-chained ledger; sovereign bootability — collapsing a deployment into one portable image — is a design goal, not yet a shipped feature.

• Platform Services

  The autonomous services that implement Ring 1 boundary ingest and Ring 2 deterministic knowledge processing in the PointSav three-ring architecture — grouped by ring layer and function.

• Platform Tasks

  Step-by-step developer guides covering toolchain setup, console TUI navigation, WORM ledger operations, and multi-entity scale for the PointSav platform. Device pairing and capability tokens now live in Machine Authorization; self-hosted deployment now lives in Self-Hosting.

• POI data schema

  The record structures for location data ingested from OpenStreetMap and Overture Maps Foundation, normalised into a unified JSONL schema before cluster analysis. Wikidata QIDs are the primary chain identifier, and a parent-child sub-location model handles co-branded ancillary services.

• PointSav architecture 2030 — a planned overview

  The planned scope for PointSav's future constitutional charter — not yet ratified or written; described here in planned/intended terms only.

• PointSav encyclopedia — glossary and lexicon

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

• PointSav Knowledge

  The engineering library for the PointSav platform — operating systems and services for regulated businesses that own their data, their AI, and their record-keeping outright. Where the monorepo holds the code, this wiki holds the reasoning: architecture, services, security, and the governance commitments that bind future development.

• PointSav media kit

  Media kit for PointSav Digital Systems: company description, wordmark and trademark usage terms, press-inquiry contacts, and the CC BY 4.0 licence covering this wiki's content.

• PointSav platform — architectural overview

  The planned scope for a future constitutional charter intended to encode foundational commitments and structural claims governing PointSav engineering decisions — not yet written or ratified.

• PointSav software distribution substrate

  A three-component system — release server, storefront, payment watcher — delivering compiled binaries against on-chain USDC payments, no accounts or subscriptions.

• PointSav — company overview and three-organisation structure

  PointSav Digital Systems is a technology vendor building sovereign, on-premise-capable operating systems for record-keeping, within a three-organisation structure.

• 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 the OLMo 3 32B base model.

• 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 app-network-admin uses to issue commands to os-infrastructure nodes over WireGuard, with no central broker.

• PPN distributed VM fabric

  The planned extension of the per-node PPN hypervisor layer to a multi-node resource pool, letting VMs borrow compute and migrate across the fleet automatically.

• PPN hypervisor resource pool

  The PPN hypervisor layer is designed to manage a per-node pool of CPU and RAM via virtio_balloon and cgroups v2 — neither mechanism is built in os-infrastructure yet.

• 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; subnet isolation is a planned milestone.

• PPN Three-Path seL4 Architecture

  Three sequential seL4 options for PPN infrastructure nodes: Option B ships first (hypervisor + Linux guest), Option C adds WireGuard as a protection domain.

• PPN VM resource pool architecture

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

• Pre-commit defense in depth

  Four independent git hooks run before a commit is recorded: a helper-only gate, a data-path block, a staged-content secret and size scan, and an author-identity check. Every bypass is logged.

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

• Presentation-layer routing and client-side script

  The platform's public homepage templates use a native-CSS checkbox pattern for language toggling and interactive elements, alongside a small amount of client-side JavaScript for page-integrity display and analytics.

• Privacy Notice

  Privacy notice for this wiki: one technical measurement per page view — URL path and approximate time — with no identifiers, no cookies, no third-party sharing, and no external tracking scripts.

• Private binary download endpoint for paying customers

  The binary release server behind software.pointsav.com verifies Ed25519 license tokens and streams compiled binaries — stateless, holding no payment records or keys, with some products served openly and no license check at all.

• Private git OS

  The OS layer hosting the private Git infrastructure underpinning the development workspace, staging-tier commit flow, and canonical repos for PointSav engineering.

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

  A Private Platform Network assembles machines a business already owns into an encrypted compute pool. WireGuard isolation runs today; seL4 host isolation is planned.

• Procurement overview

  What a regulated buyer acquires deploying PointSav: hardware the customer owns outright, data the vendor never holds, and compliance enforced by architecture.

• Proofreader console

  Terminal content cartridge for the service-proofreader pipeline — operators submit text, review findings, and record a binary accept/reject verdict that feeds the apprenticeship corpus.

• Query the DataGraph

  Queries the DataGraph for current entity state with the real query_datagraph and get_entity_context MCP tools, and handles DataGraph unavailability as its own signal, separate from Doorman's inference tiers.

• Read the command ledger

  Reads the append-only WORM ledger over service-fs's real HTTP API — paging entries with a cursor and fetching a signed checkpoint — since no ledger-browsing UI exists in the console.

• Regional name resolution architecture

  The layered offline reverse-geocoding engine that turns a cluster's coordinates into a human-readable regional name — its boundary datasets, its country-specific routing order, and the post-processing that makes source-language names readable — with no external API calls.

• Registry-driven releases: one source of truth for tokens, components, and counts

  Explains the registry-driven architecture behind the design-system site's releases: navigation, homepage statistics, the machine-readable registry endpoint, MCP responses, and release packaging all resolve against one registry file, so they cannot drift apart — illustrated with two real defects from the system's own history rather than hypotheticals.

• Retail co-location tier methodology

  Gate-based tier classification for retail co-location clusters — Regional, District, Local, or Fringe — assigned by passing fixed composition, catchment, civic-support, and overlap tests rather than by a composite score.

• Reverse-flow substrate

  The Doorman gateway and audit ledger enforcing inbound data discipline are planned to also enforce outbound commercial flows — marketplace and ad exchange, 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.

• Rotate keys and capability tokens

  Replaces a service-content credential within the real system's limits: tokens expire on a fixed 24-hour clock, overlap is unavoidable, and no mechanism cuts a live token short.

• Run local SLM inference

  Starts the local Tier A SLM service, verifies Doorman readiness, and submits an inference request from the console or the API, with all prompt data staying on the deployment.

• Run your first SLM query

  Submits a first inference request to Doorman directly over HTTP — the real path, since the console's F9 slot is a monitoring dashboard with no query interface at all.

• Scale user access

  Grants role-scoped capability tokens to new users as a team scales, using service-content's real pairing API — there is no promote/demote or bulk-revoke operation, since no revocation mechanism exists at all.

• Scaling coordinated development across many Totebox Archives

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

• Security and Trust

  How the platform is protected and how its records are verified: identity and permissions, cryptographic verification, isolation boundaries, how data is handled and kept private, and the supply-chain controls designed to keep code honest.

• Security overview

  The platform's security posture: capability-based hardware isolation, the Diode command-flow standard, the Doorman AI boundary, and the WORM audit ledger.

• Security Policy

  How Woodfine, PointSav, and MCorp receive, triage, and disclose security vulnerabilities in Woodfine-managed software and services.

• 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 the security policy is the shape of the capability graph established at boot, not a runtime policy layer. First-party work is nine bare-metal test binaries; no platform service runs on seL4.

• seL4 microkernel substrate

  Formally verified seL4 microkernel, PointSav's planned shared L1 kernel substrate — not yet the running kernel for every OS family member as shipped today.

• seL4 Unikernel Substrate for os-console

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

• Self-host a deployment

  Builds the os-totebox and app-orchestration-slm seL4 appliance images from source and boots them under QEMU, with configuration baked in at build time via device-tree bootargs, and verifies both come up healthy.

• Self-Hosting

  Running the platform on your own infrastructure: booting the seL4 appliance images, deploying the wiki engine, and wiring up local inference.

• Self-hosting a design system, and why it's separate from using the tokens

  Two offers of the PointSav Design System — using the Apache-2.0 token data directly, which requires nothing, and separately self-hosting the serving engine to run another organization's in-house design system — including the five-step fork procedure, the three-variable configuration surface, git-based governance, and the license boundaries between token data, server source, and article text.

• service-content — entity extraction and knowledge-graph host

  service-content extracts named entities from raw payloads through a tiered model pipeline, writes them into the knowledge graph under a human-review checkpoint, and hosts the platform's reference taxonomies.

• service-extraction — the DataGraph ingestion pipeline

  service-extraction watches a directory for incoming JSON payloads carrying edge-classified entities, writes a per-payload ledger record for the target service, and can bridge the same text into the DataGraph ingestion pipeline.

• service-fs — the WORM ledger backbone

  The per-tenant Write-Once-Read-Many immutable ledger that backs every record written to the platform — a real, implemented HTTP and MCP interface over a hash-chained append log, with monthly external anchoring to a public transparency log.

• service-input — reference-archive migration and calibration

  service-input batch-migrates markdown reference material from a source archive into the platform's ingest pipeline, deduplicating by content hash and validating against each file's own ledger record — with a companion tool that scores how well downstream extraction matches that ledger.

• service-people — the identity ledger service

  service-people is the F2 surface in os-console — an MCP server over an append-only, WORM-backed identity ledger with three tools: append, lookup, and regex-based email scanning.

• service-pointsav-link — planned PointSav fleet adapter

  service-pointsav-link is a named but unbuilt adapter concept for connecting an os-* node to a PointSav fleet — no corresponding package exists in the monorepo today.

• service-slm graph store rebuild

  service-slm's graph store runs a nightly rebuild — entity extraction via the Doorman writes directly to the graph on completion, with no human review step in the rebuild script itself.

• service-vm-fleet — the PPN VM fleet controller

  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 PPN VM tenant proxy

  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: the Doorman boundary, the local and burst tiers, the apprenticeship queue, and the idle-shutdown cost ceiling.

• SLM as Totebox sysadmin — the plan

  A planned direction for service-slm: using its real, already-operational capture-then-verdict training pipeline to build a Totebox sysadmin assistant — the specific task taxonomy and tooling described here are not yet built.

• SLM operationalization plan

  The plan for transitioning from externally hosted language model calls toward a per-tenant small language model substrate that heals via a 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 canonical (signed record), a second derived (rebuilt on demand), and a third session-ephemeral (discarded).

• Sovereign AI commons

  PointSav's market positioning as steward of shared, open AI infrastructure for regulated SMBs: structural properties large cloud providers cannot offer without changing billing.

• Sovereign airlock

  The staged-commit protocol enforcing separation between staging identities and canonical repository identities — two staging authors, two admin push identities.

• Sovereign desktop

  os-workplace is the planned free desktop tier in the PointSav family — today a growing set of independent Rust and Tauri apps an operator runs on their own computer, joining the network as a station-* WireGuard peer; the intended adoption gateway to the commercial line.

• Sovereign mesh

  The sovereign mesh is the application-level WireGuard overlay connecting every PPN fleet node, carrying signed binary commands without a centralised message broker.

• Sovereign replacement initiative

  The engineering governance program tracking third-party dependencies, isolating them in quarantine, and coordinating the moonshot programs replacing them.

• Sovereign vault and service host

  os-totebox is the archive layer of the PointSav family — one isolated vault per entity, storing inert flat files with no delete, exposed via the Diode on command. Its production path hosts a Linux guest under the seL4 microkernel; other host forms exist for compatibility and local development.

• 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 PointSav's approach to market differentiation: architectural commitments visible in code and topology, not named-competitor comparisons.

• 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 and integrator conventions while declining API mimicry, keeping substrate-native interfaces to reduce maintenance burden.

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

• System substrate architecture

  The kernel-level architecture beneath every PointSav service — a customer-rooted capability ledger, a two-bottoms sovereign OS strategy, and boot-anywhere recovery.

• Telemetry architecture

  The platform collects web traffic analytics from production edge nodes, routing them to a locally controlled environment via an encrypted path, no third-party cloud.

• 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 financial and construction tool family — a shared design across three products

  How tool-accounting, tool-construction, and tool-payroll relate as one product family — a shared double-entry design, one-way data feeds between them, and a shared free/paid architecture boundary.

• The proofreading pipeline's wire contract

  The real client-confirmed contract for the platform's proofreading pipeline: a fixed set of language protocols, a response that reports which compute tier ran and what degraded, and a binary human verdict that feeds the training corpus.

• Theming via semantic tokens

  Dark mode, in this design system, is not a second stylesheet. It is a

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

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

• 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 across PointSav deployments, separating raw compute, isolated platform execution, and secure operator access.

• Three-ring architecture

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

• Three-tier contributor model

  The Three-Tier Contributor Model organises substrate contributors into Core (4-7 engineers), Paid (50-100 contractors), and Open (10,000+ public), with mobility paths.

• 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 no required internet connectivity.

• 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 entity extraction pipeline runs three tiers per document: Tier 0 fast extractive detection via GLiNER, Tier A generative fallback via OLMo, Tier B GPU enrichment.

• Tiered inference gateway — local-first AI routing

  A tiered inference gateway routing AI requests through a local model first, escalating to remote GPU nodes and external APIs only when needed, minimizing cost and exposure.

• tool-accounting — double-entry ledger and audit-ready financial statements

  A flat-file, owner-held double-entry accounting engine producing audit-ready financial statements from plain-text journals; its core engine and PDF/HTML renderer are built, verified against representative multi-entity accounting scenarios, and driven by a real CLI toolchain of statement, ledger, narrative, and timeline report binaries, plus a construction-industry draw-workbook extension — CLI-only, with no console surface yet.

• tool-construction — construction cost, schedule, and quality ledger

  A flat-file, owner-held ledger for construction cost, schedule, and quality control, built on the same double-entry discipline as tool-accounting; both the quantity and money ledgers now run as a real CLI against a live pilot, rendering more than a dozen reports across kick-off, ongoing-monitoring, and job-completion cadences — no console surface yet.

• tool-payroll — jurisdiction-aware payroll and statutory remittance

  A jurisdiction-aware payroll and statutory-remittance engine whose first real report — a division-level Payroll Register aggregating the construction pilot's budgeted labour hours under a cited single-jurisdiction wage-rules row — is built and running; gross-to-net pay, pay frequency, and remittance computation remain design-only.

• Totebox archive

  A Totebox Archive is a sovereign data vault for a single entity — a freely transferable bootable disk image storing WORM flat files, accessed only via the Diode Standard.

• Totebox Archives as the asset

  Why a Totebox Archive is designed as a self-contained, freely transferable data unit rather than a database record owned by the platform that created it.

• Totebox orchestration

  Totebox Orchestration is the coordination layer managing multiple Totebox data-archive containers, keeping execution engines isolated from passive corporate ledgers.

• Totebox orchestration as the development environment

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

• Totebox session

  A Totebox Session is an AI-assisted contributor session within a single Totebox Archive — scoped to declared repositories, the standard entry point for development.

• Trajectory substrate

  The platform mechanism converting operational work — commits, sessions, feedback — into structured JSONL training tuples feeding a continued-pretraining corpus.

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

• Use declarative knowledge mounts

  Adds a secondary content repository to a running knowledge instance via a knowledge.toml [[mount]] entry — into the same flat slug namespace as the primary, since no URL-prefix isolation exists.

• Use the F-key cartridge model

  Works the os-console F-key cartridge model — F3 email, F9's monitoring-only SLM dashboard, F12's file-based Input Machine — where each compiled-in cartridge owns its slot's rendering and input.

• 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

  A command-line tool that requires a person to confirm each extracted identity against external evidence before it is promoted from a queue to a verified record, throttled to ten confirmations per day.

• Verify a WORM ledger entry

  Verifies WORM ledger entries against a fetched checkpoint over service-fs's real HTTP API, using a standard SHA-256 toolchain — no CLI or proprietary tooling exists or is required.

• 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 runtime deployments under five named VM types — Totebox, MediaKit, Orchestration, PrivateGit, Infrastructure — each mapping to one os-* binary.

• Wallet settlement — the design

  service-wallet is a planned per-tenant accounting ledger for reverse-flow marketplace revenue — no code exists yet; the design calls for a non-custodial, signed-entry ledger rather than a payment rail.

• What a design token is

  Entry-level background article defining design tokens, the W3C Design Tokens Community Group Format Module (first stable version, October 2025), and the primitive/semantic/component three-tier architecture, grounded in the PointSav Design System's published DTCG bundle (130 primitive + 86 theme tokens, plus separate paper and writing pillars).

• Wiki component library

  The shared chrome — header, off-canvas mobile nav, left sidebar, and footer — plus the page templates it wraps, that together render every page on the PointSav knowledge platform.

• Wiki dark mode

  Light and dark colour schemes for the PointSav wiki, driven by semantic-token overrides on a data-theme attribute, with theme persistence via localStorage.

• Wiki provider landscape

  A structural audit of the wiki-shaped knowledge-surface market by archetype, documenting why no category of provider has closed Wikipedia's encyclopedic gap, and what closing it would require.

• Wiki typography system

  The Inter and Source Serif 4 type stack, heading scale, and spacing tokens governing every wiki article page across the PointSav knowledge platform.

• 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

  A systemd cgroup memory reservation that protects production services from being evicted by heavy build or research processes on the same host — single-node isolation without Kubernetes.

• 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

  C2SP tlog-tiles is the target storage primitive; the current service-fs build persists a per-tenant JSON append log pending the tile backend, immutable by design.

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

  The per-tenant WORM immutable ledger every Ring 1 service writes through, built on C2SP tlog-tiles with hash-chaining and monthly Sigstore Rekor anchoring.

• Yo-yo #1 nightly LoRA training pipeline

  The nightly two-phase pipeline on Yo-Yo #1: Phase 1 runs entity extraction for the DataGraph; Phase 2 trains a LoRA adapter via QLoRA on a single L4 GPU.

• Yo-yo compute substrate

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

• Yo-Yo daily enrichment cycle

  The nightly two-phase GPU batch window that rebuilds the DataGraph and, once fully enabled, trains adapter weights for the local language model — currently running in DataGraph-only mode.

• Zero-container inference

  Tier B GPU deployment pattern using native Linux binaries under systemd on an L4 GPU, with idle detection run from the Doorman server process rather than a timer on the GPU VM itself.

• Zero-container runtime

  The structural commitment that every PointSav deployment runs as a Linux binary under systemd on a plain host, with no container runtime or orchestrator.

• Zero-state telemetry architecture

  Zero-state telemetry: a single unload beacon carrying URI and timestamp, paired server-side with the requester's IP and user agent, written unmasked to an append-only CSV ledger.