Architecture
- Architecture overview — PointSav platform
A map of the PointSav platform's major architectural surfaces: compute substrate, software distribution, GIS intelligence, and the editorial pipeline.
- Asset-anchored BIM vault
A building's authoritative digital record structured as plain-text and standardized-binary files in a git-versioned directory, qualifying as an ISO 19650-conforming Common Data Environment that travels with the property deed.
- Building Design System
A planned coordination layer for the built environment: a canonical, machine-readable library of building-element specifications that independent BIM authoring surfaces consume by reference, the way a software design system keeps independent product teams consistent.
- Crypto payment and license issuance architecture
The payment and license architecture behind software.pointsav.com — custodian-free, from on-chain USDC transfer to Ed25519-signed download token, no accounts.
- Customer hostability
Customer hostability is the architectural commitment that every artefact runs on the customer's own hardware and keys, making self-hosted deployment the canonical pattern.
- DataGraph Federation: From app-orchestration-slm to app-orchestration-graph
How PointSav federates sovereign per-archive DataGraphs through a single auditable gateway, and the conditions under which that gateway becomes a dedicated service.
- Direct-payment settlement
Payment for marketplace transactions is planned to flow directly from buyer to customer-tenant; PointSav's share is a settlement fee, not a recurring subscription.
- Economic model — community and SMB customer tiers
PointSav's two-tier commercial structure: a free Community tier as an adoption funnel, and a paid SMB tier targeting regulated businesses hyperscale billing can't serve.
- Flat-file BIM leapfrog
The Building Design System is built on five architectural constraints — flat-file storage, open standards, Rust and Tauri, offline-first operation, and Apache 2.0 licensing. Asset-anchored ownership, offline field use, IoT ingestion, and convergence of the model with lease and financial records follow from the architecture rather than being added on top.
- Hardware co-location methodology
A structured approach for ranking hardware co-location candidates across jurisdictional, network, infrastructure, and cost dimensions, regulatory requirements first.
- Leapfrog 2030 architecture
Structural positioning thesis pairing customer-owned hardware, data, and adapter weights with transactional rather than subscription revenue.
- Mailbox atomicity — flock-based prepend and msg-id idempotency
flock-guarded prepend and msg-id idempotency for flat-file mailboxes — how concurrent sessions serialize writes instead of silently losing messages.
- Multi-engine session coordination — session locks, boot_id, and role guards
Session-lock protocol for concurrent AI engines on one host — boot_id staleness detection and role locks that keep two sessions off the same .git/index.
- os-infrastructure and os-network-admin: Distribution Model
os-network-admin distributes today at software.pointsav.com at $0 USDC (beta); os-infrastructure's bare-metal/cloud-VM distribution model is planned but not yet catalogued. Both ship as signed artifacts, licensed and delivered on-chain.
- Per-user build cache discipline — preventing cross-user Cargo races
Per-user partitioning of the shared Cargo build cache — why a per-developer CARGO_TARGET_DIR eliminates cross-user lock races and permission errors.
- Platform architecture overview
The platform's cryptographic consistency rests on a real Merkle-chained ledger; sovereign bootability — collapsing a deployment into one portable image — is a design goal, not yet a shipped feature.
- PointSav architecture 2030 — a planned overview
The planned scope for PointSav's future constitutional charter — not yet ratified or written; described here in planned/intended terms only.
- PointSav platform — architectural overview
The planned scope for a future constitutional charter intended to encode foundational commitments and structural claims governing PointSav engineering decisions — not yet written or ratified.
- PointSav software distribution substrate
A three-component system — release server, storefront, payment watcher — delivering compiled binaries against on-chain USDC payments, no accounts or subscriptions.
- PointSav — company overview and three-organisation structure
PointSav Digital Systems is a technology vendor building sovereign, on-premise-capable operating systems for record-keeping, within a three-organisation structure.
- Six-tier sovereignty matrix
Six fixed directory prefixes organising the PointSav monorepo by purpose, making the repository self-documenting and enforcing dependency hygiene by convention.
- Three-binary architecture: os-console, os-totebox, os-orchestration
Totebox Orchestration is delivered through three binary operating environments — os-console, os-totebox, os-orchestration — each with a distinct role and target.
- Three-layer architecture
Strict one-way flow of PointSav deliverables through three layers — vendor monorepo, customer showcase catalogue, and private running instances.
- Three-layer stack
The Three-Layer Stack is the infrastructure decomposition pattern across PointSav deployments, separating raw compute, isolated platform execution, and secure operator access.
- Three-ring architecture
The durable composition pattern for the platform: three concentric rings with one-way dependencies, where the AI ring is structurally optional and data flows without it.
- Totebox orchestration as the development environment
PointSav's development environment is itself a Totebox Orchestration instance — the workspace that builds the platform runs on the same architecture it delivers.
- Totebox session
A Totebox Session is an AI-assisted contributor session within a single Totebox Archive — scoped to declared repositories, the standard entry point for development.
- Vertical seed packs marketplace
PointSav intends to distribute curated industry-specific seed packs as starter taxonomies, enabling tenants to contribute refinements back through a planned marketplace.
- Workspace services slice — cgroup partitioning for multi-developer environments
A systemd cgroup memory reservation that protects production services from being evicted by heavy build or research processes on the same host — single-node isolation without Kubernetes.