Category: Digital Preservation

Fixity

Also known as: bit-level integrity

Simply put

Fixity refers to the state of a digital file remaining fixed or unchanged over time. In digital preservation, it is a way of confirming that a file or bitstream has not been altered, corrupted, or tampered with since it was captured or last verified. Establishing fixity gives confidence that a digital object is still the same as it was previously.

Formal definition

In a recordkeeping and digital preservation context, fixity is the property of a digital file, object, or bitstream being fixed or unchanged, and in this sense it is often treated as synonymous with bit-level integrity. It concerns whether the underlying bits of a digital object remain identical to a known prior state, and it typically underpins the integrity component of an authoritative digital record rather than its authenticity, reliability, or usability as a whole. Note that the general English sense of the word ('the quality or state of being fixed or stable') and unrelated technical uses in fields such as structural engineering fall outside this recordkeeping meaning.

Why it matters

Fixity is central to demonstrating the integrity of a digital record over time. In recordkeeping, integrity is one of the properties that distinguishes an authoritative record from mere information, and fixity provides evidence that the underlying bits of a digital object remain identical to a known prior state. Without a means of confirming that a file has not been altered, corrupted, or tampered with since capture, an organization has limited basis for asserting that a digital object is still what it purports to be.

It is important to keep the scope of fixity narrow. Fixity typically underpins the integrity component of a digital record, but it does not on its own establish the record's authenticity, reliability, or overall usability. A file whose bits remain unchanged may still lack sufficient contextual metadata to be trusted as evidence, and confirming fixity does not confirm that the object was authoritative to begin with. Fixity is therefore best understood as one supporting control among several, rather than a comprehensive measure of record trustworthiness.

Professionals should also be careful to separate the recordkeeping meaning from the general English sense of the word, which refers broadly to the quality or state of being fixed or stable, and from unrelated technical uses in other fields such as structural engineering. Within digital preservation, fixity carries the specific meaning of a digital file, object, or bitstream remaining unchanged, and is in that sense often treated as synonymous with bit-level integrity.

Who it's relevant to

Digital preservation specialists

Those responsible for preserving digital files and bitstreams over the long term rely on fixity as a core concept for confirming that objects in their care remain unchanged since capture or last verification. It informs how they monitor collections for corruption or unintended alteration.

Records managers

Records managers concerned with maintaining authoritative digital records use fixity as evidence supporting the integrity component of a record. It helps them demonstrate that a digital object has not been altered, while recognizing that fixity alone does not establish authenticity, reliability, or usability.

Archivists

Archivists managing digital holdings draw on fixity to confirm that accessioned digital objects remain identical to their prior state, supporting confidence in the continued trustworthiness of preserved material over time.

Information governance and compliance professionals

Those accountable for the trustworthiness of digital information may treat fixity as one control among several that contribute to the defensibility of digital records, understanding its narrow scope as a measure of bit-level integrity rather than a comprehensive assurance of record quality.

Inside Fixity

Fixity information

Data used to verify that a digital object has not changed over time, most commonly cryptographic hash values (such as message digests) but potentially also including checksums, file size, and other verifiable properties. Fixity information is typically generated at capture and recalculated periodically for comparison.

Checksums and hash values

Computed values derived from the content of a digital object that serve as a fingerprint of its bit-level state. Recalculating the value and comparing it against a stored reference allows detection of unintended alteration or corruption, though the specific algorithms used depend on organizational policy and tooling.

Fixity checking

The process of recalculating fixity information at intervals and comparing it against previously recorded values to confirm that stored digital objects remain unchanged. This is an ongoing activity across the retention period rather than a one-time action at capture.

Relationship to integrity

Fixity is one means of supporting the integrity property of a record, providing evidence that the object's bitstream has not been altered. It typically underpins, but is not identical to, the broader concept of record integrity, which also concerns completeness and the trustworthiness of content and structure.

Scope of the fixed object

Fixity generally applies to the bit-level state of a specific digital object or file. It does not by itself address the object's authenticity, provenance, or the accuracy of associated metadata, which are managed through complementary recordkeeping controls.

Common questions

Answers to the questions practitioners most commonly ask about Fixity.

