Diff: architecture/3-layer-stack.es
From b069558 to b069558
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Three-layer stack" | title: "Three-layer stack" |
| slug: 3-layer-stack | slug: 3-layer-stack |
| category: architecture | category: architecture |
| type: topic | type: topic |
| quality: stub | quality: stub |
| short_description: "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." | short_description: "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." |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-04-30 | last_edited: 2026-04-30 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: [] | cites: [] |
| paired_with: 3-layer-stack.es.md | 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 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 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. |
| <!-- EXPAND: lead needs 200+ words --> | <!-- EXPAND: lead needs 200+ words --> |
| ## Overview | ## Overview |
| The three layers map directly to the operational concerns of a regulated SMB deployment: | 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. | - **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|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. |
| - **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. | - **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 | ## See also |
| - [[compounding-substrate]] | - [[compounding-substrate]] |
| - [[capability-based-security]] | - [[capability-based-security]] |
| - [[sel4-microkernel-substrate]] | - [[sel4-microkernel-substrate]] |
| - [[sovereign-ai-routing]] | - [[sovereign-ai-routing]] |
| - [[worm-ledger-architecture]] | - [[worm-ledger-architecture]] |