Data Integrity¶

Prime #: 172
Origin domain: Computer Science & Software Engineering
Also from: Information Theory, Accounting Auditing, Systems Thinking & Cybernetics
Aliases: Integrity, Data Correctness, Tamper Resistance
Related primes: Consistency, checksum, digital signature, Transaction, Provenance

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

Imagine you write a phone number on a paper and pass it around the room. By the end, has anyone changed a digit? Data integrity means making sure the number stays exactly right from the first person to the last - no smudges, no copy mistakes, no sneaky changes.

Information Stays Correct

Computers store and move lots of information - photos, messages, bank balances - and stuff can go wrong: bits get flipped, copies get messed up, bugs change values, or someone tries to sneak in a change. Data integrity is the promise that information stays accurate and unchanged from when it's made until it's used. Computers use tricks like checksums (little math fingerprints) and rules that block bad edits to catch mistakes and prove nothing snuck in.

Trustworthy, Unaltered Data

Data integrity is the property that data stays accurate, consistent with its intended meaning and rules, and free from unauthorized, erroneous, or accidental changes throughout its whole lifecycle - creation, storage, transmission, processing, archival, retrieval. Without explicit protection, data drifts: bits rot in storage, transmission flips bits, bugs corrupt records, operators mistype, and attackers tamper. Detecting corruption requires either redundancy (extra copies you can compare) or cryptographic verification (a math fingerprint only the legitimate writer could produce). Protections combine technical mechanisms (checksums, error-correcting codes, digital signatures, database constraints, transactions) with organizational mechanisms (validation rules, audits, change control, provenance tracking). Different threats need different defenses.

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 entire lifecycle - creation, storage, transmission, processing, archival, and retrieval. It is enforced through a combination of technical mechanisms (checksums, error-correcting codes, digital signatures, database constraints, ACID transactions) and organizational mechanisms (validation rules, audit trails, change control, provenance tracking). The essential commitment of the concept 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 either redundancy or cryptographic verification, since corrupted data does not announce itself; and that different threat classes demand different mechanisms - a checksum catches random transmission errors but cannot stop a sophisticated attacker, while a digital signature catches tampering but does not detect storage degradation. Integrity is distinct from confidentiality (whether unauthorized parties can read) and availability (whether legitimate parties can access), forming the third leg of the classical CIA triad in information security.

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 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.

Hierarchy paths (2) — routes to 2 parentless roots

Data Integrity → Verification → Evaluation → Comparison → Self Checking

Show alternative path (1)

Neighborhood in Abstraction Space¶

