Immutable storage and secure backup

@@ -18,6 +18,8 @@ The platform is designed to provide auditors and investors with a tamper-evident

## Key Takeaways

**Correction (2026-08-02) — compliance-relevant, escalated:** the "hardware controller" / "drive-level" enforcement claimed throughout this article does not match the real mechanism. Verified against canonical `origin/main`, `service-fs/ARCHITECTURE.md` documents the real enforcement as three layers, none of them hardware: (1) Rust API surface — no public `WormLedger` method removes or modifies an entry; (2) **filesystem level** — finalised tiles are marked read-only (`chmod 0o444`), with `chattr +i` immutability planned as *future* hardening once a systemd unit lands and the operator grants `CAP_LINUX_IMMUTABLE`; (3) cryptographic — a Merkle hash chain and Rekor-anchored checkpoints detect retroactive modification. This is materially weaker than "the hardware controller rejects the write" — a privileged administrator today *can* `chmod` a finalized tile back to writable (detection would still catch it via the hash chain, but the write itself isn't hardware-blocked). No evidence was found anywhere in `service-fs` of a "paired backup drive" cryptographic-pairing scheme or key-destruction-based legal deletion — both confirmed absent, zero hits. This directly contradicts the more careful, filesystem-level framing already correctly stated in this wiki's own `[[worm-ledger-architecture]]` article, which this article cites as its "full specification." Escalated to Command given the compliance stakes (tamper-evidence strength claims for regulated recordkeeping). **Flagged, not resolved.**

- Append-only enforcement operates at the drive controller level, not software policy. A system administrator with full credentials cannot overwrite or delete existing blocks — the hardware controller rejects the write. This makes the tamper-evident guarantee non-circumventable by internal actors with elevated privileges.
- Legal deletion works through cryptographic key destruction, not ledger modification. The encrypted record's ciphertext remains on disk after the key is destroyed, proving the record existed at the time of writing while making it permanently unreadable. Access-revocation obligations are met without breaking the append-only ledger's structural integrity.
- Backup drives are cryptographically paired with the primary system's identity keys at provisioning time. A drive physically removed from the system produces unreadable ciphertext — protecting against physical theft of backup media without requiring an additional encryption layer.