Data Integrity¶
Core Idea¶
Data integrity is the property that data remains accurate, consistent with its intended meaning and internal rules, and free from unauthorized, erroneous, or accidental modification throughout its lifecycle — creation, storage, transmission, processing, archival, retrieval — enforced by a combination of technical mechanisms (checksums, error- correcting codes, digital signatures, constraints, transactions) and organizational mechanisms (validation rules, audit, change control, provenance tracking). The essential commitment is that data without explicit integrity protection is progressively corrupted by bit rot, transmission errors, software bugs, operator mistakes, and adversarial manipulation; that detecting corruption requires redundancy or cryptographic verification; and that different threats require different mechanisms[1].
How would you explain it like I'm…
Keeping Information Right
Information Stays Correct
Trustworthy, Unaltered Data
Structural Signature¶
- The specified threat model (accidental corruption, concurrent modification, malicious tampering, operator error) [2]
- The detection mechanism (checksums, error-correcting codes, cryptographic signatures, constraints, audit logs) [2]
- The trust anchor (root hash, signed manifest, certificate, auditor identity, notarized record) [3]
- The verification protocol (periodic scrub, quorum read, canonical snapshot, audit trail reconciliation) [4]
- The layered protection approach (network + application + storage + organizational controls) [5]
- The recovery and remediation path (rollback, reconstruction from parity, compensation, investigation) [2]
What It Is Not¶
-
Not equivalent to confidentiality. Integrity and confidentiality are distinct CIA-triad properties (Confidentiality, Integrity, Availability); data can be correct but public, or confidential but corrupted. Different mechanisms protect each: encryption provides confidentiality, checksums provide integrity, access controls provide both.
-
Not the same as consistency in the database sense. ACID's Consistency (C) means "transitions from valid state to valid state per declared constraints" — a specific database meaning. Broader data integrity encompasses constraint-based consistency plus bit-level correctness, tamper-resistance, and provenance.
-
Not identical to accuracy. Accuracy is "the data matches reality"; integrity is "the data matches what was recorded, transmitted, stored." Data can have integrity (unchanged from what was written) but be inaccurate (what was written was wrong). Both matter but are distinct concerns.
-
Not automatic — requires engineered protection. Raw storage exhibits bit rot, network errors permit silent data corruption, and operator errors continuously degrade integrity absent active protection. Modern systems (ZFS, HDFS, BigQuery) checksum and verify routinely; older systems (ext3, legacy SMB) allow silent corruption.
-
Not uniform across mechanisms. CRC-32 is fast but weak for adversarial tampering; SHA-256 is strong but slower; Reed-Solomon codes correct errors but require overhead; digital signatures validate origin but don't prevent replay. Choosing the right mechanism requires threat-model analysis.
-
Not free of the authenticated-origin distinction. Integrity alone ("nothing changed since some state") is weaker than authenticity ("this came from X unchanged"). Authentic-origin typically requires asymmetric keys or pre-shared secrets. Plain SHA-256 provides integrity against accidental error but not proof of authenticity.
Broad Use¶
Data integrity appears in storage systems (filesystem checksums: ZFS, Btrfs; RAID-6 and erasure coding; silent-corruption detection), in databases (ACID transactions, constraints, foreign keys, triggers, CHECK constraints; DB corruption detection in PostgreSQL, Oracle), in networking (TCP checksums, Ethernet CRC, IPsec authentication headers, TLS MACs), in software distribution (signed packages: APT / DEB signing, RPM signing; npm / PyPI package signing, sigstore), in blockchain and distributed ledgers (Merkle trees, cryptographic linking), in version control (Git's content-addressed Merkle DAG), in messaging (HMAC in API requests, Kafka's CRC-32C per record), in healthcare (HL7 FHIR digital signatures, tamper-evident EHR storage), in finance (double-entry bookkeeping, audit trails, SOX controls, SWIFT message integrity), in supply chain (track-and-trace, blockchain-based provenance, RFID-tagged authentication), in scientific research (data integrity plans, raw-data retention, reproducibility), in archival (digital preservation, repeated checksum verification, format migration), in aerospace (triple redundancy, ECC memory, radiation-hardened storage), and in government (certified records, tamper-evident election systems, evidence chain-of-custody).
Clarity¶
Data integrity clarifies that correctness of data requires active engineering, that different threats (accidental, concurrent, malicious) need different mechanisms, that integrity and authenticity are related but distinct (often both needed), that layer-by-layer protection (network + app + storage + audit) is more robust than any single layer, and that organizational mechanisms (audit, provenance, change control) complement technical ones [1].
Manages Complexity¶
The construct manages complexity by decomposing "correctness" into verifiable properties (bit-level, logical, tamper-evident, provenance- traceable), providing mechanisms with well-understood guarantees (CRC catches single-bit errors probabilistically; SHA-256 is collision-resistant under current assumptions; ACID transactions enforce declared constraints), enabling end-to-end reasoning via trust-anchor composition (a signed manifest over checksum-over-encrypted chunks), and supporting audit and compliance through retained, verifiable trails.
Abstract Reasoning¶
Data integrity reasoning proceeds by identifying the data and its lifecycle stages, modeling the threats at each stage (accidental flip, network error, concurrent edit, adversarial tampering, operator error), selecting mechanisms for each (checksum, RAID, signature, constraint, transaction, audit), specifying the trust anchor and verification protocol, and monitoring for integrity violations (checksum failures, constraint violations, anomalous changes)[1].
Knowledge Transfer¶
Role mappings across domains:
- Data ↔ disk blocks / files / packets / database rows / financial transactions / goods / documents
- Threat ↔ bit rot / network error / concurrent edit / operator mistake / adversarial tampering
- Detection mechanism ↔ checksum / parity / hash / signature / constraint / audit log
- Trust anchor ↔ root hash / signed manifest / certificate / auditor identity / notarized record
- Recovery ↔ reconstruction / rollback / compensation / investigation and correction
- Organizational control ↔ audit / provenance / change control / separation of duty
A storage engineer designing ZFS checksumming, a database engineer enforcing ACID constraints, and a supply-chain auditor implementing blockchain-based provenance all apply the same structural reasoning: identify data and lifecycle, model threats, select detection mechanisms, specify trust anchors, and maintain verification trails[4].
Examples¶
Formal/abstract¶
ZFS filesystem (designed by Sun Microsystems, 2001-2005) computes a SHA-256 (or fletcher4) checksum for every data and metadata block at write time and stores the checksum in the parent block's pointer, forming a Merkle tree rooted at the über-block. On read, checksums are verified; mismatches trigger reconstruction from redundant copies (mirror, RAIDZ). A periodic "scrub" operation reads and verifies all blocks proactively, catching silent corruption (bit rot, misdirected writes, bad cables, firmware bugs) before access. ZFS pioneered the "end- to-end integrity" design for storage; subsequent filesystems (Btrfs, APFS) and object stores (Ceph, S3 with checksums) follow similar approaches. This is a canonical formal instance of integrity enforcement via redundancy + cryptographic verification + active verification[4].
Mapped back: This instantiates the structural signature directly — threat model (bit rot, corruption), detection (SHA-256 checksums, Merkle tree), trust anchor (über-block root hash), verification protocol (on-read check, periodic scrub), layered protection (block-level checksums + parent pointers + redundancy), and recovery (reconstruction from parity).
Applied/industry¶
Double-entry bookkeeping (Luca Pacioli 1494) records every financial transaction twice — once as a debit to one account and once as a credit to another — with the invariant that debits always equal credits. Any single-sided error (data entry mistake, fraud, corruption) produces an imbalance visible in trial-balance reporting. Organizational controls (separation of duties, audit, reconciliation) reinforce the technical invariant. The structural match is precise: data (financial transactions), threats (error, fraud, operator mistake), mechanism (dual-entry redundancy + invariant), verification (trial balance, reconciliation, audit), trust anchor (auditor, regulator), and recovery (audit trail enabling investigation and restatement). Pacioli's system has provided data integrity for mercantile finance for 500+ years and remains the foundation of every modern accounting system[6].
Mapped back: This shows the same structural commitments (threat model, detection, trust anchor, verification, layered control, recovery path) translate from technical storage systems to organizational financial systems, demonstrating data integrity's role as a universal abstraction of correctness assurance.
Structural Tensions¶
-
T1: Checksum Strength vs Compute Cost. Strong cryptographic hashes (SHA-256, SHA-3) resist adversarial tampering but are slower than CRC / fletcher / XXH. Many systems use fast weak checks for transport + per-block and slower strong checks at trust-anchor boundaries. Failure mode: systems use CRC-32 alone and are vulnerable to collision-based tampering; or use SHA-256 universally and become CPU-bound; the right layering requires threat-model analysis[7].
-
T2: Silent Corruption Is Often Undetected. Without end-to-end checksumming, bit- level corruption at any stage (storage, network, memory, driver) can propagate silently. Consumer-grade systems rarely detect silent corruption; enterprise storage (ZFS, ECC memory, enterprise NICs) does. Failure mode: data corrupted at rest / in transit is stored and read as valid; decisions are made on wrong data; integrity violation is discovered months or years later, via downstream consistency check or customer complaint.
-
T3: Integrity vs Availability on Failure. On integrity failure, strict policies (fail-closed) reject corrupted data — potentially impacting availability; lenient policies (fail-open) serve data with degraded integrity. Medical, financial, and legal systems typically fail-closed; social media and entertainment often fail-open. Failure mode: the wrong choice is made (serving corrupted medical data; dropping valid entertainment requests); remediation requires clearer per-data-class classification and policy.
-
T4: Organizational Integrity Requires Culture + Process. Technical mechanisms (checksums, signatures, constraints) do not substitute for organizational process (audit, change control, separation of duty, provenance tracking). Insider- threat and authorized-but-wrong changes bypass technical controls. Failure mode: data corrupted by authorized but mistaken / malicious changes; technical integrity unchanged but semantic integrity lost; remediation requires organizational controls (review, segregation, audit, retention).
-
T5: End-to-End Integrity Across Distributed Systems. Enforcing integrity across network hops, services, and storage layers requires choosing mechanisms at each layer and ensuring they compose (TLS checksums + app-level signatures + storage checksums + audit logs). Weak links undermine the chain. Failure mode: integrity protected at one layer but lost at another (verified by app but corrupted in transit; signed at source but corrupted at rest); requires holistic architecture review[8].
-
T6: Integrity as Organizational Memory. Provenance tracking (who changed what when) requires retention of audit logs, which themselves must be protected from alteration. Immutable logs (append-only, signed, replicated) are expensive to operate. Failure mode: audit logs are mutable or deleted; integrity violations cannot be investigated; compliance violations accumulate; redesign around immutable-log infrastructure is required[3].
Structural–Framed Character¶
Data Integrity is a hybrid on the structural–framed spectrum. Part of it is a bare pattern that means the same thing in any field; part of it is a frame — a vocabulary and a set of assumptions — inherited from computer science. The frame here is substantial, though a structural core exists.
The structural element is a clean correctness pattern: a threat model of possible corruptions, a detection mechanism that catches deviations, and a notion of data staying consistent with its intended rules across its lifecycle. That guard-against-corruption structure is recognizable wherever a value must be preserved unchanged. But the prime carries a substantial technical and normative frame: it presupposes the engineering apparatus of checksums, error-correcting codes, cryptographic signatures, constraints, and audit logs, together with organizational controls and an implicit standard that data ought to remain accurate and authorized. That vocabulary and its evaluative weight travel with it into databases, financial-transaction systems, and digital-records archives. Because applying it imports those technical mechanisms and the norm of trustworthiness on top of a real structural core, it lands on the framed side of the middle.
Substrate Independence¶
Data Integrity is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its signature — accuracy and consistency maintained through detection and verification mechanisms — is largely substrate-agnostic, and it shows genuine crossover between filesystem checksums in computation and double-entry bookkeeping in accounting. Still, the prime is most fully worked out in computational and accounting contexts, and reaching other domains takes deliberate translation. Moderate abstraction with a couple of real cross-substrate examples, but no broad spread, places it squarely in the middle of the scale.
- Composite substrate independence — 3 / 5
- Domain breadth — 3 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 3 / 5
Relationships to Other Abstractions¶
Current abstraction Data Integrity Prime
Parents (2) — more general patterns this builds on
-
Data Integrity is a kind of Verification Prime
Data Integrity is a kind of verification: checksums, signatures, and audits confirm conformance to the data's intended specification.Data integrity is preserved by mechanisms — checksums, error-correcting codes, digital signatures, validation rules, audit, provenance — that check stored or transmitted data against the criteria it must satisfy and produce a verdict of accept or repair. That is the defining structure of Verification: a procedure that checks conformance to specification and yields evidence-backed verdicts. Data integrity specializes verification to the case where the specified object is data and the specification covers accuracy, consistency, and authorized state.
-
Data Integrity presupposes Invariance Prime
Data integrity presupposes invariance because preserving accuracy across the data lifecycle is the preservation of intended content under storage, transmission, and processing operations.Data integrity presupposes invariance because the integrity guarantee names a feature -- the data's intended content and internal rules -- that must remain unchanged under the family of transformations data undergoes (writes, reads, transmission, archival, processing). Checksums, signatures, and constraints are the mechanisms that verify invariance under each operation. Without invariance's joint commitment to preserved feature and preserving operations, there is no formal sense in which data is or is not corrupt; integrity is engineered invariance with detection and recovery. Invariance supplies the prerequisite condition: Properties unchanged under transformation. Data Integrity operates against that background: Accuracy and consistency preserved. If the parent condition is removed, the child relation becomes undefined or loses the mechanism asserted by this edge; the parent can obtain independently, so the relation is presupposition rather than subsumption.
Children (2) — more specific cases that build on this
-
Biba Model Domain-specific is a kind of Data Integrity
The proposed strict upward parent is
prime:data_integrity.prime:data_integrity is the nearest broader Prime; the source domain and invariant supply the autonomous residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Biba Model adds domain-specific constraints. The entry does not collapse into that parent because the domain-specific identity determined by the subjects and objects, integrity lattice and dominance relation, read, write and invocation semantics, transition rules, trusted subjects, declassification or endorsement, covert channels, and exact Biba variant are explicit It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Biba Model. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge toprime:data_integrity. No live DAG mutation is authorized. -
Label noise Domain-specific is a kind of Data Integrity
The proposed strict upward parent is
prime:data_integrity.prime:data_integrity is the nearest broader Prime; the source domain and invariant supply the autonomous residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Label noise adds domain-specific constraints. The entry does not collapse into that parent because the domain-specific identity determined by the task and label ontology, latent-truth assumption, annotation process, observed labels, noise taxonomy and transition model, repeated or gold labels, class and subgroup prevalence, train-test contamination, detection method, uncertainty, and correction evaluation are explicit It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Label noise. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge toprime:data_integrity. No live DAG mutation is authorized.
Hierarchy paths (2) — routes to 2 parentless roots
- Data Integrity → Verification → Evaluation → Comparison → Self Checking
- Data Integrity → Invariance
Neighborhood in Abstraction Space¶
Data Integrity sits in a sparse region of abstraction space (81st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Data Integrity & Provenance Infrastructure (7 primes)
Nearest neighbors
- Traceability — 0.71
- Attestation — 0.70
- Trusted Intermediary Compromise — 0.70
- Provenance — 0.68
- Versioning — 0.68
Computed from structural-signature embeddings · 2026-09-10
Not to Be Confused With¶
Data Integrity must be distinguished from Legitimacy, its nearest neighbor (similarity 0.669), because they address fundamentally different kinds of authority. Data Integrity is a technical property—a measurable state of data that has remained unchanged and uncorrupted throughout its lifecycle, enforced by checksums, error-correcting codes, digital signatures, and verification protocols. Legitimacy, by contrast, is a normative-political property—the question of whether authority, decisions, or institutions are justly grounded and broadly accepted by the constituencies they affect. Data can have perfect integrity (verified checksums, unaltered records) but be based on a illegitimate premise or derived from illegitimate authority. A government database recording census information might have complete data integrity—every record checksummed, every transaction audited, no bit corruption—yet the authority collecting and storing that data might be fundamentally illegitimate. Conversely, a regime with legitimate authority might maintain poor data integrity due to negligent storage practices. A bank's financial records might be seen as legitimate by regulators (based on audited practices, transparent governance, market trust) even if those records suffer silent bit-level corruption undetected by weak checksums. Integrity is about preservation of existing state; legitimacy is about the justness of the authority or process that created that state. A system demonstrating integrity without legitimacy is trustworthy at the technical level but not at the moral or political level.
Data Integrity also differs sharply from Provenance, with which it is often conflated. Data Integrity answers the question: "Has this data been modified since its last verified state?" Provenance answers: "Where did this data come from, who handled it, and what transformations occurred?" Integrity is a present property—a snapshot verdict about whether the current data matches a checksum or signed state. Provenance is a historical chain—a documented sequence of origins, transfers, and transformations. Data can have excellent integrity (cryptographically signed, unaltered since creation) but opaque provenance (no record of intermediary steps, no documentation of who accessed or processed it). A scientific dataset might be bit-perfect (every file checksummed, no corruption) but have poor provenance if the processing steps that generated it are undocumented or the raw data sources are lost. Conversely, data with excellent provenance (full audit trail showing every step of processing, every person who touched it, every transformation) might have poor integrity if those records themselves are not protected from tampering. Financial audit trails often maintain detailed provenance (transaction history, approval chain) without the cryptographic integrity protection of modern blockchains. The distinction matters for forensics and compliance: integrity failures tell you "this data was corrupted," while provenance gaps tell you "we don't know how this data was created or handled." A regulatory audit might pass integrity checks (data unchanged) but fail on provenance requirements (insufficient documentation of the data's origin and processing path).
Finally, Data Integrity is not Validation, though both involve conformance checking. Data Integrity ensures that data has not been corrupted or altered—a property about preservation of existing state across storage, transmission, or processing. Validation ensures that data meets specified standards or requirements—a property about conformance to purpose. A database field validated as "non-negative integer" ensures the data meets the semantic requirement; but a corrupted non-negative integer (bit-flipped from 5 to 261 by a cosmic ray) can pass validation while failing integrity. Conversely, data can have perfect integrity (uncorrupted, unchanged from original) but fail validation if the original data was incorrect. A patient blood-pressure reading of "500 mmHg" might be transmitted with perfect integrity (checksummed, unsigned, bit-perfect) but fails clinical validation (medically impossible). Data validation asks: "Does this data conform to our rules about what it should be?" Data integrity asks: "Is this the same data we stored?" The two are orthogonal. A system can validate all data and still allow bit rot to corrupt storage. A system can have perfect bit-level integrity and still store data that is nonsensical (a file of zeros might be perfectly protected but utterly useless). Modern systems combine both: they validate at ingest (ensuring data meets semantic requirements) and enforce integrity across the lifecycle (ensuring stored data remains unchanged). The distinction clarifies why integrity violations and validation failures require different remediation: integrity failure suggests investigation (what corrupted this? where else is damage?) and recovery (reconstruct from parity or backup); validation failure suggests either correcting the source (the original data was wrong) or updating the validation rule (the requirement was misstated).
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (29)
- Capture-Latency Evidence Stratification: Prevent late evidence from becoming falsely immediate by separating raw observation, delayed reconstruction, inference, and backfill into visible, time-marked record layers.▸ Mechanisms (10)
- Confidence Annotation Rubric
- Contemporaneous Event Log — Captures events into the record as they happen, at near-zero latency, so a timestamped primary trace exists before memory or hindsight can reshape it.
- Delayed Interview Protocol — Elicits after-the-fact accounts on a structured protocol that labels their memory-based uncertainty and cross-checks them against independent sources, so reconstruction never impersonates live observation.
- Evidence-Age Release Rule — Gates whether aging evidence may be released for a decision by testing it against an age threshold and attaching the warning the age warrants.
- Evidence-Latency Dashboard — Displays how stale each evidence stream is and where expected records are missing, so users can see latency and gaps before they trust a number.
- Late-Entry and Backfill Protocol — A procedure for adding a late or corrected entry so it is marked as backfill with its author, time, and basis, never fused into the primary record.
- Layered Case Note — A record template with separate fields for what was observed, what is inferred, and what was reconstructed later, so a single note keeps its evidentiary strata visible.
- Provenance and Chain-of-Custody Log — A ledger that records who produced, held, moved, and altered each piece of evidence, so every layer's origin and handling travel with it.
- Read-Only Raw Evidence Archive — An immutable, write-once store that preserves the earliest raw evidence read-only, so correction and synthesis can never overwrite the original trace.
- Reconstruction Workspace or Replay Table — A workspace that replays independent evidence streams onto a shared timeline to reconstruct what happened, keeping the reconstruction visibly separate from the raw inputs.
- Collision-Free Mapping Design: Protect source distinctions by ensuring that no two distinct inputs map to the same target unless an explicit, reviewed merge is intended.▸ Mechanisms (8)
- Booking Lock — A concurrency control preventing two active sources from reserving the same target slot.
- Collision Quarantine Queue — A review workflow for conflicting assignments, suspected collisions, and merge decisions.
- Deterministic ID Allocator — A controlled allocator that assigns target values under uniqueness and lifecycle rules.
- Duplicate Target Scan — A scan that detects target values assigned to multiple distinct sources.
- Hash Collision Check — A check for cases where hashes, digests, short codes, or encodings collapse distinct sources.
- Namespace Reservation Table — A registry of reserved, active, retired, and quarantined target values.
- Preimage Audit Log — A record preserving source-to-target assignment evidence for collision diagnosis.
- Unique Index Constraint — A database or datastore rule preventing duplicate target values inside a scoped collection.
- Conservation Accounting: Track conserved quantities across transformations so losses, leaks, substitutions, duplications, and hidden transfers become visible.▸ Mechanisms (9)
- Chain-of-Custody Record — Holds an artifact's identity intact through every handoff by logging who held it, when, and what they did — an unbroken, tamper-evident chain of possession.
- Data Lineage Map
- Energy Accounting — Tracks energy through every conversion across a defined boundary — input, useful work, storage, and losses — so that energy, conserved in quantity but degraded in quality, is fully accounted rather than assumed.
- Financial Ledger — Records every transaction as balanced debits and credits so monetary value is conserved on the books — each period's opening balance, flows, and closing balance reconcile by construction.
- Inventory Reconciliation — Periodically counts physical stock against the book record and resolves the difference, so shrinkage, miscount, and unrecorded movement surface as a measured, explained adjustment rather than a silent drift.
- Mass Balance — Applies conservation bookkeeping across a declared boundary so a hazard that 'disappears' from one channel must reappear as an outflow somewhere — and the unaccounted gap localises the leak.
- Quota or Credit Ledger — Tracks each credit, allowance, or entitlement from issuance through transfer to retirement so a unit is created once and used once — never double-counted, double-spent, or left phantom.
- Responsibility Accounting Matrix — Maps every duty, risk, and obligation from its old owner to a named new owner across a reorganization, so responsibility relocates rather than evaporating in the gap between roles.
- Variance Report — Summarizes each mismatch between expected and observed quantities, filters it by materiality, and routes it to an owner for explanation, escalation, or correction — turning a reconciliation gap into an accountable action.
- Data Integrity Preservation: Preserve the accuracy, consistency, and traceability of data or records across their lifecycle.▸ Mechanisms (11)
- Access Control Enforcement — Restricts who or what may read, write, approve, delete, or restore protected data, so records change only through authorized paths and never through hidden side doors.
- Audit Log — Keeps an append-only, attributable record of every action on protected data — who, when, and what changed — so integrity events can be investigated and reconstructed after the fact.
- Backup and Restore Verification — Proves that protected data can actually be restored and that the restored records still satisfy their integrity invariants — not merely that a backup file exists.
- Checksum or Hash Validation — Detects unintended alteration, transmission error, or corruption by comparing a freshly computed hash against a trusted reference value.
- Data Lineage Capture — Records how each value moved through sources, transformations, joins, and derivations, so a suspect output can be traced back to the upstream step that produced it.
- Data Validation Schema — Encodes the structure, types, allowed values, and cross-field rules a record must satisfy, rejecting malformed data at the boundary before it is trusted.
- Integrity Anomaly Monitoring — Watches trusted data for impossible values, unexpected drift, duplication spikes, missing records, or staleness, and raises a visible exception when something looks wrong.
- Reconciliation Workflow — Compares two records or states that should agree, classifies each discrepancy, and drives it to a repair, quarantine, or accepted-divergence decision that is recorded.
- Referential Integrity Constraint — Prevents a record from pointing to a nonexistent or invalid related record, so links between data never dangle.
- Source-of-Truth Registry — Documents, per field or claim, which system or role is authoritative — the reference that integrity checks and reconciliation consult to know which value should win.
- Transactional Write Control — Groups related updates so they all commit or none do, keeping partial, duplicate, or inconsistent intermediate states out of trusted records.
- Declared Effect Boundary Enforcement: Prevent hidden shared-state changes by declaring, isolating, monitoring, and enforcing the effects an action is allowed to produce.▸ Mechanisms (10)
- Audit Log and Trace — Records actual effect events in a durable form that can be inspected, explained, and reconciled.
- Command–Query Separation — Separates operations that ask for information from operations that change shared state.
- Compensating Action Protocol — Provides a known repair path when an unauthorized or irreversible effect has already occurred.
- Effect Contract Annotation — Documents allowed reads, writes, emissions, notifications, and external calls in or near the interface definition.
- Effect Review Checklist — Prompts designers or operators to ask what shared state an action can change beyond the declared interface.
- Immutable Data or Copy-on-Write — Prevents accidental mutation by making default state reads non-mutating and requiring explicit creation of changed versions.
- Permission Scope or Capability Token — Grants an action narrowly scoped authority to touch only declared resources.
- Sandbox or Staging Execution — Executes the action in a bounded environment before effects reach production or shared operational state.
- State Diff Test — Runs an action and compares before/after state surfaces to detect undeclared changes.
- Transaction Boundary — Groups allowed changes into an atomic unit with commit, rollback, and consistency rules.
- Deductive Chain Validation: Validate that conclusions actually follow from stated rules and premises before acting on them.▸ Mechanisms (8)
- Diagnostic Logic Check — Checks whether a case actually meets the stated classification criteria and labels the evidential uncertainty that remains, so a criteria-based label is not mistaken for certainty.
- Legal Syllogism Review — Verifies the material facts, hunts for exceptions and defenses, and bounds the holding of a legal argument so the conclusion is no broader than the proven facts and surviving rule support.
- Logic Checklist — Runs a fixed set of prompts over any argument — hidden premises, equivocal terms, invalid steps — so common reasoning faults are caught by routine rather than by luck.
- Policy Eligibility Review — Traces an approval or denial back to the exact governing policy and the verified case facts, so an eligibility conclusion follows from the rule rather than from discretion.
- Proof Checking — Independently re-verifies a decidability or impossibility proof step by step, so the boundary claim rests on a checked argument rather than on its author's authority.
- Requirements Traceability Check — Links a 'complete', 'safe', or 'compliant' claim down to the specific requirements, assumptions, and tests that ground it, flagging every link that rests on an unverified assumption.
- Rule-Engine Validation — Tests whether an automated decision system's outputs actually follow from its encoded rules and supplied facts, including how it resolves priority rules and behaves at edge cases.
- Syllogism Template — Casts a rule-to-case argument into major premise, minor premise, and conclusion so its logical form becomes inspectable before anyone checks whether it is sound.
- Enacted-Control Verification and Closure: Verify controls as enacted, not merely as documented, and close the gap when paper controls and real operating practice diverge.▸ Mechanisms (10)
- Control Performance Walkdown — Walks the specified control in the live system to confirm that the barrier, interlock, approval, or response path actually fires when its hazard shows up.
- Corrective Action Effectiveness Retest — Re-tests a control after its corrective action to confirm the gap was actually fixed in practice, not just closed on paper under a new label.
- Document-to-Practice Trace Matrix — Maps every documented control requirement to concrete execution evidence, exposing which requirements have no proof, a substitution, or a silent deviation.
- Exception, Waiver, and Override Log Review — Reads the waiver, override, and exception logs to find controls that are mandatory on paper but routinely set aside, and asks whether the exception path has become the real process.
- Line-of-Defense Sample Reperformance — Independently re-executes a sample of control actions or approvals to see whether the control operated as claimed, instead of trusting the owner's evidence packet.
- Near-Miss and Deviation Review — Mines near misses, deviations, and weak signals to pick which controls are most likely lying about their health and should be verified next.
- Operator Shadowing and Contextual Inquiry — Sits beside the people who run a control to elicit the tacit steps, constraints, and hidden compensations that never reach the procedure — under protection that makes honest disclosure safe.
- Process-Mining Nominal-Actual Comparison — Reconstructs what actually happened from event logs and checks it against the documented process, surfacing skipped steps, out-of-order paths, and undocumented variants across the whole population.
- Safeguard Bypass Probe — Tests whether a protective safeguard can be — or routinely is — routed around, and why the bypass is locally attractive enough to be worth it.
- Work-as-Done Audit — Reconstructs how a control is actually performed under ordinary and pressured conditions, so the enacted version can be laid beside the documented one.
- Event-Log-Centered Modeling: Preserve happenings as the primary record and derive entity state, relationships, places, periods, timelines, and summaries as reproducible projections of the governed event log.▸ Mechanisms (18)
- Append-Only Event Store — An immutable, ordered store that only ever accepts new events and never edits old ones, serving as the single source of truth from which all state is derived.
- Bitemporal Event Register — Records every fact along two clocks — when it happened and when the system came to know it — with the source of each assertion, so you can ask what was believed as of any past moment.
- Compensating-Event Correction — Corrects a mistaken event not by editing it but by appending a new reversing or adjusting event, so the erroneous record and its correction both remain in the history.
- Deterministic Replay Protocol — Reconstructs a past state or sequence by re-applying the same events in the same order through the same logic, so the rebuild is reproducible down to the last detail.
- Entity-Trajectory Projection — Derives one entity's path through time by gathering every event it took part in — resolving its identity across records and stitching cross-referenced layers into a single ordered trajectory.
- Event Capture Template — A standard shape for recording a happening — its type, what changed, who took part, and where — so a raw occurrence becomes a well-formed, self-describing event rather than a bare timestamped row.
- Event Knowledge Graph — Materializes the event log as a queryable graph, linking events, participants, and entities across layers with typed participation and causal-or-correlation edges.
- Event Replay Deduplication — Lets a consumer process an at-least-once event stream safely by keying on stable event identifiers, so a redelivered or replayed message never applies its effect twice.
- Event-Sourced Projection — Builds a read-optimized view by folding an append-only log of events, so the same history can be replayed to produce many views — or rebuild any of them from scratch.
- Log Compaction — Reclaims space by keeping only the latest or still-necessary record per key and discarding superseded history, under a retention policy that must never break the ability to rebuild state.
- Periodization Projection — Derives named periods from the event log by cutting the timeline at the transformations that mark one regime turning into the next.
- Place-History Projection — Assembles the full history of a place by gathering every event bound to it into one time-ordered account, resolving the many names a single place goes by.
- Process Mining / Trace Analysis — Reconstructs the real process from event traces — discovering the actual control flow, its variants, and where reality deviates from the intended path — that the log reveals but no diagram admits.
- Projection Rebuild and Diff — Rebuilds a projection from the log and diffs it against the live view, treating any disagreement as evidence the view is wrong, never the log.
- Projection-Frontier Dashboard — Shows how far each projection has consumed the log, turning invisible replication lag and coverage gaps into watched, actionable numbers.
- Provenance-Weighted Event Reconciliation — Resolves conflicting, duplicate, and late event claims by weighting each by the trustworthiness of its source, while keeping the disagreement on the record.
- Snapshot Plus Replay — Rebuilds current state fast by starting from a periodic snapshot and replaying only the events since, instead of the whole history.
- Versioned Event-Schema Registry — Versions event type contracts so producers and projections can evolve their schemas without silently breaking each other or the old history.
- Exhaustive Population Mapping: When missing even one unit changes the conclusion or action, replace representativeness with a defensible all-units map.▸ Mechanisms (10)
- Administrative Record Linkage — Joins existing registries and ledgers through a secure crosswalk to reveal units and cut the fieldwork the enumeration would otherwise need.
- Capture-Recapture Check — Estimates how many units were never seen from the overlap between two independent enumeration passes, without treating either as the final list.
- Census Protocol — Runs a designed, declared all-units count over a bounded population and certifies its completeness rather than sampling a representative subset.
- Coverage Gap Heatmap — Renders where enumeration evidence is thin, stale, or suspiciously overlap-free as a scannable map that directs the next sweep.
- Door-to-Door or Field Sweep — Sends people to physically walk every zone and verify units on the ground, catching the ones administrative records never held.
- Duplicate Resolution Queue — Routes look-alike records to deterministic, probabilistic, and human adjudication so each real unit is counted exactly once.
- Enumeration Area Map — Partitions the declared population space into numbered, owner-assigned zones so every area has an accountable search path and no ground is silently skipped.
- Enumeration Quality Backcheck — Re-verifies a sample of already-enumerated units to measure error, fraud, and omission, turning a completeness claim into a tested one.
- Late-Unit Inclusion Window — Defines a transparent, time-boxed path for newly discovered or disputed units to enter the closed enumeration under stated evidence and cutoff rules.
- Master Unit Index — Maintains one deduplicated, versioned, access-controlled record per real unit as the registry the whole enumeration reads and writes against.
- First-Class Absence Modeling: Represent “nothing here” as a valid typed case with defined behavior, rather than as an error, omission, ambiguous null, or unhandled edge case.▸ Mechanisms (10)
- Absence Reason Enum — Attaches a machine-readable code to an empty result naming why it is empty, so consumers can branch on no-match versus denied versus not-yet-loaded.
- Empty Collection Return — Makes 'nothing found' return an empty collection of the right type rather than null, so every caller can iterate without a special case.
- Empty Set Literal — The canonical written value for a collection with no members — a first-class constant that operations and proofs can reference instead of improvising a blank.
- Empty-State Message — Turns a blank screen into a designed empty state that tells the person why nothing is here and what to do next.
- Identity Element Test — Pins the empty boundary with executable tests that assert the empty value behaves as the identity or neutral element under each operation.
- No-Op Command — A command object that satisfies the action interface but performs nothing when executed, filling a required slot without changing state.
- Null Object Pattern — Stands a real, do-nothing object in place of a missing one so callers invoke the same interface and never branch on null.
- Option or Maybe Type — Wraps a value in a type that makes absence an explicit case, forcing the caller to handle 'nothing' before touching the contents.
- Sentinel Value Retirement — Migrates a system off magic sentinel values that overloaded a normal value to mean absence, replacing them with a typed empty case.
- Zero-Row Result with Schema — Returns a query result that has zero rows but keeps its full schema and execution metadata, so 'ran and found nothing' is never confused with 'not run.'
- Idempotent Operation Design: Design operations so repeating them after uncertainty, retry, duplicate submission, or replay does
not create duplicate, compounding, or corrupt effects.▸ Mechanisms (9)
- Cached Result Replay — Returns the original completion result to duplicate attempts so callers receive a stable answer instead of causing new execution.
- Checklist Confirmation — A human-facing procedure that confirms whether an action has already been completed before repeating it in operational, clinical, legal, or administrative settings.
- Deduplication Table or Ledger — A persisted record of seen operation identities, completion status, and results used to detect and resolve duplicates.
- Duplicate-Safe Payment Operation — Combines payment identifiers, authorization boundaries, settlement status, and reversal paths to prevent repeated payment attempts from transferring value twice.
- Event Replay Deduplication — Lets a consumer process an at-least-once event stream safely by keying on stable event identifiers, so a redelivered or replayed message never applies its effect twice.
- Idempotent API — An interface that lets a client safely repeat a request: a duplicate carrying the same key returns the original result instead of executing the action a second time.
- Outbox Deduplication — Separates recording the intended state change from sending downstream messages, then ensures each material outbound effect is sent once per canonical operation.
- Safe Retry Protocol — A client-side procedure that retries a failed or uncertain request only through repeat-safe paths, with bounded attempts and backoff, so recovery doesn't turn into a self-inflicted overload.
- Upsert or Set Operation — Replaces additive action with set-to-state or create-if-absent behavior, making repetition converge on a single record or condition.
- Invariant Guarding: Identify conditions that must always remain true and guard operations so those invariants are preserved.▸ Mechanisms (8)
- Contract Check — Attaches preconditions, postconditions, and state assumptions to a boundary and evaluates them at runtime, so a transition is refused the moment it would break the contract.
- Database Constraint — Encodes a record invariant — uniqueness, referential integrity, a balance rule — directly in the data schema so the store itself rejects any write that would break it.
- Integrity Monitor — Watches live state for violations, near misses, and bypasses and records them, surfacing invariant breaks that slipped past the guards so they can be governed.
- Invariant Test Suite — Expresses declared properties as executable assertions and exercises common, rare, and regression cases offline, so a change that would break the invariant fails before it ships.
- Policy Guardrail — Routes, refuses, or demands evidence for decisions that might violate a rule, right, or separation-of-duties requirement, with scoped exceptions and a named owner.
- Rollback Transaction — When a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed.
- Safety Interlock — Makes a hazardous action physically impossible unless every enabling safety condition is true, holding the system in a safe default state until they are.
- Two-Person Rule — Requires two authorized people to independently confirm a high-risk transition before it proceeds, so no single actor can break the invariant alone.
- Layered Record Accumulation: Preserve successive layers of change as a readable record so the system’s history, provenance, and path of formation remain interpretable.▸ Mechanisms (10)
- Archival Layer — Stores older layers outside the active workspace while preserving context, retrieval paths, and interpretation rules.
- Audit Log — Keeps an append-only, attributable record of every action on protected data — who, when, and what changed — so integrity events can be investigated and reconstructed after the fact.
- Case History — Accumulates observations, interventions, decisions, and outcomes for a person, client, patient, asset, project, or legal matter.
- Chain-of-Custody Record — Holds an artifact's identity intact through every handoff by logging who held it, when, and what they did — an unbroken, tamper-evident chain of possession.
- Change Ledger — Creates a structured ledger of changes, rationales, approvals, and consequences across time.
- Commit History — Implements layered record accumulation for software and document systems by preserving revisions, authorship, timestamps, and messages.
- Incident Timeline — Orders observations, actions, decisions, and discoveries during an incident so later review can reconstruct what unfolded.
- Learning Portfolio — Preserves successive attempts, feedback, revisions, reflections, and evidence of development over time.
- Stratigraphic Record — Uses physical or conceptual strata to infer the sequence and conditions by which a cumulative structure formed.
- Version History — Preserves successive revisions of an artifact, document, model, product, policy, or codebase.
- Leakage-Resistant Validation Design: Before trusting a fitted model, score, policy, or benchmark result, enforce the boundary between what would have been knowable at decision time and what was learned only through the target, future, holdout, or deployment outcome.▸ Mechanisms (12)
- As-Of Join Rule — Joins each record only to the feature values that were already knowable as of that record's decision timestamp, so no later information leaks into a training row.
- Benchmark Deduplication Scan — Searches the training and development corpus for copies or restatements of the evaluation benchmark, so a memorised answer can't masquerade as a solved problem.
- Duplicate and Near-Duplicate Scan — Hunts for the same or nearly-identical cases sitting on both sides of a split — the overlap that quietly turns memorisation into apparent generalisation.
- Entity-Grouped Split — Partitions train and test by the underlying entity — patient, speaker, site, household, lineage — so no single entity has rows on both sides of the boundary.
- Feature Availability Audit — Walks every candidate input and asks whether its value would truly have been known at decision time, cataloguing the fields that would not.
- Fresh Holdout Retest — Re-scores the frozen model on newly collected or freshly sealed cases the moment its old holdout is suspected of contamination, measuring how much of the reported skill survives.
- Holdout Access Log — Records every query, submission, and human view of protected evaluation material, so exposure is metered and a spent or peeked-at holdout stops being trusted as fresh evidence.
- Label Proxy Screen — Scans every candidate feature for the tell-tale signature of a target proxy — a column that is suspiciously predictive because it is really a downstream trace of the outcome — and files the suspects for confirmation.
- Leakage Ablation Test — Removes a suspected leak pathway, refits, and reads the drop in performance — a collapse convicts the pathway and its size is the leak's severity, while the leak-free score is the honest number to expect in deployment.
- Nested Cross-Validation — Wraps model selection in an inner cross-validation loop nested inside an outer one, so hyperparameters and model choices are never tuned on the same data used to report performance.
- Preprocessing Fit-on-Training-Only — Requires every fitted transform — scalers, imputers, encoders, vectorizers, feature selectors, resamplers — to learn its parameters from the training partition alone, then apply unchanged to validation and test.
- Time-Based Holdout — Splits data by time rather than at random — training on everything before a cutoff and evaluating only on what came after — so a model meant to predict the future is graded on a genuine future it never saw.
- Mapping-Fidelity Distortion Control: Treat distortion as a governed property of an input-output mapping: define the reference, profile the deviation, bound what is tolerable, correct what is correctable, and label what remains.▸ Mechanisms (9)
- Blind Reconstruction Comparison — A protocol that compares reconstructed or transformed outputs against held-out reference cases without tuning to the answer.
- Calibration Reference Set — A set of known inputs, standards, gold samples, or benchmark cases used to estimate mapping deviation.
- Distortion Heatmap or Profile Report — A visualization or report showing where and how distortion varies by region, frequency, class, or operating condition.
- Distortion-Budget Gate — A release or use gate that blocks outputs whose distortion profile exceeds tolerated deviation.
- Golden-Sample Regression Suite — A recurring test using stable known cases to detect whether mapping fidelity has drifted.
- Inverse Correction Mapping — A compensation method that applies an estimated inverse or offset to reduce systematic deviation.
- Raw-Corrected Overlay Review — An interface that overlays raw and corrected outputs so reviewers can inspect what the correction changed.
- Residual Error Analysis — A comparison of expected and observed outputs after fitting, correction, or transformation.
- Transfer-Function Estimation — A method for estimating how inputs are transformed into outputs over an operating range.
- Noise-Bounded Measurement Interpretation: Treat every measurement as a noisy observation with a bounded claim, not as a direct copy of reality.▸ Mechanisms (10)
- Calibration-Curve Residual Report — Fits an instrument's response against known reference standards and reads the leftover residuals to expose systematic bias and tie every later reading back to a traceable curve.
- Duplicate or Blind Remeasurement Check — Re-measures the same item a second time with the first result hidden, so the scatter you observe is honest field variation rather than an observer agreeing with their own earlier answer.
- Error Bar, Confidence Band, or Quality Flag — Attaches the uncertainty to the number where it is read — a whisker, a shaded band, or a high/medium/low grade — so the display itself refuses to imply more precision than the measurement supports.
- Gauge Repeatability and Reproducibility Study — Separates the variation that comes from the parts from the variation that comes from measuring them, so that a stack analysis is not silently built on the noise of its own gauges.
- Measurement Claim-Limitation Note — A short written caveat, bound to the measurand and its intended use, that states in plain words which conclusions a measurement can and cannot support.
- Measurement Uncertainty Budget Table — Lists every contributor to a measurement's uncertainty on its own row, sized in common units, and combines them into a single defensible total — showing not just how big the uncertainty is but where it comes from.
- Noise-Floor Estimation Protocol — Measures the background an instrument produces with no real signal present, establishing the smallest change that can be told apart from the apparatus's own hiss.
- Sensor Health and Drift Monitor — Watches a live instrument over time for slow departure from its calibration and rising degradation, tripping a recalibration or escalation before drift quietly corrupts the data stream.
- Signal-to-Noise Action Gate — Refuses to let a measured change trigger an action unless the change is larger than the measurement noise, routing borderline cases to corroboration instead of firing on jitter.
- Uncertainty Propagation Calculation — Carries the uncertainty of raw inputs through the formula that combines them, so a derived quantity inherits an honest error bar instead of acquiring fake precision on the way out.
- Reconciliation After Drift: Restore consistency when records, states, versions, accounts, or representations of the same underlying reality have drifted apart.▸ Mechanisms (10)
- Audit Log Review — Replays an append-only event history to reconstruct how two records drifted apart, classifying the cause so the correct prior state can be restored and the leak sealed.
- Custody Chain Reconciliation — Reconstructs an unbroken sequence of who held an item when, confirming each handoff refers to the same sealed object and assigning any gap to an accountable owner.
- Data Diff and Merge Tool — Compares two divergent copies against their common ancestor, auto-merges the changes that don't overlap, and surfaces the ones that do as explicit, reviewable conflicts.
- Exception Queue Review — Routes the conflicts no automatic rule could resolve into a monitored queue where a named owner adjudicates each one to closure.
- Inventory Count Reconciliation — Resets a system's stock record to a fresh physical count, freezing movement while it counts and treating the shelf, not the database, as ground truth.
- Ledger Reconciliation Workflow — Matches an internal ledger against an external statement transaction by transaction, explaining every gap as a reconciling item until the two balances tie out.
- Reconciliation Report — Documents decisions, unresolved conflicts, exceptions, tests, adoption guidance, and change impacts for a reconciled mapping.
- Replica Repair Job — Runs on a schedule to find replicas that have fallen behind or diverged and reconciles them back toward the others, bounding how stale any copy is allowed to get.
- Source-of-Truth Table — A declarative table that names, in advance, which system or role is authoritative for each field, state, or jurisdiction, so any later conflict has a predetermined winner.
- Three-Way Merge — Uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions.
- Reference-Baseline Deviation Flagging: Make departure meaningful by declaring the reference, calculating the observed-minus-expected difference, and recording the deviation as a fact with scope, direction, magnitude, and context.▸ Mechanisms (10)
- Baseline Delta Table — Displays observed, baseline, difference, direction, and percent change for each unit or period in a scannable table.
- Baseline Version Register — Records baseline definitions, thresholds, reference windows, model versions, and change rationales so past deviations stay reconstructable.
- Control Chart or Run Chart — Plots observations against a centerline, control limits, reference bands, or expected ranges over time to reveal departures as shifts and trends.
- Deviation Event Log — Stores each flagged departure as a durable fact stamped with baseline version, unit, context, status, and review history.
- Deviation Review Queue — Routes flagged departures to human or automated review, annotation, escalation, or follow-up, with a fairness check on who gets scrutinized.
- Exception Flag Rules Engine — Applies configurable threshold, tolerance, materiality, and suppression rules to a stream to produce deviation flags automatically.
- Null-Model Residual Report — Shows departures from a declared null or expected model as residuals, documenting the model but refusing to read the residual as a causal effect.
- Reference Range Flag — Labels a single observation as below, inside, or above a context-appropriate expected or acceptable range.
- Rolling Baseline Comparison — Compares each current observation against a moving historical reference window, preserving the window definition so past comparisons stay reconstructable.
- Standardized Residual Score — Transforms an observed-minus-expected difference into a scale-adjusted, z-like residual so departures are comparable across units of different variability.
- Reference-State Conservation Intervention: Stabilize a valued object, record, state, or practice by defining the reference state worth preserving, diagnosing decay, intervening within a bounded treatment scope, and documenting future care.▸ Mechanisms (10)
- Before/After Condition Photography — Creates a dated, registered set of before, during, and after images so condition change is visible at a glance and every treatment stays traceable to what was originally there.
- Condition Assessment Survey — Systematically scores the condition of a whole population to diagnose how it is decaying and rank which objects get scarce treatment first.
- Conservation Logbook — Keeps an append-only ledger of everything done to an object — materials, methods, and approved departures from standard practice — so its post-treatment history stays fully traceable.
- Conservation Treatment Plan — Fixes the intervention boundary and selects the least-disturbing treatment sufficient to arrest or reverse decay, before any hand touches the object.
- Digital Fixity Check and Repair — Verifies each stored digital object against a saved cryptographic baseline and repairs any corruption from a known-good copy.
- Environmental Control Protocol — Manages the surrounding climate, light, pollutants, and access so a whole collection decays more slowly — without touching any individual object.
- Minimal Intervention Review Board — A custodian panel that decides whether an intervention is legitimate and how far it may go, before scope creep turns conservation into redesign.
- Monitoring and Retreatment Cadence — Sets the recurring re-inspection rhythm, retreatment triggers, and named owner that keep a conserved object from silently decaying again.
- Restoration Protocol — Actively returns an object toward a documented reference state, recovering lost form or function without inventing history that was never there.
- Stabilization Intervention — Arrests active decay at the object's current state — buying time and preserving what remains — without attempting to return it to any earlier reference.
- Reproducibility Protocol: Make methods, data, assumptions, and environments explicit enough that results can be repeated or checked.▸ Mechanisms (10)
- Audit Trail
- Containerized Environment Snapshot — Captures software, dependency, and runtime context so computational behavior can be rerun under a known environment.
- Decision Log — Captures each significant decision as a linked record — its rationale, the alternatives weighed, who approved it, and the artifacts it affects — so a choice can later be traced back to why it was made and forward to what it touched.
- Lab Notebook Record — Records experimental conditions, materials, observations, deviations, and interpretive notes so later teams can reconstruct the work.
- Protocol Documentation — Describes the ordered method, required inputs, assumptions, roles, and output checks that allow a process or analysis to be repeated.
- Replication Package — Packages enough material for an outside person or team to repeat, verify, or challenge the original result.
- Reproducible Research Package — Bundles data, code, methods, documentation, and expected outputs so a scientific or analytic result can be rerun or inspected.
- Rerun Checklist — Provides a lightweight confirmation list for rerunning the result path and comparing outputs against the reference.
- Version-Controlled Analysis — Uses a version-control system to preserve changes to code, data-processing scripts, notebooks, parameters, and documentation.
- Workflow Script or Pipeline — Automates the steps that transform inputs into outputs, reducing hidden manual variation and making reruns observable.
- Source Provenance Triangulation: Evaluate an account by tracing source type, origin, proximity, perspective, corroboration, and confidence before treating its claims as settled.▸ Mechanisms (9)
- Audit Trail Review — Inspects logs, version histories, document histories, custody records, or system traces to identify edits, gaps, and handling anomalies.
- Chain-of-Custody Record — Holds an artifact's identity intact through every handoff by logging who held it, when, and what they did — an unbroken, tamper-evident chain of possession.
- Citation Lineage Review — Traces a claim through references and derivative accounts to determine whether sources are independent or reproducing the same origin.
- Confidence Annotation Rubric
- Conflicting Source Table — Keeps contradictory sources visible by listing the claim, source positions, possible explanations, and unresolved questions.
- Evidence Provenance Log
- Source Criticism Protocol — Uses structured questions about authorship, purpose, audience, context, proximity, and transmission to evaluate a source before accepting its claims.
- Triangulation Matrix — Places claims against multiple sources so agreement, disagreement, independence, and source-type diversity can be seen at once.
- Witness / Source Comparison — Compares firsthand accounts or records by role, access, incentive, timing, memory risk, and corroboration against non-testimonial evidence.
- Source-of-Truth Assignment: Assign authoritative status to one representation or system so conflicting versions can be resolved consistently.▸ Mechanisms (12)
- Access and Update Rights Matrix — A grid mapping actors and systems against fields and states to who may view, edit, approve, override, and publish, converting 'this is authoritative' into an enforceable set of who is allowed to change it.
- Authoritative Policy Repository — Holds the current policy statements in one governed location so that outdated copies, summaries, and local interpretations must be resolved against it.
- Canonical Registry — Maintains the one official list of entities and their canonical identifiers that every system looks up, with a mapping from aliases and legacy codes back to the canonical entry.
- Change Log and Audit Trail — Preserves an append-only record of every change to authoritative state — who, when, why, under what right, and what it propagated to — so the source's history is accountable and reconstructable.
- Conflict Resolution Workflow — Routes a detected disagreement between representations through review, reconciliation, escalation, or authoritative override, applying a standing precedence rule so the same conflict resolves the same way every time.
- Deprecation and Forwarding Notice — Marks an obsolete representation as no longer authoritative and attaches a forwarding pointer to the current source, so anyone still holding the old copy is redirected rather than misled.
- Golden Record Consolidation — Merges many duplicate and conflicting records of the same entity into one consolidated 'golden' record, picking the surviving value field by field with survivorship rules.
- Master Data Management — A standing enterprise program that assigns data stewards, carves which system is authoritative for each data domain across business units, and sets the synchronization and duplicate-resolution policy the point mechanisms execute.
- Official Record Policy — Declares which document, filing, or register is the official record for legal, compliance, and historical purposes, ranking it above informational copies and defining the exceptions under which another may temporarily stand in.
- Source-Control Main Branch — Treats one branch — main or trunk, reached through a reviewed merge — as the authoritative state of code, config, or content, so every working copy is provisional until it lands there and merge rights gate what may.
- Synchronization Job — Propagates authoritative values from the source into every dependent system on a schedule or on change, and records the lag, transformations, and failures so downstream copies are known to be aligned — or known to be behind.
- System-of-Record Designation — Names one system as the governing record for a defined subject and scope, so its value wins whenever copies elsewhere disagree.
- Summary-Substance Alignment Audit: Audit the short surface against the long substance so compression stays faithful rather than becoming a second, more persuasive truth.▸ Mechanisms (15)
- Abstract–Full-Text Alignment Review — Walks an abstract claim by claim back into the full text, demanding a specific supporting passage for each — and flags the findings the abstract quietly leaves out.
- Body-Change Summary Invalidation — Treats any material edit to the substance as automatically making the summary stale — invalid until it is re-derived and re-approved.
- Certainty & Causality Inflation Check — Catches the summary that upgrades the substance's certainty or causality — a hedge hardened into a fact, an association reported as a cause, a subgroup generalized to everyone.
- Correction Synchronization Workflow — Once a correction is decided, drives it through every human-owned surface that repeated the error and confirms each was fixed, so no stale copy is left behind.
- Dual-Surface Sign-Off — Refuses to approve the summary and the substance separately: the two are signed off together, by accountable owners, or neither ships.
- Executive-Summary Caveat Budget — Reserves a fixed share of an executive summary for the caveats that would change the decision, and spends that budget before the confident headlines.
- Headline–Body Consistency Check — Isolates the single claim a headline asserts and tests whether the body actually supports it — at that scope, tense, and force — before it goes out.
- Material-Divergence Red Team — Puts an adversarial team on the summary alone to manufacture the most damaging defensible misreading — and log it before a hostile outsider finds it.
- Press-Release Claim Review — Reads a promotional summary — a press release or announcement — against the study or report it publicizes, grading each headline claim as supported, overstated, or unsupported with the author's incentive to amplify held in view.
- Qualifier-Drop Scan — Inventories the hedges, scope limits, and conditions in the substance that fix when a claim is true, then flags the material ones the summary silently dropped.
- Quote-Snippet Context Window — Bundles an excerpted quote with the minimum surrounding context and a trace to its source, so the fragment cannot be flipped by removing the words that stood next to it.
- Social-Preview Cache Invalidation — Keeps every cached preview — social card, search snippet, chat unfurl — coupled to the live body, so a correction to the substance forces the stale surface to refresh instead of outliving it.
- Summary-Claim Traceability Matrix — Decomposes the summary into atomic claims and gives each one a trace-link to the exact place in the body that supports it — or marks it unsupported.
- Summary-Diff Review — Reviews the change between two versions of a summary, so an edit that quietly flips a modal verb or drops a not is caught at the diff rather than after it ships.
- Summary-Only Reader Test — Puts the summary in front of readers who never see the body and measures what they conclude, catching the gap between what the summary says and what a summary-only audience takes away.
- Traceability Linking: Create explicit links from sources, requirements, decisions, actions, or artifacts to their downstream consequences or implementations.▸ Mechanisms (10)
- Audit Trail Record — Records who created, changed, approved, accessed, or retired each record and link, and when, in an append-only tamper-evident history — so the traceability system itself can be reviewed and trusted.
- Chain-of-Custody Record — Holds an artifact's identity intact through every handoff by logging who held it, when, and what they did — an unbroken, tamper-evident chain of possession.
- Change Impact Report — A shareable summary that states a proposed change and lists the downstream artifacts, obligations, tests, and owners it touches, so reviewers can see the blast radius before approving.
- Citation Chain — Links each claim to the specific sources that support it with a typed support relation, so a reader can walk from an assertion back to the evidence it actually rests on.
- Data Lineage Record — Follows a data value back through every source, join, and transformation that produced it and forward to everything that now depends on it, pinning each step to the pipeline version and the steward who owns it.
- Decision Log — Captures each significant decision as a linked record — its rationale, the alternatives weighed, who approved it, and the artifacts it affects — so a choice can later be traced back to why it was made and forward to what it touched.
- Requirements Traceability Matrix — Threads every requirement through to the design, code, and verification that satisfy it, so any requirement with no downstream link — or no passing test — is a visible coverage hole.
- Source Control Linkage — Captures trace links as a byproduct of version control — pinning each commit, pull request, and release to the issue, requirement, or review that justified it.
- Test Coverage Link — Links each requirement, behavior, or risk to the test that verifies it, turning an untested promise into a gap the links make visible.
- Traceability Dashboard — Watches the health of an existing link set — surfacing unowned items, unresolved exceptions, and links that have gone stale or broken since the work was done.
- Transactional Atomicity: Bundle related operations so they either complete together or are undone together, preserving consistency.▸ Mechanisms (9)
- All-or-Nothing Checklist — A checklist that refuses completion until every required transaction condition is verified.
- Atomic Deployment Step — A release procedure that activates a coherent bundle or restores the previous valid state.
- Batch Settlement — Groups many obligations into one clearing cycle that completes at a fixed cutoff, so a single failed item is quarantined without unwinding the rest.
- Contract Execution Bundle — Packages every required signature, exhibit, payment, and filing into one instrument that becomes operative only when the whole bundle is present.
- Coordinated Approval Workflow — A workflow that releases execution only after a required approval set is complete.
- Database Transaction — A software mechanism that groups database operations under commit and rollback semantics.
- Escrow Closing — A custody-and-release mechanism that completes an exchange only when stated conditions are satisfied.
- Reservation-Commit Protocol — Takes the resource out of contention the moment it is checked — an expiring hold that the commit later consumes — so the precondition cannot drift between check and use.
- Two-Phase Commit Protocol
- Transitive Trust Boundary Hardening: Do not let a trusted relationship admit a payload automatically; re-scope and verify the artifact, channel, transformation, and authority at the point of use.▸ Mechanisms (16)
- Artifact Signature Verification — Checks a cryptographic signature over an artifact's exact bytes against a pre-decided trust anchor at the point of use, so it is accepted because it verifies — not because of the channel it arrived through.
- Canary Rollout with Kill Switch — Admits a trusted-but-unproven update to a small slice first and watches it, so a bad payload that passed every check still cannot reach the whole fleet before it is caught and cut off.
- Content Disarm and Reconstruction — Rebuilds an incoming file into a known-clean equivalent instead of trying to detect what is wrong with it, so a hidden payload is dropped in reconstruction whether or not it was ever recognized.
- Dependency Lockfile and Allowlist — Pins every dependency to an exact, pre-approved version and digest and refuses anything else, so a build can only pull what was reviewed — not whatever the registry serves today.
- Key Rotation and Revocation Drill — Rehearses revoking a trusted signing key and cutting over to a new one, so when a signer is compromised the trust anchor can actually be replaced fast — not just in theory.
- Multi-Source Release Corroboration — Accepts a release only when independent observers agree on the same artifact digest, so no single compromised source, signer, or channel can define what 'the release' is.
- Package Namespace Confusion Guard — Binds each dependency name to its legitimate publisher and source registry, so a same-named or look-alike package from the wrong place can never be resolved in.
- Provenance Attestation Check — Verifies the signed record of how and where an artifact was built against an expected-provenance policy, so a genuine signature on a maliciously-built artifact still fails.
- Quarantine Release Workflow — Holds every incoming artifact in an untrusted staging zone and promotes it to trusted use only after the required checks pass — recording an exception whenever it is released without them.
- Reproducible Build or Derivation Check — Rebuilds the artifact independently from its published source and confirms a bit-for-bit match, so trust can rest on the source anyone can read rather than on the builder who shipped the binary.
- Sandboxed Payload Execution — Runs the payload inside an isolated, instrumented cage and judges it by what it actually does, so its behaviour is observed before it is ever granted real trust or reach.
- Software Bill of Materials Review — Enumerates every component and supplier packed inside an artifact and reviews that inventory, so trust attaches to a known list of parts and origins rather than to an opaque whole.
- Transparency Log Monitoring — Continuously watches an append-only public log for entries no one authorized, turning an upstream compromise into something you detect rather than something you assume cannot happen.
- Trust Chain Red Team — Maps the chain of trusted upstreams and actively attacks its weakest link, proving where a compromised or spoofed producer would deliver a hostile payload straight past the consumer's controls.
- Trusted Intermediary Compromise Tabletop — Walks a team through the assumed compromise of a trusted intermediary to rehearse the response — who is notified, what may be bypassed — before a real one forces those decisions under pressure.
- Trusted Update Channel Pin — Binds update trust to one specific channel and signing key set in advance, so anything signed by anyone else is refused even when it arrives looking like a legitimate update.
- Use-Time Precondition Binding: Act on a precondition only when the condition is still bound to the state at the moment of use, not merely when it was true during an earlier check.▸ Mechanisms (12)
- Abort-and-Retry After State Mismatch — When a use-time check finds the state has changed since it was first read, it abandons the stale attempt cleanly and re-runs the operation on fresh state — instead of forcing the old decision through.
- Compare-and-Swap Version Token — Reads a value together with a version marker and writes back only if the version is still unchanged — so a write computed from stale state is refused instead of silently overwriting a newer one.
- Confirmation Dialog with State Refresh — Re-fetches the live state the instant a person clicks confirm and shows it — with what changed highlighted — so the human commits against current reality, not the stale screen they were looking at.
- Final Revalidation Before Commit — Re-runs the original precondition check as the very last step before the irreversible commit, so the action fires only if the condition that justified it still holds at the instant of use.
- Lease-Bound Capability Token — Grants permission as a self-expiring token whose short validity window bounds the check–use gap, so a stale grant simply stops working instead of needing to be revoked.
- Lock or Hold Until Use — Takes an exclusive hold on the resource at check time and keeps it through the use, so the checked condition cannot change inside the gap.
- Reservation-Commit Protocol — Takes the resource out of contention the moment it is checked — an expiring hold that the commit later consumes — so the precondition cannot drift between check and use.
- Revocation Status Check at Use — At the point of use, queries a live revocation source to confirm a previously-granted authority has not since been withdrawn before acting on it.
- Snapshot-Pinned Decision — Computes and records a decision against one frozen, versioned snapshot of the state, binding the action to the exact evidence it was based on.
- Stale Data Revalidation Gate — Refuses to act on state older than its validity window, forcing a refresh before a decision is allowed to ride on data that may already be wrong.
- Timestamp and Freshness Badge — Stamps every datum with its capture time and shows its age at a glance, so whoever acts on the state can see whether it is fresh enough to trust before they rely on it.
- Two-Phase Commit with Freshness Check — Coordinates a multi-party action as prepare-then-commit and re-verifies every precondition is still fresh at the commit boundary before any change is allowed to land.
- Use-Time Referent Validation: Verify that the thing an action depends on still exists and is valid at the moment of use, then bind, use, or fail safely.▸ Mechanisms (10)
- Atomic Check-and-Use Operation — Fuses the validity check and the dependent action into one indivisible operation, so no other actor can change the referent in between — there is no window to lose a race in.
- Capability or Authorization Revalidation — Re-evaluates at the moment of use whether the authority presented still permits this actor to perform this action on this referent, rather than trusting a grant decided earlier.
- Compare-and-Swap or Version Guard — Carries the version, state, or token seen when the referent was read, and permits the action only if the referent still bears that exact marker at commit — otherwise it rejects rather than clobbers.
- Just-in-Time Existence Check — Re-resolves the referent through the same path the action will use, at the last possible instant before use, refusing to trust any earlier lookup.
- Lease, Lock, or Reservation Token — Binds a referent to one actor for a bounded window with an expiry, so within the window the holder may act without re-checking, and on expiry, release, or commit the binding dissolves for others to claim.
- Preflight Resource Probe — Sweeps every referent a high-stakes operation depends on in one go/no-go check just before the point of no return, so a single missing dependency blocks the whole action rather than surfacing mid-flight.
- Revocation or Tombstone Check — Looks a referent up against an authoritative record of things that are still named but deliberately killed — revoked, deleted, merged, or superseded — so a well-formed name is never mistaken for a still-valid one.
- Safe Missing-Referent Fallback — Pre-defines the recovery ladder — retry, refresh, degrade, escalate, abort — so that when a referent can't be confirmed valid, the action lands in a defined safe state instead of proceeding blindly or crashing.
- Stale Reference Monitor — Watches use-time outcomes over time to find which references keep going stale — measuring observed age against a freshness window and logging the recurring offenders so the rot gets fixed at its source rather than one failure at a time.
- Transactional Precondition Guard — Runs the precondition check and the use inside one atomic boundary so nothing can change the referent in between — and if the precondition fails, the entire unit rolls back to a consistent state rather than half-completing.
- Versioned Evolution: Track changes as explicit versions so evolution remains comparable, reversible, auditable, and compatible.▸ Mechanisms (10)
- Dataset Version Registry — Pins each state of a dataset — its records, schema, transformations, and provenance — to a stable, immutable snapshot, so a dataset name always resolves to one reproducible state that analyses can re-run or compare.
- Document Revision History — Preserves a document's identity across drafts and editions by recording every revision, redline, and approval in order, so any past state is recoverable and every change is attributable.
- Legal Amendment Record — Keeps a legal instrument the same instrument through amendment by recording superseded language, effective dates, and which parties are bound by which version.
- Model Registry — The system of record for every regulating model — its lineage, assumptions, owner, approvals, and deployment status — so any model in production can be traced, re-approved, or rolled back.
- Policy Amendment Register — Maintains one authoritative register of each policy's current version, amendments, owners, and effective dates, and periodically reviews the accumulated changes for drift.
- Protocol Version Negotiation — Lets two independently-versioned parties discover their overlapping supported versions and agree on one to speak — at connection time — so systems on different versions can still interoperate without upgrading in lockstep.
- Release Notes or Changelog — Turns a release's raw diff into an audience-facing announcement — what changed, what's fixed, what will break, and what's going away — so a consumer can decide whether and how to upgrade without reading the code.
- Schema Migration — Transforms stored data and the interfaces over it from an old structural version to a new one — old-version dependents mapped first — so structure can change without losing or stranding information.
- Semantic Versioning — Encodes the compatibility relationship between releases into a MAJOR.MINOR.PATCH number, so a dependent can predict what will break before upgrading — without reading the diff.
- Version Control System — Keeps every historical state, diff, branch, and merge of a digital artifact under one parented lineage, so any version can be named, compared, and restored while the artifact stays the same tracked subject.
Also a related prime in 169 archetypes
- Abstraction–Substrate Traceability Guardrail: Keep abstractions useful without letting them harden into substitute reality by requiring each action-guiding abstraction to carry its representational claim, validity boundary, substrate trace, and re-grounding trigger.
- Access-Optimized Redundant Representation: Create a governed redundant representation around a proven access path, keep one authority and an explicit derivation, bound divergence, verify the benefit, and make refresh, repair, schema change, privacy, and retirement part of the design.
- Accountability Chain Design: Trace responsibility from action or decision to owner, record, answerability forum, and repair consequence.
- Accumulation Compaction: Compress accumulated layers or records so history remains usable without overwhelming present operation.
- Adaptive Precision-Weighted Signal Fusion: Combine imperfect signals by how reliable they are now, not by treating every input as equal or permanently trustworthy.
- Adaptive Threshold Recalibration: Revise thresholds when system conditions, risk tolerance, or measurement reliability changes.
- Aggregation Bias Detection and Correction: Protect decisions from misleading aggregate summaries by disaggregating the data, comparing subgroup and overall patterns, correcting composition effects, and restating only the claims the evidence can support.
- Aggregation Function Design and Weighting: Turn many inputs into one usable output by explicitly choosing the aggregation rule, weights, normalization, and information-loss guardrails.
- Alternative-Hypothesis Generation: Before treating a conclusion as settled, generate credible alternative explanations and identify the evidence that would distinguish them.
- Approximation-Target Divergence Mapping: Refine an approximation by mapping where it diverges from the target, then focus improvement effort on the most consequential gaps.
Notes¶
Data integrity is foundational to computer science, information security, and accounting. The field distinguishes threat models (accidental vs malicious), mechanism classes (checksums for detection vs error- correcting codes for correction vs signatures for authenticity vs constraints for logical consistency), and trust anchors (root hashes, signed manifests, auditor identity, notarized records). Modern systems emphasize end-to-end integrity (every hop verifies) and defense-in-depth (no single layer is sufficient). The design- implementation gap remains critical: many systems claim integrity that is unverified or fails under replay, timing, or concatenation attacks.
References¶
[1] Shannon, C. E. (1948). "A Mathematical Theory of Communication." The Bell System Technical Journal, 27(3), 379-423. Founds information theory; establishes redundancy and channel coding as the basis for reliable transmission over noisy channels. Anchors D30-106, D30-113, D30-114 as the information-theoretic foundation for detecting corruption via redundancy. Verified. (See flag on D30-106: Shannon grounds redundancy-for-detection but not the specific 'different threats require different mechanisms' phrasing.) registry ↩a ↩b ↩c
[2] Hamming, R. W. (1950). "Error Detecting and Error Correcting Codes." The Bell System Technical Journal, 29(2), 147-160. Introduces single-error-correcting / double-error-detecting codes (Hamming codes) and minimum-distance theory. Supports D30-107 (specified threat model / accidental corruption), D30-108 (detection mechanism: error-detecting/correcting codes), and D30-112 (recovery/remediation via parity reconstruction). Verified. registry ↩a ↩b ↩c
[3] Merkle, R. C. (1987). "A Digital Signature Based on a Conventional Encryption Function." In Advances in Cryptology — CRYPTO '87, LNCS 293, pp. 369-378. Springer. Introduces the hash-tree (Merkle tree) construction underlying content-addressed integrity and tamper-evident logs. Supports D30-109 (trust anchor: root hash / signed manifest) and D30-119 (immutable, signed, replicated audit logs / provenance as organizational memory). Verified. registry ↩a ↩b
[4] Bonwick, J., Ahrens, M., Henson, V., Maybee, M., & Shellenbaum, M. (2005). "The Zettabyte File System (ZFS)". Sun Microsystems whitepaper. Describes ZFS's end-to-end integrity: per-block checksums stored in parent block pointers (a Merkle tree rooted at the über-block), verified on read, scrubbed periodically, repaired from redundancy. Supports D30-110 (verification protocol: periodic scrub, canonical snapshot), D30-115 (storage engineer's integrity reasoning), D30-116 (canonical formal instance: redundancy + cryptographic + active verification). Verified. (Often cited as Bonwick & Moore, 'ZFS: The Last Word in Filesystems'; no DOI — vendor whitepaper.) registry ↩a ↩b ↩c
[5] Saltzer, J. H., & Schroeder, M. D. (1975). "The Protection of Information in Computer Systems." Proceedings of the IEEE, 63(9), 1278-1308. Canonical statement of security design principles (defense in depth, complete mediation, fail-safe defaults, least privilege) governing layered, multi-control protection of information. RE-SOURCE for D30-111 (the layered protection approach: network + application + storage + organizational controls). Replaces codd-1970, whose relational-model paper does not address layered/defense-in-depth protection. Verified. registry ↩
[6] Pacioli, L. (1494). Summa de arithmetica, geometria, proportioni et proportionalita (the Particularis de computis et scripturis section). Paganino Paganini, Venice. First printed, systematic description of double-entry bookkeeping: every transaction recorded as equal debit and credit, with the debits=credits invariant detecting single-sided errors via the trial balance; corrections made by offsetting entries (append-only, attributable audit trail). Supports D30-117 (double-entry bookkeeping as an applied integrity instance). Verified. No DOI (1494 incunable); link is a digitized copy. registry ↩
[7] National Institute of Standards and Technology. (2015). SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (FIPS PUB 202). U.S. Department of Commerce. Specifies the Keccak-based SHA3-224/256/384/512 and SHAKE128/256 functions. Supports D30-118 (strong cryptographic hashes — SHA-256, SHA-3 — resist adversarial tampering but cost more than CRC/fletcher; layering requires threat-model analysis). Verified, approved 5 Aug 2015. registry ↩
[8] Rivest, R. L., Shamir, A., & Adleman, L. (1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems." Communications of the ACM, 21(2), 120-126. First practical public-key cryptosystem and digital-signature scheme; a signature verifiable by anyone establishes authenticated origin. Supports D30-120 (end-to-end integrity across distributed systems via app-level signatures that must compose with TLS/storage checksums). Verified. registry ↩
[9] Codd, E. F. (1970). "A Relational Model of Data for Large Shared Data Banks." Communications of the ACM, 13(6), 377-387. Introduces the relational model and the notion of declared integrity constraints over relations. Bibliography-only after re-sourcing (removed from D30-111). Existence-verified and linked. NON-SUPPORTING for its former marker: the relational-model paper does not address the 'layered protection (network + application + storage + organizational controls)' claim it was attached to; defense-in-depth/layering was re-sourced to Saltzer & Schroeder 1975. registry
[10] Härder, T., & Reuter, A. (1983). "Principles of Transaction-Oriented Database Recovery." ACM Computing Surveys, 15(4), 287-317. Coins the ACID acronym (atomicity, consistency, isolation, durability) and gives a unified terminology for transaction recovery. Bibliography-only (tier C) — appears only in the references list (appended to the codd-1970 entry), never cited in the body; existence-verified and linked. registry