Diff: architecture/3-layer-stack
From eaac482 to eaac482
+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 deployments. The infrastructure layer provides raw computing capability — bare metal, cloud instances, or customer hardware. The platform layer runs isolated micro-kernels and services, applying 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 deployments. The infrastructure layer provides raw computing capability — bare metal, cloud instances, or customer hardware. The platform layer runs isolated micro-kernels and services, applying 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: ToteboxOS, capability managers, and the 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: ToteboxOS, capability managers, and the 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: 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: 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-foundation]] | - [[sel4-foundation]] |
| - [[sovereign-ai-routing]] | - [[sovereign-ai-routing]] |
| - [[worm-ledger-architecture]] | - [[worm-ledger-architecture]] |
| ## References | ## References |
| - `conventions/three-ring-architecture.md` — the Ring 1 / Ring 2 / Ring 3 service model that sits inside the platform layer | - `conventions/three-ring-architecture.md` — the Ring 1 / Ring 2 / Ring 3 service model that sits inside the platform layer |
| - `DOCTRINE.md §IV` — workspace topology and deployment pattern | - `DOCTRINE.md §IV` — workspace topology and deployment pattern |
| - `IT_SUPPORT_Nomenclature_Matrix_V8.md §3` — canonical OS and service names | - `IT_SUPPORT_Nomenclature_Matrix_V8.md §3` — canonical OS and service names |