Does fixity mean a record can never be changed?

No. Fixity does not make a record immutable or prevent change; it provides a means to detect whether change has occurred. A fixity value, such as a checksum or hash, allows you to verify that a digital object remains identical to a previously recorded state. If the object is altered, corrupted, or tampered with, the fixity check will typically reveal a mismatch. Fixity is therefore an evidentiary and monitoring mechanism rather than a control that physically locks content against modification.

Is fixity the same thing as maintaining a record's integrity?

Not exactly. Fixity is one component that supports integrity, but the two are not identical. Integrity, as one of the properties that make something a trustworthy record, concerns whether a record is complete and unaltered in ways that matter to its evidential value. Fixity provides technical evidence that the bitstream has not changed, which contributes to demonstrating integrity. However, integrity is a broader concept that also depends on context, metadata, and management processes, and fixity alone does not establish authenticity, reliability, or usability.

How is fixity information typically generated and recorded?

Fixity is commonly established by generating a checksum or hash value for a digital object at the point of capture or ingest, then storing that value, often as metadata associated with the object. Depending on organizational policy and the systems in use, this value may be recorded alongside the record, in a separate register, or within a repository's management layer. The specific algorithms and storage approaches vary by system and by the assurance level an organization requires.

How often should fixity checks be performed?

There is no single required frequency; it depends on organizational policy, risk tolerance, the value and sensitivity of the holdings, and the capabilities of the repository or storage environment. Some organizations verify fixity at ingest and again at defined intervals, or when objects are moved, copied, or transferred. Higher-risk or long-term preservation contexts often warrant more regular verification. The appropriate cadence should be documented and justified within a preservation or recordkeeping policy.

What should happen when a fixity check fails?

A failed fixity check typically indicates that the object no longer matches its previously recorded state, which may result from corruption, incomplete transfer, or unauthorized alteration. Organizations generally respond by following a documented procedure, which may include investigating the cause, restoring from a verified copy or backup where available, and recording the event for audit purposes. The response depends on organizational policy and the systems in place, and effective handling usually relies on having trustworthy alternative copies to restore from.

At what points in the records lifecycle is fixity most relevant?

Fixity is often most relevant during capture or ingest, during transfer between systems or to another custodian, and throughout retention and any long-term preservation. Establishing fixity at capture provides a baseline, verifying it during transfer helps confirm that objects arrive intact, and periodic verification during storage supports ongoing assurance. The emphasis placed on fixity at each stage depends on organizational policy and the risks associated with the records concerned.

Common misconceptions

Fixity guarantees a record is authentic.

Fixity typically demonstrates only that a digital object's bits have not changed since fixity information was generated. Authenticity, which concerns whether a record is what it purports to be and was created by whom it claims, depends on additional controls such as provenance, chain of custody, and metadata, and is not established by fixity alone.

Fixity and integrity mean the same thing.

Fixity is a specific, verifiable measure of bit-level stability, often expressed through hash or checksum comparison. Integrity is a broader recordkeeping property concerning whether a record remains complete and unaltered in its content, structure, and context. Fixity supports integrity but does not fully encompass it.

Checking fixity once at capture is sufficient.

Because digital storage can suffer silent corruption and degradation over time, fixity checking is generally understood as a recurring process across the retention period. A single check at capture does not confirm that an object remains unchanged during subsequent storage and migration.

Best practices

Generate fixity information at the point of capture and record it as part of the object's associated metadata so a reliable baseline exists for later comparison.

Perform fixity checks on a recurring schedule appropriate to storage risk and organizational policy, rather than relying on a single check at ingest.

Recalculate and verify fixity before and after any migration, transfer, or format change to confirm the object was not altered during the operation.

Treat fixity as one component within a wider set of controls, combining it with provenance, chain of custody, and access controls to support authenticity and integrity rather than relying on fixity in isolation.

Document and retain the outcomes of fixity checks, including any detected discrepancies and the actions taken, to maintain an evidentiary trail of the object's continued reliability.

Define, in policy, which objects are subject to fixity checking, how often, and how exceptions are escalated and remediated, recognizing that appropriate practice depends on the organization, sector, and jurisdiction.