Deadlock Prevention

batch: First Iteration/Batch 11

aliases:
circular wait prevention
resource acquisition ordering
hold-and-wait prevention
deadlock avoidance
lock-order deadlock prevention
stalemate prevention

source_primes: deadlock resource_management order

related_primes: blocking concurrency scheduling constraint transaction coupling task_interdependence queueing state_and_state_transition

slug: deadlock

slug: order

slug: blocking

slug: concurrency

slug: scheduling

slug: constraint

slug: coupling

slug: queueing

components:
Shared Resource Inventory
Actor / Process Map
Wait-For Dependency Map
Circular Wait Risk Model
Resource Acquisition Order Rule
Hold-and-Wait Limit
Preemption or Release Rule
Timeout or Lease Rule
Safe-State Admission Criterion
Rollback and Recovery Path
Contention Monitoring Signal
Exception and Escalation Path
Resource Pooling or Buffer
Priority Tie-Breaker
Contention Test Scenario

mechanisms:
Lock Ordering Protocol
Resource Acquisition Protocol
All-or-Nothing Acquisition
Try-Lock and Backoff
Timeout Policy
Lease-Based Resource Hold
Safe-State Admission Check
Preemption with Rollback
Agenda Ordering Rule
Reservation and Capacity Escrow

essence_one_line: Structure resource acquisition, authority, or sequencing so circular blocking cannot arise.

compression_statement: When multiple actors, processes, tasks, or parties can each hold a needed resource, commitment, lock, approval, or authority while waiting for another, prevent deadlock by changing the rules of acquisition, holding, release, ordering, admission, timeout, or preemption so a circular wait state is not reachable.

core_intuition: A deadlock is not just a slow queue; it is a self-sustaining blocked structure. Prevention works by removing one of the conditions that makes that structure possible before the system reaches it: inconsistent acquisition order, indefinite holding while waiting, non-preemptable claims, or unsafe admission of new requests.

canonical_formula: For actors/processes P and resources/commitments R, prevent any reachable state where P1 waits for R2 held by P2, P2 waits for R3 held by P3, ..., and Pn waits for R1 held by P1; break reachability through order, release, preemption, timeout, or safe-state admission.

structural_problem: A system contains multiple actors or processes that need shared resources, permissions, commitments, or sequencing positions. Each can acquire and hold part of what it needs while waiting for something held by another actor. Under the wrong interleaving, the system can enter a circular wait in which no participant can proceed and none is structurally forced to release what others need.

condition: Actors or processes acquire more than one resource, permission, lock, commitment, or approval.

rationale: Single-resource contention can create queues, but deadlock risk grows when participants can hold one thing while requesting another.

condition: Resources are scarce, exclusive, or effectively non-shareable during use.

rationale: If resources can be freely shared without blocking, the circular wait structure has less force. Exclusive claims create the hold condition.

condition: Different participants acquire resources in different orders.

rationale: Inconsistent ordering allows one participant to hold A while waiting for B and another to hold B while waiting for A.

condition: Release, rollback, timeout, or preemption is absent, unsafe, or socially costly.

rationale: If held resources cannot be taken back or released safely, a partial acquisition can become a hard block.

condition: Negotiations, approvals, or governance steps allow mutual hostage-taking.

rationale: Deadlock can occur in human systems when parties each control something another party needs and procedural design lets everyone wait for everyone else.

condition: High-contention periods, rare interleavings, or crisis conditions change normal waiting into circular blocking.

rationale: Deadlocks often appear under load, urgency, or unusual sequencing, so prevention should target reachable states rather than average conditions only.

symptom: Work stops even though the necessary resources still exist somewhere in the system.

diagnostic_meaning: The problem is not simple absence of resources; it is the blocked configuration of claims and waits.

symptom: Each participant is waiting for another participant to act first.

diagnostic_meaning: A circular wait or mutual hostage-taking pattern may be possible or already near formation.

symptom: The same workflow succeeds in isolation but stalls when run concurrently with similar workflows.

diagnostic_meaning: The shared-resource interleaving, not the individual workflow, is the likely source of risk.

symptom: Escalations repeatedly break stalemates that routine process design should have prevented.

diagnostic_meaning: The system is relying on after-the-fact resolution because prevention rules are missing or weak.

symptom: Local teams invent different acquisition or approval sequences for the same shared resources.

diagnostic_meaning: Inconsistent local ordering can create global circular wait risk.

symptom: Timeouts, releases, or retries exist informally but are not connected to a recoverable state.

diagnostic_meaning: The system has partial prevention mechanisms without safe recovery design.

root_tension: Each actor wants to protect progress by holding what it has already acquired, but when everyone does that while waiting for the next scarce thing, the aggregate result can be total loss of progress. Local prudence becomes global paralysis.

case: A system is already stuck in a concrete circular wait state.

why_not: Use Deadlock Resolution, which detects and breaks an existing cycle. Prevention is for design before the cycle forms.

case: A queue is merely long because demand exceeds capacity, but jobs eventually move forward in order.

why_not: Use queue discipline, capacity adjustment, load shedding, or resource rationing; a long queue is not necessarily a deadlock.

case: Tasks have dependencies, but the dependency graph is acyclic and well sequenced.

why_not: Use dependency ordering or stage-gate progression. Deadlock prevention specifically targets circular blocking risk.

case: One actor refuses to cooperate despite having no resource interdependence cycle.

why_not: Use incentive alignment, conflict resolution, accountability, or adjudication rather than deadlock prevention.

case: Scarcity requires choosing who gets resources, but no participant holds resources while waiting for others.

why_not: Use priority-based admission, resource rationing, or allocation design rather than a deadlock-specific pattern.

case: The goal is to optimize throughput rather than preserve liveness under circular wait risk.

why_not: Use throughput optimization or queue management unless circular blocking is the structural failure mode.

structural_intervention: Make deadlock states unreachable by altering at least one structural precondition of circular blocking: require consistent acquisition order, prevent indefinite hold-and-wait, make claims time-bounded or preemptable, admit only safe states, reserve linked resources together, or define release and escalation rules before actors begin competing for resources.

action: Inventory resources and holders.

logic: Identify what can be held, by whom, for how long, under what authority, and with what release cost. Include technical locks, physical assets, approvals, agenda slots, commitments, credentials, staff capacity, and attention.

action: Map possible wait-for cycles.

logic: Represent which actor or process can wait for which resource and who can hold it. Look for cycles that could arise from realistic acquisition sequences, not only current average behavior.

action: Choose which deadlock precondition to remove.

logic: Decide whether the best lever is ordering, all-or-nothing acquisition, bounded holding, preemption, safe-state admission, resource pooling, or procedural sequencing.

action: Encode the prevention rule where acquisition happens.

logic: Put the rule into protocols, APIs, workflow gates, calendars, authorization systems, contract terms, meeting rules, or scheduling tools rather than relying on memory or goodwill.

action: Design release and recovery paths.

