InfrastructureIndex

Infrastructure articles sit at the boundary between the abstract platform architecture and the concrete machines, services, and network paths that constitute a live deployment. This category covers storage substrate design, fleet topology, edge deployment patterns, key management operations, and the telemetry and mesh network that connect a fleet. Where the Three-ring architecture articles describe the logical model, the infrastructure articles describe the runtime — the physical substrate, the WireGuard tunnels, and the on-disk WORM ledger that any auditor can verify byte-for-byte.

Start here: The WORM ledger design — the four-layer, tile-based, hash-chained ledger that every other article in this category ultimately writes to or builds on.

Storage substrate

The foundational persistence layer — the Write-Once-Read-Many ledger and the bookkeeping vault built on top of it.

• Totebox archive — A self-contained, freely transferable micro-virtual machine that persists institutional data as immutable flat files; the deployment and storage unit for the os-totebox archive layer.
• WORM ledger design — The four-layer Write-Once-Read-Many ledger: tile-based, hash-chained, cryptographically signed; satisfies SEC 17a-4(f), eIDAS, and SOC 2 by structure rather than policy.
• WORM ledger substrate: four-layer architecture and two boot envelopes — Architectural layout of the WORM ledger across Ring 1 services.
• WORM ledger storage architecture — Physical storage organisation for WORM ledger deployments.
• Immutable storage and secure backup — Hardware-level append-only writes, tamper-evident records, legal deletion through cryptographic key destruction, and backup protection via cryptographically paired secondary drives.
• Data vault bookkeeping substrate — An SMB bookkeeping architecture built on an immutable source vault and append-only journal, with structural separation between the bookkeeping record and any accounting tool.
• Cryptographic ledgers — Immutable-state storage by hash-chain; any alteration breaks a verifiable cryptographic proof rather than a policy check.

Fleet and edge deployment

How a deployment is provisioned, updated, and maintained across on-premises and cloud hardware.

• Edge deployment and boundary ingest — Edge deployment patterns: external network connections routed through Ring 1 boundary-ingest services, payload sanitisation before the core processing rings, clean events recorded to the audit ledger rather than raw network traffic.
• Tier C key wiring — The operational procedure for managing external API keys in the Doorman service: where keys live, how they rotate, and how a breach is contained.
• Genesis protocol — How an isolated fleet bootstraps itself from a cold state, deriving its identity and pairings without an external authority.
• Five-stage supply chain — Code moves from contributor to production through five stages, with a double-blind air-gap that separates production credentials from contributor workspaces.

Network and telemetry

How fleet nodes communicate and how observability signals are collected without centralising identifiable data.

• Sovereign mesh — The WireGuard-based peer-to-peer mesh that connects PointSav fleet nodes without a central routing authority.
• PPN mesh architecture — The private WireGuard mesh that connects Woodfine's fleet nodes, providing encrypted transport without granting application-layer access to the services on those nodes.
• PPN command protocol — The command protocol used over the private mesh: compact binary packets carried inside WireGuard tunnels.
• Zero-state telemetry architecture — Zero-state telemetry: the V4 Intent Beacon collects behavioural and hardware signals from edge clients without cookies, session identifiers, or third-party analytics.
• Telemetry architecture — End-to-end telemetry pipeline: collection at production edge nodes, encrypted transport, locally controlled processing, no third-party cloud dependencies.
• Data sovereignty and zero-state telemetry — How telemetry preserves data-sovereignty guarantees while still producing operationally useful signal.

Compute and VM fabric

How virtual machines are pooled, isolated, and secured across PPN nodes — from the per-node hypervisor resource pool to the seL4 architecture roadmap and the planned distributed fabric that lets VMs borrow compute across the mesh.

• PPN VM resource pool — The three-service stack — fleet controller, host agent, tenant proxy — that provisions, places, and accounts for VMs across a heterogeneous WireGuard mesh.
• PPN hypervisor resource pool — Per-node CPU and RAM pooling via virtio_balloon and cgroups v2 weights, structurally blind to the data-layer aggregator above it.
• PPN tenant VM isolation — What namespace, process, and network isolation the PPN resource pool provides today, and the planned path to per-tenant WireGuard subnets.
• PPN distributed VM fabric — The planned extension of the per-node hypervisor layer to a multi-node pool: cross-node memory lending, a distributed capability ledger, and a sovereign attestation chain.
• PPN three-path seL4 architecture — Three sequential seL4 options for PPN infrastructure nodes, from a hypervisor with a Linux guest to protection domains with no virtual machines at all.

See also

• Architecture — cross-cutting platform architecture and the three-ring model
• Systems — the operating systems that run on this infrastructure
• Services — the services that depend on the storage and network substrate
• Substrate — the foundational mechanism concepts the infrastructure realises