Design Patterns
- 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.
- 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.
- 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.
- 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.
- 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-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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.