logic: If a timeout, preemption, backoff, or refusal occurs, the system must return to a coherent state without losing data, trust, fairness, safety, or accountability.

action: Test high-contention and edge-case interleavings.

logic: Deadlock risk often hides in rare sequences. Stress tests, simulations, tabletop exercises, and negotiation rehearsals can reveal whether the prevention rule actually blocks cycles.

action: Monitor near-misses and rule drift.

logic: Track long waits, repeated retries, inconsistent orderings, informal exceptions, and escalation frequency. Update prevention rules when new resources, actors, workloads, or dependencies appear.

rule: Use prevention when circular blocking can be anticipated before operation.

rationale: If the cycle is already active, resolution is required; if potential cycles are visible in design, prevention is cheaper and safer.

rule: Prefer a consistent acquisition order when resources are enumerable and ordering does not impose excessive bottlenecks.

rationale: Ordering directly eliminates circular wait, but it can reduce parallelism if applied too broadly.

rule: Prefer hold-and-wait limits when partial acquisition is the dominant risk and release is safe.

rationale: All-or-nothing acquisition or release-before-request prevents participants from accumulating hostage positions.

rule: Prefer timeout, lease, or preemption rules when indefinite holding is the dominant risk.

rationale: Time-bounded or revocable claims prevent permanent capture, but they require recovery paths.

rule: Prefer safe-state admission when future needs can be estimated and a completion path can be checked.

rationale: Admission control avoids unsafe states without imposing one rigid global order on every resource.

rule: Do not add prevention rules that solve deadlock by creating starvation, corruption, or hidden unfairness.

rationale: Liveness should improve without permanently excluding low-power actors, losing work, or damaging trust.

invariant: No reachable circular wait state remains under normal operating rules.

preservation_reason: This is the central invariant: the system should not be able to reach a state where every participant in a cycle waits for another.

invariant: Resource release, preemption, timeout, or refusal leaves a coherent state.

preservation_reason: Preventing deadlock by corrupting records, breaking commitments, or destroying trust is not a successful intervention.

invariant: Prevention rules are applied consistently across local actors.

preservation_reason: Conflicting local interpretations of ordering or release rules can recreate the circular risk the archetype is meant to remove.

invariant: Progress remains possible for legitimate low-priority or low-power participants.

preservation_reason: A system can avoid deadlock by starving some actors forever, but that substitutes one liveness failure for another.

invariant: Exceptions are visible, accountable, and recoverable.

preservation_reason: Exception paths are necessary in complex systems, but hidden exceptions are a common source of deadlock reintroduction.

outcome: Circular blocking states become structurally unreachable or rare enough to manage safely.

evaluation_signal: Wait-for cycles, emergency escalations, and hard stalls decline under high-contention conditions.

outcome: Actors know how to acquire and release resources without improvising under pressure.

evaluation_signal: Protocols, schedules, approval paths, or negotiation procedures show consistent ordering and bounded holding rules.

outcome: Throughput becomes more predictable during contention.

evaluation_signal: Work may queue or back off, but it does not freeze indefinitely due to circular wait.

outcome: Escalation is reserved for exceptions rather than routine cycle-breaking.

evaluation_signal: Fewer cases require managers, arbitrators, incident commanders, or external authorities to break routine stalls.

outcome: Near-deadlock states become observable and correctable.

evaluation_signal: Long waits, backoff storms, conflicting acquisition sequences, and recurring hostage-like negotiations are logged and reviewed.

prose_essence:
Deadlock Prevention is the design pattern for making circular blocking unreachable before it occurs. It applies when multiple actors, processes, tasks, services, or parties can each hold something another needs while waiting for the next thing they need. The intervention is not merely to tell everyone to move faster. It changes the acquisition, holding, release, ordering, admission, or timeout rules so the system cannot settle into a state where every participant is waiting for another participant to act first.

The simplest intuition is: do not let local self-protection become global paralysis. A process that keeps its lock while waiting for another lock, a team that keeps an approval slot while waiting for another team, or a negotiating party that banks a concession while waiting for a reciprocal move can all be locally rational. Deadlock prevention changes the rules so those local actions cannot combine into a circular wait.

prose_when_to_use:
Use this archetype when the risk is a possible circular wait, not just a long delay. The key question is whether participants can hold one resource, commitment, approval, lock, or authority point while waiting for another participant who is doing the same thing. The pattern is especially useful before high-contention operations, concurrent software execution, multi-resource scheduling, approval workflows, infrastructure deployments, and negotiations where parties can hold dependent commitments hostage.

This archetype is also appropriate when past incidents were resolved by escalation, restart, or force, but the same kind of stall keeps recurring. That recurrence often means the system has a prevention problem: it allows a circular blocked state to become reachable and then relies on heroic after-the-fact intervention.

prose_structural_problem:
The structural problem is a reachable circular wait. There are at least two participants, and often many more. Each participant can hold a resource or commitment that someone else needs. Each can wait for another resource or commitment before releasing what they already hold. If no rule forces release, consistent ordering, safe admission, or preemption, the system can freeze even though every necessary resource still exists somewhere in the system.

This differs from ordinary scarcity. In a queue, people may wait because a resource is scarce, but the line can still move. In a deadlock risk, the waiting structure can become self-sustaining: A waits for B, B waits for C, and C waits for A. No participant can finish without another moving first.

prose_intervention_logic:
The intervention removes at least one precondition that makes circular blocking possible. The most common route is a consistent resource acquisition order: everyone acquires resources in the same sequence, so cycles cannot form. Another route is to eliminate hold-and-wait: participants must acquire everything they need together or release what they hold and retry. A third route is to make claims time-bounded or preemptable through timeouts, leases, rollback, or release rules. A fourth route is safe-state admission: new requests are admitted only if the resulting state still has a feasible completion path.

The best intervention depends on which precondition is easiest and safest to change. Technical systems often use lock ordering, timeouts, leases, and admission checks. Human systems often use agenda ordering, conditional commitments, release norms, and explicit escalation paths. Across domains, the logic is the same: prevent a circular wait from becoming reachable rather than waiting until the system is already stuck.

prose_key_components:
### Shared Resource Inventory

A shared resource inventory names the things that can be held while others wait. These may be locks, database rows, machines, rooms, staff, approvals, budget, agenda slots, credentials, rollback capacity, or social commitments. This component matters because deadlocks often involve hidden resources that are not obvious in a normal task list.

### Actor / Process Map

The actor or process map identifies who can acquire, hold, request, and release resources. In software, these may be threads, services, transactions, or jobs. In organizations, they may be teams, reviewers, agencies, vendors, or negotiating parties. The prevention rule needs to attach to these concrete participants.

### Wait-For Dependency Map

The wait-for dependency map shows who may wait for whom, or which process may wait for which held resource. It turns a vague fear of stalling into an analyzable structure. The important feature is the possible cycle, not just the presence of dependencies.

### Circular Wait Risk Model

