Retention-enforced, tamper-evident preservation designed for decades rather than backup cycles.
Backup answers a question about recent state: can yesterday be restored. Preservation answers a question about durable obligation: will this remain available, intact, and interpretable years from now, including under legal or regulatory examination, and including when the people and systems that created it are gone.
The two have different failure modes, different time horizons, and different architectures.
Our research treats retention as something a system enforces rather than something an operator promises. A retention decision should be bound to the asset, expressed in terms the storage layer understands, and resistant to being shortened by ordinary administrative action.
That reframing exposes an important distinction between configurations where retention is administratively reversible and configurations where it is genuinely write-once until expiry, which we document explicitly rather than eliding.
Bytes surviving is a necessary but insufficient condition. An asset preserved without its provenance, relationships, and context may remain readable while ceasing to be meaningful.
We therefore treat lineage as part of the preserved object rather than as external documentation about it.
Obligations bound to assets and honored by the storage layer.
Alteration that is detectable and localizable, not merely discouraged.
Lineage and relationships preserved alongside content.
Architecture premised on decades, personnel turnover, and system replacement.