AI Glossary / Data governance and quality / Intermediate

Data corruption

Definition

Data corruption is an unintended or unauthorized change to data that damages its correctness, structure, or usability. It can occur during writing, storage, reading, transmission, or processing, and may result from faults, software errors, mistakes, or malicious activity. Corruption may make a file unreadable, but it can also leave a readable file containing altered values. It is therefore broader than an obvious “file cannot be opened” error.

What it means

The stored or transmitted information no longer faithfully represents what it was meant to contain. A changed byte in an image may affect its appearance; an altered database value may look ordinary while being wrong. Not every incorrect record is corruption in the narrow technical sense: a person can enter a false fact into an otherwise intact system. Distinguishing storage or processing damage from original data-quality errors helps identify the appropriate investigation and correction.

How it works

Data passes through several layers, including applications, memory, storage, networks, and transformations. A fault at one layer can change content or structure, sometimes without immediate detection. Integrity checks compare current data with a trusted reference or validate structural and semantic rules. Checksums can help detect changes but do not by themselves identify the original correct value or repair damage. Recovery depends on trustworthy copies, logs, reconstruction methods, or other evidence, followed by validation that the recovered result is usable.

Three practical examples

  • File transfer: a downloaded archive fails an integrity comparison with a trusted publisher-provided digest.
  • Database operations: a faulty transformation writes incorrect values while preserving valid column types, so business-level reconciliation is needed.
  • AI artifacts: an altered model file or training-data shard causes loading failures or changes the inputs used in an experiment, making version verification important.

Think of it this way

Think of a document whose characters have been changed or lost while it was copied or stored. Some damage is obvious, while one altered number can look perfectly plausible. The analogy is limited because digital checks can detect tiny changes automatically, yet detection still depends on trusted references and does not explain the intended business meaning.

Worked example

A toy archive contains 1,000 records. A trusted manifest records both its cryptographic digest and a control total of 25,000 units. After transfer, the recipient obtains a different digest, even though the file opens and still contains 1,000 records. The equal row count does not establish byte-for-byte integrity. The team compares the transfer with a verified original rather than accepting it. In another scenario, the digest matches the manifest but the original manifest was created after a faulty conversion. The match then proves consistency with that reference, not that the conversion was correct. These examples distinguish change detection from provenance and semantic validation without prescribing a particular recovery tool.

Illustrative case study

Fictional example: Hazel Research finds that one training-data shard no longer matches its recorded manifest. The team isolates the affected artifact, checks a separately maintained copy, and reviews the processing history before rebuilding the dataset version. It also checks whether downstream experiments used the altered shard. This invented case illustrates scope and traceability; it does not claim that any specific checksum failure reveals whether the cause was accidental or malicious.

Common misconceptions and mistakes

Do not assume that readable data is intact or that unreadable data is necessarily corrupted; incompatible software or missing dependencies can also prevent access. Do not treat a checksum match as proof that the original facts were true. A reference digest must itself be trustworthy, and ordinary checksums are not interchangeable with authenticated integrity mechanisms. Also, replicating a damaged version can spread corruption. A recent backup may already contain the same error, so recovery requires validation rather than blind replacement.

Business use

Corruption can disrupt operations, distort reports, and invalidate AI results. Manage it through layered prevention, detection, and recovery practices appropriate to the data's importance. Keep version and provenance records, monitor integrity signals, and test restoration. Separate known-good recovery material from routine synchronization where the risk warrants it. When an incident occurs, identify affected records, artifacts, time periods, and downstream uses so corrected data reaches the places that relied on it. No single check covers every failure mode.

People also ask

Does corruption always make a file impossible to open?

No. A file can remain readable while values or meaning have changed.

Can a checksum repair corrupted data?

A checksum generally detects a difference; repair needs a valid copy or another recovery mechanism.

Is corruption always caused by an attacker?

No. Faults, bugs, interrupted operations, and human mistakes can also cause it.

Check your understanding

A transferred file has the expected number of rows but a different digest from a trusted original. Is the matching count sufficient to declare the transfer intact?

Answer: No. Row count is only one property. The mismatch requires investigation of the changed content and the trustworthiness of both references.

Related terms

  • Data integrity
  • Backup
  • Data recovery
  • Validation
  • Replication (statistics)
  • checksum
  • cryptographic hash
  • fixity
  • bit rot
  • provenance
  • ransomware
  • replication
  • error detection

Learn next

create a small test artifact with a trusted manifest, then compare unchanged and deliberately modified copies. Observe which checks detect byte changes, missing rows, and invalid values. Document how a known-good copy would be selected and how downstream users would learn that a version was replaced.

More in Data governance and quality

  • Cyber kill chain - The Cyber Kill Chain is a framework associated with Lockheed Martin for analyzing an intrusion as a sequence of stages and identifying opportunities to...
  • Data catalog - A data catalog is an organized collection of metadata that helps people discover, understand and manage data assets.
  • Data Contract - A data contract is an explicit specification of expectations about data supplied to a consumer.
  • Data degradation - Data degradation is deterioration in the integrity or usability of data over time.
  • Data entry - Data entry is the process of recording information in a computer system so it can be stored, processed, and used.
  • Data exfiltration - Data exfiltration is the unauthorized transfer of information out of a system or controlled environment.

Sources

Sources: NIST, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events, https://www.nist.gov/publications/data-integrity-identifying-and-protecting-assets-against-ransomware-and-other ; NIST NCCoE, Data Integrity, https://www.nccoe.nist.gov/publication/1800-11/VolB/ ; National Digital Stewardship Alliance, Checking Your Digital Content, https://www.digitalpreservation.gov/ndsa/working_groups/documents/NDSA-Fixity-Guidance-Report-final100214.pdf ; Canadian Heritage Information Network, Digital Preservation Recommendations, https://www.canada.ca/en/heritage-information-network/services/digital-preservation/recommendations-small-museums.html . Primary guidance excerpts consulted; examples are original and do not claim that one integrity test establishes all forms of correctness.

Previous: Data control language Next: Data Definition Language

  • Home
  • Daily AI Updates
  • Blog
  • AIFBL Academy
  • AI Glossary
  • Products and Tools
  • Store
  • Free CFO AI Prompt Pack
  • About Shihan Sheriff
  • Privacy Policy
  • Terms of Use
  • Refund Policy
  • Cookie Policy
  • Earnings Disclaimer