The circular wait risk model states the conditions under which the system can enter a cycle. It asks: Which resources can be held at the same time? Which requests can happen while holding? Which releases are optional? Which interleavings or negotiation sequences could produce mutual blocking?

### Resource Acquisition Order Rule

A resource acquisition order rule imposes a consistent sequence for acquiring resources. In software this may be a lock hierarchy. In project governance it may be a fixed review order. In negotiation it may be a pre-agreed agenda sequence. The point is to stop participants from taking resources in conflicting sequences.

### Hold-and-Wait Limit

A hold-and-wait limit prevents participants from keeping one resource indefinitely while waiting for another. It can require all-or-nothing acquisition, release-before-request, retry after release, or explicit approval for partial holds. This component directly attacks one of the most common structures behind deadlock.

### Preemption or Release Rule

A preemption or release rule defines when a held claim can be revoked, released, reassigned, or suspended. This can preserve liveness, but only when release is safe. In social systems, release rules must preserve legitimacy and avoid simply forcing weaker participants to bear the cost of progress.

### Timeout or Lease Rule

A timeout or lease rule makes holding or waiting time-bounded. The resource is not captured forever; it expires, renews, or triggers review. This is useful when indefinite holding is the main risk, but it must be paired with recovery logic so expiration does not corrupt the system.

### Safe-State Admission Criterion

A safe-state admission criterion checks whether admitting a new request leaves at least one feasible completion path. This is the heart of deadlock-avoidance variants. It is useful when the system can estimate future resource needs before accepting work, patients, transactions, deployments, or commitments.

### Rollback and Recovery Path

A rollback and recovery path ensures that prevention actions leave the system coherent. If a timeout, preemption, release, or refusal happens, the system needs a safe state to return to. Without this component, deadlock prevention can create broken records, lost work, unfair forfeiture, or damaged trust.

### Contention Monitoring Signal

A contention monitoring signal tracks near-deadlocks: long waits, repeated backoffs, growing wait chains, conflicting local orderings, and recurring hostage-like negotiations. Prevention rules drift as systems evolve, so monitoring keeps the design connected to actual risk.

prose_common_mechanisms:
### Lock Ordering Protocol

A lock ordering protocol is a software mechanism that requires all processes to acquire locks in the same order. It is one implementation of Deadlock Prevention, not the archetype itself. The archetype is broader because it also includes timeouts, leases, safe-state checks, release rules, and human procedural designs.

### Resource Acquisition Protocol

A resource acquisition protocol specifies how resources are requested, acquired, held, and released. It operationalizes the prevention rule at the point where deadlock risk begins: the moment a participant claims something while still needing something else.

### All-or-Nothing Acquisition

All-or-nothing acquisition prevents partial holds. A process or actor gets the full required bundle or releases everything and retries later. This can be effective in operations and scheduling, but it may be costly if the required bundle is large or uncertain.

### Try-Lock and Backoff

Try-lock and backoff lets a process attempt acquisition without waiting forever. If it cannot acquire what it needs, it releases, backs off, waits, or retries. This mechanism prevents indefinite blocking but must be tuned to avoid synchronized retry storms.

### Timeout Policy

A timeout policy caps how long a participant can wait or hold. It helps prevent indefinite circular blocking, but it is not sufficient by itself. A timeout without recovery design can produce churn, lost work, or unfair release.

### Lease-Based Resource Hold

A lease-based hold grants access for a defined period, with renewal required for continued holding. Leases are common in distributed systems, but analogous structures appear in administration, contracts, and scheduling when claims expire unless reaffirmed.

### Safe-State Admission Check

A safe-state admission check asks whether a proposed new request keeps the system in a state from which all admitted work can still complete. This implements the safe-state variant and is especially useful where future needs can be estimated.

### Preemption with Rollback

Preemption with rollback takes back a held resource or commitment before a deadlock can harden, while rollback restores a coherent prior state. This mechanism is powerful but risky when release damages trust, safety, or data integrity.

### Agenda Ordering Rule

An agenda ordering rule brings the logic into human governance. By sequencing issues, claims, concessions, or approvals, it prevents each party from holding one issue hostage while waiting for another party to move first.

### Reservation and Capacity Escrow

Reservation and capacity escrow reserve linked resources together or hold reciprocal commitments conditionally. This prevents partial capture of one scarce element while the participant waits indefinitely for another.

prose_failure_modes:
One common failure mode is hidden resource omission. The design orders rooms and equipment but forgets staff attention, rollback capacity, approval authority, or agenda control. Another is inconsistent local ordering: each team has a sensible local rule, but the rules conflict globally. A third is over-conservative serialization, where everything becomes safe but slow. A fourth is unsafe preemption, where the system avoids deadlock by causing corruption, broken commitments, or unfair forfeiture.

Timeout churn is another failure mode. If timeouts are too short or retries are synchronized, the system may repeatedly abort and re-contend without making progress. Exception-path erosion is also dangerous: informal overrides can quietly reintroduce the circular wait that the formal rule was meant to remove.

prose_neighbor_distinctions: Deadlock Prevention is distinct from Deadlock Resolution. Prevention acts before the cycle exists; resolution breaks a cycle that already exists. It is distinct from Dependency Ordering because not every dependency order is about held resources and circular wait. It is distinct from Queue Discipline Design because a queue can be long without being circular. It is distinct from Resource Rationing because rationing decides who gets scarce resources, while prevention governs how claims interact so nobody traps the system in a cycle. It is distinct from Stage-Gate Progression because gates sequence evaluation, whereas deadlock prevention targets liveness under shared-resource contention.

prose_cross_domain_examples:
In software, a lock hierarchy prevents threads from taking locks in conflicting order. In databases, safe-state admission prevents transactions from entering a resource configuration with no feasible completion sequence. In hospital scheduling, linked reservation prevents a room, equipment, bed, and staff from being captured separately in a way that strands the procedure. In cloud deployment, rollback capacity and lease-based holds prevent rollout and recovery systems from blocking one another. In negotiation, agenda ordering and conditional commitments prevent each party from holding one concession while waiting for another.

These examples differ in vocabulary, but their structure is the same: define what can be held, identify circular wait risk, and change the rules so the cycle cannot form.

prose_non_examples: A long checkout line is not Deadlock Prevention unless customers or clerks are holding resources that create circular waits. A single uncooperative manager is not a deadlock unless that manager is part of a mutual blocking cycle. A project with a long but acyclic dependency chain needs dependency management, not deadlock prevention. Killing a process after detecting a wait-for cycle is Deadlock Resolution, not prevention. A priority policy that serves urgent cases first is resource allocation unless it specifically prevents circular holding.

prose_tradeoffs:
The main tradeoff is liveness versus concurrency. Strong prevention can make deadlock impossible, but it can also serialize work that could have proceeded in parallel. Another tradeoff is simplicity versus fit: a single global order is easy to reason about but may not fit every local context. A third tradeoff is responsiveness versus stability: timeouts and preemption keep claims from lasting forever, but excessive revocation can create churn and distrust.

