Doctrine entries in this series may include operational tests and controls. These are design requirements derived from first principles; references are illustrative, not determinative. They are not audit methods or compliance checklists. Confidence is high because claims are architectural and derived from first principles, not event reporting. References are included only as context. Failure modes described in this entry reflect general engineering and compliance patterns. They are not claims about any specific platform or organisation.
Summary
The object permanence fallacy is the assumption that a digital object remains unchanged simply because it is retrievable. Retrievability confirms existence. It does not confirm integrity.
ISO 14721:2025 (OAIS) distinguishes archival functions including access and data management, and explicitly addresses long-term preservation concerns such as migration across changing technologies, media, and data formats. In this entry, availability and access are treated as insufficient, by themselves, to establish integrity over time.
NIST SP 800-209 identifies data corruption, unauthorised alteration, tampering of storage-related audit and log data, and compromise of backups and storage OS/binaries, firmware, and images as documented storage infrastructure risks. These risks can manifest even when backups exist and access controls are in place.
A digital object can be corrupted or silently modified without an obvious read error and may not be detected during normal retrieval unless integrity verification is performed.
Compliance programs that treat storage as preservation, and retrievability as proof of integrity, carry structural evidence debt (as defined in the companion entry on structural accumulation of evidence debt) that is not visible during normal operations.
Definition
Object permanence fallacy (as used in this entry): The incorrect assumption that a digital object persists in its original, unmodified state simply because it can be retrieved from a store. The fallacy conflates retrievability with integrity. These are independent properties.
Retrievability (as used in this entry): The capacity to access and read a stored digital object. A necessary but insufficient condition for evidentiary integrity. A retrievable object may be corrupted, silently modified, or missing its integrity binding.
Silent degradation (as used in this entry): Modification or corruption of a stored digital object that may occur without an obvious read error and may not be detected during normal retrieval unless integrity verification is performed. Sources include data corruption, media failure, storage-layer tampering, and format migration side effects.
Active preservation (as used in this entry, informed by ISO 14721:2025): A managed process of maintaining digital objects over time such that their integrity, provenance, and authenticity can be independently verified. ISO 14721:2025 defines mandatory responsibilities for an OAIS and addresses long-term preservation across changing technologies, including migration to new media and forms. This entry uses active preservation to mean managed integrity and preservation-metadata practices that make objects verifiable over time. Distinct from passive storage, which maintains availability without integrity assurance.
Boundary
Retrievability answers: can the object be accessed? Integrity answers: can the object be proven unmodified from its original state? A system can answer yes to the first and be unable to answer the second. These are independent questions with independent control requirements.
Mechanism
How the fallacy develops:
Digital storage systems are designed for availability. Objects written to a store are expected to be readable on retrieval. In practice, this expectation is largely met. Objects are retrieved successfully in the vast majority of cases. The system appears to be working.
The fallacy develops from this operational success. Because retrieval works, the assumption forms that the retrieved object is what it was when it was written. This assumption is not tested unless an explicit integrity verification step is performed.
Object Written to Store
|
v
Time passes.
Normal operations continue.
Objects are retrieved successfully.
|
v
Assumption forms:
"The object is unchanged because it is retrievable."
|
v
Integrity verification is not performed.
Silent degradation is not detected.
Evidence debt accumulates.
|
v
Interrogation Demand
|
v
Verification attempted.
|
v
Degradation detected / integrity binding absent /
hash mismatch / provenance unverifiable.
|
v
Object is retrievable. It is not provable.
What ISO 14721:2025 addresses:
ISO 14721:2025 (OAIS) distinguishes archival functions including access and data management, and explicitly addresses long-term preservation concerns such as migration across changing technologies, media, and data formats. Availability and access functions handle the organisation and retrieval of stored objects. In this entry, those functions are treated as insufficient to establish that objects remain verifiable over time. Preservation responsibilities address what is required to keep objects verifiable as technologies change. These are different functions with different control requirements.
What NIST SP 800-209 identifies:
NIST SP 800-209 addresses storage infrastructure security including risks of data corruption, unauthorised data alteration, tampering of storage-related audit and log data, and compromise of backups and storage OS/binaries, firmware, and images. These are storage-layer risks that can manifest even when access controls and backup coverage are in place. An object can be protected from unauthorised access and simultaneously subject to storage-layer corruption or tampering.
Failure Modes
Failure Mode 1: Retrieval Treated as Verification. A system retrieves an object and returns it to the caller. No hash verification is performed. No integrity binding is checked. The successful retrieval is logged as confirmation that the object is available and intact. Availability is confirmed. Integrity is not verified.
Failure Mode 2: Data Corruption Undetected. A stored object is corrupted at the storage layer due to media failure or data-level corruption. The object remains addressable and retrievable. The corruption may produce no read error. The retrieved object is silently degraded. Without a hash computed at point of write and verified on retrieval, the corruption may go undetected.
Failure Mode 3: Integrity Binding Absent. An object is written to a store without a cryptographic hash computed at point of write. The object is retained for the required period. On retrieval, there is no reference hash against which to verify the current state of the object. The object's integrity at any point in its retention lifecycle is unverifiable. Retrievability is confirmed. Integrity is unverifiable by design.
Failure Mode 4: Format Migration Breaks Provenance. A long-term retention program migrates objects from an obsolete format to a current format to maintain readability. ISO 14721:2025 identifies changing technologies and new media and data formats as concerns that active preservation must address. The migration alters byte content. No re-attestation is performed. No transformation record is generated. The migrated object is retrievable and readable. Its cryptographic link to the original state is broken. A readable object is not the same as a provable object.
Failure Mode 5: Storage-Layer Tampering Undetected. A stored object is modified at the storage layer by a process with write access to the underlying storage infrastructure. Per NIST SP 800-209, unauthorised data alteration and tampering of storage-related audit data are identified storage infrastructure risks. No hash verification is performed on retrieval. The modified object is returned to the caller as the original. Without an integrity binding computed at point of original write, the modification may go undetected.
Failure Mode 6: Retention Period Satisfied, Integrity Unverifiable. An object is retained for its required retention period and is retrievable at the end of that period. The retention obligation is addressed. On retrieval, the object carries no integrity binding, no external time attestation, and no verifiable provenance. The object addresses the retention schedule. It does not address an evidence obligation. Retention and evidentiary integrity are independent properties.
Failure Mode 7: Preservation Metadata Separated from Object. An object is written to a store. Integrity metadata, provenance records, and preservation description information are stored in a separate system, not cryptographically linked to the object. Over time, the metadata store is migrated, modified, or partially deleted. On retrieval, the object exists but its associated integrity metadata is unavailable or unverifiable. The object is retrievable. Its integrity is unverifiable because the metadata is orphaned.
Operational Tests
The following tests allow a practitioner to validate or falsify the integrity of stored objects in a given system. Pass conditions are internal engineering gates, not regulatory requirements.
Test 1: Retrieval vs. Verification Separation. Select ten objects from a production store. For each, perform two independent checks: first, confirm the object is retrievable; second, recompute the hash using the documented algorithm and compare against the hash stored at point of write. Pass condition: both checks are performed independently and both pass. A system that performs only the first check has retrievability without verified integrity.
Test 2: Data Corruption Detection. Select a sample of objects stored for more than 12 months. Recompute the hash of each and compare against the stored reference hash. Pass condition: all hashes match. Any discrepancy indicates silent corruption or modification. A system with no reference hashes cannot perform this test and has structural evidence debt.
Test 3: Integrity Binding Presence. Select a random sample of objects from the store. Verify that each carries a cryptographic hash computed at point of write, stored alongside the object in a form that is not overwritable or replaceable without an auditable event. Pass condition: 100% of sampled objects carry a verifiable reference hash. Any object without a reference hash is unverifiable by design.
Test 4: Format Migration Re-Attestation. Identify objects that have undergone at least one format migration. Verify that each migration event produced a transformation record with input hash, output hash, transformation type, and timestamp. Pass condition: unbroken re-attestation chain from original format to current format. Objects with no re-attestation chain have broken provenance.
Test 5: Preservation Metadata Co-Location. Select five objects. For each, verify that integrity metadata and provenance records are either co-located with the object or cryptographically linked to it. Pass condition: metadata is verifiable without reference to a separate, unlinked store. Orphaned metadata is a failure.
Test 6: Long-Retention Integrity Spot Check. Select objects at or near the end of their retention period. Verify that each carries a valid integrity binding, external time attestation token, and verifiable provenance chain. Verify that time attestation tokens remain verifiable using authentic copies of historical revocation material (e.g., CRLs) and renewed timestamps per RFC 3161 Section 4 (Security Considerations), item 3, where applicable. Pass condition: all integrity properties are verifiable at the point of retrieval. Objects that address retention schedules but carry no verifiable integrity properties have evidence debt.
Controls
A high-assurance evidence system managing objects over extended retention periods typically implements the following at minimum. These controls are architectural reference points derived from first principles. They are not a compliance guarantee and are not a prescriptive checklist.
Minimum viable set
- Cryptographic hash computed at point of write and stored with the object in a form not overwritable without an auditable event.
- External time attestation token issued at point of write and stored with the object.
- Integrity verification performed on every retrieval, logged independently of the access event.
- Preservation metadata cryptographically linked to the object, not stored separately without a verified link.
These four controls represent a minimal baseline. Everything below extends them.
Write-Time Integrity Controls
- Cryptographic hash computed over the full object payload at point of write. SHA-256 or stronger is a common operational choice in practice.
- Hash stored alongside the object in a form that is not overwritable or replaceable without generating an auditable event.
- External time attestation token issued at point of write, consistent with RFC 3161 timestamp token controls.
- RFC 5816 updates RFC 3161 by allowing ESSCertIDv2 so the TSA certificate identifier can be computed with hash algorithms other than SHA-1. Where a non-SHA-1 algorithm is used, SigningCertificateV2 must be used per RFC 5816. As an operational control choice, SHA-256 or stronger is commonly used for the messageImprint hash in timestamp tokens. RFC 3161 requires a one-way collision-resistant hash function but does not mandate SHA-256 specifically.
- Per RFC 3161 Section 4 (Security Considerations), item 3, tokens SHOULD be time-stamped again at a later date, using authentic copies of old CRLs where available, or notarized if they are not, to renew trust as TSA signing keys age. For objects with retention periods exceeding the TSA certificate lifecycle, a documented re-timestamping schedule is appropriate. Authentic copies of historical revocation material should be retained to support future verification.
Retrieval Verification Controls
- Every object retrieval should trigger a hash verification against the stored reference hash before the object is returned.
- Verification results should be logged independently of the access event.
- Objects that fail verification should not be returned. They should trigger an integrity incident.
- Retrieval logging should distinguish between access events and verification events. These are separate operations.
Storage-Layer Integrity Controls
- Per NIST SP 800-209, storage infrastructure risks include data corruption, unauthorised alteration, tampering of storage-related audit and log data, and compromise of backups and storage OS/binaries, firmware, and images. Storage infrastructure should be monitored for these risk classes.
- Periodic integrity scans should recompute hashes for stored objects and compare against reference values. Scan results should be logged.
- Administrative write access to storage infrastructure should be access-controlled and itself logged at the storage layer, independent of application-layer controls.
Preservation Controls (informed by ISO 14721:2025 OAIS)
- Evidence-class objects in long-term retention should be managed with integrity metadata and preservation description practices, consistent with OAIS preservation responsibilities for long-term verifiability across changing technologies and formats.
- Preservation responsibilities include migration planning across changing technologies, media, and data formats. Migration events should be documented and re-attested.
- Preservation metadata should be co-located with the object or cryptographically linked to it. Separate storage is acceptable only if the link is itself integrity-protected.
- Passive storage is not sufficient for evidence-class objects with long retention requirements. Active preservation with integrity assurance is the applicable model.
Migration and Transformation Controls
- Every format migration or transformation event should produce a transformation record: input hash, output hash, format change description, timestamp token, signing key.
- The original object should be retained alongside the migrated version where feasible.
- Where original retention is not feasible, the transformation record constitutes the integrity bridge and should itself be integrity-protected.
Architecture
Object Written
|
v
Hash(payload) + External TSA Token
|
v
Preservation Metadata (co-located or cryptographically linked)
|
v
Store
|
v
Periodic Integrity Scan
(hash recomputed, compared against reference)
|
v
Migration Event (if any)
|
v
Transformation Record Generated
(input hash, output hash, timestamp, signing key)
|
v
Retrieval Request
|
v
Hash Verification (independent of access event)
TSA Token Verification (historical revocation material / renewed timestamps)
|
v
Object Returned if Verified / Incident if Mismatch
Diagram reflects controls described in this entry. No new claims are introduced.
What This Is Not
This is not a storage system specification. NIST SP 800-209 is cited as context for storage infrastructure risks including data corruption, unauthorised alteration, and tampering. Full storage security scope is broader and is covered separately in SP 800-209.
This is not a digital preservation standard. ISO 14721:2025 is cited as context for the distinction between availability and access functions and active preservation responsibilities. Full OAIS implementation is out of scope for this entry.
This is not a backup or disaster recovery framework. Retrievability is addressed here only as a property distinct from integrity. Backup coverage and recovery objectives are out of scope for this entry.
This is not a post-incident remediation guide. Objects that were written without integrity bindings are generally not recoverable to an original provable state. Re-attestation can reduce future verification cost but cannot reliably recreate original creation conditions.
This is not limited to financial services. The object permanence fallacy applies to any system in which stored objects may be demanded as independently verifiable proof by an external party. The failure modes are architectural, not sector-specific.
This is not a prescriptive compliance checklist. Controls described represent a minimum architectural baseline. They are not a guarantee of legal sufficiency for any specific deployment or jurisdiction.