Design PatternsIndex

The patterns category collects named design patterns realised across the platform. A pattern in this category is a recurring shape — applied at the editorial, interface, or coordination layer — that solves a structural problem in a way other parts of the platform reuse. Patterns differ from substrates: a substrate is a load-bearing mechanism the platform depends on (and that compounds over time); a pattern is a design choice that can be applied or not. Patterns differ from architecture: an architecture article describes how a specific system is composed; a pattern describes a shape that recurs across systems.

Patterns in this collection sit on top of the Compounding substrate and the Three-ring architecture — they describe how the platform expresses those foundations in recurring, named shapes.

Start here: read Source-of-truth inversion and Pairing as permission first — they are the load-bearing patterns that the others build on.

Sovereignty and infrastructure patterns

The structural commitments that define what a PointSav deployment is and is not.

• Source-of-truth inversion — Designates one layer as canonical (signed, committed), a second as a deterministically rebuilt view, and a third as session-ephemeral; eliminates entire classes of sync and data-loss bugs.
• Pairing as permission — The Object Capability access-control principle — a cryptographic pairing is the permission, its absence means no pathway — as embodied in the platform's machine-based node admission.
• Zero-container runtime — Every deployment runs as a Linux binary under systemd on a plain VM or bare-metal host; no container runtime, no container orchestrator, no managed-runtime platform.
• Presentation-layer routing and client-side script — The platform's public homepage templates use a native-CSS checkbox pattern for language toggling and interactive elements, alongside a small amount of client-side JavaScript for page-integrity display and analytics.
• Customer-first ordering — A software vendor building something a customer will install should build it in the same order the customer will install it, on the same substrate the customer will use.
• 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.
• Totebox Archives as the asset — Why a Totebox Archive is a self-contained, freely transferable data unit rather than a database record owned by the platform that created it.
• City code as composable geometry — A composition-first pattern that encodes regulatory requirements into element specifications as geometric and numeric constraints rather than applying them post-design, so a non-compliant configuration cannot be placed in the first place.

Deployment and configuration

The canonical configurations in which the substrate is shipped and the disciplines that keep deployments composable.

• Deployment patterns — The six canonical configurations in which the PointSav substrate is deployed — each built on the same five primitives and OS surface, with the Chart of Accounts and compliance surface adapted per segment.
• Three-layer architecture — How PointSav deliverables move through SOFTWARE, SHOWCASE, and INSTANCE layers with a strict one-way vendor-to-customer flow.
• Three-layer stack — The three-layer infrastructure decomposition: raw compute capability, isolated platform execution, and secure operator access.
• Customer-tier catalog pattern — Separates deployment catalog entries (tenant-agnostic, git-tracked in the fleet-deployment repository) from numbered instances (tenant-specific, gitignored); the prefix taxonomy and path structure make catalog-versus-instance visible without reading a MANIFEST.

Collaboration and editorial workflow

Patterns that govern how multiple sessions, multiple engines, and multiple humans collaborate without corrupting the canonical record.

• Collaboration via passthrough relay — a removed substrate pattern — A real-time collaborative editing design that held no document state on the server, forwarding CRDT updates directly between clients — implemented in the wiki engine, then removed.
• Model tier discipline — The Doorman routes every inference request to one of three compute tiers — local, burst GPU, or external API — based on a complexity hint and live budget state, not a caller's direct choice.
• Multi-engine session coordination — session locks, boot_id, and role guards — How multiple AI engines coordinate on the same workspace without racing on the .git/index or each other's session state.
• Mailbox atomicity — flock-based prepend and msg-id idempotency — The atomic mailbox primitive that keeps inbox / outbox handoffs across sessions consistent under concurrent writes.

Interface and user experience

Patterns that recur in the operator-facing chrome — the wiki, the location-intelligence surface, the desktop family.

• Knowledge wiki leapfrog architecture — The wiki engine design: Wikipedia-shaped interface elements over flat Markdown git files, with citation verification, research trail provenance, and AI-integrated editing as the differentiation layer.
• Location intelligence UX design philosophy — The Conclusion-First design philosophy: ranked tier conclusions rather than individual data points, so users see the most defensible commercial nodes at national zoom before drilling into individual operators.
• Wikipedia leapfrog design — muscle memory and 5% headroom — What the wiki engine inherits from Wikipedia, what it adds beyond it, and what the five-percent leapfrog headroom means.
• Content mounts and federation — The wiki engine renders curated articles committed directly to its repository alongside content mounted from separate local directories, sharing one URL surface and search index.
• AEC interface conventions — BIM authoring tools across the industry share a common interface vocabulary — a spatial hierarchy, an element properties panel, a 3D viewport, and saved views — because they build on the same underlying IFC data model; the Building Design System's planned interface layer reuses this vocabulary rather than inventing a new one.

See also

• Building Blocks — foundational mechanisms patterns build on
• How It's Built — concrete platform architecture
• Applications — operator-facing applications that compose these patterns
• Operating Systems — the operating systems on which the patterns are realised