In human systems, the tradeoff also includes legitimacy. A sequence that prevents stalemate may still fail if participants view it as biased or as a disguised way to shift losses onto them.

prose_invariants_to_preserve: The central invariant is that normal rules should not allow a reachable circular wait. A second invariant is coherent recovery: every release, timeout, preemption, or admission refusal should leave the system in a valid state. A third invariant is consistency across local actors, because conflicting local prevention rules can recreate deadlock. A fourth invariant is fairness: preventing deadlock should not mean the same low-power actor is always forced to release, wait, or lose.

prose_target_outcomes:
A successful Deadlock Prevention design reduces hard stalls, emergency escalations, process restarts, and hostage-like negotiations. Work may still queue. People may still wait. Resources may still be scarce. But the system should not freeze because every participant is holding something while waiting for someone else to release something first.

Another target outcome is clearer operating behavior under stress. Participants know the acquisition order, the release rule, the timeout, the admission criterion, and the escalation path before contention peaks.

prose_parameter_dimensions:
The main tuning dimensions are strictness, time, revocability, admission conservatism, and monitoring sensitivity. Strict ordering gives strong prevention but may suppress useful parallelism. Short timeouts keep resources moving but can cause abort churn. Strong preemption preserves liveness but may damage trust or fairness. Conservative admission avoids unsafe states but can underuse capacity. Sensitive monitoring catches near-misses but can create false alarms.

A good design tunes these dimensions to the severity and reversibility of the deadlock risk. Safety-critical systems should bias toward stronger prevention and tested recovery. Low-stakes systems may allow more concurrency and accept occasional resolution.

prose_variants_and_near_names:
Global Resource Ordering Prevention is the variant behind lock ordering and many approval-order rules. Hold-and-Wait Elimination prevents partial possession from becoming a hostage state. Timeout and Lease Prevention uses time boundaries to keep claims from becoming indefinite. Safe-State Admission Prevention, often called deadlock avoidance, checks that every admitted state still has a feasible completion path. Negotiation Deadlock Prevention adapts the pattern to social commitments, bargaining sequences, and governance processes.

Near names such as `lock_ordering`, `timeout`, and `agenda_ordering` should generally be treated as mechanisms or variants, not as top-level archetypes. They are useful implementation names, but they do not cover the whole prevention logic.

Global Resource Ordering Prevention

short_definition: Prevents circular wait by assigning resources to a stable global order and requiring acquisition to follow that order.

distinctive_feature: The prevention lever is a shared ordering scheme rather than timeout, preemption, buffering, or admission control.

distinct_from_parent: The parent includes several ways to break deadlock preconditions; this variant specifically eliminates circular wait through ordering.

still_same_parent_because: The causal logic remains prevention before deadlock occurs by making a wait cycle structurally unreachable.

source_primes: deadlock order resource_management

use_when: resources can be listed and ordered consistently across actors or processes

use_when: deadlock risk comes from conflicting acquisition sequences

use_when: the cost of consistent ordering is lower than the cost of circular blocking

Shared Resource Inventory

role: Defines what must be ordered.

Resource Acquisition Order Rule

role: Encodes the global ordering constraint.

Contention Monitoring Signal

role: Detects violations or near-misses.

Lock Ordering Protocol

role: Concrete software or infrastructure ordering mechanism.

Agenda Ordering Rule

role: Human-system ordering mechanism.

example_domains:
software concurrency
database transactions
approval workflows
negotiation design

domain: software

example: Acquire account locks by account ID rather than caller-specific order.

domain: governance

example: Decide jurisdiction before funding allocation so both sides cannot hold each issue hostage.

failure_modes: global order becomes too coarse and reduces useful parallelism

failure_modes: teams invent local exceptions that reintroduce conflicting acquisition order

Hold-and-Wait Elimination

short_definition: Prevents deadlock by disallowing actors or processes from holding one resource while waiting indefinitely for another.

distinctive_feature: The intervention targets the holding condition rather than the order of acquisition.

distinct_from_parent: The parent is broader; this variant specializes in release-before-wait or all-or-nothing acquisition rules.

still_same_parent_because: It remains a structural prevention rule that makes a deadlock state unreachable before it forms.

source_primes: deadlock resource_management constraint

use_when: resources can be acquired together or released safely before retry

use_when: the main deadlock risk comes from partial possession

use_when: holding partial claims creates fairness or progress problems

Hold-and-Wait Limit

role: Defines what cannot be held while waiting.

Rollback and Recovery Path

role: Makes release safe.

All-or-Nothing Acquisition

role: Requires complete acquisition or full release.

Try-Lock and Backoff

role: Avoids indefinite wait while partially holding resources.

example_domains:
operating systems
project staffing
equipment scheduling
committee bargaining

example: A job must reserve machine, operator, and inspection slot together or release the partial reservation.

domain: negotiation

example: A party cannot bank a concession while refusing to move on the dependent reciprocal issue.

failure_modes: release-and-retry creates churn under high contention

failure_modes: all-or-nothing acquisition requires too much advance information

Timeout and Lease Prevention

short_definition: Prevents indefinite circular blocking by making resource holds or waits expire unless renewed under explicit conditions.

distinctive_feature: The intervention uses time boundaries as the prevention lever.

distinct_from_parent: The parent includes non-temporal prevention such as ordering and admission checks; this variant makes waiting or holding duration the central parameter.

still_same_parent_because: It prevents circular blocking before it hardens into an indefinite stalled state.

source_primes: deadlock scheduling resource_management

use_when: resources can be safely released or reviewed after a bounded time

use_when: deadlock risk comes from indefinite holding rather than immediate incompatibility

use_when: timeout damage is lower than indefinite blockage damage

Timeout or Lease Rule

role: Defines expiration conditions.

Rollback and Recovery Path

role: Ensures expiration does not corrupt the system.

Timeout Policy

role: Caps waiting or holding time.

Lease-Based Resource Hold

role: Requires renewal of resource claims.

example_domains:
distributed systems
service operations
public administration
contract negotiation

domain: distributed systems

example: A service holds a lease on a shard only until renewal succeeds.

domain: administration

example: An approval slot expires if required supporting materials are not delivered by a review deadline.

failure_modes: timeouts are too short and cause wasteful aborts

failure_modes: timeouts are too long and merely delay deadlock

failure_modes: lease renewal becomes a hidden permanent hold

Safe-State Admission Prevention

short_definition: Prevents deadlock by admitting new work, commitments, or resource requests only when the resulting state still has at least one feasible completion path.

distinctive_feature: The prevention lever is a state-screening rule rather than a fixed acquisition order.

distinct_from_parent: The parent includes static structural prevention; this variant dynamically checks whether a proposed transition preserves a safe state.

still_same_parent_because: It still acts before deadlock by blocking state transitions that could make circular waiting unavoidable.

use_when: future resource needs can be estimated before admission

use_when: the system can model whether a completion sequence remains possible

