Architecture

@@ -1,50 +1,82 @@
---
schema: foundry-doc-v1
title: "Architecture — Category Landing"
title: "Architecture"
slug: _index
category: architecture
type: topic
quality: complete
short_description: "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."
status: active
bcsc_class: public-disclosure-safe
last_edited: 2026-04-29
last_edited: 2026-05-15
editor: pointsav-engineering
paired_with: _index.es.md
---

## Architecture
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.

This category covers the design principles, substrate patterns, and cross-cutting invariants that govern how the PointSav platform is built. Architecture articles describe the logical structure of the system — how rings compose, how properties compound across deployments, how editorial and AI-routing layers are coordinated, and why the design choices are durable at the scale of a decade.
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.

The platform is organised around a three-ring stack: Ring 1 handles per-tenant boundary ingest, Ring 2 provides deterministic knowledge and processing, and Ring 3 adds optional AI inference. Architecture articles explain what each ring does, how they interoperate, and the invariants that must hold across all three. Articles in this category are written for engineers and technical readers who need to understand the platform at depth before building on it or extending it.
## Platform structure

## Articles in this category
The foundational structural articles — the patterns that compose every PointSav deployment.

- [[compounding-substrate]] — The five structural properties of the Compounding Substrate and the value-chain inversion they produce.
- [[3-layer-stack]] — The three-ring architecture: boundary ingest, knowledge and processing, and optional intelligence.
- [[apprenticeship-substrate]] — How every operational interaction generates training signal that compounds across deployments.
- [[citation-substrate]] — The machine-readable citation graph that links every published claim to its evidential source.
- [[customer-hostability]] — The design properties that allow a customer to host the full stack on their own hardware.
- [[decode-time-constraints]] — Inference-time constraints applied at the boundary to enforce compliance and safety without post-processing.
- [[design-system-substrate]] — The visual and component substrate that keeps UI consistent across the platform's applications.
- [[disclosure-substrate]] — The continuous-disclosure architecture that produces BCSC-compliant output as a structural property.
- [[language-protocol-substrate]] — The four-family adapter taxonomy that routes editorial work through a shared linguistic air-lock.
- [[reverse-funnel-editorial-pattern]] — The pipeline by which cluster drafts are refined and published to the documentation wiki.
- [[substrate-native-compatibility]] — How the substrate maintains compatibility across tenant deployments without a compatibility layer.
- [[trajectory-substrate]] — The session-trajectory capture mechanism that feeds the continued-pretraining path.
- [[worm-ledger-architecture]] — The four-layer WORM ledger that satisfies SEC 17a-4(f) and eIDAS requirements by structure.
- [[anti-homogenization-discipline]] — The editorial discipline that prevents AI-generated content from converging to a single voice.
- [[capability-based-security]] — Capability-based security as the foundation of the ToteboxOS isolation model.
- [[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-two 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.

<!-- ENGINE: this list is editorial in iteration-1; iteration-2+
generates it from category-directory file listing once PL.7
chunked-migration moves articles into category subdirectories. -->
## Security and identity

## See also
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-auth]] — Machine-based authorization: cryptographic hardware pairing replaces username and password; the pair is the permission.
- [[crypto-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-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-stack-architecture]] — The full Rust dependency graph and binary architecture for service-slm.
- [[sovereign-ai-routing]] — 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

- [Wiki home](/)
- [Systems](/systems/)
- [Services](/services/)
- [Governance](/governance/)
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]] — 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; Foundry'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.
- [[vertical-seed-packs-marketplace]] — Curated industry-specific starter taxonomies distributed as seed packs; tenants contribute refinements back through a planned marketplace.

## Location intelligence and domain

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

- [[co-location-methodology]] — The spatial analysis methodology for co-location ranking: how retail and institutional concentrations are measured and scored.
- [[location-intelligence-strategy]] — The strategic and architectural frame for the location intelligence substrate: flat-file open-GIS, offline-first, no per-seat vendor costs.
- [[flat-file-bim-leapfrog]] — How Building Information Modelling is handled as flat-file ISO 19650 records rather than hosted database instances.
- [[building-design-system-bim]] — Design system tooling adapted for BIM and real-property workflows.
- [[development-regions]] — Regional taxonomy for development and planning analysis across PointSav deployments.

## See also

<!-- EDITORIAL NOTE: PL.7 chunked normalization sweep will migrate
 root-prefixed TOPICs into this category subdirectory. Until
 migration lands, the existing root TOPICs render at their current
 URLs (topic-<slug>.md); this landing references them by current slug. -->
- [Substrate](/substrate/) — foundational mechanism concepts: the compounding, apprenticeship, citation, and disclosure substrates
- [Patterns](/patterns/) — named design patterns realised across the platform
- [Governance](/governance/) — the formal decision records, licensing posture, and compliance requirements
- [Infrastructure](/infrastructure/) — fleet deployment topology, cloud runtime, and physical infrastructure