FS architecture and the WORM backbone
← All revisions
editorial(media-knowledge-documentation): enrich System of Record TOPICs — Key Takeaways + vs-local-FS contrast in service-fs-architecture; cross-link service-content↔service-fs
@@ -17,6 +17,8 @@ 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. `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 To ensure modularity and survivability, `service-fs` is implemented as a decoupled four-layer stack: @@ -43,10 +45,20 @@ The platform achieves structural WORM compliance by structurally denying record This architecture ensures that `service-fs` remains portable, verifiable, and resilient to vendor obsolescence. ## Key takeaways - `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 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). - Monthly Sigstore Rekor anchoring by [[fs-anchor-emitter]] creates an external, publicly verifiable timestamp chain for the entire ledger. ## See also - [[fs-anchor-emitter]] - [[service-fs-security-compliance]] - [[worm-ledger-architecture]] - [[sel4-microkernel-substrate]] - [[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 - [[worm-ledger-architecture]] — infrastructure-level WORM architecture - [[worm-ledger-design]] — the design philosophy behind the WORM approach - [[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-pointsav-link|PointSav Link Service]] — hot-pluggable adapter connecting os-* nodes to the fleet fabric