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.

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.

See also

• Substrate — foundational mechanisms patterns build on
• Architecture — concrete platform architecture
• Applications — operator-facing applications that compose these patterns
• Systems — the operating systems on which the patterns are realised