Fault Tolerant Distributed Consensus

Declare the fault and timing model, preserve agreement and validity with intersecting evidence, and pursue termination only under assumptions that make progress possible.

Version

v1 · 2026-08-24 · History

Solution archetype #

438

Problem family

Coordination, Dependency & Sequencing Failure

Problem subfamily

Concurrent Shared-State Consistency

Essence

Fault-Tolerant Distributed Consensus is the reusable solution pattern for making one authoritative decision—or one authoritative order of decisions—when no participant has a complete view, communication is uncertain, and some participants may fail. The pattern begins with a model, not a named algorithm. It states who participates, what counts as the same value, which faults are tolerated, how messages and clocks may behave, which properties must never be violated, and under what eventual conditions progress is expected.

The pattern then creates durable, intersecting evidence. A participant's vote constrains its future behavior; a decision certificate proves that a sufficiently overlapping set accepted one safe value; terms or ballots fence stale coordinators; and recovery carries accepted evidence forward. Agreement and validity remain unconditional within the model. Termination is conditional on adequate connectivity, eventual timing behavior, fair scheduling, randomness, or another declared progress assumption.

This is not a generic metaphor for teamwork. Its result is machine-verifiable authority under a fault model. Human consensus processes may choose the requirements, operators, or membership, but they do not replace quorum intersection, persistent votes, or a liveness argument.

Compression statement

Fault-Tolerant Distributed Consensus turns independent proposals and partial observations into a single certified decision by fixing the value domain, participants, membership epoch, fault threshold, timing assumptions, and safety/liveness properties; collecting votes whose quorums must intersect in at least one trustworthy witness; persisting enough evidence to prevent conflicting decisions across retries and leadership changes; and separating always-required safety from conditional progress. It reconfigures or stops when the declared model no longer supports a valid guarantee.

Canonical formula: fixed(epoch, members, value_domain, validity, fault_model, timing_model); require agreement AND validity always; decide(v) only with a durable certificate whose quorum intersects every conflicting quorum in more correct witnesses than the fault model can corrupt; guarantee termination only when the declared progress assumptions hold.

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Diagnostic problem

Multiple independently failing participants must expose one authoritative value or ordered history, yet messages can be delayed, duplicated, reordered, lost, or forged; processes can crash, recover, or equivocate; and no participant has complete knowledge of the others' state. Local acceptance can therefore create split decisions, stale leaders, divergent logs, double execution, or indefinite waiting unless the protocol binds safety evidence, persistence, membership, and progress assumptions together.

What this problem means

Distributed participants act from local state. A message that has not arrived gives no definitive
information about whether its sender is slow, isolated, overloaded, crashed, recovering, or
malicious. Two partitions can each observe internally coherent evidence and still disagree about
which coordinator is current. A recovering node can forget a promise unless it was made durable.
A leader can expose an external effect before the system has enough evidence to prevent a rival
leader from exposing the opposite effect.

The hardest problem is not collecting many affirmative responses. It is ensuring that every set
of responses capable of deciding intersects every conflicting deciding set in enough trustworthy
participants that conflicting certificates cannot both form. Under crash faults this often means
majority intersection; under Byzantine faults it requires larger quorums and authentication so the
intersection contains sufficient correct witnesses despite equivocation. Weighted membership,
joint reconfiguration, flexible quorums, and failure domains change the arithmetic but not the
obligation to prove it.

Safety and liveness must be separated. Safety says that nothing contradictory happens: correct
participants do not decide different values and invalid values cannot be certified. Liveness says
that something eventually happens. A system can preserve safety indefinitely by refusing all
progress. Conversely, it can appear highly available by letting disjoint partitions decide, but
then it no longer provides consensus. A mature design documents exactly where it sits in that
tradeoff and what conditions authorize progress.

Applicability expression6 distinct conditions

Multiple decision proposersandDivergent decisions unsafeandIndependent participant failuresandDurable decision across recoveryandPartition consistency tradeoffandDynamic membership continuity

Algebraic1∧2∧3∧4∧5∧6

5=a∨(b∧b′)∨(c∧c′)∨d∨e

′ context guard? connective not recorded∅ no catalog witness yet

groundedpartly groundedopen

6 conditions, all required.

6Required in every casenumbered 1–6

These hold no matter which pattern applies.

1

Multiple decision proposers · grounded

Two or more participants can propose or acknowledge values for one logical decision. more

primeConsensus— Producing a single shared decided state from many participants with disagreeing or adversarial views, under a fault model, satisfying agreement, validity, and termination together.

and — also required

2

Divergent decisions unsafe · grounded

Two correct participants deciding differently would violate correctness or external safety. more

primeConsensus— Producing a single shared decided state from many participants with disagreeing or adversarial views, under a fault model, satisfying agreement, validity, and termination together.

and — also required

3

Independent participant failures · open

Participants or communication paths can fail independently during the decision. more

and — also required

4

Durable decision across recovery · open

The decision must persist across retry, leadership change, or recovery. more

and — also required

5

Partition consistency tradeoff · grounded · any one of 5

Availability must be traded explicitly against consistency during partitions. more

a

domainCAP Theorem— A distributed data store cannot guarantee consistency and availability at once during a network partition, and since real networks always partition, the architect must choose which to sacrifice when one strikes.

or — any one of these establishes this case

b

domainStrong Consistency— Guarantee that every read of a replicated store reflects the most recently completed write and all clients see one real-time-consistent total order (linearizability), so the system can be reasoned about as a single copy — bought with a coordination round and partition-time unavailability.

AND both parts required

context guardThe architecture decision explicitly selects the strong-consistency posture for partition operation.

suppliesThe tradeoff must be made explicitly.

or — any one of these establishes this case

c

domainSplit-Brain Problem— The distributed-systems failure where a network partition splits a replicated cluster into subsets that each elect themselves as write authority and accept divergent writes; guard against it by enforcing that at most one subset — the quorum majority — may write.

AND both parts required

context guardThe partition-time availability-versus-consistency posture is explicitly chosen rather than left implicit in failover behavior.

suppliesThe tradeoff must be made explicitly.

or — any one of these establishes this case

d

domainPACELC Theorem— Classify a replicated data system by two regime-dependent trade-offs — availability vs. consistency under Partition, and Else (normal operation) latency vs. consistency — into a four-letter posture from which its workload behaviour reads directly.

or — any one of these establishes this case

e

domainCAP Theorem (and variants)— Characterize any replicated data store by its coordinates on a small set of axes — the forced C-versus-A choice under partition, PACELC's latency-versus-consistency choice at rest, plus granularity dials and the CRDT merge-algebra escape.

How this was matched — 5 requirements, all needed

A partition requires an explicit tradeoff between availability and consistency.

All of

• roleAvailability and consistency are distinct system guarantees whose simultaneous satisfaction is at issue.
• relationThe system trades availability against consistency.
• comparisonGaining or preserving one guarantee is evaluated against loss or weakening of the other.
• modalityThe tradeoff must be made explicitly.
• timingThe tradeoff is required during a partition.

and — also required

6

Dynamic membership continuity · open

Membership can change while earlier votes or log entries remain valid evidence. more

Coverage

3 of 6 conditions grounded · 3 open.

Read the methodology · Download the trigger-logic data

When to Use This Archetype

Use this archetype when conflicting local decisions would be unsafe and authority must survive participant failure: configuration stores, replicated databases, lock and lease services, metadata control planes, leader election, ordered command processors, membership services, replicated safety controllers, and permissioned adversarial networks.

Do not apply consensus reflexively. If one durable authority is acceptable, primary/backup replication with explicit failover may suffice, though failover itself often needs fencing. If concurrent updates commute and can merge, conflict-free replication may preserve more availability. If the task is atomic effects across services, transaction coordination is the broader lifecycle. If the task is agreement among people, use deliberative governance structures.

Structural Problem

Distributed participants act from local state. A message that has not arrived gives no definitive information about whether its sender is slow, isolated, overloaded, crashed, recovering, or malicious. Two partitions can each observe internally coherent evidence and still disagree about which coordinator is current. A recovering node can forget a promise unless it was made durable. A leader can expose an external effect before the system has enough evidence to prevent a rival leader from exposing the opposite effect.

