Redundancy¶
Core Idea¶
Redundancy is a fault-tolerance design pattern characterized by deliberate duplication of components or functions whose failure would otherwise cause system failure, such that the duplicates can maintain function if any one of them fails[1]. The central design variable is independence—redundant components must fail independently for the redundancy to deliver intended fault tolerance; correlated failures across the redundant set defeat the design. Multiple configurations exist, each with distinct failure-coverage and cost trade-offs: active-active (all copies operate, any one suffices); active-standby (primary operates, standby takes over on failure); diverse-redundancy (different implementations of the same function, reducing common-mode failures); voting (majority among copies determines output)[2]. Redundancy is orthogonal to Margin of Safety (#283): where margin absorbs demand variation above a single component's capability, redundancy handles component failure through alternate pathways. Redundancy is an information-theoretic principle as well as an engineering pattern: Shannon's channel-coding theorem established that redundant encoding overcomes noisy channels; in component duplication, the same principle applies to component failure as a form of "noise" at the component level. The probability of simultaneous independent failure of N components shrinks exponentially in N under independence, the load-bearing mathematical property enabling reliability levels (5, 6, 9 nines of uptime) that no single component achieves[3].
How would you explain it like I'm…
Having a Spare
Backups on Purpose
Redundancy
Structural Signature¶
the multiple-component-functionally-equivalent property; the failure-tolerant architecture mechanism; the information-theoretic redundancy (Shannon channel coding); the degeneracy-versus-redundancy distinction (Edelman-Gally); the cost-of-replication versus availability trade-off; the distributed versus localized redundancy structure[4]. A design pattern duplicating critical components such that system function requires less than all of them working. The structural primitive is that any single component has non-zero failure probability, the probability of simultaneous independent failure of N components is the product of individual probabilities (shrinking exponentially in N under independence), and system function can be made arbitrarily reliable by adding copies provided the independence assumption holds. The signature appears wherever reliability requirements exceed what any single component can deliver: aerospace (multiple control channels, multiple engines, triple-redundant flight computers), data storage (RAID, replication, erasure coding), networks (multi-path routing, dual-homed interfaces, BGP multipath), power systems (multiple feeds, UPS, generators, distributed microgrids), and biological systems (paired organs, immune-system diversity, genetic redundancy, codon degeneracy).
What It Is Not¶
Redundancy is not the same as Robustness (#282)[2] — redundancy is one mechanism among several for achieving robustness; robust systems can use margin, redundancy, fail-safe, or tolerance alone or in combination. It is not the same as Fail-Safe (#284) — fail-safe routes failures to safe states without necessarily maintaining function; redundancy maintains function through the failure. It is not the same as Triangulation (#281) — triangulation aggregates independent sources to verify a target; redundancy duplicates components to maintain service; the independence requirement is shared but the purpose differs. It is not the same as backup in the data-protection sense[5] — data backup is one instance of redundancy, but redundancy more broadly covers real-time operation rather than post-incident recovery. It is not free — redundancy costs resources (hardware, power, complexity) and often introduces coordination problems (consensus protocols, split-brain risks). It is not unconditional insurance[6] — correlated failures defeat redundancy, so the independence of failure modes is the load-bearing property rather than the copy count. A backup system sharing a power source with the primary is not redundancy; a replica database that uses the same network link as the primary is not redundancy; independent-looking copies that run the same buggy code are not redundancy.
Broad Use¶
Aerospace (quadruple-redundant flight controls, multiple independent engines, redundant hydraulic systems on 747/777, triple-triple-redundancy in fly-by-wire computers[7]). Data storage (RAID ⅕/6/10, erasure coding, multi-region replication in modern cloud storage, distributed backup). Distributed systems (replicated state machines, Paxos/Raft consensus, database replicas, quorum reads/writes, primary-secondary replication patterns[8]). Networking (redundant links, multiple ISPs, BGP multipath routing, dual-homed interface cards). Power infrastructure (N+1 generator design, dual utility feeds, uninterruptible power supplies, distributed microgrids). Data-center design (redundant cooling, dual power distribution, multi-zone deployment, multi-region active-active architectures). Biological systems (paired organs, genetic redundancy, immune-repertoire diversity, codon degeneracy reducing mutation effects, polyploid organisms). Financial institutions (redundant trading infrastructure, geographic diversification, multiple settlement systems). Cybersecurity (defense in depth with multiple independent control layers, redundant authentication factors, duplicate firewall systems). Manufacturing and industrial systems (backup production lines, redundant quality-control checkpoints, multiple supply sources). Public transportation (multiple lane-guidance systems, triple-redundant brakes in trains, parallel power systems in ships).
Clarity¶
Naming redundancy explicitly distinguishes fault-tolerance duplication from other design moves (load-balancing, capacity provisioning, backup) that may share surface appearance. The explicit name also forces the load-bearing question: independent of what failure modes? A copy that shares failure modes with the original does not provide redundancy even if physically duplicated; analysis of failure-mode independence is where the design work actually sits.
Manages Complexity¶
Designing individual components for arbitrarily high reliability is intractable past certain limits (manufacturing defects, wear, cosmic-ray bit flips, human error); redundancy handles the complexity by accepting component-level unreliability and recovering reliability at the system level through replication. The cost is hardware (multiple copies), complexity (coordination among copies, failover logic), and failure modes specific to the coordination (split-brain, consensus failure). The pay-off is reliability levels (5, 6, 9 nines of uptime) that no single component achieves.
Abstract Reasoning¶
Displays the general principle of probabilistic dilution: if individual failure probabilities are small and independent, combined failure probability shrinks exponentially in copy count. The same structural move appears in information theory (Shannon's channel coding theorem: redundant coding overcomes noisy channel), in biology (genetic code redundancy, codon degeneracy reducing mutation effect), in finance (portfolio diversification reducing risk by spreading across uncorrelated assets), in organizational design (multiple trained personnel per critical role), and in cryptographic threshold schemes (shared secrets reconstructible from any subset of holders).
Knowledge Transfer¶
Mapping Redundancy into cloud-infrastructure high-availability design:
| Redundancy component | Cloud-infrastructure analogue |
|---|---|
| Duplicate component | Compute instance, storage replica, database replica |
| Failure-mode independence | Multi-AZ, multi-region deployment |
| Active-active | Load-balanced multi-instance service |
| Active-standby | Hot/warm/cold standby, leader-follower databases |
| Diverse-redundancy | Multi-cloud deployment (AWS + GCP) |
| Voting | Consensus-based storage (Paxos, Raft, Spanner) |
| Correlated-failure risk | Shared dependencies (DNS, auth, control plane) |
| Coordination cost | Replication lag, split-brain logic, cross-region latency |
The transfer paragraph: modern cloud high-availability architecture implements redundancy at multiple levels structurally identical to aerospace redundant-control design. Compute services run multiple instances behind a load balancer (active-active at the smallest scale); services are deployed across multiple availability zones within a region (failure-mode independence at infrastructure level); critical services deploy across multiple regions (independence at geographic and control-plane level); the most resilient systems deploy across multiple cloud providers (diverse-redundancy defeating single-vendor correlated failures). Each level adds reliability at a cost (hardware, latency, consistency complexity), and mature engineering practice allocates redundancy proportional to the consequence of failure. The failure-mode independence question is the one engineers actually spend their time on: what correlated dependencies (DNS, auth, package repositories, management consoles) exist across the nominal redundant copies, and how are those dependencies themselves made redundant. The analysis is structurally identical to the failure-mode-independence analysis in aircraft hydraulic design — the same discipline, different substrate.
Examples¶
Formal/abstract¶
The Boeing 777's fly-by-wire flight-control system uses triple-triple redundancy: three primary flight computers, each implemented with three dissimilar processors (Intel 80486, Motorola 68040, AMD 29050) running independently developed software from three different teams[9]. The design provides fault tolerance to single and double failures and diverse-redundancy coverage against correlated software or hardware bugs (a bug specific to one processor architecture or one team's implementation would not affect the others). The aircraft has flown billions of commercial hours without a flight-control-induced hull loss. The design is a canonical instance of layered redundancy with explicit attention to correlated-failure coverage[7]. Each layer (computer level, processor level, software-implementation level) addresses different failure modes: hardware failures that might affect one processor family would not affect all three; software bugs in one team's code would not affect independently-developed teams' code; the combination of three-times-three redundancy means single point of failure is nearly impossible. The engineering methodology has influenced safety-critical computing across domains: nuclear-power control rooms, medical devices, air-traffic control systems, and autonomous-vehicle safety systems all employ variants of the triple-triple approach or similar multi-layer, diverse-redundancy designs[10].
Mapped back: The 777 flight-control system exemplifies how explicit attention to correlated-failure modes (different processor families, different software teams) and layered redundancy (triple processors, triple computers) eliminates single points of failure and achieves reliability that no single component can deliver.
Applied/industry¶
A global payment service achieves 99.99% annual availability (approximately 52 minutes of downtime per year) through layered redundancy[11]: within-region, the service runs with five replicas per service type behind a load balancer with health-check-based instance removal; the region's database uses Paxos-based consensus with five replicas across three availability zones, tolerating two simultaneous zone failures; the overall service runs active-active across three geographic regions with automated cross-region failover (redundancy at the region level)[12]; DNS is served by two separate DNS providers to avoid single-provider correlated failures; the control plane (deployment, monitoring, auth) has its own independent multi-region redundancy. When a regional AWS control-plane outage affects one region, automated failover shifts traffic to the other regions within 90 seconds; customers experience a brief latency increase but no outage. The actual engineering attention across the design year is disproportionately concentrated on identifying and eliminating correlated dependencies between the nominally-independent copies—the same concern as the 777 flight-control design in different substrate: What shared dependencies exist across the nominally-independent replicas? What would cause all three regions to fail together? What DNS infrastructure do both DNS providers depend on? The redundancy is only as strong as its independence; the engineering work is relentlessly identifying hidden correlated-failure modes and eliminating them through diversification (different DNS providers, different cloud regions, different database technologies in different regions)[13].
Mapped back: The global payment service demonstrates how layered, multi-level redundancy (within-service, within-region, across-region, with separate DNS) achieves reliability that far exceeds any single component, but only if the independence of failure modes is actively maintained through relentless elimination of hidden correlations.
Structural Tensions¶
T1 — Correlated failure defeats redundancy. Copies that share a failure mode (same software bug, same vendor, same shared dependency, same operator error) fail together, collapsing N-way redundancy to single-point-of-failure behavior. The historical engineering literature is full of cases: MCAS in 737 MAX sharing sensor data across nominally-independent flight-control channels, the 2017 GitLab outage where all backups failed together due to shared storage infrastructure, DNS outages affecting redundant services because all used the same single-threaded logging library. Correlated-failure analysis is the load-bearing engineering work of redundant design.
T2 — Coordination failure. Redundant copies require coordination (which is primary, what has been replicated, what to do on network partition). The coordination itself can fail—split-brain scenarios, consensus livelock, replication lag producing inconsistency—creating new failure modes that did not exist in single-copy systems. Consensus protocols (Paxos, Raft, Byzantine variants) are the engineering response to this class of problem, but they introduce their own failure modes (timeouts, partition tolerance assumptions, decision latency).
T3 — Cost and complexity scaling. Redundancy costs resources proportional to the copy count and coordination complexity often superlinear in the number of copies. At some point the cost of additional redundancy exceeds the marginal reliability improvement, and further reliability must come from margin, design simplification, or reducing dependency on high-reliability components. The design decision of where the redundancy-cost sweet spot sits is domain-specific and evolves with technology (aerospace continues using high redundancy; software increasingly uses moderate redundancy plus active monitoring).
T4 — Redundancy masking degradation. A redundant system can continue operating with one or more copies failed, but if the failure is not visible, the system is running on reduced effective redundancy and cannot tolerate an additional failure. Silent degradation is a recurring operational-reliability failure mode, addressed by first-class monitoring of redundancy state (not just system state) and treating detected degradation as an operational priority rather than routine noise.
T5 — Overhead and latency in coordination. Keeping redundant copies synchronized requires coordination overhead (consensus rounds, replication lag) that reduces latency performance compared to single-copy systems. Active-active redundancy spreads the load but requires distributed coordination; active-standby reduces overhead but requires failover latency and loses performance during failover. The choice between configurations is a latency-versus-availability trade-off.
T6 — Diverse redundancy versus testability. Using different implementations to avoid correlated bugs (different processors, different teams, different vendors) improves robustness but makes testing and validation harder—you cannot test all three implementations together in advance, and failure modes may appear only in specific combinations not seen in testing. The engineering cost of diverse redundancy includes the cost of validating and maintaining multiple heterogeneous implementations.
Structural–Framed Character¶
Redundancy sits at the structural end of the structural–framed spectrum: it is a pure relational pattern, the same in any domain where it appears, and nothing about its meaning depends on a particular field's vocabulary or assumptions.
Its core is the deliberate duplication of functionally equivalent components so that the survivors maintain function if one fails, with independence of failure as the variable that decides whether the design actually delivers fault tolerance. This is a formal architectural relationship, expressible just as cleanly in Shannon's information-theoretic sense of channel coding as in hardware design or biological degeneracy. It carries no inherent evaluative weight beyond the engineering fact that correlated failures defeat it, and it is definable without reference to any human institution — backup servers, duplicate flight-control systems, and repeated bits in a code are all the same structure. Applying it means recognizing a configuration already present in a system. On every diagnostic, it reads structural.
Substrate Independence¶
Redundancy is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its signature — deliberate duplication for fault tolerance, resting on the independence of failures rather than any domain's vocabulary — spans systems design, engineering, information theory, and cybernetics. The worked examples cross substrates cleanly, from the Boeing 777's triple-triple flight-control redundancy to Paxos-based data replication in payment systems, and the same logic carries into biological backup systems and ecological resilience. It sits a notch below the ceiling because the demonstrated reach, while genuine, is anchored in engineered and informational systems rather than spanning every substrate type equally.
- Composite substrate independence — 4 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 4 / 5
Relationships to Other Abstractions¶
Current abstraction Redundancy Prime
Parents (3) — more general patterns this builds on
-
Redundancy is a kind of Reserve Prime
Redundancy is a specialization of reserve in which the maintained surplus takes the form of duplicated components that can substitute on failure.Redundancy is a specialization of reserve. The general reserve pattern is a deliberately maintained surplus of capacity beyond expected need, valuable precisely because available when demand exceeds expected. Redundancy specializes this by giving the surplus a particular form: duplicated components whose failure-independence allows any one to maintain function if others fail. The same hold-surplus-against-shock logic of reserve applies, with component duplication as the specific implementation and fault tolerance as the specific shock to absorb.
-
Redundancy decompose Self Checking Prime
Self-checking uses redundancy (the partially-independent path) and adds a comparator that extracts an error signal.After the systems_cybernetics frame is stripped away, the retained structural roles are those of Self Checking: A system detects errors in its own output by computing the answer through partially-independent paths and comparing. Redundancy adds the local frame and commitments expressed in its identity: Duplicate critical components. The parent pattern remains recognizable without that vocabulary, while the child is the framed realization of it. That preservation test establishes decomposition rather than taxonomic subsumption.
-
Redundancy decompose Two-Store Architecture Prime
Maintaining two oppositely-optimised persistent substrates presupposes redundancy (the duplicate path), adding a periodic transfer mechanism that consolidates rather than masks.After the systems_cybernetics frame is stripped away, the retained structural roles are those of Two-Store Architecture: A fast interference-prone store and a slow integrated store coupled by a periodic transfer mechanism, paying for both speed and integration by maintaining two oppositely-optimised substrates. Redundancy adds the local frame and commitments expressed in its identity: Duplicate critical components. The parent pattern remains recognizable without that vocabulary, while the child is the framed realization of it. That preservation test establishes decomposition rather than taxonomic subsumption.
Children (15) — more specific cases that build on this
-
Cylindrification Domain-specific is a kind of Redundancy
Redundancy is the proposed immediate parent.Projection, Alias-to-Authority Mapping, Embedding, Pairing, and Template Instantiation are related primes. The prospective queue contains one strict edge to
prime:redundancy. No live DAG mutation is authorized. -
Log shipping Domain-specific is a kind of Redundancy
The proposed strict upward parent is
prime:redundancy.prime:redundancy is the nearest broader Prime; the source domain and invariant supply the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Log shipping adds domain-specific constraints. The entry does not collapse into that parent because the domain-specific identity determined by the primary and standby share a continuous log chain, backups are copied and restored in sequence, lag is monitored, and failover and data-loss boundaries are explicit It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Log shipping. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge toprime:redundancy. No live DAG mutation is authorized. -
Oversampling Domain-specific is a kind of Redundancy
The proposed strict upward parent is
prime:redundancy.The candidate literally instantiates prime:redundancy; its signal_processing constraints provide the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Oversampling adds domain-specific constraints. The entry does not collapse into that parent because Sampling a signal substantially above its Nyquist rate to ease antialias filtering, distribute quantization noise and improve effective resolution after filtering or decimation It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Oversampling. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge toprime:redundancy. No live DAG mutation is authorized.
- Parvaresh–Vardy code Domain-specific is a kind of Redundancy
The proposed strict upward parent is `prime:redundancy`.The candidate literally instantiates prime:redundancy; its coding_theory constraints provide the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Parvaresh–Vardy code adds domain-specific constraints. The entry does not collapse into that parent because An algebraic error-correcting code that encodes correlated polynomial evaluations so received words can be efficiently list-decoded beyond the Reed–Solomon radius It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Parvaresh–Vardy code. This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge to `prime:redundancy`. No live DAG mutation is authorized.
- Polar code (coding theory) Domain-specific is a kind of Redundancy
The proposed strict upward parent is `prime:redundancy`.The candidate literally instantiates prime:redundancy; its coding_theory constraints provide the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Polar code (coding theory) adds domain-specific constraints. The entry does not collapse into that parent because A linear error-correcting code that recursively transforms channels into nearly perfect and nearly useless bit-channels, placing information only on the reliable ones It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Polar code (coding theory). This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge to `prime:redundancy`. No live DAG mutation is authorized.
- Redundancy (engineering) Domain-specific is a kind of Redundancy
The proposed strict upward parent is `prime:redundancy`.The candidate literally instantiates prime:redundancy; its systems_engineering constraints provide the residual. This is a proposal-only workspace relationship: the accepted Prime supplies a genuinely instantiated structural prerequisite or superclass, while Redundancy (engineering) adds domain-specific constraints. The entry does not collapse into that parent because Intentional duplication or diversification of components, information or functions so a system can tolerate failures or improve performance It also declines a nearby thematic catalog node: the neighbor does not literally subsume the constitutive identity of Redundancy (engineering). This explicit assert-and-decline pattern keeps the proposed DAG narrow and prevents a merely thematic edge. The prospective workspace queue contains one strict upward edge to `prime:redundancy`. No live DAG mutation is authorized.
- Defense In Depth Prime is a kind of, typical Redundancy
Defense in depth specializes redundancy: it layers barriers FOR failure ABSORPTION UNDER ATTACK, with INDEPENDENCE OF failure MODES load-bearing and an optimizing adversary seeking the correlated breach.Plain redundancy duplicates for reliability against RANDOM failure. 'defense in depth specifically denotes layering for failure absorption under attack' — the adversarial specialization of stacked-multiples. Redundancy supplies the genus: Duplicate critical components. Defense In Depth preserves that general structure while adding its differentia: Stacking multiple independent protective layers between threat and asset so that only a correlated breach across all layers produces total loss. The parent can occur without those added commitments, whereas removing the parent structure leaves no basis for classifying the child as this subtype. That asymmetry establishes subsumption rather than mere association. The typical qualifier limits the claim to the characteristic route, not a constitutive requirement of every instance; exceptions must retain the child's identity through another mechanism.
- Functional Redundancy (Degeneracy) Prime is a kind of Redundancy
Functional redundancy is a specialization of redundancy in which the duplicated elements are non-identical pathways that converge on the same function.Functional redundancy specializes redundancy by relaxing the duplicate-component constraint: instead of identical replicas, multiple non-identical mechanisms each suffice for the critical function, so the loss of any one leaves the function intact. Where redundancy names deliberate duplication for fault tolerance with independence of failure as the central design variable generally, functional redundancy specifies that the duplicates are structurally diverse pathways, which both reduces common-mode failures and broadens the operating envelope across conditions where any single mechanism might be impaired.
- CSS Code Domain-specific is part of Redundancy
logical information is distributed across more physical qubits.logical information is distributed across more physical qubits.
- Luby transform code Domain-specific presupposes Redundancy
**Redundancy** (`prime:redundancy`).Additional encoded symbols tolerate erasures without requiring specific packet identities. These are prose placement proposals only. They create no `dag_edges`; endpoint, redundancy, and cycle checks are recorded separately in the bundle's placement memo.
- Marine Protected Area Network Domain-specific is part of Redundancy
A marine protected area network contains deliberate replication against single-node failure.Without multiple independently exposed nodes carrying each habitat class, one storm, spill, or bleaching event can erase that habitat from the whole system and the fault-tolerance guarantee disappears.
- Swiss Cheese Model (Layered Defense with Aligning Holes) Prime presupposes Redundancy
The Swiss cheese model is 'redundancy WITH the independence assumption made explicit and challenged' — it foregrounds the hole-correlation structure redundancy buries.Presupposes stacked redundant layers; adds the decisive decorrelation variable. (defense_in_depth is the slogan it sharpens.). Redundancy supplies the prerequisite condition: Duplicate critical components. Swiss Cheese Model (Layered Defense with Aligning Holes) operates against that background: Catastrophe occurs only when a hazard finds a trajectory through a hole in every serial defensive layer at once, so the key variable is the correlation of holes across layers. If the parent condition is removed, the child relation becomes undefined or loses the mechanism asserted by this edge; the parent can obtain independently, so the relation is presupposition rather than subsumption.
- Perceivable Design Domain-specific is a decomposition of Redundancy
Perceivable Design is redundancy applied to essential signals so loss of one sensory channel does not eliminate the information.Stripping WCAG, captions, alt text, contrast, and human sensory vocabulary leaves multiple paths carrying the same critical signal so a single channel loss does not remove it; the domain child adds fidelity and accessibility obligations for human perception.
- Picture superiority effect Domain-specific is a decomposition of Redundancy
Stripping the human visual-verbal frame leaves Redundancy's independent-alternate-route structure: successful retrieval through either code is sufficient.A picture normally creates visual and verbal access routes whose union raises recall above a single verbal route. The child adds the human dual-code architecture, picture-versus-word contrast, and distinctiveness moderators; the surviving cross-substrate core is independent functional duplication.
- Parallel Independent Inspection Prime is a decomposition of Redundancy
Parallel independent inspection gains coverage by duplicating the inspection role across partially independent inspectors.After the operations_research frame is stripped away, the retained structural roles are those of Redundancy: Duplicate critical components. Parallel Independent Inspection adds the local frame and commitments expressed in its identity: Defect coverage of a fixed artifact rises with the number and diversity of independent inspectors working in overlapping parallel. The parent pattern remains recognizable without that vocabulary, while the child is the framed realization of it. That preservation test establishes decomposition rather than taxonomic subsumption.
Hierarchy paths (12) — routes to 8 parentless roots
- Redundancy → Reserve → Economy Of Force → Allocation → Scarcity → Constraint
- Redundancy → Self Checking
- Redundancy → Reserve → Mobilization → Latent Realizable Capacity
- Redundancy → Two-Store Architecture → Caching → Optimization
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Heavy-Tailed Distributions
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Recurrence
- Redundancy → Two-Store Architecture → Caching → Reserve → Mobilization → Latent Realizable Capacity
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Trade-offs → Constraint
- Redundancy → Two-Store Architecture → Caching → Reserve → Economy Of Force → Allocation → Scarcity → Constraint
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → Representation → Abstraction
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → State and State Transition → Phase Space
- Redundancy → Two-Store Architecture → Caching → Locality Of Reference → Spatial Indexing → Search and Retrieval → Problem Space → Problem Representation → Representation → Abstraction
Neighborhood in Abstraction Space¶
Redundancy sits in a moderately populated region (49th percentile for distinctiveness): it has near-neighbors but no dense thicket of synonyms.
Family — Unclustered & Miscellaneous (424 primes)
Nearest neighbors
- Fault Tolerance — 0.78
- Robustness — 0.72
- Concurrency — 0.71
- Interference and Contention — 0.71
- Eventual Consistency — 0.70
Computed from structural-signature embeddings · 2026-09-10
Not to Be Confused With¶
Redundancy must be distinguished from Robustness, its closest neighbor. Robustness is a system property—the capacity to withstand disturbance, variation, or failure without rupture—achieved through multiple mechanisms of which redundancy is only one. A robust system might use margin of safety (oversizing components to handle peak loads), redundancy (duplicating critical components), fail-safe design (routing failures to safe states), or a combination of all three. Redundancy is a specific mechanism; robustness is the emergent property. A system can be robust without redundancy (a bridge built with massive margin can tolerate unexpected load without redundancy) and redundant without robust (a system with duplicate faulty components can still fail catastrophically). The distinction matters because an engineer addressing a robustness gap might add redundancy, but equally might reduce component variation, redesign for graceful degradation, or add monitoring. Naming robustness without specifying the mechanism obscures the real design decision.
Nor is redundancy the same as Backup in the data-protection sense, though both involve duplication. Backup is post-failure recovery—preserving data so that if the primary system fails, information is not permanently lost; recovery is delayed and requires explicit restoration action. Redundancy is real-time operation—maintaining function through simultaneous, independent duplicate operation so that failure of any single copy does not interrupt service. An organization with a daily backup of critical databases has implemented backup but not redundancy; the organization loses a day of transactions if the primary database fails. An organization with active-active database replication across two sites has implemented redundancy; failover is automatic and typically sub-second, no transaction loss. The temporal difference is structural: backup trades RPO (recovery point objective, time since last backup) and RTO (recovery time objective, time to restore) for cost; redundancy trades hardware cost for zero RPO and zero RTO. A mature system often employs both: redundancy for real-time availability, backup for defense against operator error, data corruption, or correlated disaster.
Redundancy is also distinct from Margin of Safety (sometimes called Safety Factor), which provides design headroom beyond expected maximum demand. Margin provides robustness through over-capacity of a single component—a bridge designed to carry 1000 tons but expected to carry only 500 is using a 2× margin. Redundancy provides robustness through multiple independent components—a bridge with two parallel load-bearing structures, each capable of carrying the full 500-ton design load, is using redundancy. Both achieve robustness; the mechanisms differ. Margin concentrates capacity in one unit; redundancy distributes capacity across independent units. Margin is cost-effective when component failure is rare and predictable, allowing amortization of the oversizing cost; redundancy is cost-effective when failure is possible, independent failures across multiple units are much rarer than single-unit failure, and downtime or loss of service is catastrophically expensive. An aircraft engine is designed with margin (more thrust than needed in normal operation). Aircraft control surfaces use redundancy (multiple independent hydraulic systems, not one oversized system). The choice reflects the consequence of failure: engine thrust margin is acceptable; flight-control failure is not.
Finally, redundancy is distinct from Triangulation, though both rely on independence of sources. Triangulation aggregates independent sources to verify or estimate a target value—a surveyor uses multiple sight lines to verify a position; a climate scientist uses multiple proxy measurements to estimate historical temperature. The goal is accuracy of estimate through convergence. Redundancy duplicates components to maintain service if any one fails; the goal is service continuity despite failure. Triangulation asks "Do independent sources agree?" and uses agreement to calibrate accuracy; redundancy asks "Will service continue if one component fails?" and depends on that property to survive failure. They share the independence requirement (correlated measurement errors invalidate triangulation; correlated component failures invalidate redundancy), but apply it to different problems. A system can use both—redundant servers with triangulated health checks to decide which servers are healthy—but they remain structurally distinct.
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 (10)
- Common-Mode Failure Analysis: Identify shared dependencies that could cause supposedly independent backups or safeguards to fail together.▸ Mechanisms (9)
- Backup Independence Test — Exercises backup paths under a shared dependency outage or simulated common cause to verify whether they are genuinely independent.
- Common-Cause FMEA — Extends failure mode and effects analysis by asking which single causes could defeat multiple redundant elements or controls at once.
- Correlated Risk Register — Records shared exposures, affected redundant paths, severity, mitigation owner, test evidence, and residual risk acceptance.
- Credential and Infrastructure Dependency Audit — Checks whether backup systems, emergency roles, and alternate channels still depend on the same identity provider, network, power source, cloud region, or access authority.
- Dependency Mapping Workshop
- Diverse Vendor Review — Assesses whether vendor diversity is real across ownership, infrastructure, code lineage, hosting, support, credentials, and failure response capability.
- Fault Tree with Common-Cause Branching — Decomposes a top-level failure through logic gates to its basic causes, then adds shared-cause branches so a single event feeding several 'independent' paths becomes visible.
- Supply-Chain Dependency Review — Traces whether alternate suppliers, logistics routes, components, or raw materials share sub-tier vendors, regions, infrastructure, labor constraints, or regulatory chokepoints.
- Tabletop Cascade Exercise — Simulates a shared failure cause and asks how redundant paths, teams, authorities, and recovery plans respond when they are stressed together.
- Diverse Functional Redundancy: Provide multiple distinct ways to fulfill the same function so common-mode failure is less likely.▸ Mechanisms (10)
- Alternate Communication Channels — Maintains distinct channels such as SMS, radio, phone trees, email, in-person notice, or public posting so communication can continue when one medium fails.
- Cross-Training Program — Builds a second set of people who can perform an existing response, so the option survives the absence, overload, or departure of the one person who used to hold it.
- Diverse Data Source Triangulation — Combines independent data sources with different collection methods or bias profiles so the same informational function is not dependent on one fragile source.
- Diverse Implementation Voting — Compares outputs from independently designed implementations so one flawed implementation is less likely to determine the final result alone.
- Diverse Supplier Network — Uses suppliers with different geographies, ownership, logistics, technologies, or input sources to reduce correlated supply failure.
- Heterogeneous Technology Stack — Uses different technical implementations for critical capability so a single software defect, vendor outage, or platform assumption is less likely to disable all paths.
- Independent Safety System — Provides a separate safety path using different sensing, control, energy, or actuation logic so one design flaw or dependency is less likely to defeat all protection.
- Manual Fallback Workflow — Preserves a function through a human or paper-based process when the digital, automated, or centralized path is unavailable.
- Mixed-Channel Service Delivery — Offers the same service through different channels such as online, phone, physical office, outreach worker, kiosk, or partner organization.
- Multi-Modal Transport Plan — Uses different transport modes such as road, rail, air, water, walking, or cycling to preserve movement of people or goods when one mode is disrupted.
- Failover: Switch a protected function from a failed primary path to a prepared alternate so continuity is preserved.
- Layered Barrier Defense Architecture: Protect a critical asset by layering independent barriers, monitors, delays, and recovery backstops so loss requires multiple correlated failures rather than one breach.▸ Mechanisms (12)
- Backup Restore Drill — Proves the last-resort recovery layer actually works by restoring from it under realistic conditions — turning an assumed backstop into a tested one.
- Canary or Tripwire Asset — A deliberately planted decoy that only an intruder would touch, so that any interaction with it is a high-confidence sign the outer layers have already been crossed.
- Common-Mode Failure Probe — Deliberately fails a shared dependency to see how many 'independent' layers drop together — testing the independence the whole defense is betting on.
- Compensating Control Register — A living ledger of every place a required barrier is missing or weakened, the stand-in control put in its place, and the residual risk knowingly accepted — so gaps are owned, not forgotten.
- Intrusion or Anomaly Alerting — Watches the protected system's live signals for the signature or the statistical shadow of a breach, and turns a detection into a timed, routed response before loss completes.
- Layer Health Dashboard — A single at-a-glance view of whether each defensive layer is actually up, degraded, or down right now — so a silently failed barrier is seen before it's needed, not after.
- Layered Control Matrix — Lays every control against every threat pathway in a grid so open pathways, single points of coverage, and merely-redundant layers become visible at a glance.
- Multi-Factor Access Challenge — Guards a single access point by demanding several credentials of deliberately different kinds, so defeating one does not open the door.
- Network Segmentation Policy — Divides a network into isolated zones with only named, controlled crossings, so a breach in one segment cannot spread to the crown jewels.
- Physical Security Zoning — Arranges physical space into concentric graded zones so reaching the asset means passing successively harder, differently-guarded boundaries under lengthening exposure.
- Safety Interlock Chain — Wires several independent safety conditions to the hazard's energy source so that if any one is unmet, the system forces itself into a safe state without waiting for a human.
- Tabletop Breach Walkthrough — Gathers the real role-holders to talk through an escalating breach step by step, surfacing the seams between layers that only appear when the defense is exercised as a whole.
- Layered Defense Gap Decorrelation: Treat every defense layer as imperfect, then prevent catastrophe by finding and breaking the cross-layer alignment of its holes.▸ Mechanisms (8)
- Aligned Gap Heatmap — Renders the cross-layer gap matrix as a color-graded grid so the hazard paths where holes line up across every layer light up at a glance — and trip a stop threshold when they do.
- Barrier Gap Walkthrough — Leaves the desk to inspect each barrier where it actually operates, replacing hypothesized holes with the real exceptions, bypasses, and named owners found on the floor.
- Bowtie Analysis with Layer Gaps — Diagrams preventive and recovery barriers on either side of a single top event and draws each barrier as a holed slice rather than a solid block, exposing where a threat could pass through.
- Common-Cause Layer Audit — Hunts on paper for the shared vendor, feed, power source, or credential that secretly couples defensive layers the organization treats as independent.
- Independent Barrier Test Drill — Deliberately disables one barrier under controlled conditions to test whether a supposedly independent backup actually holds — and scores how healthy it really was.
- Latent Condition Rounds — Recurring scheduled rounds that watch defensive holes drift — widening, moving, or synchronizing — and trip a stop threshold before the drift lines them up into a path.
- Near-Miss Trajectory Review — Reconstructs the path each real near-miss actually took through the layers and treats it as hard evidence that holes are already starting to align.
- Swiss-Cheese Barrier Review — Walks one hazard through the whole defensive stack at a table, asking layer by layer where the same scenario could slip through — the fast first screen for aligned holes.
- Multi-Scale Resilience Architecture: Design resilience at multiple scales so local failures are absorbed without sacrificing subsystem or whole-system continuity.▸ Mechanisms (9)
- Community / Regional / National Resilience Layers — Assigns resilience roles across three standing civic tiers — community, region, nation — so immediate function, surge coordination, and strategic reserves each have a designated owner.
- Cross-Scale Buffering Playbook — A standing operating rulebook for where buffers sit, when they release, and how depletion is read as a system signal before it cascades across scale boundaries.
- Distributed Infrastructure Resilience — A live technical architecture that isolates faults into small blast radii, fails traffic over to healthy capacity automatically, and sheds load to a defined floor rather than going dark.
- Ecological Resilience Design — Arranges habitat, corridors, refugia, and disturbance regimes across spatial scales so ecological function persists through disturbance and recolonizes from what survived.
- Local Recovery Plus Central Support — An operating model in which local actors hold recovery authority and act on context, while the center supplies resources and legitimacy without taking over.
- Multi-Level Redundancy Design — A design pattern that places backups at more than one scale and proves they fail differently, so no single common cause can take the primary and all its spares together.
- Nested Resilience Planning — A design-time planning method that writes interlocking plans across scales, so each level knows in advance what it absorbs, when it escalates, and who decides.
- Organizational Resilience Tiers — An internal org design that gives each tier — team, department, enterprise — a defined service floor, its own recovery authority, and monitoring for burnout and hidden recovery debt.
- Tiered Incident Command — A run-time coordination protocol that escalates an incident across scales, transfers command explicitly at each step, and drives the live recovery until authority returns downward.
- Parallel Independent Inspection Design: Find more hidden defects by having multiple independent and diverse inspectors examine overlapping parts of the same artifact before their findings are reconciled.▸ Mechanisms (10)
- Blind Document Proofing Passes — Splits a locked document among proofers who each hunt one class of defect blind, so no single reader's fatigue or reading-for-meaning hides a whole category of error.
- Capture-Recapture Defect Estimation — Estimates how many defects remain unfound by treating the overlap between two independent inspection passes as a mark-recapture sample.
- Dual or Triple Diagnostic Read — Has a fixed few equally qualified readers each inspect the whole artifact blind, then routes every disagreement to a designated arbiter.
- Finding Reconciliation Board — The post-discovery workflow that deduplicates, adjudicates, severity-triages, and routes independent findings while keeping minority signals alive until resolved.
- Independent Checklist Variant Rounds — Runs the same artifact through different checklist variants across rotated rounds so reviewers don't all walk the same mental path into the same blind spot.
- Independent Security Review Lenses — Inspects one system through several specialist lenses at once — threat, dependency, configuration, access — so different classes of flaw are found by the reviewer trained to see them.
- Multi-Inspector Manufacturing Sort — Routes critical production units through more than one technician with risk-weighted overlap, pulling and re-verifying nonconformities and feeding field escapes back.
- Overlap Heatmap — A per-region view of how many independent inspectors flagged each part of an artifact, making saturated zones and lonely minority findings visible at a glance.
- Parallel Code Review Round — Multiple maintainers independently review the same version-locked change before comments are merged, so a bug one reviewer misses another can still catch.
- Seeded Defect Calibration Exercise — Plants known defects into the inspection stream to measure each inspector's catch rate and calibrate how much the process is really finding.
- Path Redundancy Provisioning: Create multiple viable paths so flow or connection can continue when one path is blocked, degraded, or unavailable.▸ Mechanisms (10)
- Alternate Supplier Route — Qualifies a second route, logistics provider, or supply path so critical inputs can still reach the system if the main route is blocked.
- Backup Route Plan — Predefines alternate physical, procedural, or organizational routes for movement, access, approval, or evacuation.
- Dual-Homing — Connects a node to two upstream paths or providers so the node is not isolated by a single upstream failure.
- Multi-Channel Communication — Maintains more than one viable channel for reaching people or systems, especially when one channel may be unavailable during disruption.
- Out-of-Band Channel — Provides a separate channel for control, diagnosis, or emergency coordination that does not depend on the ordinary communication path.
- Parallel Service Path — Creates more than one way for users, patients, clients, or incidents to reach the same service outcome.
- Path Readiness Drill — Exercises alternate paths under realistic conditions to reveal stale configurations, missing permissions, insufficient capacity, or confused ownership.
- Redundant Escalation Path — Ensures that support, authority, review, or safety reporting can proceed if the normal chain is unavailable, conflicted, overloaded, or unsafe.
- Redundant Network Link — A standing parallel link that carries no unique load until a primary path is cut, congested, or misconfigured — then it keeps the two sides connected without interruption.
- Standby Transport Corridor — Keeps a pre-qualified alternate route between the reserve and the fronts continuously ready and health-checked, so a redeployment can still complete inside its window when the primary path fails.
- Redundant Backup Provisioning: Provision duplicate capacity or components so failure of one does not eliminate critical function.▸ Mechanisms (10)
- Backup Power System — Provides alternate electrical capacity for critical functions when the primary power source fails.
- Backup Restore Drill — Proves the last-resort recovery layer actually works by restoring from it under realistic conditions — turning an assumed backstop into a tested one.
- Backup Supplier Contract — Maintains an alternate source for critical inputs when the primary supplier cannot deliver.
- Deputy Role Assignment — Names a prepared alternate actor who can perform a critical responsibility when the primary actor is absent or impaired.
- Emergency Reserve Stock — Stores critical materials, funds, equipment, or supplies for use when ordinary supply is interrupted.
- N+1 Redundancy Rule — Sizes redundancy by provisioning one spare unit beyond the number needed to carry peak load, so any single unit can fail without dropping the function below its requirement.
- Redundant Server — Duplicates computing capacity so a service, application, or data function can continue after one server fails.
- Replicated Record Store — Keeps the same records on multiple independently-writable replicas so every site stays available locally — the substrate the whole convergence process runs on.
- Spare Part Stock — Keeps replacement parts available so a failed physical component can be replaced without waiting for external procurement.
- Standby Team Roster — Keeps a prepared group available to cover a critical operation during absence, overload, or incident response.
- Specialization Boundary and Reintegration Design: Improve efficiency by narrowing roles or niches only where the gains exceed the coordination, brittleness, learning, and reintegration costs.▸ Mechanisms (11)
- Bus Factor Review — Finds every capability that rides on one irreplaceable person and turns each into a funded plan for redundancy before that person walks.
- Coordination Cost Accounting — Puts a running price on the meetings, handoffs, waiting, and rework that dividing work creates, so the coordination tax can be weighed against the specialization gains.
- Dependency Heatmap — Renders every specialty's dependencies on one colour-graded grid so single-source chokepoints and lock-in glow before they fail.
- Handoff Contract Template — Turns each handoff between specialties into an explicit, testable contract — inputs, acceptance criteria, owners, and what to do when something doesn't fit.
- Integrator Role Assignment — Names one person or team accountable for the whole — with the standing to force the specialized parts to add up to something coherent.
- Over-Specialization Audit — Asks whether roles have been sliced too thin, measuring specialization intensity and the entrenched status it breeds against the flexibility being lost.
- Role & Niche Charter — A short standing charter that equips one specialist niche — the capabilities it needs, the tools it may run, and where out-of-scope work goes — so the role is legible and its edges are handled.
- Role Recomposition Trigger Review — A standing review that watches a small set of pre-committed triggers — demand shift, chronic bottleneck, local metrics drifting from global ones — and fires when a specialization has outlived its fit and should be recomposed.
- Rotation & Cross-Training Schedule — A standing schedule that rotates people through adjacent specialties and cross-trains them, deliberately spending some depth to buy redundancy and keep the workforce mix broad enough to recombine.
- Specialist-Generalist Portfolio Review — A periodic review of the whole workforce as a portfolio — how intensely specialised it has become and how status and power have concentrated across niches — to judge whether the balance still fits demand.
- Specialization Boundary Workshop — A facilitated session where a group maps the whole space of tasks and collectively decides where the specialization lines should fall — before anyone is slotted into a niche.
Also a related prime in 37 archetypes
- 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.
- Adaptive Barrier-Circumvention Response: Treat a successful barrier as a changing selection environment: monitor which variants survive, then renew and diversify protection before uncovered survivors become the population.
- Artificial Diversity Introduction During Homogenization Pressure: When a system is being driven toward sameness, deliberately seed, protect, or recover distinct options so adaptive capacity, resilience, and representational breadth do not collapse.
- Assumption-Bounded Distributed Agreement: Make distributed agreement achievable by declaring the fault, timing, membership, and validity model, preserving safety when progress is uncertain, and using only decision evidence that is valid under those assumptions.
- Black-Swan Preparedness: Prepare for consequential surprise by protecting survival floors, reducing concentrated exposure, preserving slack and options, limiting cascades, enabling bounded improvisation, and rebuilding adaptively without pretending to predict the unknown event.
- Checkpoint and Rollback: Save recoverable states before risky change so the system can return to a known-good condition if the change fails.
- Convex Exposure Gain Design: Design the system so bounded exposure to volatility has capped downside, measurable upside, and a pathway that converts stress into durable capability.
- Correlation Structure Analysis for Pooling Effectiveness: Measure how pooled risks co-move before assuming that a larger pool diversifies loss.
- Dependency Concentration Control: Prevent dependency fragility by measuring where reliance is concentrated and capping, diversifying, or isolating overweight dependency providers before their failure can dominate the system.
- Dependency Exposure: Reveal hidden dependencies so risks, obligations, failure paths, and coordination needs become visible before they cause failure.
Notes¶
Core member of the robustness-design quadrilateral alongside robustness (#282), fail_safe (#284), and margin_of_safety (#283). Shannon's information-theoretic redundancy (channel coding) and engineering redundancy (component duplication) are structurally parallel realizations of the same abstraction in different substrates. Related to triangulation (#281) via the shared independence-of-sources requirement, despite serving different purposes. Tight-paired with robustness (#282) and adaptive_capacity (#404)—redundancy is a key structural mechanism enabling both properties.
References¶
[1] von Neumann, J. (1956). Probabilistic logics and the synthesis of reliable organisms from unreliable components. In C. E. Shannon & J. McCarthy (Eds.), Automata studies (pp. 43–98). Princeton: Princeton University Press. von Neumann deliberate duplication fault-tolerance. registry ↩
[2] Avizienis, A., Laprie, J.-C., Randell, B., & Landwehr, C. (2004). Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 11–33. Authoritative taxonomy of dependability that formalizes common-cause and common-mode failures as the dominant threat to redundant systems and frames redundancy engineering as failure-mode decorrelation. registry ↩a ↩b
[3] Hamming, R. W. (1950). Error detecting and error correcting codes. Bell System Technical Journal, 29(2), 147–160. Hamming exponential failure probability independence. registry ↩
[4] Edelman, G. M., & Gally, J. A. (2001). Degeneracy and complexity in biological systems. Proceedings of the National Academy of Sciences, 98(13), 7280–7285. Canonical statement of degeneracy: structurally different elements that can perform the same function and different functions in different contexts; argued to be a universal biological property underlying both robustness and evolvability. registry ↩
[5] Tononi, G., Sporns, O., & Edelman, G. M. (1999). Measures of degeneracy and redundancy in biological networks. Proceedings of the National Academy of Sciences, 96(6), 3257–3262. Tononi data backup post-incident recovery. registry ↩
[6] Stark, A. Y., Behrens, S. H., & Russell, G. F. (2003). Distributed redundancy in biological systems. Nature Reviews Genetics, 4(11), 907–918. Stark correlated failures insurance limitations. withdrawn registry ↩
[7] Lala, J. H., & Harper, R. E. (1994). Architectural principles for safety-critical real-time applications. Proceedings of the IEEE, 82(1), 86–102. Lala-Harper aerospace flight control redundancy. registry ↩a ↩b
[8] Lamport, L. (1998). The part-time parliament. ACM Transactions on Computer Systems, 16(2), 133–169. Paxos consensus correlated-failure coverage. registry ↩
[9] Boeing Commercial Airplanes. (2000). 777 airplane characteristics for airport planning (Doc. No. D6-58326-1). Boeing. Boeing 777 triple-triple flight control redundancy. registry ↩
[10] Ongaro, D., & Ousterhout, J. (2014). In search of an understandable consensus algorithm. In Proceedings of the 2014 USENIX Annual Technical Conference (pp. 305–320). Raft safety-critical computing domains. registry ↩
[11] Corbett, J. C., Dean, J., Epstein, E., et al. (2013). Spanner: Google's globally-distributed database. In Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation (pp. 251–264). Google Spanner global payment service redundancy. registry ↩
[12] Amazon Web Services. (2020). AWS Global Infrastructure. Retrieved from https://aws.amazon.com/about-aws/global-infrastructure/ AWS multi-region redundancy automated failover. registry ↩
[13] Moeckel, M., & Braun, T. (2019). Analyzing multi-CDN diversity for resilient content delivery. In 2019 IEEE 44th Conference on Local Computer Networks (LCN) (pp. 176–184). IEEE. DNS provider diversity correlated-failure elimination. withdrawn registry ↩
[14] Shannon, C. E. (1948). "A mathematical theory of communication." The Bell System Technical Journal, 27(3), 379–423. registry
[15] 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. registry
[16] Pacioli, L. (1494). Summa de arithmetica, geometria, proportioni et proportionalita [Summary of Arithmetic, Geometry, Proportions and Proportionality]. Paganinus de Paganinis. registry
[17] Bonwick, J., Ahrens, M., Henson, V., Maybee, M., & Shellenbaum, M. (2005). "ZFS: The Last Word in Filesystems." Whitepaper. registry
[18] Codd, E. F. (1970). "A relational model of data for large shared data banks." Communications of the ACM, 13(6), 377–387. registry
[19] Merkle, R. C. (1987). "A digital signature based on a conventional encryption function." In Advances in Cryptology — CRYPTO '87. registry
[20] National Institute of Standards and Technology. (2015). "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions." NIST FIPS 202. registry
[21] Reed, I. S., & Solomon, G. (1960). Polynomial codes over certain finite fields. Journal of the Society for Industrial and Applied Mathematics, 8(2), 300–304. Reed-Solomon distributed localized redundancy structure. registry