Diff: infrastructure/storage
From 21d8df6 to 21d8df6
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Immutable storage and secure backup" | title: "Immutable storage and secure backup" |
| slug: storage | slug: storage |
| short_description: "The platform enforces hardware-level append-only writes to provide an unalterable, tamper-evident record while supporting legal deletion through cryptographic key destruction and backup protection via cryptographically paired secondary drives." | short_description: "The platform enforces hardware-level append-only writes to provide an unalterable, tamper-evident record while supporting legal deletion through cryptographic key destruction and backup protection via cryptographically paired secondary drives." |
| category: infrastructure | category: infrastructure |
| type: topic | type: topic |
| quality: complete | quality: complete |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-09 | last_edited: 2026-05-09 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| paired_with: storage.es.md | paired_with: storage.es.md |
| --- | --- |
| The platform is designed to provide auditors and investors with a tamper-evident record: once data is written, it cannot be secretly overwritten or deleted. This property is enforced at the hardware level as part of the [[worm-ledger-design|WORM ledger substrate]], not solely by software policy. | The platform is designed to provide auditors and investors with a tamper-evident record: once data is written, it cannot be secretly overwritten or deleted. This property is enforced at the hardware level as part of the [[worm-ledger-design|WORM ledger substrate]], not solely by software policy. |
| ## Hardware-enforced append-only writes | ## Hardware-enforced append-only writes |
| Standard storage hardware allows an administrator with sufficient privileges to overwrite or delete any file. The platform's storage subsystem uses drives configured in an append-only mode enforced by the hardware controller. The drive accepts new writes but rejects modification of existing blocks. This produces an unalterable history of every record added to the system — no administrative action can retroactively change what was written. | Standard storage hardware allows an administrator with sufficient privileges to overwrite or delete any file. The platform's storage subsystem uses drives configured in an append-only mode enforced by the hardware controller. The drive accepts new writes but rejects modification of existing blocks. This produces an unalterable history of every record added to the system — no administrative action can retroactively change what was written. |
| The append-only property is the foundation of the WORM (Write Once, Read Many) ledger design. See [[worm-ledger-architecture]] for the full ledger specification. | The append-only property is the foundation of the WORM (Write Once, Read Many) ledger design. See [[worm-ledger-architecture]] for the full ledger specification. |
| ## Legal deletion without breaking the ledger | ## Legal deletion without breaking the ledger |
| Some legal frameworks require that specific records be made inaccessible on request. The platform satisfies these requirements without modifying the ledger itself. When a record must be made unreadable: | Some legal frameworks require that specific records be made inaccessible on request. The platform satisfies these requirements without modifying the ledger itself. When a record must be made unreadable: |
| 1. The encryption key for that record is cryptographically destroyed. | 1. The encryption key for that record is cryptographically destroyed. |
| 2. The record's ciphertext remains on the drive, proving the record existed at the time of writing. | 2. The record's ciphertext remains on the drive, proving the record existed at the time of writing. |
| 3. The record is permanently unreadable without the key. | 3. The record is permanently unreadable without the key. |
| This approach maintains the integrity of the append-only ledger while meeting the access-revocation obligations a regulatory authority may impose. | This approach maintains the integrity of the append-only ledger while meeting the access-revocation obligations a regulatory authority may impose. |
| ## Paired backup drives | ## Paired backup drives |
| When the primary drive reaches capacity, backup copies are made to a secondary drive that is cryptographically paired with the primary system. A backup drive removed from the primary system produces unreadable ciphertext. This protects against physical theft of backup media. | When the primary drive reaches capacity, backup copies are made to a secondary drive that is cryptographically paired with the primary system. A backup drive removed from the primary system produces unreadable ciphertext. This protects against physical theft of backup media. |
| The pairing is established at provisioning time and is specific to the primary system's identity keys. Restoring from a backup drive requires access to those keys, which are held in the primary system's key store. | The pairing is established at provisioning time and is specific to the primary system's identity keys. Restoring from a backup drive requires access to those keys, which are held in the primary system's key store. |
| ## See also | ## See also |
| - [[worm-ledger-architecture]] — the full WORM ledger four-layer specification | - [[worm-ledger-architecture]] — the full WORM ledger four-layer specification |
| - [[worm-ledger-design]] — the regulatory compliance mapping and customer key sovereignty rationale | - [[worm-ledger-design]] — the regulatory compliance mapping and customer key sovereignty rationale |
| - [[edge-deployment]] — how data is sanitized at the boundary before it reaches storage | - [[edge-deployment]] — how data is sanitized at the boundary before it reaches storage |