ArchitectureIndex

PointSav is composed from three concentric rings with strict one-way dependencies, a deterministic data pipeline that runs fully without AI, and a sovereignty discipline that allows customers to fork the entire stack on day one. Architecture articles describe the structural decisions behind those properties — why they are designed the way they are, how they compose, and what invariants must hold across every deployment.

The three-ring model is the load-bearing frame: Ring 1 handles per-tenant boundary ingest, Ring 2 provides deterministic knowledge and processing, and Ring 3 adds optional AI inference that never writes to the authoritative record. Articles in this category explain the rings, the security model that enforces their boundaries, the AI routing logic, and the customer-ownership principles that govern the platform's commercial architecture.

Start here: Three-ring architecture — the load-bearing frame every other article in this category assumes: three concentric rings with strict one-way dependencies, AI structurally optional throughout.

Platform structure

The foundational structural articles — the patterns that compose every PointSav deployment.

• Three-ring architecture — Three concentric rings with strict one-way dependencies; AI is structurally optional; the deterministic pipeline runs fully without Ring 3.
• Three-layer stack — The three-layer infrastructure decomposition: raw compute capability, isolated platform execution, and secure operator access.
• Three-layer architecture — How PointSav deliverables move through SOFTWARE, SHOWCASE, and INSTANCE layers with a strict one-way vendor-to-customer flow.
• Six-tier sovereignty matrix — The six-prefix monorepo taxonomy (app-, asset-, os-, service-, system-, moonshot-) that makes dependency hygiene structural.
• PointSav architecture 2030 — a planned overview — A public summary of the platform's constitutional charter: six pillars, fifty-four structural claims, and the economic model that sustains them.
• Leapfrog 2030 architecture — The Leapfrog 2030 architectural vision: the infrastructure physics of the 2030 hyperscaler era, and how the platform is positioned to benefit from it.
• PointSav — company overview and three-organisation structure — PointSav Digital Systems: what the company builds, how it is organised, and the three-entity corporate structure.
• Platform architecture overview — The platform's two structural properties: distributed cryptographic consistency and sovereign bootability, preserved simultaneously across cloud and offline-vault environments.
• Architecture overview — PointSav platform — A map of the platform's major architectural surfaces: compute substrate, software distribution, GIS intelligence, and the editorial pipeline.
• PointSav platform — architectural overview — The constitutional charter in full: the six pillars, the numbered structural claims, and the eight cross-industry process inventions.
• Three-binary architecture: os-console, os-totebox, os-orchestration — The three binary operating environments — os-console, os-totebox, os-orchestration — each with a distinct role, deployment target, and hosted-application set.

Security and identity

How the platform enforces isolation, verifies identity, and makes unauthorised access structurally impossible.

• Diode standard — The foundational unidirectional command-flow discipline; eliminates lateral movement by removing the routing logic that would allow it.
• Capability-based security — Every software component holds a cryptographic capability token to communicate with any other; no ambient authority.
• Machine-based authorization — Machine-based authorization: cryptographic hardware pairing replaces username and password; the pair is the permission.
• Cryptographic payload attestation — Edge-node content attestation: client-side SHA-256 hashing lets any auditor verify a disclosure has not been altered in transit.
• Cryptographic ledgers — Immutable-state storage by hash-chain; any alteration breaks a verifiable cryptographic proof rather than a policy check.
• Personnel and permissions — Contributor identity in Totebox Orchestration: cryptographic hardware pairings, not role-based access control stored in a database.
• Five-stage supply chain — Code moves from contributor to production through five stages, with a double-blind air-gap that separates production credentials from contributor workspaces.
• Verification surveyor — The human-in-the-loop component that presents extracted identity fragments to an operator before permanent commitment to the verified ledger.

AI routing and inference boundary

How AI requests are classified, routed, and contained so they never touch the authoritative record.

• Doorman protocol — The Doorman: the single AI boundary that sanitises data, routes among compute tiers, and holds every API key; no key lives outside this boundary.
• PointSav-LLM — The planned vendor-tier specialist model (Tier 3 of the Four-Tier SLM Substrate Ladder); continued pretraining of OLMo 3 32B on the federated apprenticeship corpus.
• SLM Rust stack architecture — The full Rust dependency graph and binary architecture for service-slm.
• AI routing and the linguistic air-lock — AI requests pass through a local sanitisation step before reaching any external model; internal structured data never travels to third-party servers in identifiable form.
• Zero-container inference — Why the platform runs inference directly in the service binary rather than in a container runtime, and what that means for isolation and cost.
• Decode-time constraints — Structural constraints applied at each token-emission step; banned vocabulary and structurally invalid responses are mathematically impossible to produce.

Customer ownership and deployment

The principles and mechanisms by which customers own their deployment outright.

• Customer hostability — The architectural commitment that every artefact runs on the customer's own hardware, against the customer's own keys, with the customer's own audit ledger.
• Economic model — community and SMB customer tiers — The two-tier commercial structure: a free Community tier and a paid SMB Customer tier sized for regulated businesses that hyperscalers cannot serve economically.
• Direct-payment settlement — Marketplace transaction payments flow directly from buyer to customer-tenant; PointSav's share is a transaction fee at settlement.
• Totebox orchestration as the development environment — The development environment itself is a Totebox Orchestration instance; the workspace that builds the platform runs on the architecture it delivers.
• Totebox session — A Totebox Session: an AI-assisted contributor session scoped to one archive, unable to write outside it, the standard entry point for all development work in Totebox Orchestration.
• Vertical seed packs marketplace — Curated industry-specific starter taxonomies distributed as seed packs; tenants contribute refinements back through a planned marketplace.
• Workspace services slice — cgroup partitioning for multi-developer environments — The systemd cgroup partition that keeps production services running under load from concurrent build sessions on the same shared Totebox host.
• Per-user build cache discipline — preventing cross-user Cargo races — Per-developer build-cache partitioning that eliminates cross-user lock races on a shared Totebox development host.
• Mailbox atomicity — flock-based prepend and msg-id idempotency — flock-guarded prepend and msg-id idempotency for the flat-file mailboxes that Totebox sessions use to communicate.
• Multi-engine session coordination — session locks, boot_id, and role guards — Session-lock protocol with boot_id staleness detection that keeps concurrent AI engines off the same .git/index.

Location intelligence and domain

Architectural decisions for the location intelligence and real-property domain.

• Hardware co-location methodology — The methodology for ranking third-party data-center facility co-location candidates: jurisdictional fit, network transit, infrastructure compatibility, and cost, regulatory requirements first. (Not to be confused with the retail co-location tier methodology, a different subject that shares the same term.)
• Flat-file BIM leapfrog — The five architectural constraints — flat-file storage, open standards, Rust and Tauri, offline-first operation, and Apache 2.0 licensing — that a building's digital record is built on, and the five capabilities that follow from them rather than being added on top.

Additional planned articles for the location-intelligence and BIM/real-property domain — covering regional development taxonomy and the design-system tooling that supports it — are not yet written.

See also

• Substrate — foundational mechanism concepts: the compounding, apprenticeship, citation, and disclosure substrates
• Patterns — named design patterns realised across the platform
• Governance — the formal decision records, licensing posture, and compliance requirements
• Infrastructure — fleet deployment topology, cloud runtime, and physical infrastructure