Blocked Dependency Trace¶

Diagnostic method — instantiates Deadlock Resolution

Follows one stalled ticket, request, or negotiation hop by hop through what each party is waiting on, until the trail loops back and reveals the circular wait hiding across teams.

When a piece of work has been "in progress" for weeks and everyone insists they're blocked on someone else, the deadlock is real but invisible — there is no lock table to query. Blocked Dependency Trace recovers it by hand: start from the stalled item, ask who or what is it waiting on, go to that party, ask the same question, and keep walking the chain until it either terminates (someone can actually move — not a deadlock) or returns to a party already on the trail, which closes the loop and proves a circular wait. Its defining move is that it is narrative and cross-organizational — it reconstructs the cycle from what people and systems are actually waiting on, and along the way it writes down what each party is holding, because in human deadlocks the blocking thing is usually a sign-off, a budget line, or a data hand-off, not a physical resource.

Example¶

A product launch has been frozen for a month. Marketing says it can't announce until Legal approves the copy; Legal says it can't approve until Security signs off on the data-handling claims; Security says it can't sign off until Engineering ships the consent feature; Engineering says the feature is descoped until the launch is "confirmed" — which Marketing owns. Each team is locally reasonable and each blames the next. A blocked dependency trace starts at the launch ticket and walks the chain: Marketing → Legal → Security → Engineering → Marketing. The fourth hop lands back on the first party, and the loop is closed.

The trace produces two artifacts. One is the loop drawn out so all four teams see the same circle instead of four separate grievances — which converts "who's dropping the ball" into "we are in a circular wait." The other is an inventory of exactly what each hold is: an approval, a sign-off, an engineering commitment, a go/no-go decision. That named inventory is what tells a resolver the cheapest, most legitimate link to break — here, letting Engineering commit conditionally so the loop opens — and the written trail is the record of how the stall arose.

How it works¶

What distinguishes it from an automated cycle finder is that the graph is elicited, not computed:

Anchor on the stalled item. Pick the concrete thing not moving — a ticket, an invoice, a decision — rather than a team, so the walk stays about dependencies, not personalities.
Walk one hop at a time, recording the hold. At each party ask precisely what is being waited on and, symmetrically, what that party is holding that others wait on. Both directions get logged.
Close or clear the loop. The walk ends when it revisits a prior party (deadlock confirmed) or reaches a party who can proceed (the stall was a linear chain or a capacity problem, not a deadlock).
Publish the loop and the inventory. The shared picture and the named held conditions become the input a break-and-recover mechanism acts on.

Tuning parameters¶

Trace granularity — trace at the team level (fast, coarse) or the individual-decision level (slower, but pinpoints the exact approval to break). Too coarse and the real break point hides inside a "team."
Elicitation channel — async status pulls versus a live facilitated dependency-mapping session. Live sessions surface holds people omit in writing but cost everyone's calendar.
Hold-vs-wait discipline — how rigorously each stop records both what a party waits on and what it holds. Skipping the "holds" side is what collapses the trace into blame.
Loop-closure threshold — how much evidence counts as "revisiting" a party (same decision vs. merely same department), which guards against declaring a false cycle.

When it helps, and when it misleads¶

Its strength is reaching deadlocks no instrument can see: those whose links are approvals, commitments, attention, and permissions distributed across teams that each hold a locally sensible position. By naming the held conditions and drawing one shared loop, it defuses the blame spiral that keeps such deadlocks alive and hands a resolver a precise, legitimate break candidate.

It misleads when the walk is corrupted by the very politics it's mapping — a party may misreport what it's "really" waiting on, or a genuinely linear-but-slow chain gets narrated as a loop because everyone feels stuck. It is also only a snapshot: dependencies reroute, and a trace taken Monday may be stale Friday. And confirming a cycle is not breaking it — the trace has no authority to release anyone. The discipline is to record the specific held condition at each hop (so a revisit is a true circular wait, not just a busy department) and to hand the loop to a mechanism that carries the authority to act, such as Mediation or Renegotiation or Escalation to Authority.

How it implements the components¶

Blocked Dependency Trace fills the human-side detection and mapping components — the ones a facilitated walk can produce:

cycle_map — the elicited chain, drawn until it loops, is the shared structural picture that replaces separate local stories.
held_condition_inventory — each hop names the specific approval, commitment, budget, or data-state being held, exposing procedural and social blocks a resource graph never sees.
evidence_record — the written trail of who was waiting on what documents how the deadlock arose and feeds any later prevention review.

It does not compute a formal detection certificate or rank cuttable edges the way Wait-For Graph Analysis does, and it neither executes a break nor recovers state — bounded_break_action, recovery_path, and resolver_authority belong to acting siblings such as Mediation or Renegotiation and Escalation to Authority.

Instantiates: Deadlock Resolution — supplies the cycle map and held-condition inventory for organizational deadlocks that no automated detector can see.
Sibling mechanisms: Wait-For Graph Analysis · Mediation or Renegotiation · Escalation to Authority · Arbitration Decision · Tie-Break Rule · Forced Release Protocol · Lock Preemption · Process Kill or Restart · Rollback to Safe State · Timeout and Retry Recovery