Design Patterns

Where to start

Fifteen named patterns are written up here, each once and referenced everywhere else. These five recur most across the rest of the knowledge base; read them and most other articles' shorthand resolves.

• Source-of-truth inversion — One layer canonical and signed, one derived and rebuildable on demand, one session-ephemeral. The storage discipline behind the ledger and the knowledge graph alike.
• Pairing as permission — A cryptographic pairing is the permission, and its absence means no pathway exists to ask for one. The object-capability principle the node-admission model is built on.
• Deployment patterns — The six canonical configurations the substrate is deployed in, all built from the same five primitives.
• Customer-first ordering — Build in the order the customer installs, on the same substrate. The rule that explains why the vendor's own workspace runs the product it sells.
• Knowledge wiki leapfrog architecture — Wikipedia-shaped chrome over flat Markdown in git, with an honest account of the two elements still missing from it.

Sovereignty and infrastructure patterns

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

• 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.
• 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 — 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.
• 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.

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 the PointSav substrate is deployed in — each built on the same five primitives and OS surface, adapted per segment.
• 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.

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.

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 — 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 design philosophy — Conclusion-First interface philosophy rendering ranked tier conclusions rather than individual data points, so defensible commercial nodes surface immediately.
• 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, and is intended to extend it into facility-management workflows.

See also

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