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.

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

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

Mechanism	Description
Crash-Fault Quorum Protocol (`crash_fault_quorum_protocol`) ↗	Type: `protocol` {"short_definition":"Implements binding decisions with intersecting quorums when participants may crash, recover, or omit messages but do not equivocate.","expanded_definition":"Uses monotonic ballots or terms, durable promises and accepts, and majority or otherwise proved quorum intersection so a new coordinator must carry forward any value that could already have been chosen.","mechanism_not_archetype_reason":"It is one protocol family selected after the archetype fixes fault, timing, persistence, and decision semantics."} Selection constraints and retained implementation evidence: faults do not equivocate; decisive quorums intersect; durable acknowledgment is reliable; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"crash_fault_quorum_protocol","name":"Crash-Fault Quorum Protocol","aliases":["majority_quorum_consensus_protocol"]},"classification":{"mechanism_type":"protocol","domain_specificity":"domain_specific","maturity":"common"},"definition":{"short_definition":"Implements binding decisions with intersecting quorums when participants may crash, recover, or omit messages but do not equivocate.","expanded_definition":"Uses monotonic ballots or terms, durable promises and accepts, and majority or otherwise proved quorum intersection so a new coordinator must carry forward any value that could already have been chosen.","mechanism_not_archetype_reason":"It is one protocol family selected after the archetype fixes fault, timing, persistence, and decision semantics."},"implementation":{"operating_logic":"Gather a phase quorum, recover prior accepted evidence, propose the safe value, gather a decision quorum, persist, and publish a verifiable result.","typical_steps":["load durable term and vote state","acquire a preparation or leadership quorum","select the safe prior value","validate and propose","persist and acknowledge votes","assemble the certificate","notify learners","retry under a higher term when progress stalls"],"required_inputs":["membership epoch","crash-fault bound","quorum policy","value-validity rule","stable storage semantics"],"outputs_or_deliverables":["decision certificate","durable accepted state","diagnostic phase trace"],"required_conditions":["faults do not equivocate","decisive quorums intersect","durable acknowledgment is reliable"],"failure_conditions":["volatile vote loss","stale epoch accepted","disjoint reconfiguration","invalid value certified"],"maintenance_or_update_needs":["fault-injection tests","storage durability verification","quorum recalculation after membership change","timeout tuning"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"crash-fault implementation family"}],"supports_components":["fault_and_network_model","quorum_and_intersection_policy","protocol_phase_and_message_state","durable_decision_evidence_log"],"can_be_confused_with_archetypes":["nested_and_distributed_transaction_coordination"],"neighboring_mechanisms":["leader_election_and_term_protocol","replicated_log_consensus_engine"]},"operational_profile":{"strengths":["deterministic safety within the crash model","widely understood quorum geometry","efficient steady state with a stable leader"],"limitations":["does not tolerate equivocation","loses progress without a reachable quorum","depends on correct stable storage"],"tradeoffs":["replica count versus tolerated outages","geographic latency versus failure independence"],"misuse_risks":["advertising Byzantine tolerance","treating timeout as proof","acknowledging before persistence"],"metrics_for_success":["decision latency","quorum availability","term churn","certificate rejection","crash-recovery invariant violations"],"ethical_or_safety_notes":["A certificate proves protocol agreement","not justice or truth.","High-stakes unavailability requires a safe degraded mode."]},"examples":{"examples":[{"domain":"metadata_service","example":"Three of five durable voters certify each log entry.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["Collecting responses from whichever three endpoints answer first without fixed membership."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","distributed_systems_review"],"notes":"Reconcile against existing quorum and consensus mechanisms."}}
Byzantine-Fault Quorum Protocol (`byzantine_fault_quorum_protocol`) ↗	Type: `protocol` {"short_definition":"Implements consensus with phase-specific authenticated quorums that tolerate bounded arbitrary or equivocating participants.","expanded_definition":"Uses identity-bound votes, locking or safe-value rules, and quorum intersection sized so conflicting certificates cannot both form despite faulty members signing conflicting messages.","mechanism_not_archetype_reason":"It is the adversarial protocol implementation family, not the general agreement-under-faults structure."} Selection constraints and retained implementation evidence: faulty weight remains below threshold; verification rules are consistent; membership authority remains trustworthy; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"byzantine_fault_quorum_protocol","name":"Byzantine-Fault Quorum Protocol","aliases":["authenticated_byzantine_agreement_protocol"]},"classification":{"mechanism_type":"protocol","domain_specificity":"domain_specific","maturity":"specialized"},"definition":{"short_definition":"Implements consensus with phase-specific authenticated quorums that tolerate bounded arbitrary or equivocating participants.","expanded_definition":"Uses identity-bound votes, locking or safe-value rules, and quorum intersection sized so conflicting certificates cannot both form despite faulty members signing conflicting messages.","mechanism_not_archetype_reason":"It is the adversarial protocol implementation family, not the general agreement-under-faults structure."},"implementation":{"operating_logic":"Validate signed proposals, collect phase certificates, lock or carry safe values forward, and decide only when the required authenticated evidence chain is complete.","typical_steps":["load the governed membership and weights","authenticate proposal and epoch","validate the value","collect preparation evidence","enforce lock and safe-value rules","collect commit evidence","form the certificate","distribute proof and equivocation evidence"],"required_inputs":["Byzantine fault threshold","authenticated identity","quorum intersection proof","validity predicate","key and membership governance"],"outputs_or_deliverables":["authenticated decision certificate","equivocation evidence","durable lock state"],"required_conditions":["faulty weight remains below threshold","verification rules are consistent","membership authority remains trustworthy"],"failure_conditions":["key compromise beyond bound","unsafe lock transition","inconsistent validity rule","correlated nominal identities"],"maintenance_or_update_needs":["cryptographic review","key rotation tests","adversarial simulation","membership-concentration audit"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"Byzantine-fault implementation family"}],"supports_components":["cryptographic_identity_and_vote_proof","quorum_and_intersection_policy","proposal_validity_rule"],"can_be_confused_with_archetypes":["consensus_convergence"],"neighboring_mechanisms":["authenticated_vote_certificate","randomized_asynchrony_breaker"]},"operational_profile":{"strengths":["tolerates bounded equivocation","portable proof","accountable conflicting signatures"],"limitations":["higher message and verification cost","complex membership security","sensitive to implementation and governance errors"],"tradeoffs":["fault threshold versus quorum size","batching throughput versus latency and complexity"],"misuse_risks":["assuming signatures alone imply consensus","hiding centralized membership control","overstating fault independence"],"metrics_for_success":["certificate latency","faulty-vote detection","invalid-signature rejection","quorum weight distribution"],"ethical_or_safety_notes":["Voting weight determines technical authority and requires transparent governance.","Protocol finality does not establish social legitimacy."]},"examples":{"examples":[{"domain":"permissioned_registry","example":"Authenticated supermajority phase certificates decide a configuration despite bounded equivocation.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["A signed majority poll with no phase or lock rule."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","Byzantine_specialist_review"],"notes":"Specialist review required before catalog acceptance."}}
Replicated Log Consensus Engine (`replicated_log_consensus_engine`) ↗	Type: `software_or_tool` {"short_definition":"Repeats safe consensus across ordered positions and exposes a committed log to a deterministic state machine.","expanded_definition":"Coordinates proposal ordering, prefix replication, commit advancement, follower catch-up, snapshot integration, and client result linkage around one certified history.","mechanism_not_archetype_reason":"It is an implementation engine for the replicated-log variant, not the broader consensus pattern or application service."} Selection constraints and retained implementation evidence: prefix agreement; deterministic application; adequate durable storage; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"replicated_log_consensus_engine","name":"Replicated Log Consensus Engine","aliases":["ordered_command_consensus_engine"]},"classification":{"mechanism_type":"software_or_tool","domain_specificity":"domain_specific","maturity":"common"},"definition":{"short_definition":"Repeats safe consensus across ordered positions and exposes a committed log to a deterministic state machine.","expanded_definition":"Coordinates proposal ordering, prefix replication, commit advancement, follower catch-up, snapshot integration, and client result linkage around one certified history.","mechanism_not_archetype_reason":"It is an implementation engine for the replicated-log variant, not the broader consensus pattern or application service."},"implementation":{"operating_logic":"A current coordinator appends valid commands, replicates them to an intersecting quorum, advances a commit boundary, and applies the certified prefix in order.","typical_steps":["accept a uniquely identified client command","assign a log position","replicate term and entry evidence","advance commit after quorum proof","apply in deterministic order","record the result","catch up lagging replicas","snapshot a certified prefix"],"required_inputs":["consensus protocol","deterministic command schema","membership configuration","client sequencing rule"],"outputs_or_deliverables":["committed log prefix","applied state and result","catch-up and snapshot evidence"],"required_conditions":["prefix agreement","deterministic application","adequate durable storage"],"failure_conditions":["applying uncommitted suffix","log overwrite past a committed entry","non-deterministic command","unsafe snapshot"],"maintenance_or_update_needs":["compatibility tests","snapshot restore drills","log divergence alarms","client dedup retention review"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"repeated ordered-decision implementation"}],"supports_components":["decision_value_domain","protocol_phase_and_message_state","durable_decision_evidence_log","checkpoint_and_snapshot_policy"],"can_be_confused_with_archetypes":["nested_and_distributed_transaction_coordination"],"neighboring_mechanisms":["deterministic_state_machine_application","leader_election_and_term_protocol"]},"operational_profile":{"strengths":["one durable command order","recoverable replica state","efficient batching and pipelining"],"limitations":["serialization bottleneck","unavailable without quorum","application determinism required"],"tradeoffs":["batch size versus latency","snapshot frequency versus recovery time","follower lag versus throughput"],"misuse_risks":["equating log commit with external atomicity","serving stale reads without policy","losing client dedup state"],"metrics_for_success":["commit latency","applied and committed index gap","follower lag","snapshot install failures"],"ethical_or_safety_notes":["Irreversible effects require domain-specific safeguards beyond ordered agreement."]},"examples":{"examples":[{"domain":"coordination_service","example":"A five-replica engine commits configuration commands and applies one ordered prefix.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["Asynchronous log shipping with manual conflict resolution."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","application_boundary_review"],"notes":"Named algorithms may instantiate this generic mechanism."}}
Leader Election and Term Protocol (`leader_election_and_term_protocol`) ↗	Type: `protocol` {"short_definition":"Selects a temporary coordinator and fences stale coordinators through monotonic terms or ballots.","expanded_definition":"Uses quorum evidence, voter restrictions, log or accepted-state comparison, and randomized retry to choose an eligible coordinator without making that coordinator the sole source of truth.","mechanism_not_archetype_reason":"Leader election is implementation machinery supporting progress within consensus and can also appear in other coordination patterns."} Selection constraints and retained implementation evidence: quorum intersection; monotonic terms; stale effect rejection; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"leader_election_and_term_protocol","name":"Leader Election and Term Protocol","aliases":["coordinator_epoch_election"]},"classification":{"mechanism_type":"protocol","domain_specificity":"domain_specific","maturity":"common"},"definition":{"short_definition":"Selects a temporary coordinator and fences stale coordinators through monotonic terms or ballots.","expanded_definition":"Uses quorum evidence, voter restrictions, log or accepted-state comparison, and randomized retry to choose an eligible coordinator without making that coordinator the sole source of truth.","mechanism_not_archetype_reason":"Leader election is implementation machinery supporting progress within consensus and can also appear in other coordination patterns."},"implementation":{"operating_logic":"After a liveness timeout, an eligible participant advances its term, gathers unique votes, proves adequate prior state, and acts only while its epoch remains current.","typical_steps":["detect progress stall","randomize candidacy timing","persist a higher term","request votes with prior-state evidence","reject stale or ineligible candidates","assemble election quorum","fence effects with the new term","step down on higher evidence"],"required_inputs":["membership epoch","election quorum","eligibility rule","durable term storage","timeout policy"],"outputs_or_deliverables":["leader certificate or quorum evidence","current term","election trace"],"required_conditions":["quorum intersection","monotonic terms","stale effect rejection"],"failure_conditions":["double voting after crash","same-term dual authority","election storm","stale resource access"],"maintenance_or_update_needs":["timeout tuning","correlated-load tests","fencing verification","term-churn review"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"optional liveness coordination mechanism"}],"supports_components":["leader_or_coordinator_epoch","timeout_retry_and_backoff_policy","protocol_phase_and_message_state"],"can_be_confused_with_archetypes":[],"neighboring_mechanisms":["failure_detector_and_heartbeat_service","crash_fault_quorum_protocol"]},"operational_profile":{"strengths":["simplifies proposal ordering","efficient stable-leader path","explicit stale-leader fencing"],"limitations":["leader hotspot","election unavailability","no safety without underlying vote rules"],"tradeoffs":["fast detection versus false elections","eligibility strictness versus recovery speed"],"misuse_risks":["treating elected leader as unconditionally authoritative","relying on process identity without fencing"],"metrics_for_success":["election duration","term churn","simultaneous candidates","stale-term rejection"],"ethical_or_safety_notes":["Operational override of elections must remain governed and auditable."]},"examples":{"examples":[{"domain":"replicated_log","example":"A candidate with an up-to-date log wins a majority in a new persisted term.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["The first node to boot declares itself leader forever."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","fencing_review"],"notes":"Reconcile with existing leader-election mechanisms."}}
Authenticated Vote Certificate (`authenticated_vote_certificate`) ↗	Type: `artifact` {"short_definition":"Packages unique identity-bound votes as portable, independently verifiable proof of a protocol transition or decision.","expanded_definition":"Carries instance, epoch, phase, value digest, signer set or aggregate proof, quorum rule version, and validation metadata needed by learners and recovery agents.","mechanism_not_archetype_reason":"It is a proof artifact produced by a consensus protocol, not the lifecycle that creates safe agreement."} Selection constraints and retained implementation evidence: stable encoding; trustworthy identity map; algorithm and key lifecycle support; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"authenticated_vote_certificate","name":"Authenticated Vote Certificate","aliases":["consensus_decision_certificate"]},"classification":{"mechanism_type":"artifact","domain_specificity":"domain_specific","maturity":"common"},"definition":{"short_definition":"Packages unique identity-bound votes as portable, independently verifiable proof of a protocol transition or decision.","expanded_definition":"Carries instance, epoch, phase, value digest, signer set or aggregate proof, quorum rule version, and validation metadata needed by learners and recovery agents.","mechanism_not_archetype_reason":"It is a proof artifact produced by a consensus protocol, not the lifecycle that creates safe agreement."},"implementation":{"operating_logic":"Normalize the claimed transition, verify every unique eligible signer and protected field, check the epoch-specific quorum predicate, and retain the certificate with the decision.","typical_steps":["canonicalize the decision statement","collect identity-bound votes","reject duplicates and stale epochs","verify signatures or trusted attestations","check quorum threshold and intersection context","bind certificate to outcome","retain for audit and recovery"],"required_inputs":["membership configuration","quorum rule","protected vote fields","verification keys"],"outputs_or_deliverables":["portable decision or phase certificate","signer and weight summary"],"required_conditions":["stable encoding","trustworthy identity map","algorithm and key lifecycle support"],"failure_conditions":["duplicate signer count","missing epoch","ambiguous value encoding","revoked key accepted"],"maintenance_or_update_needs":["cryptographic agility","certificate-format versioning","long-term verification test"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"portable decision-evidence artifact"}],"supports_components":["quorum_and_intersection_policy","cryptographic_identity_and_vote_proof","durable_decision_evidence_log"],"can_be_confused_with_archetypes":[],"neighboring_mechanisms":["byzantine_fault_quorum_protocol","joint_consensus_reconfiguration"]},"operational_profile":{"strengths":["independent verification","compact handoff","attributable evidence","recovery support"],"limitations":["depends on correct quorum context and key governance","may be large without aggregation"],"tradeoffs":["aggregate proof size versus complexity and signer transparency"],"misuse_risks":["verifying signatures but not eligibility","replaying a certificate in another epoch","treating certificate as truth"],"metrics_for_success":["verification failure rate","duplicate signer rejection","certificate size and latency"],"ethical_or_safety_notes":["A valid certificate proves authorized technical agreement only."]},"examples":{"examples":[{"domain":"Byzantine_registry","example":"A certificate binds a configuration digest to one epoch and sufficient authenticated voting weight.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["A leader-signed statement saying that everyone agreed."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","cryptographic_review"],"notes":"Check alias collisions with consensus_vote and certificate artifacts."}}
Joint Consensus Reconfiguration (`joint_consensus_reconfiguration`) ↗	Type: `protocol` {"short_definition":"Changes voting membership through an overlap phase that prevents old and new configurations from deciding independently.","expanded_definition":"Represents both configurations in a certified transition state, applies the declared old/new quorum rule, and activates the new-only epoch only after the transition decision is durable.","mechanism_not_archetype_reason":"It is a membership-change protocol inside the broader consensus lifecycle."} Selection constraints and retained implementation evidence: one governed transition; old quorum initially available; joining nodes recover safely; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"joint_consensus_reconfiguration","name":"Joint Consensus Reconfiguration","aliases":["overlap_preserving_membership_transition"]},"classification":{"mechanism_type":"protocol","domain_specificity":"domain_specific","maturity":"specialized"},"definition":{"short_definition":"Changes voting membership through an overlap phase that prevents old and new configurations from deciding independently.","expanded_definition":"Represents both configurations in a certified transition state, applies the declared old/new quorum rule, and activates the new-only epoch only after the transition decision is durable.","mechanism_not_archetype_reason":"It is a membership-change protocol inside the broader consensus lifecycle."},"implementation":{"operating_logic":"Propose a joint configuration under current authority, require overlap-preserving evidence, commit and apply it, then certify a new-only configuration after required learners are ready.","typical_steps":["validate the requested change","calculate old and new quorum geometry","commit joint state","distribute state to joining nodes","verify readiness","commit new-only state","fence removed voters","retain transition evidence"],"required_inputs":["old configuration","new configuration","quorum policies","joining-node recovery evidence"],"outputs_or_deliverables":["certified joint epoch","certified new-only epoch","removal and fencing record"],"required_conditions":["one governed transition","old quorum initially available","joining nodes recover safely"],"failure_conditions":["one-step replacement","concurrent uncoordinated transitions","removed voter still accepted"],"maintenance_or_update_needs":["reconfiguration drills","quorum calculator tests","stale-voter rejection audit"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"membership transition mechanism"}],"supports_components":["membership_configuration","quorum_and_intersection_policy","recovery_and_reconfiguration_rule"],"can_be_confused_with_archetypes":["nested_and_distributed_transaction_coordination"],"neighboring_mechanisms":["authenticated_vote_certificate","replicated_log_consensus_engine"]},"operational_profile":{"strengths":["preserves authority continuity","explicit audit path","supports rolling replacement"],"limitations":["temporarily stricter availability","operational complexity","requires careful catch-up"],"tradeoffs":["transition safety versus maintenance speed"],"misuse_risks":["skipping joint phase under urgency","activating an unready voter","forgetting external fencing"],"metrics_for_success":["transition duration","joint-quorum availability","joining-node lag","stale-epoch rejection"],"ethical_or_safety_notes":["Membership changes alter technical authority and need governed authorization."]},"examples":{"examples":[{"domain":"database_cluster","example":"Old and new voter sets jointly certify transition before old voters are removed.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["Edit every node's configuration file independently."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","reconfiguration_review"],"notes":"Check for generic joint-configuration components before indexing."}}
Randomized Asynchrony Breaker (`randomized_asynchrony_breaker`) ↗	Type: `method` {"short_definition":"Uses unpredictable choices to obtain probabilistic progress when deterministic scheduling can perpetually prevent termination.","expanded_definition":"Introduces random candidate timing, proposal selection, committee sampling, or a common random signal while preserving safety independently of the random outcome.","mechanism_not_archetype_reason":"Randomization is one liveness technique within consensus, not the complete agreement pattern."} Selection constraints and retained implementation evidence: safety does not depend on favorable randomness; source is sufficiently unpredictable and available; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"randomized_asynchrony_breaker","name":"Randomized Asynchrony Breaker","aliases":["randomized_consensus_progress_mechanism"]},"classification":{"mechanism_type":"method","domain_specificity":"domain_specific","maturity":"specialized"},"definition":{"short_definition":"Uses unpredictable choices to obtain probabilistic progress when deterministic scheduling can perpetually prevent termination.","expanded_definition":"Introduces random candidate timing, proposal selection, committee sampling, or a common random signal while preserving safety independently of the random outcome.","mechanism_not_archetype_reason":"Randomization is one liveness technique within consensus, not the complete agreement pattern."},"implementation":{"operating_logic":"Generate an unbiased or sufficiently unpredictable choice, bind it to the instance and round, use it only in allowed progress transitions, and expose the probability assumptions.","typical_steps":["define the adversarial scheduler","select randomness source","bind output to instance and epoch","verify availability and unpredictability","use result to break symmetry","measure tail termination behavior"],"required_inputs":["liveness model","entropy or common-randomness source","bias and availability assumptions"],"outputs_or_deliverables":["round-specific random choice","progress evidence","statistical termination profile"],"required_conditions":["safety does not depend on favorable randomness","source is sufficiently unpredictable and available"],"failure_conditions":["biased source","reused randomness","adversary predicts the choice","tail latency hidden"],"maintenance_or_update_needs":["entropy health checks","adversarial tests","probability-model review"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"probabilistic liveness mechanism"}],"supports_components":["liveness_property_specification","timeout_retry_and_backoff_policy"],"can_be_confused_with_archetypes":[],"neighboring_mechanisms":["failure_detector_and_heartbeat_service","byzantine_fault_quorum_protocol"]},"operational_profile":{"strengths":["breaks symmetry under hostile schedules","supports probabilistic termination arguments"],"limitations":["tail behavior","randomness governance","harder reproducibility"],"tradeoffs":["unpredictability and distribution cost versus progress probability"],"misuse_risks":["claiming deterministic termination","using weak correlated randomness","allowing randomness to bypass validity"],"metrics_for_success":["rounds to decision distribution","entropy failures","bias tests","tail decision latency"],"ethical_or_safety_notes":["Probability and reversal risk must be communicated honestly to affected users."]},"examples":{"examples":[{"domain":"asynchronous_protocol","example":"A verifiable common random value chooses the next admissible proposal path.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["Randomly pick a value and call it valid."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","probabilistic_liveness_review"],"notes":"Specialist review required."}}
Failure Detector and Heartbeat Service (`failure_detector_and_heartbeat_service`) ↗	Type: `software_or_tool` {"short_definition":"Supplies imperfect liveness hints for election, retry, routing, and diagnostics without authorizing decisions.","expanded_definition":"Exchanges heartbeats or probes, measures delay and progress, emits suspicion levels, and adapts thresholds while preserving the distinction between suspicion and proof.","mechanism_not_archetype_reason":"It supports progress and observation but cannot establish agreement or validity."} Selection constraints and retained implementation evidence: safety rules ignore unproved absence; probes cannot overload the system; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"failure_detector_and_heartbeat_service","name":"Failure Detector and Heartbeat Service","aliases":["consensus_liveness_detector"]},"classification":{"mechanism_type":"software_or_tool","domain_specificity":"cross_domain_with_adaptation","maturity":"common"},"definition":{"short_definition":"Supplies imperfect liveness hints for election, retry, routing, and diagnostics without authorizing decisions.","expanded_definition":"Exchanges heartbeats or probes, measures delay and progress, emits suspicion levels, and adapts thresholds while preserving the distinction between suspicion and proof.","mechanism_not_archetype_reason":"It supports progress and observation but cannot establish agreement or validity."},"implementation":{"operating_logic":"Sample peer and protocol progress, update suspicion after bounded evidence, trigger allowed liveness actions, and retract suspicion when newer evidence arrives.","typical_steps":["send or observe heartbeat","record epoch and progress position","estimate delay distribution","mark suspicion after policy threshold","initiate retry or election","clear or escalate based on later evidence"],"required_inputs":["peer registry","timing policy","progress indicators","network and overload context"],"outputs_or_deliverables":["suspicion signal","delay and reachability metrics","election trigger"],"required_conditions":["safety rules ignore unproved absence","probes cannot overload the system"],"failure_conditions":["false suspicion storm","correlated probe failure","stale heartbeat accepted","detector treated as oracle"],"maintenance_or_update_needs":["threshold tuning","overload tests","clock and pause analysis","telemetry retention"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"liveness and observability support"}],"supports_components":["timeout_retry_and_backoff_policy","consensus_observability_boundary","liveness_property_specification"],"can_be_confused_with_archetypes":[],"neighboring_mechanisms":["leader_election_and_term_protocol","randomized_asynchrony_breaker"]},"operational_profile":{"strengths":["faster reaction to failure","actionable diagnostics","adaptive delay awareness"],"limitations":["cannot distinguish delay from failure perfectly","can amplify overload"],"tradeoffs":["detection speed versus false positives","probe volume versus visibility"],"misuse_risks":["removing voters on one missed heartbeat","committing from reachability alone"],"metrics_for_success":["false suspicion rate","detection delay","probe overhead","correlation with term churn"],"ethical_or_safety_notes":["Automated removal changes authority and should require the reconfiguration protocol."]},"examples":{"examples":[{"domain":"replicated_log","example":"Progress-aware heartbeats trigger a new election without proving the leader has failed.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["A ping result directly changes the committed membership."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","overload_review"],"notes":"Reconcile with generic failure-detection mechanisms."}}
Deterministic State-Machine Application (`deterministic_state_machine_application`) ↗	Type: `workflow` {"short_definition":"Applies the same certified command sequence to replicas with deterministic inputs, deduplication, and result recording.","expanded_definition":"Converts agreement on order into matching application state by versioning command semantics, externalizing nondeterministic inputs, and separating commit from effect execution.","mechanism_not_archetype_reason":"It operationalizes decided commands after consensus and does not itself create a decision certificate."} Selection constraints and retained implementation evidence: deterministic execution; compatible versions; idempotent recovery; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"deterministic_state_machine_application","name":"Deterministic State-Machine Application","aliases":["consensus_log_application_loop"]},"classification":{"mechanism_type":"workflow","domain_specificity":"domain_specific","maturity":"common"},"definition":{"short_definition":"Applies the same certified command sequence to replicas with deterministic inputs, deduplication, and result recording.","expanded_definition":"Converts agreement on order into matching application state by versioning command semantics, externalizing nondeterministic inputs, and separating commit from effect execution.","mechanism_not_archetype_reason":"It operationalizes decided commands after consensus and does not itself create a decision certificate."},"implementation":{"operating_logic":"Read the next committed command, verify version and prerequisites, deduplicate client identity, apply deterministically, persist state and result, and advance the applied boundary.","typical_steps":["load committed prefix","verify command schema","resolve all nondeterministic input from the command","check client sequence","execute state transition","persist result and applied index","compare state digest","expose outcome"],"required_inputs":["committed ordered log","versioned state machine","client command identity"],"outputs_or_deliverables":["applied state","stable client result","state digest and applied index"],"required_conditions":["deterministic execution","compatible versions","idempotent recovery"],"failure_conditions":["local time or randomness divergence","duplicate effect","incompatible upgrade","effect before commit"],"maintenance_or_update_needs":["cross-version replay tests","state digest comparison","upgrade sequencing","dedup retention review"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"replicated-log application mechanism"}],"supports_components":["decision_value_domain","client_command_deduplication_window","checkpoint_and_snapshot_policy"],"can_be_confused_with_archetypes":["nested_and_distributed_transaction_coordination"],"neighboring_mechanisms":["replicated_log_consensus_engine"]},"operational_profile":{"strengths":["matching replica state","retry-safe results","auditable applied boundary"],"limitations":["cannot make uncontrolled external effects deterministic","requires version discipline"],"tradeoffs":["synchronous effect confirmation versus throughput","result retention versus storage"],"misuse_risks":["assuming exactly-once external execution","applying before commit","hiding application errors"],"metrics_for_success":["commit-to-apply lag","state digest mismatch","duplicate suppression","replay failures"],"ethical_or_safety_notes":["Commands affecting people require domain authorization and appeal beyond protocol agreement."]},"examples":{"examples":[{"domain":"key_value_store","example":"Each replica applies the same committed put command and returns the retained client result.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["Each replica reads its own wall clock while applying the same command."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","application_safety_review"],"notes":"Keep external transaction semantics out of this mechanism."}}
Consensus Safety Model Check (`consensus_safety_model_check`) ↗	Type: `test_or_assessment` {"short_definition":"Explores protocol interleavings, failures, recovery, and membership changes to find violations of formal consensus invariants.","expanded_definition":"Encodes state, messages, faults, storage, quorums, and transitions in a bounded or symbolic model and checks agreement, validity, fencing, and recovery properties across schedules ordinary tests rarely reach.","mechanism_not_archetype_reason":"It validates a design; it does not operate the production agreement protocol."} Selection constraints and retained implementation evidence: model corresponds to implementation decisions; state reduction does not erase the bug class; Complete legacy mechanism record retained: {"metadata":{"schema_version":"1.0","artifact_type":"solution_mechanism","status":"draft","source":"phase_02_related_only_coverage_batch_002/fault_tolerant_distributed_consensus"},"identity":{"slug":"consensus_safety_model_check","name":"Consensus Safety Model Check","aliases":["distributed_protocol_invariant_model_check"]},"classification":{"mechanism_type":"test_or_assessment","domain_specificity":"domain_specific","maturity":"specialized"},"definition":{"short_definition":"Explores protocol interleavings, failures, recovery, and membership changes to find violations of formal consensus invariants.","expanded_definition":"Encodes state, messages, faults, storage, quorums, and transitions in a bounded or symbolic model and checks agreement, validity, fencing, and recovery properties across schedules ordinary tests rarely reach.","mechanism_not_archetype_reason":"It validates a design; it does not operate the production agreement protocol."},"implementation":{"operating_logic":"Translate the protocol and assumptions into an executable formal model, state invariants, explore schedules and faults, minimize counterexamples, and bind fixes back to implementation tests.","typical_steps":["define abstract state and actors","encode message and crash transitions","encode durable and volatile storage","assert safety invariants","constrain only declared assumptions","explore interleavings","inspect minimal counterexample","patch design and regression model"],"required_inputs":["protocol specification","fault and timing model","quorum rules","safety properties"],"outputs_or_deliverables":["checked model","coverage bounds","counterexample traces","regression properties"],"required_conditions":["model corresponds to implementation decisions","state reduction does not erase the bug class"],"failure_conditions":["overconstrained network","omitted recovery path","incorrect abstraction","treating bounded check as universal proof"],"maintenance_or_update_needs":["update after protocol change","link counterexamples to tests","review assumptions and bounds"]},"archetype_links":{"instantiates_archetypes":[{"slug":"fault_tolerant_distributed_consensus","role":"design verification mechanism"}],"supports_components":["safety_property_specification","protocol_phase_and_message_state","recovery_and_reconfiguration_rule"],"can_be_confused_with_archetypes":[],"neighboring_mechanisms":["crash_fault_quorum_protocol","byzantine_fault_quorum_protocol"]},"operational_profile":{"strengths":["finds rare interleaving bugs","explicit assumptions","replayable counterexamples"],"limitations":["abstraction and state-space limits","does not validate deployment or code by itself"],"tradeoffs":["model fidelity versus tractability","exhaustive small bounds versus sampled large cases"],"misuse_risks":["claiming full correctness from a weak model","omitting operator and reconfiguration paths"],"metrics_for_success":["states and transitions explored","invariant coverage","counterexamples converted to tests","model-to-code drift"],"ethical_or_safety_notes":["Communicate proof and exploration bounds precisely; do not market bounded evidence as absolute safety."]},"examples":{"examples":[{"domain":"protocol_design","example":"A model explores crash between durable vote and acknowledgment plus concurrent reconfiguration.","archetype_instantiated":"fault_tolerant_distributed_consensus"}],"non_examples":["A happy-path integration test with no message reordering."]},"review":{"review_status":"not_reviewed","review_flags":["mechanism_extraction_review","formal_methods_review"],"notes":"Retain model assumptions in quality review."}}

Authenticated Vote Certificate
Byzantine-Fault Quorum Protocol
Consensus Safety Model Check
Crash-Fault Quorum Protocol
Deterministic State-Machine Application
Failure Detector and Heartbeat Service
Joint Consensus Reconfiguration
Leader Election and Term Protocol
Randomized Asynchrony Breaker
Replicated Log Consensus Engine

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.

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

Built directly on (4)

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