Design Patterns

@@ -11,7 +11,7 @@ index_type: thematic
index_scope: patterns
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,13 +32,13 @@ Patterns in this collection sit on top of the [[compounding-substrate]] and the 
The structural commitments that define what a PointSav deployment is and is not.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: sovereignty-and-infrastructure-patterns -->
- [[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.
- [[source-of-truth-inversion]] — Source-of-truth inversion designates one storage layer canonical (signed record), a second derived (rebuilt on demand), and a third session-ephemeral (discarded).
- [[pairing-as-permission]] — The Object Capability access-control principle — a cryptographic pairing is the permission, and its absence means no pathway exists to ask for one — as embodied in the platform's machine-based node admission.
- [[zero-container-runtime]] — The structural commitment that every PointSav deployment runs as a Linux binary under systemd on a plain host, with no container runtime or orchestrator.
- [[zero-execution-routing]] — 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-first-ordering]] — The principle that a vendor building something a customer will install should build it in the same order the customer installs it, on the same substrate.
- [[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.
- [[totebox-archives-as-the-asset]] — Why a Totebox Archive is designed as 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.
<!-- END AUTO-GENERATED -->

@@ -47,10 +47,10 @@ The structural commitments that define what a PointSav deployment is and is not.
The canonical configurations in which the substrate is shipped and the disciplines that keep deployments composable.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: deployment-and-configuration -->
- [[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.
- [[deployment-patterns]] — The six canonical configurations the PointSav substrate is deployed in — each built on the same five primitives and OS 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.
- [[3-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.
- [[customer-tier-catalog-pattern]] — Catalog-versus-instance discipline at the customer tier — reusable deployment definitions tracked in git, tenant-specific instances kept out of shared repositories.
<!-- END AUTO-GENERATED -->

## Collaboration and editorial workflow
@@ -69,11 +69,11 @@ Patterns that govern how multiple sessions, multiple engines, and multiple human
Patterns that recur in the operator-facing chrome — the wiki, the location-intelligence surface, the desktop family.

<!-- AUTO-GENERATED MEMBERSHIP: DO NOT EDIT BELOW — regenerate from index_group: interface-and-user-experience -->
- [[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]] — 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.
- [[knowledge-wiki-leapfrog-architecture]] — Wiki engine strategy serving flat Markdown from git with Wikipedia-shaped chrome, reaching muscle-memory parity before adding a citation and provenance layer.
- [[location-intelligence-ux]] — Conclusion-First interface philosophy rendering ranked tier conclusions rather than individual data points, so defensible commercial nodes surface immediately.
- [[wikipedia-leapfrog-design]] — What the wiki engine inherits from Wikipedia, what it adds beyond it, and what the five-percent leapfrog headroom means.
- [[federation-via-content-mounts]] — 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.
- [[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, and is intended to extend it into facility-management workflows.
<!-- END AUTO-GENERATED -->

## See also