PointSav platform — architectural overview
The PointSav constitutional charter is planned to encode the principles, commitments, and structural claims intended to govern engineering, operational, and editorial decisions across the platform. No version has been ratified; this article describes intended scope, not a shipped document. See the doctrine overview for the introductory framing.
The Six Pillars
The platform is intended to be built on six foundational commitments planned to take precedence over any specific design decision or engineering convenience:
Plain text, flat file, open source. Every artifact produced by the substrate — knowledge graphs, audit ledgers, documentation, configuration, training data — is plain text. No binary-only stores, no proprietary formats that require a running service to read.
Sovereignty is structural, not procedural. Customer data and compute stay inside the customer's boundary by construction. Firewall rules, bearer-token confinement, and WORM append-only ledgers enforce sovereignty at the infrastructure level; no policy document is load-bearing.
Ring 3 is optional. The AI inference ring (AI inference service and the Yo-Yo compute substrate) is structurally optional. The deterministic substrate — knowledge graph, search, ingest, egress — functions completely when AI is disabled or unavailable. Optional Intelligence is a design constraint, not a marketing framing.
Vendor → Customer → Deployments is the only flow. Engineering source lives in pointsav/* canonical repos. Customer runbooks live in woodfine/*. Runtime instances are numbered and local-only. No reverse writes. No shortcuts through the layer boundary.
Every session trains the model. Every contributor session that produces output — diffs, briefs, editorial refinements, sysadmin interactions — generates a training tuple that accumulates in the apprenticeship corpus. The substrate sharpens monotonically with use.
Human checkpoint at F12 is mandatory. SYS-ADR-10 — the final human checkpoint before any state is committed to a verified ledger — is never bypassed. Automation serves the human; no automated path exists around F12.
The Fifty-Four Leapfrog Claims
The planned charter is intended to enumerate numbered structural claims that would together constitute the platform's competitive positioning relative to hyperscaler software-as-a-service — each identifying a structural property of the platform substrate that hyperscaler economics or architecture would structurally foreclose, not a feature advantage but a property intended to be unreplicable without changing the underlying business model.
Representative clusters from the intended claim set:
Sovereignty and data ownership (claims #1–#11, #48, #54). The customer's knowledge graph is the customer's intellectual property. The per-tenant WORM ledger is customer-rooted. Export formats are open at day zero. The substrate runs fully — queries, audit, search, transfer of ownership — with no platform-side dependency. No hyperscaler SaaS can offer this without abandoning per-tenant hosting economics.
Compounding substrate (claim #18). Each unit of work — a commit, a session, an editorial pass, a training run — increases the capability of the next unit. Engineering work trains the engineering adapter; editorial work trains the language-protocol adapter; sysadmin interactions train the sysadmin adapter. The capability curve is monotonically increasing with work volume; the marginal cost of capability declines over time.
Adapter composition algebra (claim #22). At inference time the Doorman composes up to three adapters: base ⊕ tenant ⊕ protocol. The resulting inference is tuned simultaneously to the base model's general capability, the tenant's domain vocabulary and operational patterns, and the current request's genre requirements. Per-tenant continued pretraining (claim #15) deepens the tenant adapter monotonically as the corpus accumulates.
Apprenticeship substrate (claim #32). Code-shaped and prose-shaped work routes through the Doorman as a structured brief. The apprentice (local SLM) produces a candidate diff with cited reasoning. A senior identity issues a signed verdict. The (brief, attempt, verdict, final-diff) tuple lands in the apprenticeship corpus and feeds the next training cycle. Shadow routing on every commit exercises the apprentice continuously.
Capability ledger substrate (claim #33). Every kernel-mediated capability invocation emits a signed entry to a customer-rooted Merkle log. Revocation is a log entry. Ownership transfer is an apex-cosigning ceremony — no state migration, no service interruption. The deployment IS the ledger; the running system is the materialization of the ledger state.
Two-bottoms sovereign substrate (claim #34). The design intends that os-* binaries run on two kernel bottoms — seL4 (native, formally verified, AArch64-first) and NetBSD (compatibility, BSD 2-clause, boot-anywhere) — via a thin compatibility shim, so a customer could boot the same substrate on a leased laptop today and on a verified production appliance for regulated records tomorrow, without re-provisioning. The NetBSD compatibility bottom and the WireGuard mesh layer operate today; the seL4 native bottom and the shared-binary shim are planned (Phase 3). No service currently ships a single binary that runs unmodified on both bottoms.
Four-tier SLM ladder (claim #40). Customers move through four product positions — Community (pure API gateway), Tier 1 (local 7B specialist), Tier 2 (vendor-hosted Yo-Yo 32B), Tier 3 (PointSav-LLM continued-pretrained specialist) — as their corpus accumulates and their compute appetite grows. The ladder is designed for breakout: every tier is customer-portable; no lock-in accrues at any rung.
Reverse-flow substrate (claim #52). The same Doorman gateway and audit ledger that enforce inbound discipline also enforce outbound commercial flows — data marketplace and ad exchange — as tenant-selectable, opt-in configurations. Monetization configuration is a contract decision, not an architectural rebuild.
The Eight Cross-Industry Inventions
Beyond the structural claims, the planned charter is intended to draw on process inventions borrowed from established industries — Workspace Passport, NOTAM, Recall Procedure, Bill of Lading, Time-Vested Operation, Apprentice Mode, Integrity Anchor, and Constitutional Convention. See the planned overview's "Cross-Domain Operational Patterns" section for the full description of each.
Workspace Structure
The workspace is itself a deployment of the substrate — vault-privategit-source-1. Three tiers flow in one direction:
vendor/— engineering source (pointsav/*) — GitHub-trackedcustomer/— guide catalog (woodfine/*) — GitHub-trackeddeployments/— numbered runtime instances — local-only, gitignored
Three session roles operate the workspace: the hub session (workspace control plane, single at a time), the archive session (per engineering-repo plane, one per repo), and the project session (per project-cluster, multiple concurrent). The .git/index constraint — one session per index — is the hard race condition that determines this structure.
See also
- Compounding substrate — the Compounding Substrate claim in detail
- Three-ring architecture — Ring 1, Ring 2, Ring 3 service composition
- Single-boundary compute discipline — the Doorman as single boundary
- System substrate architecture — the capability ledger and two-bottoms claims
- SLM Rust stack architecture — the Rust stack that implements the Doorman
- Yo-yo compute substrate — Tier B cloud GPU burst substrate