The hardest problem is not collecting many affirmative responses. It is ensuring that every set of responses capable of deciding intersects every conflicting deciding set in enough trustworthy participants that conflicting certificates cannot both form. Under crash faults this often means majority intersection; under Byzantine faults it requires larger quorums and authentication so the intersection contains sufficient correct witnesses despite equivocation. Weighted membership, joint reconfiguration, flexible quorums, and failure domains change the arithmetic but not the obligation to prove it.

Safety and liveness must be separated. Safety says that nothing contradictory happens: correct participants do not decide different values and invalid values cannot be certified. Liveness says that something eventually happens. A system can preserve safety indefinitely by refusing all progress. Conversely, it can appear highly available by letting disjoint partitions decide, but then it no longer provides consensus. A mature design documents exactly where it sits in that tradeoff and what conditions authorize progress.

Intervention Logic

First define one consensus instance. Give it an unambiguous identity, value domain, equality rule, validity predicate, and external effect boundary. If consensus orders a log, define each index and how gaps, prefixes, snapshots, and client retries behave. If it elects a leader or chooses a configuration, define when that choice becomes effective and how stale authority is fenced.

Second declare participants and system assumptions. Distinguish voters from learners, clients, observers, and recovery agents. State the maximum number or weight of crash, omission, recovery, or Byzantine faults. State whether channels authenticate identity and whether communication is asynchronous, partially synchronous, synchronous, or probabilistically scheduled. Place replicas across actual failure domains so a logical threshold is not defeated by shared infrastructure.

Third derive safety evidence. Specify the promises a voter makes, when those promises become durable, the allowed sequence of ballots or phases, the quorum sets, and the intersection proof. A new coordinator must collect enough prior evidence to choose a value that cannot conflict with anything already chosen. A learner must validate a portable certificate rather than trust the coordinator's assertion.

Fourth engineer conditional progress. Timeouts and heartbeats may initiate a new ballot or leader election, but they never prove a safety fact. Backoff reduces synchronized contention. Randomization can break an adversarial schedule. Operational controls detect when a quorum is unreachable or term churn prevents useful work. When assumptions fail, the system narrows availability, enters a safe read-only mode, or requires governed recovery rather than inventing authority.

Finally, connect decision to effect. Apply the decided command deterministically, retain stable client identifiers, deduplicate retries, record the result, and make snapshot or compaction rules preserve the proof needed for future recovery. Consensus without safe application can still produce duplicate payments, non-deterministic replica state, or irreversible actions before finality.

Decision Rules

1. Fix the instance, epoch, participant set, fault threshold, and validity predicate before counting votes.
2. Require every binding vote to name its signer, instance, membership epoch, ballot or term, phase, and value digest.
3. Reject duplicate identities, stale epochs, invalid values, impossible phase transitions, and unverifiable signatures.
4. Persist promises and accepted votes before acknowledging them when future safety depends on memory.
5. Decide only from a certificate satisfying the declared quorum predicate and intersection proof.
6. On leadership change, adopt the value required by the highest safe prior evidence; do not choose freely.
7. Use timeouts to initiate progress actions, never to infer that conflicting evidence cannot exist.
8. Separate commit from external application and make application deterministic and retry-safe.
9. Change membership through an overlap-preserving transition with an explicit completion certificate.
10. Suspend unsafe writes when the observed membership, identity, storage, or communication model exceeds the declared bound.
11. Preserve audit evidence for every exceptional recovery, forced removal, or operator-issued epoch.
12. Revalidate invariants after protocol, storage, topology, membership, or timeout changes.

Key Components