Data Integrity sits in a sparse region of abstraction space (80^th 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 (6 primes)

Nearest neighbors

Traceability — 0.71
Trusted Intermediary Compromise — 0.70
Attestation — 0.69
Authentication — 0.69
Provenance — 0.68

Computed from structural-signature embeddings · 2026-07-26

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
- Delayed Interview Protocol
- Evidence-Age Release Rule
- Evidence-Latency Dashboard
- Late-Entry and Backfill Protocol
- Layered Case Note
- Provenance and Chain-of-Custody Log
- Read-Only Raw Evidence Archive
- Reconstruction Workspace or Replay Table
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
- Collision Quarantine Queue
- Deterministic ID Allocator
- Duplicate Target Scan
- Hash Collision Check
- Namespace Reservation Table
- Preimage Audit Log
- Unique Index Constraint
Conservation Accounting: Track conserved quantities across transformations so losses, leaks, substitutions, duplications, and hidden transfers become visible.
▸ Mechanisms (9)
- Chain-of-Custody Record
- Data Lineage Map
- Energy Accounting
- Financial Ledger
- Inventory Reconciliation
- 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
- Responsibility Accounting Matrix
- Variance Report
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
- Command–Query Separation
- Compensating Action Protocol
- Effect Contract Annotation
- Effect Review Checklist
- Immutable Data or Copy-on-Write
- Permission Scope or Capability Token
- Sandbox or Staging Execution
- State Diff Test
- Transaction Boundary
Deductive Chain Validation: Validate that conclusions actually follow from stated rules and premises before acting on them.
▸ Mechanisms (8)
- Diagnostic Logic Check
- Legal Syllogism Review
- Logic Checklist
- Policy Eligibility Review
- 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
- Rule-Engine Validation
- Syllogism Template
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
- Corrective Action Effectiveness Retest
- Document-to-Practice Trace Matrix
- Exception, Waiver, and Override Log Review
- Line-of-Defense Sample Reperformance
- Near-Miss and Deviation Review
- Operator Shadowing and Contextual Inquiry
- Process-Mining Nominal-Actual Comparison
- Safeguard Bypass Probe
- Work-as-Done Audit
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
- Capture-Recapture Check
- Census Protocol
- Coverage Gap Heatmap
- Door-to-Door or Field Sweep
- Duplicate Resolution Queue
- Enumeration Area Map
- Enumeration Quality Backcheck
- Late-Unit Inclusion Window
- Master Unit Index
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
- Empty Collection Return
- Empty Set Literal
- Empty-State Message
- Identity Element Test
- No-Op Command
- Null Object Pattern
- Option or Maybe Type
- Sentinel Value Retirement
- Zero-Row Result with Schema
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
- Checklist Confirmation
- Deduplication Table or Ledger
- Duplicate-Safe Payment Operation
- 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
- 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
Invariant Guarding: Identify conditions that must always remain true and guard operations so those invariants are preserved.
▸ Mechanisms (8)
- Contract Check
- Database Constraint
- Integrity Monitor
- Invariant Test Suite
- Policy Guardrail
- Rollback Transaction
- Safety Interlock
- Two-Person Rule
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
- 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
- Chain-of-Custody Record
- Change Ledger
- Commit History
- Incident Timeline
- Learning Portfolio
- Stratigraphic Record
- Version History
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
- Benchmark Deduplication Scan
- Duplicate and Near-Duplicate Scan
- Entity-Grouped Split
- Feature Availability Audit
- Fresh Holdout Retest
- Holdout Access Log
- Label Proxy Screen
- Leakage Ablation Test
- Nested Cross-Validation
- Preprocessing Fit-on-Training-Only
- Time-Based Holdout
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
- Calibration Reference Set
- Distortion Heatmap or Profile Report
- Distortion-Budget Gate
- Golden-Sample Regression Suite
- Inverse Correction Mapping
- Raw-Corrected Overlay Review
- Residual Error Analysis
- Transfer-Function Estimation
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
- Duplicate or Blind Remeasurement Check
- Error Bar, Confidence Band, or Quality Flag
- 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
- Measurement Uncertainty Budget Table
- Noise-Floor Estimation Protocol
- Sensor Health and Drift Monitor
- Signal-to-Noise Action Gate
- Uncertainty Propagation Calculation
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
- Custody Chain Reconciliation
- 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
- Ledger Reconciliation Workflow
- Reconciliation Report
- 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
- Three-Way Merge
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
- Baseline Version Register
- Control Chart or Run Chart
- Deviation Event Log
- Deviation Review Queue
- Exception Flag Rules Engine
- Null-Model Residual Report
- Reference Range Flag
- Rolling Baseline Comparison
- Standardized Residual Score
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
- Condition Assessment Survey
- Conservation Logbook
- Conservation Treatment Plan
- Digital Fixity Check and Repair
- Environmental Control Protocol
- Minimal Intervention Review Board
- Monitoring and Retreatment Cadence
- Restoration Protocol
- Stabilization Intervention
Reproducibility Protocol: Make methods, data, assumptions, and environments explicit enough that results can be repeated or checked.
▸ Mechanisms (10)
- Audit Trail
- Containerized Environment Snapshot
- Decision Log
- Lab Notebook Record
- Protocol Documentation
- Replication Package
- Reproducible Research Package
- Rerun Checklist
- Version-Controlled Analysis
- Workflow Script or Pipeline
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
- Chain-of-Custody Record
- Citation Lineage Review
- Confidence Annotation Rubric
- Conflicting Source Table
- Evidence Provenance Log
- Source Criticism Protocol
- Triangulation Matrix
- Witness / Source Comparison
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
- Chain-of-Custody Record
- Change Impact Report
- Citation Chain
- Data Lineage Record
- Decision Log
- 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
- Test Coverage Link
- Traceability Dashboard
Transactional Atomicity: Bundle related operations so they either complete together or are undone together, preserving consistency.
▸ Mechanisms (9)
- All-or-Nothing Checklist
- Atomic Deployment Step
- Batch Settlement
- Contract Execution Bundle
- Coordinated Approval Workflow
- Database Transaction
- Escrow Closing
- 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
- capability_or_authorization_revalidation
- compare_and_swap_or_version_guard
- just_in_time_existence_check
- lease_lock_or_reservation_token
- preflight_resource_probe
- revocation_or_tombstone_check
- safe_missing_referent_fallback
- stale_reference_monitor
- transactional_precondition_guard
Versioned Evolution: Track changes as explicit versions so evolution remains comparable, reversible, auditable, and compatible.
▸ Mechanisms (10)
- Dataset Version Registry
- Document Revision History
- Legal Amendment Record
- 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
- Protocol Version Negotiation
- Release Notes or Changelog
- Schema Migration
- Semantic Versioning
- Version Control System

Also a related prime in 168 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.

▸ Show 158 more

Aspect-Scoped Identity Projection: Represent one underlying entity under a defined aspect or role as a linked derived bearer, so properties, rights, obligations, identifiers, and lifecycle rules attach only where they belong.
Asymmetric Interface Tolerance Calibration: Treat producer strictness and receiver tolerance as separate interface design choices, then choose and govern the regime that preserves compatibility without hiding drift or unsafe ambiguity.
Asynchronous Replica Convergence: Let replicas make bounded local progress without continuous coordination, then force equivalent outcomes through explicit causal context, deterministic merge, repair, and a verifiable convergence contract.
Attrition and Dropout Monitoring: Track who leaves a study, when they leave, why they leave, and from which condition so dropout cannot silently distort causal or comparative conclusions.
Backlog Visibility: Make waiting work visible by size, age, priority, ownership, and drain rate so the system can manage reality instead of hidden accumulation.
Baseline Covariate Balance Verification: Check whether randomization actually produced comparable groups by comparing pre-treatment covariates before causal conclusions are drawn.
Behavior-Preserving Refactoring: Improve the inside without changing what the outside can validly observe or rely on.
Bidirectional Conceptual Translation: Translate concepts between frameworks by mapping meaning, use, assumptions, and consequences while making gaps and losses explicit.
Black-Box / White-Box Selection: Choose whether to test or govern a system by observed behavior, internal mechanism, or both.
Blinding and Expectancy Bias Reduction: Hide condition identity from the roles that could be biased by knowing it, while preserving safety, correct operation, and auditable exceptions.
Blocking Design: Group similar experimental units before assignment and compare treatments within blocks so nuisance variation does not obscure the effect being studied.
Boundary-Embedded Disclosure Design: Make critical scope, provenance, version, limitation, and next-action information travel with an artifact by embedding a compact disclosure at the artifact’s reuse boundary.
Branching and Merging: Allow parallel versions or lines of work to diverge safely and then recombine through explicit merge rules.
Carrier-Independent Work Identity Governance: Keep a work recognizable as the same work across copies, formats, editions, performances, implementations, and migrations by explicitly governing what may vary and what creates a new work.
Change-Scoped Revalidation: After a change, re-derive only the facts inside a justified affected closure, retain the rest by a defeasible persistence presumption, and test that the boundary did not leak.
Closure-Preserving Operation: Design operations so their outputs remain inside the intended domain, preserving invariants and preventing escape into invalid states.
Comparative Benchmark Validation: Validate a claim by comparing the system against explicit reference standards, gold standards, incumbent alternatives, competitors, or benchmark suites under conditions that make the comparison meaningful.
Compatibility Management: Manage how old and new versions interact so change does not break dependent systems or users.
Compensating Transaction: When atomic rollback is impossible, apply compensating actions that restore an acceptable state after partial completion.
Completeness Audit: Systematically search for missing cases, gaps, states, stakeholders, paths, records, requirements, or risks so the system does not fail in unhandled regions.
Composability Testing and Validation: Test whether components that work alone still work together, and use the results to define safe recombination boundaries.
Concurrency Control: Coordinate simultaneous processes so they can proceed in parallel without corrupting shared state, over-claiming shared resources, or blocking one another indefinitely.
Conditional Independence Boundary Mapping: Reduce a complex dependency field to the smallest validated statistical interface that is sufficient for reasoning about a target.
Conserved Reservoir-Flux Balancing: Name the reservoirs, name the conserved fluxes between them, and close the balance so interventions change the whole stock-flow network rather than merely moving imbalance out of sight.
Construct–Proxy–Signal Validity Alignment: Make a measurement earn its interpretation by tracing the claim from construct to proxy to signal and requiring evidence that the signal captures the intended construct rather than a correlated surrogate.
Context Anchor Design: Provide explicit context anchors so references to people, time, place, role, and situation resolve correctly.
Context-Keyed Representation Switching: Maintain several context-specific representations on one substrate, activate the right one from validated context cues, isolate inactive maps from interference, and preserve them for reliable re-entry.
Contrapositive Elimination Reasoning: Rule out a candidate by showing that a consequence it must produce is reliably absent.
Control/Data Boundary Enforcement: Keep untrusted content inert by making control authority travel only through separated, authenticated, typed, and least-privileged control paths.
Correlated Proxy Monitoring: Monitor an observable proxy that is reliably correlated with a hidden or distant state so action can begin before direct observation is available.
Correlation Structure Characterization: Characterize how variables move together—by sign, strength, form, lag, condition, uncertainty, and stability—then explicitly constrain what that association may be used to claim or decide.
Correspondence Validation: Ensure a new model, theory, version, or system matches the old one within the old one’s valid domain before replacing it.
Coupled-Signal Decay Compensation Design: Keep paired meanings from drifting apart when one side of the pair fades faster than the other.
Coverage Probability Calibration: Verify and adjust uncertainty intervals so their promised coverage rate is achieved in the regime where decisions will rely on them.
Data-Control Boundary Inertization: Keep untrusted content inert until a structural boundary, validation rule, and authority gate explicitly permit it to become control.
Deferred Fulfillment Placeholder: Create a first-class placeholder for a committed future value so dependent work can proceed, compose, wait, cancel, or fail explicitly before the value exists.
Definition-Time Context Binding: Bind a behavior unit to the minimum context that defined it so later execution resolves against that context rather than silently inheriting an unrelated ambient environment.
Demand-Triggered Deferred Evaluation: Represent optional or path-dependent work as a suspended unit, realize only the dependency closure demanded now, and make result sharing, side effects, failure timing, cancellation, lifetime, and first-use latency explicit.
Deterioration Monitoring: Track slow degradation signals so maintenance, repair, renewal, or replacement occurs before failure becomes visible, expensive, or catastrophic.
Deterministic Transition Contract: Make the transition from current state to next state fully specified so identical starting conditions, rules, inputs, ordering, and environment produce one reproducible successor.
Distributional-Assumption Governance: Make probability-distribution commitments explicit, evidence-grounded, consequence-aware, stress-tested, and revisable before they govern inference or action.
Domain–Codomain Delimitation: Define valid inputs and valid outputs so a function or process does not receive, produce, or promise out-of-scope values.
Durable Identifier Binding: Create a durable handle for a referent, bind it in an authoritative record, and maintain enough lookup, lifecycle, and audit rules that later references can rely on the handle without re-describing the entity.
Emergent Similarity Partitioning: Find provisional groups by similarity when labels are not given, then validate and interpret the partition before using it.
Empirical Cluster Discovery: Discover provisional groups in unlabeled observations by making representation, similarity, validation, interpretation, and downstream use explicit.
Encapsulated Substitutability: Make replacement safe by hiding implementation behind a stable role contract and validating that any substitute preserves the required behavior, context, and invariants.
Entity Individuation Criteria Design: Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.
Entity Persistence Across Observation Gaps: Keep a temporarily unseen entity represented as an uncertain continuing entity, then re-associate its return to the retained identity before declaring disappearance or creating a replacement.
Entropy Export: Preserve local order by moving disorder, waste, ambiguity, heat, or cleanup burden across a boundary to a governed sink with visible accountability.
Entropy Management: Counter the drift toward disorder by budgeting recurring effort for maintenance, cleanup, renewal, and information preservation.
Equivalence Class Consolidation: Treat superficially different entities as equivalent when they share the relevant structure or function, reducing duplication and inconsistent handling.
Equivalence Normalization: Normalize superficially different forms that are structurally or functionally equivalent so they can be treated consistently.
Equivalence-Preserving Rewrite Optimization: Rewrite something into a cheaper, clearer, faster, safer, or more usable form only after proving or testing that the declared behavior stays equivalent.
Event–Narration Order Decoupling: Separate what happened when from the order in which it is shown, told, taught, or argued, then keep the two orders explicitly mapped so presentation can be optimized without corrupting chronology.
Evidence-Bound Authentication: Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.
Evidence-Grounded Persona Proxy Design: Turn complex user or stakeholder evidence into a memorable persona proxy while preserving the boundary, provenance, uncertainty, and refresh rules that keep the proxy honest.
Evidentiary Trace Warranting: Treat evidence as a defeasible relation between a trace and a claim, not as raw data or free-floating support.
Expected-Absence Signal Interpretation: Treat a missing expected event as evidence only after verifying that it was expected, observable, producible, timely, and unlikely to be missing for benign reasons.
Explicit State Modeling: Make possible system states explicit so transitions, responsibilities, permissions, and failures can be governed.
Failover: Switch a protected function from a failed primary path to a prepared alternate so continuity is preserved.
Fast/Slow Path Routing: Route routine cases through a cheap, safe fast path while sending exceptional, ambiguous, risky, or high-value cases to a deliberately resourced slow path.
Fast–Slow Store Coupling: Keep a volatile fast store and a durable integrated store coupled by governed transfer so the system gets immediate access without losing long-term coherence.
Functional Specification: Define the expected input-output behavior of a component, process, role, model, or policy so it can be used, tested, replaced, or governed predictably.
Funnel Attrition Localization: Represent an ordered process as denominator-preserving stages, measure where the population is lost, and prioritize the stage whose repair most improves final yield.
Generate-and-Verify Separation: Let many, complex, heuristic, or untrusted parties search for candidates, but require every accepted candidate to pass a substantially cheaper, smaller, explicit, and independently assured verifier.
Heuristic Calibration and Confidence Judgment: Trust a heuristic only to the degree that its confidence is calibrated to its track record and operating environment.
Identity-Bounded Change: Modify an existing entity only inside an explicit identity boundary, retain its stable identity and lineage when continuity tests pass, and declare replacement or a fork when they do not.
Independent Evidence Triangulation: Cross-check a scoped claim with multiple meaningfully independent evidence streams, using both convergence and divergence to calibrate confidence and expose hidden dependence, bias, or context.
Independent Verification Oversight: When a validity judgment can be biased by the producer’s incentives or assumptions, route the evidence to an independent verifier with enough access, authority, and separation to challenge the claim before it is accepted.
Index-Based Retrieval: Create an index or retrieval structure so relevant information can be found without scanning the whole space.
Information Set Specification and Completeness Verification: Do not ask whether a price or signal is simply “efficient”; specify the information set it should reflect, then test whether available information and residual opportunities show complete incorporation.
Inline vs. Offline Inspection Trade-Off: Choose whether quality should be checked continuously during production or sampled after completion by matching inspection placement to defect severity, detectability, cost, throughput, and escape risk.
Intermittent Sampling: Sample periodically or irregularly to detect intermittent states that continuous monitoring cannot afford or guarantee.
Interoperability Standardization: Create shared standards or protocols so independently built systems can work together without bespoke negotiation each time.
Intrinsic Signature Provenance: Preserve or read an intrinsic, stable origin signature so provenance travels with the thing itself, even when external records are missing or distrusted.
Knowledge-Warrant Audit: Audit what each belief rests on, classify the strength and type of its warrant, and adjust confidence or action accordingly.
Layer Decay and Expiration Management: Give accumulated layers a managed lifecycle so old deposits are refreshed, archived, compacted, preserved by exception, or safely removed instead of silently piling up forever.
Leakage Path Containment and Recapture: Prevent constrained resources, information, risks, contaminants, funds, or obligations from escaping through unintended paths by making leakage paths visible, bounded, sealed, and recoverable.
Least-Privilege Access Design: Grant actors only the access needed for their role, task, or context, with escalation and audit paths for exceptions.
Longitudinal Follow-Up Validation: Treat validation as a time-extended claim by checking whether outcomes, harms, and operating assumptions still hold after deployment and accumulated exposure.
Lossless Bijective Mapping Design: Design mappings so nothing collides, nothing is left out, and every pairing can be traversed backward as well as forward.
Mapping Reconciliation: Resolve conflicts between competing mappings so systems, teams, or domains can interoperate or reason from a shared correspondence.
Measurement-Protocol Standardization: Make comparisons interpretable by ensuring every subject, group, site, or condition is measured with the same construct, instruments, timing, administration, scoring, calibration, and deviation rules.
Metanarrative Coherence and Internal Consistency Check: Turn a sweeping story into an auditable claim structure, then test whether its claims, exceptions, evidence links, and implied conclusions can all hold together.
Minimal-Disclosure Verification: Make a verifier confident that a bounded claim is true without handing over the underlying witness, record, identity attributes, or computation trace.
Missingness-Aware Estimator Selection: Choose the missing-data estimator only after stating why values are absent and what assumption makes the target estimand recoverable.
Model-Guided Signal Separation: Recover a target component from mixed observations by stating what the target is, modeling how target and nuisance combine, applying a calibrated separator, and proving what the output preserves, suppresses, and still leaves uncertain.
Nearest-Exemplar Response Reuse: Use the closest remembered or stored case as the model for the present response, while making similarity, adaptation, confidence, and exception boundaries explicit.
Nested and Distributed Transaction Coordination: When one transaction spans multiple participants or nested scopes, make the transaction boundary, protocol, participant states, failure behavior, compensation path, and closure evidence explicit before letting local commits create irreversible partial outcomes.
Non-Destructive Calibration Check: Confirm that a live system is still calibrated by comparing it to independent reference evidence without dismantling, damaging, consuming, or interrupting it.
Nonlocal Coupling Governance: Govern hidden remote dependencies by treating distant correlated or coupled elements as explicit edges even when no contiguous local path is visible.
Object-Centered Feature Binding: Bind separately detected features to the right object, event, entity, or record by using shared context, co-occurrence cues, exclusivity constraints, and explicit ambiguity states instead of fusing channels blindly.
Observability Instrumentation: Instrument external signals so hidden internal state becomes inferable enough for monitoring, diagnosis, and control.
Observational Equivalence Resolution: Resolve cases where different causes, states, agents, or models produce the same observations by adding discriminating observations, shifting frame, or preserving explicit ambiguity.
Open Reuse Publication Infrastructure: Make an artifact reusable by strangers by publishing it as a stable, openly accessible, license-clear, machine-readable, versioned, and maintained public dependency rather than as a private handoff.
Operation-Weighted Data Structure Design: Choose the information structure around the real operation mix, making lookup, update, traversal, storage, consistency, and maintenance tradeoffs explicit instead of accidental.
Order-Independent Processing: Redesign operations so results do not depend on processing order, enabling parallelism, retry safety, and robustness.
Perception-Comprehension-Projection Loop Design: Keep action aligned with a moving situation by continuously refreshing what is seen, what it means, what is likely next, and what decision it now supports.
Persistent Identifier Stewardship: Keep references usable over time by assigning a durable identifier and maintaining the resolver, metadata, and stewardship rules that make the identifier continue to reach the same intended entity.
Perturbative Error Correction: Correct accumulated drift by applying small, bounded perturbations that steer a system back toward its operating band without shutting it down or rebuilding it.
Physical-Constraint Design for Impossibility: Make the wrong action physically impossible, materially rejected, or harder than the correct action.
Platform Core / Extension Design: Create a stable shared core with explicit extension surfaces, contracts, lifecycle governance, compatibility, safety, evolution, and exit so many independently built variations can reuse the same foundation.
Post-Encoding Trace Stabilization: Protect a newly encoded trace long enough for it to stabilize, integrate, and survive later interference rather than relying on immediate recall.
Predictive Residual Processing: Reduce bandwidth and focus adaptation by representing expected input through a maintained model and propagating only calibrated deviations, with synchronization, raw-state audits, and full-signal fallback.
Principal-Bound Authority Mediation: Let a deputy act only when the requesting principal, stated intent, delegated scope, and use of the deputy’s authority are explicitly bound and checkable.
Process-Imprint Source Attribution: Use stable, involuntary marks left by a production process to infer where an output came from, with controls for confounders, spoofing, and over-attribution.
Propositional Mode Governance: Keep propositions in the right epistemic mode and permit only the operations that mode licenses.
Reconstruction-Resistant Disclosure Design: Before releasing outputs, model what a knowledgeable observer could reconstruct from them and redesign the disclosure until protected inputs stay unrecoverable within an explicit risk budget.
Recursive Triangulation of Triangulation: When a conclusion already rests on triangulation, audit the triangulation itself by checking whether its evidence streams are independent, its convergence logic is valid, and its confidence claim survives a second-order triangulation layer.
Registry-Mediated Discovery: Put a maintained discovery registry between agents and changing counterparts so stable names resolve to current locations, interfaces, or contact records instead of hard-coded references.
Regression-to-the-Mean Guardrail: Prevent ordinary reversion after extreme observations from being credited to an intervention, person, punishment, reward, or event without a credible counterfactual.
Regroupable Aggregation: Design partial summaries to combine associatively so an aggregate can be chunked, nested, or tree-reduced without changing its defined result.
Relation Constraint Enforcement: Define and enforce which relationships are valid so the system cannot enter inconsistent, unsafe, or contradictory relational states.
Relation Mapping: Make important associations or dependencies explicit so they can be reasoned about, governed, repaired, or redesigned.
Relevance-Substitution Detection and Correction: Stop irrelevant but persuasive cues from standing in for evidence that actually bears on the question.
Representation-Independent Interface Contract: Specify what a component does at its public surface, hide how it does it, and test that any replacement implementation honors the same contract.
Representative Sampling Design: Select observations so the sample can credibly stand in for the population or system being judged.
Reputational Signal Governance: Turn past behavior into a governed standing signal that helps others decide trust, access, scrutiny, cooperation, or priority while preserving evidence quality, context, correction, decay, and anti-abuse safeguards.
Residual Risk Decay Tracking: Track how risk decays after an event so restrictions, monitoring, or reentry can be timed appropriately.
Restricted-Issuance / Open-Verification Design: Let many actors verify an artifact, credential, claim, or mark without giving them the protected capability needed to create valid ones.
Reversibility-Aware Transition Design: Make every consequential transition explicit about what can be undone, how, by whom, within what limits, and what irreversible residue remains.
Risk-Adjustment and Benchmark Selection: Before calling performance abnormal, inefficient, or skillful, choose a benchmark that matches the relevant risk exposure, opportunity set, time horizon, and information conditions.
Role-Scoped Disclosure Minimization: Release only the role- and purpose-justified subset of a richer record, removing surplus at the producer boundary before it can propagate.
Round-Trip Code Alignment: Align encoders and decoders around a shared scheme so content survives transmission, storage, or transformation with known fidelity, loss, and failure behavior.
Selection–Transmission Change Attribution: When an aggregate mean changes, split the change into how much came from units gaining or losing weight and how much came from units changing internally.
Selective Legacy Integration: Carry forward what gives a predecessor system knowledge, trust, and identity while redesigning it for the successor context.
Self-Checking Operation: Make the operation prove or test its own acceptability before its output can propagate.
Self-Generated Signal Cancellation: Send a copy of an action command to the observer so expected self-caused effects can be canceled, tagged, or discounted before residual signals are interpreted as external events.
Sense-Experience Reduction Protocol: Translate a claim about an object, property, or state into the experiences or observations that would occur under specified access conditions.
Sequestration Containment: Remove a harmful, volatile, scarce, or sensitive target from active circulation and hold it in governed containment until safe disposal, preservation, or controlled release is justified.
Shared-State Consistency Contract Design: Make the legal observations of shared state explicit, choose the weakest guarantee that still protects the real invariant, and bind that promise to read/write rules, fault assumptions, tests, telemetry, and migration behavior.
Shortcut-Reliance Mitigation: Expose and repair cases where a learner succeeds by exploiting a cheap incidental cue rather than the structure it was meant to learn.
Source Distortion Modeling: Treat a report from a systematically distorted source as a biased channel to be modeled, not as either transparent truth or useless noise.
Specification-to-Execution Lowering: Lower a what-level specification into an executable how through explicit refinement stages, carrying forward the contract, assumptions, invariants, evidence obligations, and trace needed to justify that the result actually realizes the intent.
Standardization-and-Simplification: Make the correct action easier and the wrong action less available by replacing needless variation with a small, clear, maintained standard.
State Estimation: Infer a system's hidden state from incomplete, noisy, or indirect signals so control decisions can be made.
Stationarity Validation: Check whether the assumptions that made past data or behavior predictive still hold before extrapolating.
Strategic Caching: Store high-value reusable results near where they are needed so repeated retrieval or computation becomes faster and less costly.
Stratigraphic Time-Ordering Inference: Reconstruct what happened when by treating preserved layers as ordered evidence, while checking for missing, mixed, inverted, or disturbed strata before making causal claims.
Structural Inversion Design: Reverse a declared structure under explicit invariants, recoverability, boundary, and round-trip rules.
Summative Certification: Validate and certify whether required outcomes have been achieved at a meaningful endpoint.
Survival-Conditioned Persistence Forecasting: Use survival to the present as evidence about remaining persistence only for non-aging entities and only after testing the lifetime distribution, survivor set, and future regime.
Symmetry-Commuting Transformation Design: Design a mapping so meaningful transformations of the input are mirrored by corresponding transformations of the output rather than erased, amplified, or changed inconsistently.
Target-Complete Mapping Design: Define the required target space and ensure every target has at least one valid, feasible, and verifiable source-side witness, with no silent gaps.
Task-Legible Feature Construction: Transform raw observations into task-relevant features so a downstream consumer can see the regularity the raw data hides.
Task-Relevant Compression: Compress information by preserving what matters for the task and discarding or encoding the rest.
Temporal Resolution and Sampling Rate Design: Choose the time resolution of observation so important changes are visible without creating aliasing, blind spots, noise, or overload.
Texture as Signal Encoding: Use texture as a deliberate code so users can perceive status, category, quality, or affordance without relying only on words, color, or shape.
Time Series Cross-Section Analysis: Compare many units across many moments so change over time is not confused with stable differences between units.
Tolerance Band Management: Define and manage acceptable variation so parts, processes, or behaviors remain compatible without requiring impossible precision.
Tolerance Stack Management: Manage cumulative deviations across parts, steps, interfaces, or decisions so locally acceptable variation does not compose into system-level failure.
Traceable Measurement System Design: Define exactly what attribute is being measured, anchor it to a unit and frame, realize it through a validated instrument and procedure, and report the result together with uncertainty and traceability.
Transparency for Accountability: Expose who decided what, under which authority, using which reasons and evidence, with visible limits, questions, corrections, and remedy so disclosure produces accountability rather than noise.
Trend Detection and Removal: Separate persistent directional movement from the pattern you want to interpret so trend does not masquerade as signal, anomaly, or causal change.
Uncertainty Explicitness: Make uncertainty visible so decisions do not mistake unknowns, assumptions, or estimates for facts.
Use-Time Source Attribution Calibration: Before using a commingled memory, note, claim, trace, or generated output, classify where it came from and how certain that attribution is.
Vantage Coverage-Gap Mapping and Correction: Treat every observation as vantage-bound: map what the vantage can and cannot see, label the claim boundary, and repair or triangulate the blind zones before generalizing.
Yield Loss Attribution: Explain why realized output falls short of its theoretical maximum by partitioning the deficit into named, measured, ranked loss channels.

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.) ↩

[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. ↩

[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. ↩

[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.) ↩

[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. ↩

[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. ↩

[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. ↩

[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. ↩

[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.

[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.