Architecture

@@ -11,7 +11,7 @@ index_type: thematic
index_scope: architecture
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-08-06
last_edited: 2026-09-04
editor: pointsav-engineering
paired_with: _index.es.md
---
@@ -32,17 +32,17 @@ The three-ring model is the load-bearing frame: Ring 1 handles per-tenant bounda
The foundational structural articles — the patterns that compose every PointSav deployment.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: platform-structure -->
- [[three-ring-architecture]] — Three concentric rings with strict one-way dependencies; AI is structurally optional; the deterministic pipeline runs fully without Ring 3.
- [[3-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.
- [[foundry-doctrine-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-overview]] — PointSav Digital Systems: what the company builds, how it is organised, and the three-entity corporate structure.
- [[architecture]] — The platform's two structural properties: distributed cryptographic consistency and sovereign bootability, preserved simultaneously across cloud and offline-vault environments.
- [[architecture-overview]] — A map of the platform's major architectural surfaces: compute substrate, software distribution, GIS intelligence, and the editorial pipeline.
- [[foundry-doctrine-architecture]] — The constitutional charter in full: the six pillars, the numbered structural claims, and the eight cross-industry process inventions.
- [[three-binary-architecture]] — The three binary operating environments — os-console, os-totebox, os-orchestration — each with a distinct role, deployment target, and hosted-application set.
- [[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.
- [[3-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-layer-architecture]] — Strict one-way flow of PointSav deliverables through three layers — vendor monorepo, customer showcase catalogue, and private running instances.
- [[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.
- [[foundry-doctrine-overview]] — The planned scope for PointSav's future constitutional charter — not yet ratified or written; described here in planned/intended terms only.
- [[leapfrog-2030-architecture]] — Structural positioning thesis pairing customer-owned hardware, data, and adapter weights with transactional rather than subscription revenue.
- [[pointsav-overview]] — PointSav Digital Systems is a technology vendor building sovereign, on-premise-capable operating systems for record-keeping, within a three-organisation structure.
- [[architecture]] — 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.
- [[architecture-overview]] — A map of the PointSav platform's major architectural surfaces: compute substrate, software distribution, GIS intelligence, and the editorial pipeline.
- [[foundry-doctrine-architecture]] — 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.
- [[three-binary-architecture]] — Totebox Orchestration is delivered through three binary operating environments — os-console, os-totebox, os-orchestration — each with a distinct role and target.
<!-- END AUTO-GENERATED -->

## Security and identity
@@ -78,16 +78,16 @@ How AI requests are classified, routed, and contained so they never touch the au
The principles and mechanisms by which customers own their deployment outright.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: customer-ownership-and-deployment -->
- [[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]] — 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-development]] — 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.
- [[foundry-services-slice-model]] — The systemd cgroup partition that keeps production services running under load from concurrent build sessions on the same shared Totebox host.
- [[cargo-target-per-user-discipline]] — Per-developer build-cache partitioning that eliminates cross-user lock races on a shared Totebox development host.
- [[mailbox-atomicity]] — flock-guarded prepend and msg-id idempotency for the flat-file mailboxes that Totebox sessions use to communicate.
- [[multi-engine-session-coordination]] — Session-lock protocol with boot_id staleness detection that keeps concurrent AI engines off the same `.git/index`.
- [[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.
- [[economic-model]] — 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.
- [[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.
- [[totebox-orchestration-development]] — 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.
- [[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.
- [[foundry-services-slice-model]] — 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.
- [[cargo-target-per-user-discipline]] — Per-user partitioning of the shared Cargo build cache — why a per-developer CARGO_TARGET_DIR eliminates cross-user lock races and permission errors.
- [[mailbox-atomicity]] — flock-guarded prepend and msg-id idempotency for flat-file mailboxes — how concurrent sessions serialize writes instead of silently losing messages.
- [[multi-engine-session-coordination]] — 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.
<!-- END AUTO-GENERATED -->

## Location intelligence and domain
@@ -95,8 +95,8 @@ The principles and mechanisms by which customers own their deployment outright.
Architectural decisions for the location intelligence and real-property domain.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: location-intelligence-and-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 [[retail-co-location-tier-methodology|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.
- [[hardware-co-location-methodology]] — A structured approach for ranking hardware co-location candidates across jurisdictional, network, infrastructure, and cost dimensions, regulatory requirements first.
- [[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.
- [[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.
- [[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.
<!-- END AUTO-GENERATED -->