Skip to content

Dependency and Interaction Map

A diagnostic artifact — instantiates Distributed Coordination Architecture

Charts the actual interdependencies and handoffs between actors — where one party's state changes another's feasible action — so coordination targets real coupling, not org-chart lines.

Dependency and Interaction Map is the diagnostic that shows why coordination is necessary at all. It charts the real interdependencies between actors as a graph of relations — for each link recording the dependency type, its direction, criticality, timing, the resources it shares, what evidence a handoff produces, and how a failure there propagates. Its defining property is that the edges are dependencies, not tasks: the map exists to locate the exact interfaces where one actor's state change alters what another actor can feasibly do. And it is deliberately an input — it reveals where coordination must happen so the right mode, checkpoint, or reconciliation can be aimed there; it does not itself select the mode, store the commitments, or reconcile the resources it exposes.

Example

A hospital maps the interdependencies in its acute patient flow — Emergency, Imaging, Surgery, ICU, and the inpatient wards — but the artifact is not an org chart. It is a handoff graph. For each link the team records the relation: Emergency cannot disposition a patient until Imaging returns a radiology read (dependency type: informational; timing: needed within ≈45 minutes; failure propagation: a delayed read backs up the ED, which starts diverting ambulances). The ED→Imaging→Surgery chain is drawn with its shared resources attached.

Building it surfaces the finding no one had drawn: that chain shares one CT scanner and one porter pool across Emergency and inpatient demand — a hidden coupling that turns a routine imaging backlog into an ED gridlock. That single revealed dependency is what tells the hospital where a synchronization checkpoint and a resource reconciliation are worth the effort. The map does not fix the scanner contention; it makes visible that fixing it is where the leverage is.

How it works

  • Edges are dependencies, not tasks. Each is typed, directional, and criticality-weighted; a list of activities with no relations between them is not a dependency map.
  • Each link carries its coordination-relevant attributes — timing, shared resources, the evidence a clean handoff produces, and how failure at that link propagates downstream.
  • It is built from real evidence — workflow observation, practitioners' knowledge, and incident history — not from an idealized process diagram.
  • It is kept bounded and current. A decorative, sprawling, out-of-date system map adds nothing; the value is a used map of the couplings that matter now.

Tuning parameters

  • Scope and boundary — how wide a system to chart. Wider is more complete but harder to keep current, and a stale map misleads.
  • Edge richness — bare links versus fully typed edges with criticality, timing, and failure-propagation. Richer edges guide better but cost more to maintain.
  • Evidence-source mix — how much weight on workflow documentation versus practitioner interview versus incident history, trading tidiness against ground truth.
  • Criticality threshold — which dependencies are worth charting at all, so the map stays about the couplings that carry real risk.
  • Refresh cadence — a one-off snapshot versus a living map re-walked as the work changes.

When it helps, and when it misleads

Its strength is revealing hidden couplings and shared-resource contention that no participant sees from inside their own lane — and thereby targeting coordination effort at genuine interdependence rather than at reporting lines. It is the grounding input for choosing a coordination mode, placing a checkpoint, or scoping a reconciliation.

Its failure modes are decorative: a beautiful wall map that is never consulted, or a stale one that confidently misleads because the work moved on. The subtler error is mapping the org chart — reporting relationships — instead of the actual work dependencies, which produces a diagram of authority where a diagram of coupling was needed.[1] Its classic misuse is treating a task list as a dependency map: without the relations between the tasks, it reveals nothing about where coordination is required. The discipline that guards against this is to insist every edge be a real, evidenced dependency and to keep the map bounded and current.

How it implements the components

  • interdependence_and_handoff_map — it realizes this directly: the graph of handoffs, shared resources, signals, timing, and failure propagation that exposes the exact interfaces where one actor's state changes another's feasible action.

It does not reconcile the shared-resource contention it reveals — that is the Distributed Planning and Reconciliation Session; it does not turn coupling into decision authority — that is the Coordination Decision Rights and Autonomy Matrix; and it feeds but does not make the coordination-mode selection or verify readiness at the transitions it finds (that is the Synchronization Checkpoint).

Notes

This is a diagnostic input, not an operating mechanism. Its value is realized only when a downstream mechanism acts on what it reveals — a map that no reconciliation, checkpoint, or authority decision ever consumes is decoration, however accurate.

References

[1] A Design Structure Matrix (also called a dependency structure matrix), developed by Donald Steward, is the canonical compact representation of exactly these element-to-element dependencies, used to find hidden couplings and cycles in a system. It is the disciplined form this mechanism aspires to — a map of dependency, not of reporting lines. ↩