use_when: admission refusal or deferral is acceptable compared with deadlock risk

Safe-State Admission Criterion

role: Defines the admissibility test.

Wait-For Dependency Map

role: Supports state analysis.

Safe-State Admission Check

role: Tests whether a proposed request keeps the system safe.

example_domains:
operating systems
cloud capacity admission
hospital intake
portfolio commitments

domain: cloud operations

example: A deployment is admitted only if rollback capacity remains available for every active release.

domain: hospital operations

example: A procedure is scheduled only if staff, bed, and post-op capacity can complete the full pathway.

failure_modes: safe-state model underestimates future needs

failure_modes: admission checks become overly conservative

Negotiation Deadlock Prevention

short_definition: Structures bargaining, governance, or decision processes so parties cannot each hold a needed concession, approval, or agenda item while waiting for another party to move first.

distinctive_feature: The resources are social or institutional commitments rather than technical locks, but the circular blocking structure is similar.

distinct_from_parent: The parent is domain-general; this variant focuses on human governance and bargaining processes where legitimacy, face-saving, and trust matter.

still_same_parent_because: The logic is still to prevent circular hold-and-wait by structuring acquisition, release, sequencing, or escalation before the stalemate occurs.

source_primes: deadlock order procedural_fairness

use_when: multiple parties control different approvals, concessions, facts, or procedural steps

use_when: parties can create mutual hostage-taking by refusing to release commitments

use_when: a fair sequence or release norm can be agreed before the conflict peaks

Actor / Process Map

role: Names parties and control points.

Resource Acquisition Order Rule

role: Orders concessions or agenda items.

Exception and Escalation Path

role: Keeps disputes from becoming stalemates.

Agenda Ordering Rule

role: Sequences issues to prevent mutual hostage-taking.

Reservation and Capacity Escrow

role: Holds reciprocal commitments conditionally rather than permanently.

example_domains:
labor negotiation
coalition governance
contracting
interagency coordination

domain: labor negotiation

example: Wages, staffing, and scheduling are sequenced so neither side can hold all movement on one issue hostage to another.

domain: interagency governance

example: Data-sharing approval, funding signoff, and legal review follow a pre-agreed order.

failure_modes: procedural ordering is perceived as biased

failure_modes: parties strategically withhold information outside the rule

failure_modes: escalation becomes a substitute for negotiation

near_names:
Circular Wait Prevention
Deadlock Avoidance
Lock Ordering
Timeout
Resource Acquisition Ordering
Stalemate Prevention


Deadlock Resolution

type: archetype

source: generated

aliases:
deadlock recovery
circular wait resolution
deadlock breaking
impasse breaking
stalemate unblocking
blocked-cycle recovery
mutual obstruction resolution

slug: transaction

slug: adjudication

slug: resilience

slug: threshold

components:
Deadlock Detection
Cycle Map
Held Condition Inventory
Break Point Selection
Bounded Break Action
Recovery Path
Resolver Authority
Post-Resolution Prevention Review
Compensation or Repair Rule
Evidence Record
Safe State Checkpoint
Participant Reentry Rule

mechanisms:
Wait-For Graph Analysis
Blocked Dependency Trace
Process Kill or Restart
Lock Preemption
Forced Release Protocol
Rollback to Safe State
Arbitration Decision
Mediation or Renegotiation
Escalation to Authority
Tie-Break Rule
Timeout and Retry Recovery

essence_one_line: Break an existing circular blockage by releasing, preempting, reordering, renegotiating, or introducing an external resolver.

compression_statement: When a system is already stuck in circular blocking, resolve deadlock by detecting the cycle, selecting the least damaging point to break it, releasing or preempting a held resource, condition, commitment, or authority, and restoring a coherent path of progress.

core_intuition: Deadlock resolution is not ordinary acceleration, prioritization, or encouragement. It intervenes after progress has stopped because each participant is waiting for another participant who is also blocked. Resolution works by breaking one link in the circular wait while preserving enough state, fairness, trust, and recoverability for the system to continue.

canonical_formula: Given a wait-for cycle P1 -> P2 -> ... -> Pn -> P1, where each participant waits for a resource, commitment, approval, lock, or action controlled by the next, choose a break point B and apply release, preemption, rollback, renegotiation, arbitration, restart, or escalation so at least one participant can move and the cycle no longer holds.

structural_problem: Actors, processes, negotiations, or resources are already configured in a circular wait. Each participant may be locally reasonable in holding what it has while waiting for something else, but the combined state prevents all participants from advancing. The system is not merely slow or under-resourced; it is structurally stuck.

condition: A circular wait or mutual hold-and-wait state is present rather than merely possible.

rationale: The archetype applies after the system has entered an actual blocked state. If the goal is only to prevent future cycles, use deadlock_prevention instead.

condition: Each participant has a reason not to release its current claim first.

rationale: Deadlock persists because unilateral release can appear costly, risky, unfair, embarrassing, or unsafe even though collective progress requires some release.

condition: The blocked item is exclusive, scarce, sequenced, authoritative, or otherwise not freely shareable.

rationale: The held condition may be a technical lock, machine, worker, document, budget approval, legal concession, meeting slot, data write, or social commitment.

condition: Routine waiting no longer has a credible path to resolution.

rationale: A queue eventually moves; a deadlock may not. The key signal is that every local path depends on another blocked party moving first.

condition: Breaking the cycle has side effects that must be managed.

rationale: Resolution is often invasive: killing a process, revoking a claim, compelling release, forcing a tie-break, or renegotiating terms can damage work, trust, or fairness if done casually.

condition: An external resolver or higher-order rule can alter the blocked state.

rationale: Deadlock may require authority, mediation, protocol-level intervention, or a pre-agreed recovery rule because the participants inside the cycle cannot escape by ordinary local action.

symptom: No participant can make progress, yet each needed resource or decision exists somewhere in the system.

diagnostic_meaning: The failure is the arrangement of holds and waits, not the absolute absence of capability.

symptom: Each party says another party must act first before it can proceed.

diagnostic_meaning: The system may be trapped in a mutual dependency cycle rather than facing a linear dependency.

symptom: Retries, reminders, and ordinary escalation produce repeated returns to the same blocked state.

diagnostic_meaning: The cycle itself must be changed; motivational pressure alone is unlikely to resolve the structural block.

symptom: Partial releases are resisted because they could forfeit position, data, priority, bargaining power, or safety.

diagnostic_meaning: A safe release, rollback, or compensation mechanism may be needed before any participant can move.

symptom: A workflow, negotiation, or system requires an outside authority to select who yields first.

diagnostic_meaning: The missing mechanism may be arbitration, tie-breaking, forced release, or recovery authority.

symptom: Progress resumes immediately once one held condition is released or preempted.

diagnostic_meaning: This confirms that the problem was a circular blockage rather than a global lack of capacity.

root_tension: Participants protect local progress, bargaining position, safety, or integrity by holding what they already have. In a circular wait, that local protection becomes collective paralysis. Resolution must break the cycle without turning necessary release into arbitrary punishment or unrecoverable loss.

