Diff: services/service-fs-architecture.es
From 1c02ec1 to 1c02ec1
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| type: topic | type: topic |
| content_type: topic | content_type: topic |
| slug: service-fs-architecture | slug: service-fs-architecture |
| short_description: "A per-tenant Write-Once-Read-Many immutable ledger serving as the tamper-evident backbone for all platform records, implemented as a four-layer decoupled stack with dual Linux and seL4 microkernel runtime envelopes." | short_description: "A per-tenant Write-Once-Read-Many immutable ledger serving as the tamper-evident backbone for all platform records, implemented as a four-layer decoupled stack with dual Linux and seL4 microkernel runtime envelopes." |
| title: "FS architecture and the WORM backbone" | title: "FS architecture and the WORM backbone" |
| category: services | category: services |
| audience: vendor-public | audience: vendor-public |
| bcsc_class: current-fact | bcsc_class: current-fact |
| status: active | status: active |
| language: en | language: en |
| last_edited: 2026-05-08 | last_edited: 2026-05-08 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: service-fs-architecture.es.md | paired_with: service-fs-architecture.es.md |
| --- | --- |
| Every record written to the PointSav platform — identity anchors, email communications, document artifacts — lands in `service-fs`, a per-tenant Write-Once-Read-Many (WORM) immutable ledger. Once written, records cannot be modified or deleted; the ledger is the tamper-evident backbone that [[three-ring-architecture|Ring 2]] services query and Ring 1 services write to. For a regulated operator, this means every data event has a provable, auditable history from the moment it enters the platform. The [[worm-ledger-design]] article describes the WORM design philosophy in detail. | Every record written to the PointSav platform — identity anchors, email communications, document artifacts — lands in `service-fs`, a per-tenant Write-Once-Read-Many (WORM) immutable ledger. Once written, records cannot be modified or deleted; the ledger is the tamper-evident backbone that [[three-ring-architecture|Ring 2]] services query and Ring 1 services write to. For a regulated operator, this means every data event has a provable, auditable history from the moment it enters the platform. The [[worm-ledger-design]] article describes the WORM design philosophy in detail. |
| `service-fs` is not a general-purpose filesystem. A local filesystem permits reads, writes, modifications, and deletions through a standard directory tree. `service-fs` exposes three operations only: `append` (add a record), `read_since` (read forward from a checkpoint), and `checkpoint` (create a signed proof of state). The narrowed API surface is what makes the ledger's integrity guarantees structurally sound rather than policy-enforced. | `service-fs` is not a general-purpose filesystem. A local filesystem permits reads, writes, modifications, and deletions through a standard directory tree. `service-fs` exposes three operations only: `append` (add a record), `read_since` (read forward from a checkpoint), and `checkpoint` (create a signed proof of state). The narrowed API surface is what makes the ledger's integrity guarantees structurally sound rather than policy-enforced. |
| ## The Four-Layer Architecture | ## The Four-Layer Architecture |
| To ensure modularity and survivability, `service-fs` is implemented as a decoupled four-layer stack: | To ensure modularity and survivability, `service-fs` is implemented as a decoupled four-layer stack: |
| - **L4: Anchoring (Workspace-Tier):** Monthly periodic work performed by [[fs-anchor-emitter]] that anchors signed checkpoints to the public Sigstore Rekor log. | - **L4: Anchoring (Workspace-Tier):** Monthly periodic work performed by [[fs-anchor-emitter]] that anchors signed checkpoints to the public Sigstore Rekor log. |
| - **L3: Wire Protocol:** The communication interface (HTTP/axum today; [[mcp-substrate-protocol|MCP]] long-term) that enforces per-tenant `moduleId` boundaries. | - **L3: Wire Protocol:** The communication interface (HTTP/axum today; [[mcp-substrate-protocol|MCP]] long-term) that enforces per-tenant `moduleId` boundaries. |
| - **L2: WORM Ledger API (Rust Trait):** The stable core contract (`append`, `read_since`, `checkpoint`) that survives changes to the layers above or below. | - **L2: WORM Ledger API (Rust Trait):** The stable core contract (`append`, `read_since`, `checkpoint`) that survives changes to the layers above or below. |
| - **L1: Tile Storage Primitive:** The envelope-specific storage engine (POSIX on Linux; capability-mediated on [[sel4-microkernel-substrate|seL4]]) using the **C2SP tlog-tiles** format. | - **L1: Tile Storage Primitive:** The envelope-specific storage engine (POSIX on Linux; capability-mediated on [[sel4-microkernel-substrate|seL4]]) using the **C2SP tlog-tiles** format. |
| ## Dual Boot Envelopes | ## Dual Boot Envelopes |
| A core design property of `service-fs` is its ability to operate across two distinct runtime envelopes using the same codebase. The [[worm-ledger-storage-architecture|WORM storage architecture]] article describes how each envelope satisfies the append-only constraint. | A core design property of `service-fs` is its ability to operate across two distinct runtime envelopes using the same codebase. The [[worm-ledger-storage-architecture|WORM storage architecture]] article describes how each envelope satisfies the append-only constraint. |
| 1. **Envelope A (Current):** A Linux/BSD daemon under systemd. It uses standard POSIX file I/O and process isolation. | 1. **Envelope A (Current):** A Linux/BSD daemon under systemd. It uses standard POSIX file I/O and process isolation. |
| 2. **Envelope B (Intended):** A verified [[sel4-microkernel-substrate|seL4]] Microkit Protection Domain. It is intended to use `moonshot-database` (PSDB) for capability-addressed storage, providing formally verified tenant isolation. | 2. **Envelope B (Intended):** A verified [[sel4-microkernel-substrate|seL4]] Microkit Protection Domain. It is intended to use `moonshot-database` (PSDB) for capability-addressed storage, providing formally verified tenant isolation. |
| ## Durability and Compliance | ## Durability and Compliance |
| The platform achieves structural WORM compliance by structurally denying record modification at the storage layer. This is reinforced by: | The platform achieves structural WORM compliance by structurally denying record modification at the storage layer. This is reinforced by: |
| - **C2SP tlog-tiles:** An open-standard text-based format ensuring 100-year readability. | - **C2SP tlog-tiles:** An open-standard text-based format ensuring 100-year readability. |
| - **C2SP signed-note Checkpoints:** Compact, signed artifacts that prove the state of the ledger at any point in time. | - **C2SP signed-note Checkpoints:** Compact, signed artifacts that prove the state of the ledger at any point in time. |
| - **Audit-Log Sub-Ledger:** A dedicated WORM ledger that records every read event to satisfy SOC 2 processing integrity requirements. | - **Audit-Log Sub-Ledger:** A dedicated WORM ledger that records every read event to satisfy SOC 2 processing integrity requirements. |
| This architecture ensures that `service-fs` remains portable, verifiable, and resilient to vendor obsolescence. | This architecture ensures that `service-fs` remains portable, verifiable, and resilient to vendor obsolescence. |
| ## Key takeaways | ## Key takeaways |
| - `service-fs` is a WORM ledger, not a filesystem. Its API surface is three operations: `append`, `read_since`, `checkpoint`. | - `service-fs` is a WORM ledger, not a filesystem. Its API surface is three operations: `append`, `read_since`, `checkpoint`. |
| - The ledger is per-tenant — each Totebox holds its own isolated ledger; no cross-tenant reads are possible at the storage layer. | - The ledger is per-tenant — each Totebox holds its own isolated ledger; no cross-tenant reads are possible at the storage layer. |
| - The four-layer architecture decouples wire protocol, API contract, and storage engine, so the seL4 Envelope B swap does not require rewriting the service. | - The four-layer architecture decouples wire protocol, API contract, and storage engine, so the seL4 Envelope B swap does not require rewriting the service. |
| - Durability uses open standards: C2SP tlog-tiles (100-year readability) and C2SP signed-note Checkpoints (compact provability). | - Durability uses open standards: C2SP tlog-tiles (100-year readability) and C2SP signed-note Checkpoints (compact provability). |
| - Monthly Sigstore Rekor anchoring by [[fs-anchor-emitter]] creates an external, publicly verifiable timestamp chain for the entire ledger. | - Monthly Sigstore Rekor anchoring by [[fs-anchor-emitter]] creates an external, publicly verifiable timestamp chain for the entire ledger. |
| ## See also | ## See also |
| - [[fs-anchor-emitter]] — the periodic anchor emitter that checkpoints the ledger to Sigstore Rekor | - [[fs-anchor-emitter]] — the periodic anchor emitter that checkpoints the ledger to Sigstore Rekor |
| - [[service-fs-security-compliance]] — compliance profile: SOC 2, WORM regulatory alignment | - [[service-fs-security-compliance]] — compliance profile: SOC 2, WORM regulatory alignment |
| - [[worm-ledger-architecture]] — infrastructure-level WORM architecture | - [[worm-ledger-architecture]] — infrastructure-level WORM architecture |
| - [[worm-ledger-design]] — the design philosophy behind the WORM approach | - [[worm-ledger-design]] — the design philosophy behind the WORM approach |
| - [[sel4-microkernel-substrate]] — the seL4 Microkit envelope (Envelope B) that is the intended runtime | - [[sel4-microkernel-substrate]] — the seL4 Microkit envelope (Envelope B) that is the intended runtime |
| - [[service-content]] — the Gravity Engine that writes L0 base geometry records to service-fs | - [[service-content]] — the Gravity Engine that writes L0 base geometry records to service-fs |
| - [[service-pointsav-link|PointSav Link Service]] — hot-pluggable adapter connecting os-* nodes to the fleet fabric | - [[service-pointsav-link|PointSav Link Service]] — hot-pluggable adapter connecting os-* nodes to the fleet fabric |