architecture/foundry-doctrine-architecture

Topic

From the PointSav Documentation

Español

The PointSav constitutional charter encodes the principles, commitments, and structural claims that govern every engineering, operational, and editorial decision across the platform. The current release is v0.1.0 ALPHA, ratified 2026-04-30 under the ps-administrator signing identity. See the doctrine overview for the introductory framing.

[edit]The Six Pillars

The platform is built on six foundational commitments that 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 (service-slm 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.

[edit]The Fifty-Two Leapfrog Claims

The doctrine enumerates 54 numbered structural claims that together constitute the platform's competitive positioning relative to hyperscaler software-as-a-service. Each claim identifies a structural property of the platform substrate that hyperscaler economics or architecture structurally foreclose — not a feature advantage, but a property that cannot be replicated without changing the underlying business model.

Representative clusters from the full 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 platform runs on two kernel bottoms: seL4 (native, formally verified, AArch64-first) and NetBSD (compatibility, BSD 2-clause, boot-anywhere). The same os-* binaries run on either bottom via a thin shim. The customer boots the same substrate on a leased laptop today and on a verified production appliance for regulated records tomorrow, without re-provisioning.

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.

[edit]The Eight Cross-Industry Inventions

Beyond the structural claims, the doctrine draws on eight process inventions borrowed from established industries:

Workspace Passport (maritime) — every deployment carries a MANIFEST.md declaring origin, owner, and current state. NOTAM (aviation) — time-sensitive warnings read at every session start. Recall Procedure (pharmaceuticals) — defective vendor commits trigger recall notices into every downstream deployment inbox. Bill of Lading (shipping) — cross-realm handoffs generate append-only log entries. Time-Vested Operation (banking) — destructive operations post to a queue with a vesting date; execution is blocked until the date passes. Apprentice Mode (aviation/medicine) — new model versions run in shadow mode; graduate after N approved actions. Integrity Anchor (notarization) — monthly workspace state hashes posted to Sigstore Rekor public transparency log. Constitutional Convention (IETF/constitutional amendment) — doctrine major-version bumps require 30-day public comment in factory-release-engineering.

[edit]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-tracked
  • customer/ — guide catalog (woodfine/*) — GitHub-tracked
  • deployments/ — 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.

[edit]Continuous Disclosure Posture

Every artifact written to the workspace — documentation, commit messages, code comments — is treated as potentially reviewable under continuous-disclosure obligations. Forward-looking statements about future capability, timeline, or customer outcome carry "planned"/"intended"/"may" framing, a stated reasonable basis, cautionary language, and material assumptions. This is not a compliance statement; it is the operational practice that makes compliance a byproduct.[^1][^2]

[edit]See also

Edit this page · View source