case: The system has not yet entered a blocked cycle, but design analysis shows one could occur.

why_not: Use Deadlock Prevention. Resolution is for a cycle already active or immediately diagnosed.

case: A queue is long but eventually advances according to a known rule.

why_not: Use queue discipline, capacity expansion, load shedding, or priority-based admission. Delay alone is not deadlock.

case: A single actor refuses to cooperate without holding a condition needed by another blocked actor.

why_not: Use conflict resolution, incentive alignment, enforcement, accountability, or adjudication rather than a circular-wait pattern.

case: A resource is missing altogether.

why_not: Use resource acquisition, substitution, rationing, or redesign. Deadlock resolution assumes the needed conditions exist but are held or sequenced in a blocking cycle.

case: The intervention is simply to decide a dispute on the merits.

why_not: Adjudication may be a mechanism inside deadlock resolution, but the archetype requires a circular blocking state whose structural cycle must be broken.

case: The goal is to punish a party for noncompliance.

why_not: Resolution is aimed at restoring liveness and safe continuation, not primarily at blame assignment.

structural_intervention: Detect the existing wait-for cycle, determine which held condition can be released, preempted, rolled back, renegotiated, or decided with the least unacceptable damage, apply a bounded break action, and restore the system to a coherent state where at least one participant can proceed.

action: Stabilize the blocked state long enough to diagnose it.

logic: Avoid uncontrolled retries, blame spirals, duplicate commands, or ad hoc side deals that obscure the cycle. Capture the current holders, waiters, commitments, locks, approvals, and pending actions.

action: Map the wait-for cycle.

logic: Represent who is waiting for whom, what each party holds, what each needs next, and why each party cannot or will not release. Include technical resources, procedural permissions, data states, social commitments, and bargaining concessions.

action: Classify the deadlock and its recovery constraints.

logic: Identify whether the cycle is technical, operational, workflow-based, contractual, political, interpersonal, or mixed. Determine what cannot be corrupted, who has authority, what release costs exist, and what fairness or safety constraints apply.

action: Select a break point.

logic: Choose the link whose interruption restores progress with the least unacceptable loss. Consider reversibility, work already invested, power imbalance, safety, auditability, contractual legitimacy, and downstream dependency effects.

action: Apply a bounded break action.

logic: Use release, preemption, rollback, restart, timeout, arbitration, mediation, escalation, tie-break, or renegotiation to break at least one hold, wait, dependency, or commitment. Bound the action so it does not become arbitrary override.

action: Recover to a coherent continuation state.

logic: Restore data, permissions, ownership, work queues, expectations, and accountability. Compensate or document losses when required. Ensure the system knows what happened and what can safely happen next.

action: Convert the incident into prevention learning.

logic: After resolution, analyze why the cycle was reachable. Update ordering, admission, timeout, escalation, or release policies so the same structure is less likely to recur.

rule: Use resolution only when a current blocked cycle must be broken.

rationale: If the intervention is purely prospective, deadlock_prevention is the cleaner archetype. Resolution involves recovery from an actual stuck state.

rule: Break the cycle at the lowest-cost reversible point that actually restores progress.

rationale: A dramatic override may work but can destroy state, trust, or fairness. A reversible break preserves optionality.

rule: Prefer release or rollback when state can be restored safely.

rationale: Returning to a known safe state often preserves integrity better than forcing forward movement through corrupted dependencies.

rule: Prefer arbitration or escalation when the cycle is social, contractual, or authority-based.

rationale: Human deadlocks often require a legitimate resolver who can choose the yielding party, redefine terms, or bind participants to a decision.

rule: Prefer restart or process termination only when the killed unit is isolated or recoverable.

rationale: Terminating a process or canceling work can resolve a technical deadlock but may cause data loss or cascading disruption if isolation is weak.

rule: Do not resolve by always sacrificing the least powerful participant.

rationale: Resolution can become hidden coercion if break-point selection ignores legitimacy, fairness, and distribution of losses.

rule: After any resolution, route the incident to prevention review.

rationale: A deadlock that required resolution has revealed a reachable failure state. Repeated resolution without prevention creates institutionalized firefighting.

invariant: Liveness is restored.

reason: At least one blocked actor or process must be able to proceed after the intervention; otherwise the cycle has not actually been broken.

invariant: State remains recoverable and auditable.

reason: The break action should leave enough record, data integrity, and accountability for the system to understand and repair any side effects.

invariant: The intervention is bounded by legitimate authority or pre-agreed recovery rules.

reason: Forced release, arbitration, rollback, or termination can become arbitrary override unless authority and scope are explicit.

invariant: Essential safety, trust, and fairness constraints are preserved.

reason: Breaking a cycle at any cost can damage people, data, equipment, legal rights, or institutional legitimacy.

invariant: The cycle is not merely displaced into a new blocked configuration.

reason: A local break that immediately creates another equivalent circular wait has not restored system-level progress.

invariant: Post-resolution learning is captured.

reason: Resolution should generate prevention knowledge rather than normalizing repeated crisis intervention.

outcome: Progress resumes from a previously frozen state.

indicator: At least one participant completes the next step, releases a dependency, or reopens a viable path for others.

outcome: The wait-for cycle is made explicit.

indicator: Participants can name the holders, waits, contested conditions, and chosen break point rather than arguing only from local perspectives.

outcome: Damage from breaking the cycle is contained.

indicator: Rollback, restart, compensation, documentation, or arbitration limits the harm caused by forced movement.

outcome: Authority and accountability are clarified.

indicator: The system knows who can compel release, decide a tie, restart work, or mediate terms when routine procedures stall.

outcome: Future recurrence becomes less likely.

indicator: Post-incident changes update acquisition order, release policies, escalation paths, or admission rules.

prose_essence:
Deadlock Resolution is the recovery pattern for a system that is already stuck in circular blocking. Each actor, process, team, transaction, or authority holds something another participant needs and waits for something held by someone else. Because every local next step depends on another blocked participant, ordinary waiting cannot restore progress.

The archetype resolves the situation by making the circular wait visible, choosing a controlled point at which to break it, applying a bounded release or override, and recovering the system to a coherent continuation state. It is not just “try harder,” “escalate,” or “pick a winner.” The distinctive move is structural: break at least one hold, wait, dependency, or commitment in the active cycle.

prose_when_to_use:
Use this archetype when the blocked condition is already present and circular. A database transaction cycle, a set of processes waiting on locks, a committee waiting on another committee that is waiting on the first, or a negotiation in which each party refuses to move first can all fit. The common signature is that progress resumes only after one link in the circular hold-and-wait structure changes.

Do not use it for every delay. A long queue, a capacity shortage, a single upstream blocker, or an ordinary disagreement may be serious, but they are not deadlock unless mutual blocking closes into a cycle.

