Three-layer stack

@@ -24,13 +24,13 @@ paired_with: 3-layer-stack.es.md

> The Three-Layer Stack is the infrastructure decomposition pattern used across PointSav deployments, separating raw computing capability, isolated platform execution, and secure operator access into three distinct layers.

**The Three-Layer Stack** is the foundational infrastructure pattern that decouples operational logic from physical hardware across [[pointsav-overview|PointSav]] deployments. The infrastructure layer provides raw computing capability — bare metal, cloud instances, or customer hardware. The platform layer runs isolated [[sel4-microkernel-substrate|micro-kernels]] and services, applying [[capability-based-security|capability-based security]] boundaries between components. The delivery layer provides secure terminal access so operators interact with the system without touching the underlying infrastructure directly. Each layer is independently replaceable, which means a customer can migrate from a cloud infrastructure layer to on-premises hardware without changing how the platform layer operates.
**The Three-Layer Stack** is the foundational infrastructure pattern that decouples operational logic from physical hardware across [[pointsav-overview|PointSav]] deployments. The infrastructure layer provides raw computing capability — bare metal, cloud instances, or customer hardware. The platform layer runs [[totebox-os|the archive service]] and the rest of the Ring 1/Ring 2 service set; [[sel4-microkernel-substrate|microkernel isolation]] is the design target for this layer and has a real, working proof for the archive service specifically, but most services running today do so as ordinary processes, not yet under kernel-enforced isolation. The delivery layer provides secure terminal access so operators interact with the system without touching the underlying infrastructure directly. Each layer is independently replaceable, which means a customer can migrate from a cloud infrastructure layer to on-premises hardware without changing how the platform layer operates.

## Key Takeaways

- Three distinct layers: Infrastructure (raw compute — bare metal, cloud, or customer hardware), Platform (isolated microkernel and service execution with capability-based security boundaries), Delivery (terminal and console interfaces operators interact with directly).
- Three distinct layers: Infrastructure (raw compute — bare metal, cloud, or customer hardware), Platform (service execution with capability-scoped access, kernel-level isolation proven for one service and the design target for the rest), Delivery (terminal and console interfaces operators interact with directly).
- Independent replaceability at each layer. Migrating from a cloud infrastructure to on-premises hardware does not require changes to the platform layer. The layers are decoupled by design, not by convention.
- No component at the platform layer can exceed explicitly granted capabilities. Isolation is enforced at the [[sel4-microkernel-substrate|microkernel level]], not by policy — a compromised service cannot elevate its own access.
- No component at the platform layer is intended to exceed its explicitly granted capabilities. [[sel4-microkernel-substrate|Kernel-level isolation]] enforcing that boundary is proven for the archive service's boot path; most other services run today without it.
- The delivery layer is the only layer operators touch directly. It forwards requests into the platform and returns results upward; operators never have direct access to infrastructure-layer primitives such as raw disk or network interfaces.

## Overview
@@ -38,7 +38,7 @@ paired_with: 3-layer-stack.es.md
The three layers map directly to the operational concerns of a regulated SMB deployment:

- **Infrastructure layer** — the physical or virtual computing substrate: bare-metal servers, GCE instances, customer iMac hardware, or any combination. This layer supplies CPU time and memory. It makes no security guarantees above what the hardware provides.
- **Platform layer** — the operating system and service execution environment: [[totebox-os|ToteboxOS]], capability managers, and the [[three-ring-architecture|Ring 1/Ring 2]] service processes. Isolation between components is enforced at this layer. No component at the platform layer can exceed the capabilities explicitly granted to it.
- **Platform layer** — the operating system and service execution environment: [[totebox-os|the archive service]] and the [[three-ring-architecture|Ring 1/Ring 2]] service processes. Kernel-enforced isolation between components is the design target, proven for the archive service's own boot path; most services today run as ordinary processes without that isolation guarantee. Capability-scoped access — no component exceeding what it's explicitly granted — is the intended boundary regardless of which isolation mechanism enforces it.
- **Delivery layer** — the terminal and console interfaces operators use: [[console-os|ConsoleOS]] terminals, the proofreader interface, and any browser-based access surface. The delivery layer is the only layer operators interact with directly; it forwards requests down into the platform and returns results upward.

## See also