Component	Description
Decision Value Domain ↗	{"role_in_archetypes":"Fixes the semantic object over which agreement and validity are claimed.","typical_position":"boundary","required_properties":["versioned encoding","deterministic equality","unique instance identity","explicit effect meaning"],"variation_dimensions":["single value or log command","semantic or byte equality","deterministic or probabilistic finality"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"decision_value_domain","name":"Decision Value Domain","aliases":["consensus_value_space"]},"classification":{"component_type":"boundary","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Defines legal values, equality, encoding, instance identity, and external meaning for one consensus decision.","expanded_definition":"Makes every participant evaluate the same decision object and prevents two encodings, versions, or contexts from being mistaken as the same or different value. It includes the relationship between a certified value and any externally applied effect.","what_it_is_not":["It is not the proposal-selection algorithm.","It is not an unrestricted application payload."]},"structural_role":{"role_in_archetypes":"Fixes the semantic object over which agreement and validity are claimed.","typical_position":"boundary","required_properties":["versioned encoding","deterministic equality","unique instance identity","explicit effect meaning"],"variation_dimensions":["single value or log command","semantic or byte equality","deterministic or probabilistic finality"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required semantic boundary"}],"compatible_components":["proposal_validity_rule","safety_property_specification","protocol_phase_and_message_state"],"incompatible_or_confusing_components":["unversioned_payload","local_implicit_equality"],"selection_notes":"Reconcile with existing value-domain components before catalog insertion.","validation_questions":["Can all voters compute the same identity and equality?","Is reuse of an instance identifier impossible?","Is the external effect tied to the certified value?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["proposal_validity_rule"],"related_mechanisms":["authenticated_vote_certificate","deterministic_state_machine_application"]},"examples":{"examples":[{"domain":"replicated_database","example":"A command plus client sequence number at one log index."},{"domain":"leader_election","example":"One candidate identity for a named term."}],"non_examples":["A mutable object interpreted differently by each replica."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","reconcile_against_existing_component_index"],"notes":"Extracted from the q6 full draft; no catalog mutation performed."}}
Participant and Role Registry ↗	{"role_in_archetypes":"Establishes who can create, verify, learn, apply, or repair consensus evidence.","typical_position":"input","required_properties":["unique identity","authenticated role","explicit permissions","auditable authority"],"variation_dimensions":["equal or weighted voters","trusted or adversarial identity","static or governed enrollment"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"participant_and_role_registry","name":"Participant and Role Registry","aliases":["consensus_role_registry"]},"classification":{"component_type":"actor_or_role","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Names eligible voters, learners, proposers, clients, observers, and recovery authorities.","expanded_definition":"Binds identity to voting eligibility and role permissions so certificates cannot count duplicate, stale, or unauthorized participants.","what_it_is_not":["It is not the current membership epoch by itself.","It is not a contact list."]},"structural_role":{"role_in_archetypes":"Establishes who can create, verify, learn, apply, or repair consensus evidence.","typical_position":"input","required_properties":["unique identity","authenticated role","explicit permissions","auditable authority"],"variation_dimensions":["equal or weighted voters","trusted or adversarial identity","static or governed enrollment"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required participant boundary"}],"compatible_components":["membership_configuration","fault_and_network_model","quorum_and_intersection_policy"],"incompatible_or_confusing_components":["unauthenticated_node_count"],"selection_notes":"Use wherever a distributed proof depends on identity-specific participation.","validation_questions":["Can one actor appear under multiple counted identities?","Who may add or remove a voter?","Are learner and voter permissions distinct?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["membership_configuration"],"related_mechanisms":["authenticated_vote_certificate"]},"examples":{"examples":[{"domain":"coordination_service","example":"Five voters and any number of nonvoting learners."}],"non_examples":["Counting all currently connected sockets as voters."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","identity_governance_review"],"notes":"Reconcile exact and near-equivalent registry components."}}
Fault and Network Model ↗	{"role_in_archetypes":"Grounds every safety threshold, liveness claim, and breach response.","typical_position":"condition","required_properties":["fault semantics","maximum faulty count or weight","timing model","channel properties","correlation boundary"],"variation_dimensions":["crash or Byzantine","asynchronous or partially synchronous","count or weight"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"fault_and_network_model","name":"Fault and Network Model","aliases":["system_assumption_model"]},"classification":{"component_type":"condition","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Declares tolerated faults, threshold, communication behavior, authentication, and timing assumptions.","expanded_definition":"Supplies the assumptions from which quorum safety and progress can be derived. It distinguishes crash, recovery, omission, partition, equivocation, correlated failure, and timing behavior rather than treating “distributed” as a sufficient specification.","what_it_is_not":["It is not an observed availability metric.","It is not a promise that assumptions always hold."]},"structural_role":{"role_in_archetypes":"Grounds every safety threshold, liveness claim, and breach response.","typical_position":"condition","required_properties":["fault semantics","maximum faulty count or weight","timing model","channel properties","correlation boundary"],"variation_dimensions":["crash or Byzantine","asynchronous or partially synchronous","count or weight"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required guarantee basis"}],"compatible_components":["quorum_and_intersection_policy","liveness_property_specification","membership_configuration"],"incompatible_or_confusing_components":["timeout_as_failure_proof","undocumented_independence_assumption"],"selection_notes":"Revisit whenever topology, identity, storage, or administration changes.","validation_questions":["What exact fault bound is tolerated?","Which liveness assumption eventually holds?","Are correlated failures represented?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["safety_property_specification","liveness_property_specification"],"related_mechanisms":["crash_fault_quorum_protocol","byzantine_fault_quorum_protocol"]},"examples":{"examples":[{"domain":"crash_fault_service","example":"Up to two of five voters unavailable with eventual bounded delay."}],"non_examples":["The network is reliable enough."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","distributed_systems_review"],"notes":"High-impact component requiring specialist review."}}
Safety Property Specification ↗	{"role_in_archetypes":"Defines invariant claims that protocol phases, storage, recovery, and application must preserve.","typical_position":"guardrail","required_properties":["agreement","validity","integrity","durability","scope by instance and epoch"],"variation_dimensions":["single decree or log","crash or Byzantine","deterministic or probabilistic claim"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"safety_property_specification","name":"Safety Property Specification","aliases":["consensus_safety_contract"]},"classification":{"component_type":"invariant","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"States agreement, integrity, validity, durability, ordering, and fencing obligations that must never be violated within the model.","expanded_definition":"Separates forbidden states from eventual progress so temporary unavailability cannot be used to excuse conflicting decisions.","what_it_is_not":["It is not a latency objective.","It is not the proof or implementation itself."]},"structural_role":{"role_in_archetypes":"Defines invariant claims that protocol phases, storage, recovery, and application must preserve.","typical_position":"guardrail","required_properties":["agreement","validity","integrity","durability","scope by instance and epoch"],"variation_dimensions":["single decree or log","crash or Byzantine","deterministic or probabilistic claim"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required invariant contract"}],"compatible_components":["fault_and_network_model","quorum_and_intersection_policy","durable_decision_evidence_log"],"incompatible_or_confusing_components":["best_effort_consistency_statement"],"selection_notes":"Write properties in independently testable or model-checkable form.","validation_questions":["Can two correct learners decide differently?","Can an invalid proposal be certified?","Does recovery preserve the claim?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["liveness_property_specification"],"related_mechanisms":["consensus_safety_model_check"]},"examples":{"examples":[{"domain":"replicated_log","example":"No two committed entries differ at the same index."}],"non_examples":["Replicas usually agree after a while."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","formal_property_review"],"notes":"Validate against protocol-specific property vocabulary."}}
Liveness Property Specification ↗	{"role_in_archetypes":"Makes progress claims falsifiable and exposes when safe suspension is expected.","typical_position":"criterion","required_properties":["trigger conditions","eventual assumptions","progress measure","suspension conditions"],"variation_dimensions":["deterministic or probabilistic","bounded latency or eventual termination","client or system perspective"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"liveness_property_specification","name":"Liveness Property Specification","aliases":["consensus_progress_contract"]},"classification":{"component_type":"criterion","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"States termination and availability conditions independently from safety.","expanded_definition":"Names the eventual synchrony, connectivity, scheduling, fairness, randomness, quorum, and resource conditions under which a valid proposal reaches decision.","what_it_is_not":["It is not unconditional availability.","It is not permission to violate safety during partition."]},"structural_role":{"role_in_archetypes":"Makes progress claims falsifiable and exposes when safe suspension is expected.","typical_position":"criterion","required_properties":["trigger conditions","eventual assumptions","progress measure","suspension conditions"],"variation_dimensions":["deterministic or probabilistic","bounded latency or eventual termination","client or system perspective"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required progress contract"}],"compatible_components":["fault_and_network_model","timeout_retry_and_backoff_policy","consensus_observability_boundary"],"incompatible_or_confusing_components":["safety_property_specification_as_latency_slo"],"selection_notes":"State unavailable and degraded modes alongside normal progress.","validation_questions":["What must eventually become true?","Can an adversarial schedule block progress?","How is nonprogress diagnosed?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["safety_property_specification"],"related_mechanisms":["randomized_asynchrony_breaker","failure_detector_and_heartbeat_service"]},"examples":{"examples":[{"domain":"partial_synchrony","example":"A stable leader with a reachable quorum eventually commits proposals after network delay becomes bounded."}],"non_examples":["Every request always completes."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","liveness_claim_review"],"notes":"Confirm assumptions are visible to operators and clients."}}
Quorum and Intersection Policy ↗	{"role_in_archetypes":"Supplies the proof-bearing overlap at the core of distributed agreement.","typical_position":"decision","required_properties":["eligible unique voters","phase-specific thresholds","intersection argument","fault-bound linkage"],"variation_dimensions":["count or weight","read and write phases","old and new configurations"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"quorum_and_intersection_policy","name":"Quorum and Intersection Policy","aliases":["decision_quorum_geometry"]},"classification":{"component_type":"decision_rule","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Defines which vote sets certify phases and proves their required intersection under the fault model.","expanded_definition":"Covers simple, flexible, weighted, Byzantine, geographic, and joint-configuration quorum systems, including why conflicting certificates cannot both form.","what_it_is_not":["It is not merely a majority constant.","It is not a count that ignores identity and epoch."]},"structural_role":{"role_in_archetypes":"Supplies the proof-bearing overlap at the core of distributed agreement.","typical_position":"decision","required_properties":["eligible unique voters","phase-specific thresholds","intersection argument","fault-bound linkage"],"variation_dimensions":["count or weight","read and write phases","old and new configurations"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required certificate rule"}],"compatible_components":["membership_configuration","fault_and_network_model","durable_decision_evidence_log"],"incompatible_or_confusing_components":["simple_response_count","current_connectivity_majority"],"selection_notes":"Recalculate and re-prove after every membership or weight change.","validation_questions":["Can any two decisive sets be disjoint?","Does their intersection contain enough correct weight?","Are duplicate and stale voters excluded?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["membership_configuration"],"related_mechanisms":["crash_fault_quorum_protocol","byzantine_fault_quorum_protocol","authenticated_vote_certificate"]},"examples":{"examples":[{"domain":"crash_fault","example":"Any three of five voters intersect any other three in at least one voter."}],"non_examples":["Three acknowledgments from unknown or duplicate identities."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","quorum_proof_review"],"notes":"Specialist review required before acceptance."}}
Proposal Validity Rule ↗	{"role_in_archetypes":"Preserves the validity leg of the consensus contract before certification.","typical_position":"guardrail","required_properties":["deterministic evaluation","versioning","authorization","instance scope","stable evidence"],"variation_dimensions":["syntactic or semantic validity","external proof requirements","policy version"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"proposal_validity_rule","name":"Proposal Validity Rule","aliases":["consensus_value_validity_predicate"]},"classification":{"component_type":"criterion","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Rejects malformed, unauthorized, impossible, stale, or semantically invalid candidate values.","expanded_definition":"Ensures that agreement is reached only over values admissible for the instance and evaluated consistently by the voting software version.","what_it_is_not":["It is not proof that the decision is ethically legitimate.","It is not proposer reputation alone."]},"structural_role":{"role_in_archetypes":"Preserves the validity leg of the consensus contract before certification.","typical_position":"guardrail","required_properties":["deterministic evaluation","versioning","authorization","instance scope","stable evidence"],"variation_dimensions":["syntactic or semantic validity","external proof requirements","policy version"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required validity guardrail"}],"compatible_components":["decision_value_domain","protocol_phase_and_message_state"],"incompatible_or_confusing_components":["accept_any_quorum_value"],"selection_notes":"Put nondeterministic inputs into the proposal or a certified evidence object.","validation_questions":["Do all correct voters return the same result?","Is the rule version explicit?","Can evidence disappear after decision?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["decision_value_domain"],"related_mechanisms":["authenticated_vote_certificate"]},"examples":{"examples":[{"domain":"membership","example":"A configuration proposal is valid only when signed by the governed authority and names the current epoch."}],"non_examples":["A proposal is valid because the leader sent it."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","semantic_validity_review"],"notes":"Domain policy remains outside the generic stub."}}
Protocol Phase and Message State ↗	{"role_in_archetypes":"Encodes how evidence is created and constrains future votes.","typical_position":"process","required_properties":["instance and epoch tags","phase ordering","idempotent duplicate handling","monotonic ballots"],"variation_dimensions":["two phase or multi phase","leader based or leaderless","pipelined or serial"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"protocol_phase_and_message_state","name":"Protocol Phase and Message State","aliases":["consensus_protocol_state_machine"]},"classification":{"component_type":"state","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Defines message types, phase transitions, ballots, and admissible vote-state changes.","expanded_definition":"Makes retries, reordering, duplication, leadership change, and recovery subject to a monotonic protocol state machine rather than informal message handling.","what_it_is_not":["It is not the application state machine.","It is not a transport retry policy."]},"structural_role":{"role_in_archetypes":"Encodes how evidence is created and constrains future votes.","typical_position":"process","required_properties":["instance and epoch tags","phase ordering","idempotent duplicate handling","monotonic ballots"],"variation_dimensions":["two phase or multi phase","leader based or leaderless","pipelined or serial"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required protocol state"}],"compatible_components":["durable_decision_evidence_log","leader_or_coordinator_epoch","quorum_and_intersection_policy"],"incompatible_or_confusing_components":["application_command_state"],"selection_notes":"Specify rejection behavior for stale, duplicate, and out-of-order messages.","validation_questions":["Can a retry create a second vote?","Are transitions monotonic?","Can recovery reconstruct the state?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["durable_decision_evidence_log"],"related_mechanisms":["leader_election_and_term_protocol","replicated_log_consensus_engine"]},"examples":{"examples":[{"domain":"ballot_protocol","example":"A voter promises a ballot and later accepts only compatible proposals at that or higher ballots."}],"non_examples":["Handlers that infer phase from arrival order."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","protocol_state_review"],"notes":"Reconcile with reusable state-machine components."}}
Durable Decision Evidence Log ↗	{"role_in_archetypes":"Carries protocol constraints and proof across crash, recovery, transfer, and compaction.","typical_position":"support","required_properties":["atomic persistence","monotonic record","corruption detection","recoverable certificate","versioned format"],"variation_dimensions":["local stable storage","replicated certificate store","snapshot and suffix"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"durable_decision_evidence_log","name":"Durable Decision Evidence Log","aliases":["persistent_vote_and_certificate_log"]},"classification":{"component_type":"object_or_artifact","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Persists promises, votes, accepted values, certificates, and recovery evidence before dependent acknowledgment.","expanded_definition":"Preserves safety-relevant memory across crash and makes decisions independently auditable and recoverable.","what_it_is_not":["It is not an application event log.","It is not optional debug logging."]},"structural_role":{"role_in_archetypes":"Carries protocol constraints and proof across crash, recovery, transfer, and compaction.","typical_position":"support","required_properties":["atomic persistence","monotonic record","corruption detection","recoverable certificate","versioned format"],"variation_dimensions":["local stable storage","replicated certificate store","snapshot and suffix"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required durable evidence"}],"compatible_components":["protocol_phase_and_message_state","recovery_and_reconfiguration_rule"],"incompatible_or_confusing_components":["best_effort_trace_buffer"],"selection_notes":"Define exactly which records must be durable before each acknowledgment.","validation_questions":["Can a crash forget a binding vote?","Can corruption be detected?","Does compaction preserve recovery proof?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["checkpoint_and_snapshot_policy"],"related_mechanisms":["authenticated_vote_certificate","replicated_log_consensus_engine"]},"examples":{"examples":[{"domain":"coordination_service","example":"Persisted current term"}],"non_examples":["Volatile counters exported after the decision."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","durability_review"],"notes":"Storage semantics require implementation-specific verification."}}
Leader or Coordinator Epoch ↗	{"role_in_archetypes":"Prevents delayed or partitioned coordinators from exercising stale authority.","typical_position":"state","required_properties":["monotonic ordering","durable update","stale rejection","external fencing propagation"],"variation_dimensions":["term or ballot","centralized allocator or quorum election","per-group or global"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"leader_or_coordinator_epoch","name":"Leader or Coordinator Epoch","aliases":["term_and_fencing_epoch"]},"classification":{"component_type":"state","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Orders coordinator attempts and fences stale leaders without treating the leader as the source of truth.","expanded_definition":"A monotonic term or ballot separates authority attempts, carries through messages and effects, and requires new coordinators to recover prior safe evidence.","what_it_is_not":["It is not a permanent leader identity.","It is not wall-clock time."]},"structural_role":{"role_in_archetypes":"Prevents delayed or partitioned coordinators from exercising stale authority.","typical_position":"state","required_properties":["monotonic ordering","durable update","stale rejection","external fencing propagation"],"variation_dimensions":["term or ballot","centralized allocator or quorum election","per-group or global"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required fencing state"}],"compatible_components":["protocol_phase_and_message_state","membership_configuration"],"incompatible_or_confusing_components":["lease_without_clock_bound"],"selection_notes":"Carry fencing to every external resource capable of irreversible effect.","validation_questions":["Can two active coordinators use the same epoch?","Does restart preserve monotonicity?","Do effect recipients reject stale epochs?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["membership_configuration"],"related_mechanisms":["leader_election_and_term_protocol"]},"examples":{"examples":[{"domain":"replicated_database","example":"Storage rejects writes carrying a term lower than the highest observed term."}],"non_examples":["A leader hostname cached by clients indefinitely."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","fencing_review"],"notes":"Check for existing epoch/fencing component aliases."}}
Timeout, Retry, and Backoff Policy ↗	{"role_in_archetypes":"Regulates progress attempts and contention under uncertain communication.","typical_position":"process","required_properties":["bounded retry","jitter or desynchronization","overload awareness","retry identity","diagnostic signal"],"variation_dimensions":["fixed or adaptive","randomized or deterministic","local or coordinated"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"timeout_retry_and_backoff_policy","name":"Timeout, Retry, and Backoff Policy","aliases":["consensus_progress_retry_policy"]},"classification":{"component_type":"time_or_cadence","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Converts uncertain delay into bounded retry, election, backoff, and diagnostic behavior.","expanded_definition":"Supports liveness while preserving the principle that elapsed time is evidence for suspicion, not proof that conflicting state cannot exist.","what_it_is_not":["It is not a failure oracle.","It is not a safety certificate."]},"structural_role":{"role_in_archetypes":"Regulates progress attempts and contention under uncertain communication.","typical_position":"process","required_properties":["bounded retry","jitter or desynchronization","overload awareness","retry identity","diagnostic signal"],"variation_dimensions":["fixed or adaptive","randomized or deterministic","local or coordinated"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required liveness control"}],"compatible_components":["liveness_property_specification","consensus_observability_boundary"],"incompatible_or_confusing_components":["timeout_as_proof_of_death"],"selection_notes":"Tune against actual latency distributions and storage stalls, not only network averages.","validation_questions":["Can retries amplify overload?","Can simultaneous timeouts cause election storms?","Are client commands deduplicated?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["liveness_property_specification"],"related_mechanisms":["failure_detector_and_heartbeat_service","randomized_asynchrony_breaker"]},"examples":{"examples":[{"domain":"leader_election","example":"Randomized election timeouts plus exponential backoff after repeated failed terms."}],"non_examples":["Assume a peer is dead after one missed heartbeat."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","overload_review"],"notes":"Confirm timeout parameters remain mechanisms or settings."}}
Membership Configuration ↗	{"role_in_archetypes":"Anchors every certificate and quorum proof to one governed participant set.","typical_position":"state","required_properties":["epoch","unique voters","weights if any","activation proof","transition state"],"variation_dimensions":["static or dynamic","equal or weighted","joint or staged transition"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"membership_configuration","name":"Membership Configuration","aliases":["consensus_voter_configuration"]},"classification":{"component_type":"state","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Defines the voter set, weights, epoch, admission, removal, and active transition state.","expanded_definition":"Makes the quorum universe explicit and versioned so old and new memberships cannot create disjoint authority during replacement or repair.","what_it_is_not":["It is not service discovery.","It is not the set of currently reachable nodes."]},"structural_role":{"role_in_archetypes":"Anchors every certificate and quorum proof to one governed participant set.","typical_position":"state","required_properties":["epoch","unique voters","weights if any","activation proof","transition state"],"variation_dimensions":["static or dynamic","equal or weighted","joint or staged transition"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required quorum universe"}],"compatible_components":["participant_and_role_registry","quorum_and_intersection_policy","recovery_and_reconfiguration_rule"],"incompatible_or_confusing_components":["live_peer_list"],"selection_notes":"Permit one governed transition at a time unless concurrent transitions are formally proven.","validation_questions":["Which epoch does each vote name?","Can old and new sets decide independently?","Who authorizes membership change?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["participant_and_role_registry"],"related_mechanisms":["joint_consensus_reconfiguration"]},"examples":{"examples":[{"domain":"replicated_log","example":"A committed configuration entry activates a five-voter epoch after old/new overlap."}],"non_examples":["All nodes returned by DNS are voters."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","membership_governance_review"],"notes":"Reconcile with configuration and governance components."}}
Consensus Observability Boundary ↗	{"role_in_archetypes":"Makes failure and degraded guarantees visible while preserving the certificate boundary.","typical_position":"measurement","required_properties":["instance and epoch labels","quorum visibility","lag and churn metrics","certificate errors","model-breach alerts"],"variation_dimensions":["per group or fleet","real time or audit","privacy-preserving aggregation"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"consensus_observability_boundary","name":"Consensus Observability Boundary","aliases":["protocol_health_evidence_boundary"]},"classification":{"component_type":"feedback_signal","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Exposes quorum health, term churn, lag, conflicts, rejected certificates, and assumption breaches without bypassing proof rules.","expanded_definition":"Separates operational evidence used for diagnosis and liveness from binding evidence that authorizes a consensus decision.","what_it_is_not":["It is not a dashboard vote.","It is not permission for operators to infer safety from healthy metrics."]},"structural_role":{"role_in_archetypes":"Makes failure and degraded guarantees visible while preserving the certificate boundary.","typical_position":"measurement","required_properties":["instance and epoch labels","quorum visibility","lag and churn metrics","certificate errors","model-breach alerts"],"variation_dimensions":["per group or fleet","real time or audit","privacy-preserving aggregation"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required operational evidence"}],"compatible_components":["liveness_property_specification","durable_decision_evidence_log"],"incompatible_or_confusing_components":["metric_based_commit_override"],"selection_notes":"Ensure monitoring paths cannot mutate protocol state outside governed interfaces.","validation_questions":["Can operators distinguish no quorum from slow persistence?","Are rejected stale epochs visible?","Does monitoring expose sensitive votes?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["durable_decision_evidence_log"],"related_mechanisms":["failure_detector_and_heartbeat_service"]},"examples":{"examples":[{"domain":"control_plane","example":"Alerts show unreachable voting weight"}],"non_examples":["A green health check treated as proof of a committed write."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","observability_review"],"notes":"Name distinguishes target consensus from generic observability boundary."}}
Recovery and Reconfiguration Rule ↗	{"role_in_archetypes":"Preserves safety through the moments when state and authority are most likely to diverge.","typical_position":"pathway","required_properties":["certified recovery point","epoch fencing","overlap proof","audit trail","stop condition"],"variation_dimensions":["node restart","replacement","snapshot install","key rotation","disaster recovery"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"recovery_and_reconfiguration_rule","name":"Recovery and Reconfiguration Rule","aliases":["consensus_safe_recovery_rule"]},"classification":{"component_type":"pathway","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Restores participants and changes membership while preserving certified history and quorum overlap.","expanded_definition":"Defines snapshot installation, log catch-up, identity repair, old/new configuration overlap, and governed action when observed faults exceed the declared model.","what_it_is_not":["It is not deleting state and rejoining.","It is not unilateral operator reassignment."]},"structural_role":{"role_in_archetypes":"Preserves safety through the moments when state and authority are most likely to diverge.","typical_position":"pathway","required_properties":["certified recovery point","epoch fencing","overlap proof","audit trail","stop condition"],"variation_dimensions":["node restart","replacement","snapshot install","key rotation","disaster recovery"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"required continuity pathway"}],"compatible_components":["membership_configuration","durable_decision_evidence_log","checkpoint_and_snapshot_policy"],"incompatible_or_confusing_components":["force_rejoin_without_evidence"],"selection_notes":"Exceptional recovery must state any guarantee weakened and how a new epoch becomes authoritative.","validation_questions":["What proves the recovery point?","Can a stale node vote before catch-up?","Does membership overlap remain valid?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["membership_configuration","checkpoint_and_snapshot_policy"],"related_mechanisms":["joint_consensus_reconfiguration"]},"examples":{"examples":[{"domain":"database","example":"A replacement installs a certified snapshot and suffix before entering the joint voter set."}],"non_examples":["Copy the newest-looking disk and declare it authoritative."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","disaster_recovery_review"],"notes":"Verify boundary with transaction reconciliation."}}
Cryptographic Identity and Vote Proof ↗	{"role_in_archetypes":"Optional under trusted crash faults and required when forgery or equivocation is in scope.","typical_position":"guardrail","required_properties":["domain-separated signature","instance and epoch binding","key governance","replay protection"],"variation_dimensions":["individual or aggregate signatures","hardware backed or software keys","threshold signing"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"cryptographic_identity_and_vote_proof","name":"Cryptographic Identity and Vote Proof","aliases":["authenticated_consensus_evidence"]},"classification":{"component_type":"constraint","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Authenticates binding votes and makes equivocation attributable in adversarial settings.","expanded_definition":"Covers signer identity, protected message fields, key lifecycle, verification, revocation, and evidence retention required by the declared fault model.","what_it_is_not":["It is not consensus by itself.","It is not proof of semantic validity."]},"structural_role":{"role_in_archetypes":"Optional under trusted crash faults and required when forgery or equivocation is in scope.","typical_position":"guardrail","required_properties":["domain-separated signature","instance and epoch binding","key governance","replay protection"],"variation_dimensions":["individual or aggregate signatures","hardware backed or software keys","threshold signing"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"conditional adversarial guardrail"}],"compatible_components":["participant_and_role_registry","quorum_and_intersection_policy"],"incompatible_or_confusing_components":["unsigned_identity_label"],"selection_notes":"Select when the fault model permits forged or conflicting messages.","validation_questions":["Which fields are signed?","How are compromised keys removed?","Can evidence be verified after rotation?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["participant_and_role_registry"],"related_mechanisms":["authenticated_vote_certificate","byzantine_fault_quorum_protocol"]},"examples":{"examples":[{"domain":"Byzantine_registry","example":"Each phase vote signs instance"}],"non_examples":["TLS protects a connection but the stored vote omits its instance."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","cryptographic_review"],"notes":"Optional/required status depends on the fault model."}}
Read Consistency Policy ↗	{"role_in_archetypes":"Conditional client-interface rule when replicas serve reads.","typical_position":"decision","required_properties":["declared freshness","term and commit validation","failure behavior","client-visible semantics"],"variation_dimensions":["linearizable or stale","leader or follower","lease or quorum"]} Semantic canonical mapping retained the complete legacy component record: {"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"read_consistency_policy","name":"Read Consistency Policy","aliases":["consensus_read_semantics"]},"classification":{"component_type":"decision_rule","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Defines linearizable, lease, quorum, bounded-stale, or local read behavior around the decided history.","expanded_definition":"Prevents an implementation from claiming consensus-backed correctness while serving stale or uncommitted state through an unspecified read path.","what_it_is_not":["It is not the write consensus protocol.","It is not a cache freshness guess."]},"structural_role":{"role_in_archetypes":"Conditional client-interface rule when replicas serve reads.","typical_position":"decision","required_properties":["declared freshness","term and commit validation","failure behavior","client-visible semantics"],"variation_dimensions":["linearizable or stale","leader or follower","lease or quorum"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"optional client semantics"}],"compatible_components":["leader_or_coordinator_epoch","consensus_observability_boundary"],"incompatible_or_confusing_components":["read_any_replica_as_current"],"selection_notes":"Required whenever reads have correctness consequences.","validation_questions":["Can a stale leader serve a current-looking read?","What happens without quorum?","Is staleness visible?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["safety_property_specification"],"related_mechanisms":["replicated_log_consensus_engine"]},"examples":{"examples":[{"domain":"key_value_store","example":"A leader confirms its term through quorum before serving a linearizable read."}],"non_examples":["Return the nearest replica and call it strongly consistent."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","consistency_semantics_review"],"notes":"Reconcile with existing consistency-policy components."}} Consolidated omitted legacy component records: [{"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"client_command_deduplication_window","name":"Client Command Deduplication Window","aliases":["consensus_retry_deduplication"]},"classification":{"component_type":"boundary","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Maps retried client commands to one logical result for a defined retention window.","expanded_definition":"Binds stable client and sequence identifiers to decided command results so retry, replay, or leader change cannot duplicate an external logical operation.","what_it_is_not":["It is not transport-level duplicate packet removal.","It is not unlimited exactly-once delivery."]},"structural_role":{"role_in_archetypes":"Conditional application boundary for retry-safe replicated services.","typical_position":"guardrail","required_properties":["stable request identity","retained result","expiry semantics","deterministic duplicate response"],"variation_dimensions":["time or sequence window","per-client or global registry","snapshot retention"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"optional application safety boundary"}],"compatible_components":["decision_value_domain","checkpoint_and_snapshot_policy"],"incompatible_or_confusing_components":["network_packet_deduplication"],"selection_notes":"Align retention with client retry and disaster-recovery bounds.","validation_questions":["Can a retry after leader change repeat the effect?","What happens after expiry?","Does snapshot preserve retained results?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["decision_value_domain"],"related_mechanisms":["deterministic_state_machine_application"]},"examples":{"examples":[{"domain":"payment_ledger","example":"Client sequence 42 returns its stored result after a retry."}],"non_examples":["Assume clients never retry."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","idempotency_review"],"notes":"Reconcile with indexed idempotency components."}},{"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"checkpoint_and_snapshot_policy","name":"Checkpoint and Snapshot Policy","aliases":["consensus_log_compaction_policy"]},"classification":{"component_type":"decision_rule","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Compacts decided history while retaining certified recovery, membership, and application evidence.","expanded_definition":"Defines snapshot creation, included index and term, integrity proof, transfer, installation, suffix replay, and retention of evidence needed to reject stale history.","what_it_is_not":["It is not arbitrary log deletion.","It is not an unverified filesystem copy."]},"structural_role":{"role_in_archetypes":"Optional storage-lifecycle rule for long-lived replicated logs.","typical_position":"support","required_properties":["certified included position","state digest","epoch context","atomic install","retained suffix"],"variation_dimensions":["full or incremental","local or transferred","scheduled or size triggered"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"optional long-lived-log support"}],"compatible_components":["durable_decision_evidence_log","recovery_and_reconfiguration_rule"],"incompatible_or_confusing_components":["delete_old_log_on_disk_pressure"],"selection_notes":"Required once unbounded log retention is not operationally viable.","validation_questions":["What proves the included prefix?","Can install cross an epoch incorrectly?","Are client results and membership retained?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["durable_decision_evidence_log"],"related_mechanisms":["replicated_log_consensus_engine"]},"examples":{"examples":[{"domain":"coordination_service","example":"A snapshot names included log index"}],"non_examples":["Copy whichever replica has the largest file."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","recovery_review"],"notes":"Check overlap with catalog snapshot components."}},{"metadata":{"schema_version":"1.0","artifact_type":"solution_component","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"geographic_or_failure_domain_placement_rule","name":"Geographic or Failure-Domain Placement Rule","aliases":["quorum_failure_independence_placement"]},"classification":{"component_type":"constraint","abstraction_level":"reusable_midlevel","maturity":"provisional"},"definition":{"short_definition":"Places voters so one correlated power, network, operator, or geographic failure cannot defeat the assumed fault bound.","expanded_definition":"Connects abstract voter independence to deployment topology and records the latency and jurisdiction tradeoffs introduced by separation.","what_it_is_not":["It is not merely running several processes.","It is not a substitute for quorum proof."]},"structural_role":{"role_in_archetypes":"Optional deployment constraint that becomes required when correlated failures threaten the model.","typical_position":"constraint","required_properties":["failure-domain inventory","independence rationale","quorum reachability","latency budget"],"variation_dimensions":["rack","zone","region","provider","administrator","jurisdiction"]},"use":{"used_by_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"optional physical independence constraint"}],"compatible_components":["fault_and_network_model","membership_configuration"],"incompatible_or_confusing_components":["same_host_process_replication"],"selection_notes":"Evaluate shared dependencies below the advertised zone or provider labels.","validation_questions":["Can one outage remove a decisive quorum?","Do voters share credentials or operators?","Can surviving domains communicate?"]},"relationships":{"parent_component":"","child_components":[],"related_components":["fault_and_network_model"],"related_mechanisms":["failure_detector_and_heartbeat_service"]},"examples":{"examples":[{"domain":"cloud_control_plane","example":"Five voters span three zones and two independent power/network paths."}],"non_examples":["Five containers on one host counted as five independent faults."]},"review":{"review_status":"not_reviewed","review_flags":["component_extraction_review","correlated_failure_review"],"notes":"Reconcile with resilience placement components."}}]

Common Mechanisms

10 documented mechanisms across 5 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Control, Automation & Runtime · 6 mechanisms

• Deterministic State-Machine Application — Turns an agreed command order into identical replica state by applying each committed command deterministically and recording one result per client request.
• Failure Detector and Heartbeat Service — Emits imperfect suspicion signals from heartbeats and progress probes to drive retries and elections without ever proving a peer has failed.
• Joint Consensus Reconfiguration — Changes the voting membership through an overlap phase so old and new configurations can never decide independently.
• Leader Election and Term Protocol — Selects a temporary coordinator and fences stale ones with monotonic terms, without making the leader the source of truth.
• Randomized Asynchrony Breaker — Injects unpredictable choices to win probabilistic progress when an adversarial schedule could otherwise stall a deterministic protocol forever.
• Replicated Log Consensus Engine — Repeats safe consensus across ordered log positions and exposes one certified, durable command history to replicas.

Decision, Gate & Allocation · 1 mechanism

• Crash-Fault Quorum Protocol — Decides one safe value among participants that may crash and recover but never lie, using intersecting majority quorums and durable votes.

Experiment, Test & Rehearsal · 1 mechanism

• Consensus Safety Model Check — Explores a protocol's fault, recovery, and reordering schedules against formal invariants to catch safety violations before deployment.

Protocol, Workflow & Routine · 1 mechanism

• Byzantine-Fault Quorum Protocol — Reaches agreement among mutually distrusting participants by authenticating every vote and sizing quorums so equivocation cannot forge two conflicting certificates.

Record, Log & Register · 1 mechanism

• Authenticated Vote Certificate — Packages identity-bound votes into a portable, independently verifiable proof that a quorum accepted one safe value.

Parameter / Tuning Dimensions

• Fault semantics: crash-stop, crash-recovery, omission, partition, arbitrary Byzantine, compromised identity, correlated failure, or mixed models.
• Fault threshold: count-based or weighted bound; static or epoch-specific; independent or correlated assumptions.
• Timing model: asynchronous safety with partial-synchrony liveness, bounded-delay synchrony, randomized progress, leases with clock assumptions, or probabilistic finality.
• Decision shape: one value, repeated independent values, a totally ordered log, a leader, a membership configuration, or a checkpoint.
• Quorum geometry: simple majority, flexible phase quorums, weighted quorums, geographic quorums, Byzantine supermajorities, or joint old/new configurations.
• Finality: deterministic certificate, externally stable checkpoint, or quantified probability of reversal.
• Membership: static, manually governed, automatically replaced, jointly reconfigured, permissioned, or open with a separate identity/stake mechanism.
• Persistence: synchronous durable writes, replicated vote storage, stable hardware, reconstruction from certificates, or bounded data-loss recovery.
• Read semantics: leader-only, quorum read, lease read, linearizable read index, bounded stale, or local eventual view.
• Application semantics: pure decision, replicated state machine, transactional handoff, idempotent side effect, or human-authorized execution.

Invariants to Preserve

Agreement must hold per instance and log index. Validity must be checked against the same versioned predicate across participants. A correct voter cannot support incompatible decisions under the vote ordering rules. Any two potentially decisive certificates must intersect according to the declared fault model. Terms, ballots, and membership epochs are monotonic and cannot be reused after evidence from a later epoch exists.

Durability matters at the point where an acknowledgment can constrain peers. A promise remembered only in volatile memory is not a promise across crash recovery. Decision certificates and committed log prefixes remain interpretable after compaction. Applied state corresponds to a certified prefix, and client command identifiers prevent retry from becoming a second logical operation.

Operational urgency does not weaken the proof silently. A manual override either preserves the same invariants or creates a new governed system state whose loss of guarantee is explicit. Safety remains separate from liveness: a slow or unavailable system can still be safe, while a responsive split-brain system is not consensus.

Target Outcomes

The primary outcome is a single durable decision that every correct learner can verify and every correct replica can recover. For replicated logs, correct replicas converge on one certified prefix and apply it deterministically. Under the stated progress conditions, valid proposals eventually reach a decision without unbounded coordinator conflict.

Secondary outcomes are equally important: operators can see whether the system is waiting because of insufficient quorum, repeated terms, slow persistence, invalid proposals, or membership mismatch; clients understand when reads and writes are final; reconfiguration does not create a hidden split; and incident reviewers can reconstruct exactly which evidence authorized each effect.

Tradeoffs

Stronger fault tolerance consumes more replicas, messages, durable writes, verification, and latency. Geographic distribution improves failure independence but increases round-trip time. Larger quorums can survive more faults and strengthen read guarantees while reducing availability during maintenance or partition. Leaders improve steady-state throughput but create election churn and hotspot risk.

Deterministic finality simplifies external effects but may wait longer than probabilistic confidence. Flexible quorums can optimize common paths but make intersection reasoning and operations more complex. Aggressive timeouts reduce failure-reaction time but cause needless elections under load; conservative timeouts tolerate delay but extend unavailability. Log compaction controls storage but raises recovery and proof-preservation complexity.

The central tradeoff is not “consistency versus speed” in the abstract. It is which guarantee holds under each explicit network and fault condition, who bears the resulting unavailability or reversal risk, and whether that behavior is observable before consequential effects occur.

Ethical And Safety Considerations

Consensus proves agreement under a technical model; it does not prove truth, fairness, legitimacy, or benefit. A perfectly safe protocol can replicate discriminatory policy or irreversible harm. Proposal validity should therefore include authorization and domain safety checks where decisions affect people, and governance must remain accountable outside the protocol.

Membership and weight determine whose machines can create authority. Concentrated administration, correlated hosting, shared credentials, or opaque stake can turn nominal distribution into hidden control. Document who can add, remove, weight, repair, or reset participants and require auditable multi-party authorization for exceptional recovery.

Availability loss is not evenly distributed. Choosing safety during partition can deny essential service; choosing local progress can create conflicting records or double obligations. High-stakes deployments must define safe degraded modes, offline protections, appeal and reconciliation paths, and limits on automatic action. Do not use the language of mathematical certainty beyond the tested implementation, deployment assumptions, and actual fault boundary.

Failure Modes

Split brain: disjoint partitions each act as authoritative. Mitigate with proved quorum intersection, epoch fencing, external resource fencing tokens, and a write-stop when quorum is unavailable.

Forgotten vote: a node acknowledges a promise or acceptance before durable persistence, crashes, and later votes incompatibly. Mitigate by defining the durability point, testing crash injection around it, and reconstructing from certificates only when the protocol proves that safe.

Stale leader: a delayed coordinator resumes and issues effects after a higher term has begun. Mitigate with monotonically increasing epochs carried through storage and external effect boundaries; recipients reject stale tokens.

Invalid agreement: all voters certify a malformed, unauthorized, or impossible value. Mitigate with a deterministic, versioned validity predicate and evidence that required inputs were available at vote time.

Reconfiguration gap: old and new configurations can decide independently. Mitigate with joint consensus or another overlap proof, one active transition at a time, and a durable completion marker.

Election storm: short timeouts, correlated load, or simultaneous recovery repeatedly replace leaders. Mitigate with randomized timeout ranges, adaptive backoff, pre-vote where appropriate, capacity repair, and observability of term churn.

Non-deterministic application: replicas agree on commands but diverge because execution reads local time, randomness, or environment. Mitigate by putting nondeterministic inputs into the decided value, versioning application logic, and comparing state digests.

Duplicate external effect: client retry or replay reissues a payment or command. Mitigate with stable client sequence identifiers, retained result records, idempotency keys, and effect fencing.

Model breach: correlated failures, compromised identities, or permanent partition exceed the assumption. Mitigate by halting unsafe progress, surfacing the breached assumption, rotating membership through a governed recovery path, and never relabeling weakened behavior as the original guarantee.

False assurance from tests: happy-path integration tests miss rare interleavings. Mitigate with model checking, property-based traces, network fault injection, crash-at-every-write-boundary testing, and reconfiguration scenarios.

Neighbor Distinctions

Consensus Convergence is a close lexical neighbor but a different solution family. It maps participants, evidence, disagreement, dissent, synthesis, and closure in human collective judgment. It can legitimately end with retained minority reports or sufficient alignment. Distributed consensus requires a single machine-interpretable decided value, a validity rule, an explicit fault threshold, and proof that conflicting decisions cannot both form.

Nested and Distributed Transaction Coordination uses consensus or quorum commit as one possible mechanism, but its defining concerns are transaction boundaries, atomicity, compensation, idempotent replay, nested scope, and reconciliation. Consensus can decide a transaction outcome, yet it does not by itself orchestrate all external resources or compensate an irreversible side effect.

Dissent Protection Protocol, Structured Expert Judgment Iteration, and Subgroup Deliberation and Recombination improve human epistemic processes. Their results may become proposals submitted to a machine consensus service, but procedural fairness cannot substitute for protocol safety, and a quorum certificate cannot establish that a policy is legitimate or wise.

Cross-Domain Examples

Replicated metadata service: five crash-fault voters maintain an ordered configuration log. A leader in one term proposes entries, a majority certificate commits them, followers reject stale terms, and a client read is linearized through current quorum evidence. Losing two voters preserves progress; losing three stops writes while retaining the last certified state.

Safety-controller configuration: three controllers must agree on one active control profile before actuators accept it. Each effect carries a fencing epoch. A recovering controller installs a certified snapshot and log suffix before voting. If no quorum exists, the plant enters a separately engineered safe mode rather than accepting independent profiles.

Byzantine permissioned registry: governed members sign proposals and phase votes. The certificate threshold and membership distribution tolerate a bounded adversarial weight. Conflicting signatures are detectable evidence, but the protocol still relies on quorum intersection and a validity predicate; the signatures alone are insufficient.

Joint membership change: a replicated database replaces two machines without allowing old and new majorities to decide separately. During transition, decisions require the declared old/new overlap. Only after a certified configuration entry is applied does the new set operate independently.

Non-Examples

• A workshop where stakeholders discuss evidence and leave with sufficient alignment; this is Consensus Convergence.
• A majority vote with no fault model, persistence rule, or protection against duplicate and stale voters.
• Two services using retries and compensation to complete an order; this is transaction coordination.
• A primary database copying updates to followers with manual failover but no fencing or agreement protocol.
• A dashboard showing most replicas currently report the same value without a certificate linking those reports.
• A conflict-free set that allows concurrent additions and merges them later; it intentionally avoids consensus.
• Operators manually editing divergent replicas until values match, with no governed epoch or audit proof.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

• Consensus: Producing a single shared decided state from many participants with disagreeing or adversarial views, under a fault model, satisfying agreement, validity, and termination together.
• Coordination: Aligning independently controlled actors so their separate actions combine into a coherent collective outcome despite distributed decision-making and incomplete shared information.
• Fault Tolerance: Continue operating under failure.

Also references 10 related abstractions

• Concurrency: Manage simultaneous processes.
• Consistency: A set of commitments cannot jointly derive a contradiction.
• Consistency Model: An explicit contract over which observations of shared state are legal when updates are concurrent.
• Deadlock: Mutual blocking processes.
• Eventual Consistency: Distributed copies of shared state are allowed to diverge under local updates, with a deterministic merge guaranteeing they reconverge once updates stop.
• Idempotence: Repetition yields same result.
• Observability: Infer internal state externally.
• Resilience: Absorb shocks and adapt.
• State and State Transition: Captures system condition and evolution.
• Synchronization: The emergence of stable shared timing or phase among independent oscillating processes through local coupling, without any central conductor.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Crash-Fault Consensus · other · recognized

Assumes faulty participants stop, restart, omit, or delay messages but do not fabricate incompatible authenticated statements. Majority-style intersection can therefore rely on a correct voter retaining its durable promise rather than needing to outnumber equivocation inside the intersection.

• Distinct from parent: Assumes faulty participants stop, restart, omit, or delay messages but do not fabricate incompatible authenticated statements. Majority-style intersection can therefore rely on a correct voter retaining its durable promise rather than needing to outnumber equivocation inside the intersection.
• Use when: Participant identity and software administration are trusted; Crash, recovery, delay, loss, duplication, and partition dominate the threat model; Stable storage can preserve safety-relevant promises across restart.
• Typical domains: Participant identity and software administration are trusted., Crash, recovery, delay, loss, duplication, and partition dominate the threat model., Stable storage can preserve safety-relevant promises across restart.
• Common mechanisms: crash fault quorum protocol, leader election and term protocol, replicated log consensus engine

Byzantine-Fault Consensus · other · recognized

Tolerates a bounded number or weight of participants sending conflicting, fabricated, selectively withheld, or strategically timed messages. Its quorum geometry and phase rules ensure that any conflicting certificates intersect in sufficient correct weight, while authentication makes identity and equivocation evidence verifiable.

• Distinct from parent: Tolerates a bounded number or weight of participants sending conflicting, fabricated, selectively withheld, or strategically timed messages. Its quorum geometry and phase rules ensure that any conflicting certificates intersect in sufficient correct weight, while authentication makes identity and equivocation evidence verifiable.
• Use when: Participants cross administrative or trust boundaries; Compromise or malicious equivocation is part of the declared threat model; Identity, key lifecycle, membership, and evidence distribution are governed.
• Typical domains: Participants cross administrative or trust boundaries., Compromise or malicious equivocation is part of the declared threat model., Identity, key lifecycle, membership, and evidence distribution are governed.
• Common mechanisms: byzantine fault quorum protocol, authenticated vote certificate, consensus safety model check

Single-Decree Consensus · other · recognized

Decides one value for one explicitly bounded instance. It does not inherit the ordering, prefix, deterministic-application, snapshot, and client-session obligations of a long-lived replicated log unless those are separately added.

• Distinct from parent: Decides one value for one explicitly bounded instance. It does not inherit the ordering, prefix, deterministic-application, snapshot, and client-session obligations of a long-lived replicated log unless those are separately added.
• Use when: Electing one authority, selecting one configuration, or certifying one checkpoint; Instances are independent and have explicit unique identifiers; Repeated application semantics are outside the consensus boundary.
• Typical domains: Electing one authority, selecting one configuration, or certifying one checkpoint., Instances are independent and have explicit unique identifiers., Repeated application semantics are outside the consensus boundary.
• Common mechanisms: crash fault quorum protocol, authenticated vote certificate

Replicated-Log Consensus · other · recognized

Repeats consensus across positions to create one durable prefix-ordered command history, then binds that history to deterministic state-machine application, client sequencing, compaction, snapshots, and catch-up.

• Distinct from parent: Repeats consensus across positions to create one durable prefix-ordered command history, then binds that history to deterministic state-machine application, client sequencing, compaction, snapshots, and catch-up.
• Use when: A replicated service must process an ongoing sequence of commands; Order affects outcomes and conflicting histories cannot be merged safely; Recovery can install a certified snapshot plus a log suffix.
• Typical domains: A replicated service must process an ongoing sequence of commands., Order affects outcomes and conflicting histories cannot be merged safely., Recovery can install a certified snapshot plus a log suffix.
• Common mechanisms: replicated log consensus engine, deterministic state machine application, joint consensus reconfiguration

Permissioned Weighted Consensus · other · recognized

Defines safety and progress by authenticated voting weight rather than equal node count. The membership and weight-governance process becomes part of the security boundary because one administrator, institution, or correlated domain may control multiple nominal voters.

• Distinct from parent: Defines safety and progress by authenticated voting weight rather than equal node count. The membership and weight-governance process becomes part of the security boundary because one administrator, institution, or correlated domain may control multiple nominal voters.
• Use when: Authority is intentionally heterogeneous and documented; Weight updates occur through certified membership epochs; Fault assumptions can be expressed over independent weight.
• Typical domains: Authority is intentionally heterogeneous and documented., Weight updates occur through certified membership epochs., Fault assumptions can be expressed over independent weight.
• Common mechanisms: authenticated vote certificate, joint consensus reconfiguration, byzantine fault quorum protocol

Probabilistic-Finality Consensus · other · recognized

Exposes a quantified probability or security bound that an observed history will not be reversed, rather than presenting one immediate deterministic certificate. Applications choose confirmation depth or confidence thresholds according to consequence and threat.

• Distinct from parent: Exposes a quantified probability or security bound that an observed history will not be reversed, rather than presenting one immediate deterministic certificate. Applications choose confirmation depth or confidence thresholds according to consequence and threat.
• Use when: The protocol's evidence accumulates over rounds, descendants, or samples; A bounded reversal probability is acceptable and observable; External effects can wait for consequence-appropriate confidence.
• Typical domains: The protocol's evidence accumulates over rounds, descendants, or samples., A bounded reversal probability is acceptable and observable., External effects can wait for consequence-appropriate confidence.
• Common mechanisms: randomized asynchrony breaker, authenticated vote certificate, consensus observability boundary

Editorial Notes

Problem Classification

Classification: Coordination, Dependency & Sequencing Failure → Concurrent Shared-State Consistency

Problem kernel: faulty distributed participants cannot expose one authoritative history

Rationale: Delay, duplication, loss, crashes, and equivocation prevent local views from converging without an explicit fault-tolerant agreement contract.

Independent corroboration: The earliest necessary condition in the frozen evidence is: Multiple independently failing participants must expose one authoritative value or ordered history, yet messages can be delayed, duplicated, reordered, lost, or forged; processes can crash, recover, or equivocate; and no participant has complete knowledge of the others' state. That is a concurrent shared state consistency problem because Independently acting participants produce conflicting, partial, or irreconcilable states because simultaneous and distributed changes lack an explicit consistency and convergence contract.

Review outcome: Independent reviewer agreement; high confidence.