prose_structural_problem:
The structural problem is a closed wait-for loop. Participant A cannot proceed until B releases or decides something; B cannot proceed until C does; C cannot proceed until A does. The held condition may be a technical lock, a reserved machine, a budget approval, a legal concession, a file, a scheduling slot, a promised decision, or social willingness to move first.

This kind of blockage is stubborn because each participant’s local behavior can be rational. Holding a lock protects data integrity. Holding a concession protects bargaining position. Holding an approval protects accountability. Yet when all participants protect locally at once, the whole system loses liveness.

prose_intervention_logic:
The intervention begins by stabilizing the situation enough to diagnose it. Resolution then maps the wait-for cycle, inventories the held conditions, and asks where the cycle can be broken with the least unacceptable damage. The selected break may be technical, procedural, social, or authority-based: abort a transaction, release a reservation, roll back to a safe state, invoke an arbitrator, establish simultaneous exchange, or authorize a conditional approval.

A good resolution does not stop at the first movement. It also defines recovery: what data, work, trust, authority, or schedule must be restored after the break. Finally, it routes the incident into prevention review, because a deadlock that required resolution has revealed a reachable failure state.

prose_key_components:
### Deadlock Detection

Deadlock detection confirms that the system is in an actual circular blocking state. It separates deadlock from ordinary delay, capacity shortage, or linear dependency. Detection can use wait-for graphs, incident logs, workflow traces, interviews, or facilitated dependency mapping.

### Cycle Map

The cycle map shows who holds what, who waits for what, and where the loop closes. It gives participants a shared structural picture instead of separate local stories. Without a cycle map, resolution often becomes blame assignment.

### Held Condition Inventory

The held condition inventory names the things being held: locks, approvals, reservations, data states, concessions, commitments, permissions, or attention. This matters because many deadlocks are not caused by obvious physical resources; the blocking condition may be procedural or social.

### Break Point Selection

Break point selection chooses the link to interrupt. A strong break point is reversible enough, legitimate enough, and impactful enough to restore progress without disproportionate harm. It should be chosen by considering safety, fairness, cost, power, state integrity, and downstream effects.

### Bounded Break Action

The bounded break action is the actual intervention: release, preemption, rollback, restart, arbitration, mediation, tie-break, escalation, or renegotiation. It must be strong enough to alter the blocked state and narrow enough to avoid becoming arbitrary override.

### Recovery Path

The recovery path defines what happens after the cycle breaks. It may restore data, reschedule work, document decisions, compensate losses, reassign ownership, or rebuild trust. Deadlock resolution without recovery can trade paralysis for corruption or resentment.

### Resolver Authority

Resolver authority identifies who or what is allowed to impose the break action. In technical systems this may be a scheduler, database manager, or incident commander. In human systems it may be a mediator, chair, judge, contract clause, or governance body. Legitimacy is part of the mechanism.

### Post-Resolution Prevention Review

Post-resolution prevention review asks why the deadlock was reachable and how future rules should change. It connects this archetype back to Deadlock Prevention by updating ordering, admission, timeout, release, escalation, or recovery policies.

prose_common_mechanisms:
### Wait-For Graph Analysis

A wait-for graph implements the archetype by making the cycle explicit. It represents participants and resources as nodes and waits as edges. A detected cycle identifies where resolution must act.

### Blocked Dependency Trace

A blocked dependency trace follows a stalled workflow, ticket, negotiation, or request through its dependencies. It is useful when the deadlock is organizational rather than technical and the held conditions are distributed across teams.

### Process Kill or Restart

Process kill or restart is a technical recovery mechanism. It breaks the cycle by terminating or restarting one participant so its held resources are released. It is not the archetype itself; it is one way to execute the bounded break action.

### Lock Preemption

Lock preemption revokes or transfers an exclusive claim. It can restore progress when a holder is blocking the system, but it requires safe recovery rules because preemption can violate assumptions made by the holder.

### Forced Release Protocol

A forced release protocol requires a participant to release a resource, approval, reservation, or commitment once a verified deadlock condition exists. It works best when the release criteria and authority are agreed in advance.

### Rollback to Safe State

Rollback returns one or more participants to a prior coherent state. It is especially useful when continuing through the current state would corrupt data, violate procedure, or preserve an unrecoverable blockage.

### Arbitration Decision

Arbitration applies a legitimate external decision to break a human or governance deadlock. It is a mechanism inside this archetype when the disputed decision is the link holding a circular block in place.

### Mediation or Renegotiation

Mediation or renegotiation changes the terms of release. It may create simultaneous exchange, face-saving concessions, or a new sequence of commitments so parties can move without unilateral first-mover risk.

### Escalation to Authority

Escalation moves the blocked cycle to someone with sufficient scope to override local holds or redefine the decision rule. Escalation is not automatically deadlock resolution; it fits only when it breaks an active circular wait.

### Tie-Break Rule

A tie-break rule chooses who yields or proceeds first by a pre-agreed criterion. It can be based on severity, priority, rotation, randomization, seniority, contractual order, or another legitimate rule.

### Timeout and Retry Recovery

Timeout and retry recovery expires an indefinite wait and restarts from a controlled state. It can resolve active deadlocks, but without safe recovery it can create repeated thrashing or lost work.

prose_failure_modes:
A common failure mode is misdiagnosis: treating ordinary delay as deadlock and applying intrusive overrides unnecessarily. Another is choosing the wrong break point, which causes damage without restoring progress. Technical systems can suffer state corruption after unsafe termination or rollback. Human systems can suffer authority overreach, power-biased sacrifice, or resentment when the same party repeatedly bears the cost of release.

A subtler failure is cycle displacement. The first loop is broken, but the underlying rules remain unchanged, so the system enters a new circular wait. Resolution theater is another failure: meetings, escalations, and restarts occur, but no held condition actually changes.

prose_neighbor_distinctions: Deadlock Prevention is the closest neighbor. Prevention changes the system before the cycle forms; resolution breaks a cycle that already exists. Queue discipline is different because a queue can be slow while still moving. Dependency ordering is different because acyclic dependencies can be sequenced without a break action. Adjudication is different because many disputes are not circular blocking states. Rollback, timeout, arbitration, and escalation are mechanisms that can implement resolution, not substitutes for the archetype.

prose_cross_domain_examples: In an operating system, a process may be killed so its locks are released and other processes can proceed. In a database, a victim transaction may be rolled back and retried. In a product launch, legal, engineering, and procurement may each be waiting on another; a conditional approval can break the loop. In a diplomatic negotiation, simultaneous verified release can solve first-mover risk. In committee governance, a chair or board may use a tie-break or conditional authorization to create a first move.

prose_non_examples: A long support queue is not deadlock if tickets still move. A single missing vendor delivery is not deadlock unless it participates in a circular dependency. A manager making an ordinary decision is not deadlock resolution unless the decision breaks a circular wait. Designing lock ordering rules before launch is prevention, not resolution. Mediation of a value disagreement is not deadlock resolution unless the disagreement has become mutual blocking.

prose_tradeoffs:
Deadlock resolution trades speed against diagnosis quality. It trades forceful intervention against legitimacy. It trades minimal disruption against certainty that the cycle will actually break. It may trade local fairness against system liveness when someone has to yield first. It also trades ad hoc flexibility against repeatable recovery rules.

The best draft of the intervention makes those tradeoffs explicit rather than pretending that restoring progress is cost-free.

prose_invariants_to_preserve: The first invariant is liveness: at least one participant must be able to move after resolution. The second is recoverability: the break action must leave the system in a coherent state. The third is legitimacy: forced release, preemption, rollback, or arbitration must be justified by rule or authority. The fourth is fairness: the same low-power party should not always be sacrificed just because it is easiest to compel. The fifth is learning: resolution should feed prevention.

prose_target_outcomes: A successful resolution restores progress, clarifies the wait-for cycle, contains damage from the break action, establishes who had authority to intervene, and reduces the odds of the same deadlock recurring. In human systems, another target outcome is renewed willingness to participate after a forced or mediated release.

prose_parameter_dimensions:
Important tuning dimensions include detection confidence, break severity, reversibility, recovery cost, authority scope, fairness of burden allocation, time pressure, evidence requirements, and recurrence tolerance.

A highly automated technical system may tune for fast detection and bounded rollback. A governance system may tune for legitimacy, evidence, proportionality, and stakeholder reentry. A negotiation may tune for face-saving, reciprocity, simultaneous release, and trust repair.

prose_variants_and_near_names:
Technical Deadlock Recovery covers operating systems, databases, distributed systems, and workflow engines. It often uses wait-for graphs, process termination, lock preemption, rollback, and retry. Negotiation Stalemate Breaking covers cases where parties each wait for the other to make the first concession. Governance Impasse Resolution covers institutions whose procedures or authorities are circularly dependent. Workflow Cycle Unblocking covers operational settings where teams, approvals, reservations, or artifacts are mutually waiting.

Near names include deadlock recovery, circular wait resolution, impasse breaking, and stalemate unblocking. The near names are useful for retrieval but should not erase the structural requirement: the pattern is about resolving active circular blockage.

Technical Deadlock Recovery

short_definition: Resolves active deadlocks among processes, locks, transactions, threads, services, or jobs through detection, preemption, rollback, restart, or retry.

distinctive_feature: The break action usually manipulates executable state, locks, transactions, or reservations rather than interpersonal commitments.

distinct_from_parent: The parent covers circular blockage generally. This variant focuses on technical runtime states where detection and recovery can often be automated.

still_same_parent_because: The structural logic is still active cycle detection, break-point selection, controlled release or preemption, and recovery.

condition: A technical system has an active wait-for cycle among locks, processes, transactions, services, or jobs.

condition: The system can identify and alter at least one participant without destroying unrecoverable state.

condition: Data integrity, uptime, and replay or retry safety can be managed.

example_domains:
operating systems
database transactions
distributed services
workflow engines

domain: Database systems

example: Abort and roll back one transaction in a detected transaction cycle.

domain: Operating systems

example: Terminate or restart one process holding locks needed by the rest of the cycle.

failure_mode: State corruption from unsafe termination.

failure_mode: Repeated victim selection creates starvation.

Negotiation Stalemate Breaking

short_definition: Breaks a circular refusal in which parties each withhold a concession, commitment, or first move until another party moves first.

distinctive_feature: The held conditions are social commitments, concessions, assurances, or positions rather than technical locks.

distinct_from_parent: The parent is cross-domain. This variant emphasizes legitimacy, trust, sequencing, face-saving, and burden allocation in human deadlocks.

still_same_parent_because: The cycle still consists of mutually held conditions and waits, and resolution still requires breaking one link under recoverable terms.

condition: Parties are mutually blocked by first-mover risk, distrust, face-saving constraints, or reciprocal concession demands.

condition: A mediator, arbitrator, escrow structure, simultaneous exchange, or sequencing rule can alter the release logic.

condition: The goal is to restore a path of negotiation or action rather than declare one party simply right or wrong.

example_domains:
labor negotiation
diplomacy
contract negotiation
coalition governance

domain: Labor negotiation

example: Use a mediator to define simultaneous concessions so neither side yields first alone.

domain: Diplomacy

example: Use verified simultaneous release steps to break reciprocal refusal.

failure_mode: Mediator lacks legitimacy with one party.

failure_mode: Break action imposes asymmetric loss and hardens distrust.

Governance Impasse Resolution

short_definition: Breaks circular procedural or authority-based blockage in committees, institutions, approval chains, or multi-party governance systems.

distinctive_feature: The deadlock is produced by institutional procedure, jurisdiction, approval dependency, or distributed authority.

distinct_from_parent: The parent includes any active circular blockage. This variant focuses on governance structures where legitimacy and jurisdiction are central.

still_same_parent_because: It still resolves an existing wait-for cycle by breaking one procedural hold or decision dependency.

condition: Multiple authorities each require action from another authority before acting themselves.

condition: A legitimate escalation, tie-break, conditional approval, or temporary authority transfer can create a first move.

condition: The recovery must preserve institutional legitimacy and procedural fairness.

example_domains:
committee governance
budget approval
regulatory coordination
cross-functional executive decisions

domain: Committee governance

example: A chair invokes a conditional approval rule when committees are waiting on each other.

domain: Regulatory coordination

example: A temporary lead agency is authorized to decide a sequencing conflict.

failure_mode: Escalation bypasses legitimate stakeholder rights.

failure_mode: Tie-break solves one decision but leaves jurisdictional ambiguity unchanged.

Workflow Cycle Unblocking

short_definition: Unblocks operational, project, or approval workflows in which tasks, teams, artifacts, or reservations are circularly waiting on one another.

distinctive_feature: The held conditions are often artifacts, work packages, approvals, time slots, staff capacity, or handoff obligations.

distinct_from_parent: The parent is abstract; this variant names a common operational implementation context.

still_same_parent_because: The logic remains detection of a circular wait followed by a controlled break and recovery path.

source_primes: deadlock scheduling queueing

condition: The deadlock appears in project tasks, approvals, reservations, handoffs, or schedules rather than low-level locks or formal governance.

condition: One provisional release, conditional approval, resequencing, or temporary placeholder can create a feasible path.

condition: The organization needs a recoverable work sequence after the cycle is broken.

example_domains:
product launch
construction scheduling
service delivery
procurement
operations planning

domain: Product launch

example: Use a conditional scope freeze to let legal review proceed while final engineering details are completed.

domain: Construction scheduling

example: Release one subcontractor reservation and resequence inspections to break a circular dependency among trades.

failure_mode: Temporary workaround becomes permanent hidden process debt.

failure_mode: A provisional release lacks a follow-up closure rule.

near_names:
Deadlock Recovery
Circular Wait Resolution
Stalemate Breaking
Impasse Resolution
Process Kill
Lock Preemption
Rollback
Arbitration
Timeout