Dependency Ordering¶
Essence¶
Dependency Ordering arranges actions, decisions, components, or states according to prerequisite relations. It is useful when a later step is not merely later by convention, but depends on something earlier being true, available, completed, learned, approved, stabilized, or produced.
The key move is to turn hidden prerequisite structure into an explicit order of permissible progression. That order can be a partial order, where independent branches move in parallel, or a total order, where each step must follow the previous one. The archetype is not “do things in sequence.” It is “do dependent things only after the conditions they rely on exist.”
Compression statement¶
When unordered action causes rework, failure, or invalid states, impose a dependency order so each step occurs only after its prerequisites are satisfied.
Canonical formula: map prerequisites → impose valid partial order → verify readiness → advance dependent work
When to Use This Archetype¶
Use Dependency Ordering when premature action creates invalid states, rework, safety risk, blocked downstream work, or procedural failure. The pattern is especially strong when prerequisites cross team boundaries, disciplines, jurisdictions, tools, or physical processes, because no single actor can reliably remember all dependencies.
It is also useful when a process has become over-serialized. A clear dependency map can reveal which steps truly must wait and which branches can safely run in parallel. In that sense, dependency ordering can increase speed by removing false order while preserving true order.
Do not use this archetype when order is chosen only for fairness, priority, presentation, or reproducibility. Those cases are closer to queue discipline, priority admission, or canonical ordering.
Structural Problem¶
The structural problem is that the system contains prerequisite relations, but work proceeds as though those relations were absent, obvious, or optional. A dependent action begins before its required predecessor state exists. The immediate result may look like progress, but the structural result is invalid work: a deployment without rollback readiness, a treatment without diagnostic prerequisites, a legal action without notice, a course without prerequisite mastery, or an assembly step before material preparation.
This failure often appears as late discovery. People find the missing prerequisite only after downstream work has started. By then, the system has already spent effort in the wrong state.
Intervention Logic¶
The intervention begins by naming the units that depend on one another. These may be tasks, components, decisions, permissions, resources, states, capabilities, or deliverables. The next step is to map prerequisite relations among them and distinguish hard prerequisites from soft preferences.
Once the dependency structure is known, the system imposes a valid order. A good dependency order is not necessarily rigid. It should permit parallel work wherever no dependency relation exists. Before a dependent step begins, a prerequisite check verifies readiness through evidence, not assumption. If a prerequisite is missing, the process blocks, defers, reroutes, or returns to the missing predecessor rather than continuing in an invalid state.
The intervention must also maintain the dependency map. A stale map can be worse than no map because it gives false confidence.
Key Components¶
Dependency Ordering turns hidden prerequisite structure into an explicit partial order that prevents premature action while still permitting parallel work wherever no real dependency exists. The Dependency Map represents the prerequisite structure itself — graph, matrix, runbook, or process diagram — so reviewers can see which actions, components, states, or decisions must precede others, and so the same logic can be inspected and updated across team boundaries. A Sequencing Rule translates that map into permitted action by saying which steps must wait, which may proceed, and which can run in parallel, balancing the dual error of allowing invalid premature work and serializing independent work unnecessarily. Before each dependent step begins, a Prerequisite Check distinguishes real readiness from scheduled, claimed, or assumed readiness, and the Completion Evidence component supplies the test result, signed filing, delivered material, demonstrated skill, or inspection record that proves a predecessor has produced the condition the next step needs. A Rollback or Return Path defines what happens when work begins too early or discovers a missing prerequisite, sending the process back to remediation rather than letting actors continue in a known-invalid state.
Three optional components extend the design for specific contexts. An Optional Stage Gate formalizes prerequisite review when evidence must be examined by a reviewer rather than checked automatically — useful when the gate verifies readiness, though if its purpose becomes mostly approval or certification, the Stage-Gate Progression archetype is closer. An Optional Critical Path Marker highlights the dependency chain whose delay or failure controls the whole process, which matters when several dependency-valid orders exist but some chains create disproportionate schedule or risk exposure. An Optional Exception Override Rule defines when a dependency may be bypassed, who owns the resulting risk, and how the system returns to validity — preserving pragmatism without letting exceptions silently destroy the ordering logic.
| Component | Description |
|---|---|
| Dependency Map ↗ | A dependency map represents the prerequisite structure. It shows which actions, components, states, resources, or decisions must precede others. The map may be a graph, matrix, runbook, checklist, process diagram, or textual dependency list. Its function is not documentation for its own sake; it makes hidden prerequisite relations inspectable and governable. |
| Prerequisite Check ↗ | A prerequisite check tests whether the necessary predecessor conditions are actually satisfied before dependent work begins. It distinguishes real readiness from scheduled readiness, claimed readiness, or assumed readiness. In safety-critical and high-cost systems, this check is often the difference between controlled progression and dangerous improvisation. |
| Sequencing Rule ↗ | A sequencing rule translates the dependency map into permitted action. It says which steps must wait, which may proceed, and which can run in parallel. A strong sequencing rule avoids two opposite errors: it does not allow invalid premature action, and it does not serialize independent work unnecessarily. |
| Completion Evidence ↗ | Completion evidence shows that a prerequisite has produced the condition the next step needs. This evidence may be a test result, stable data state, signed filing, delivered material, demonstrated skill, inspection result, or verified environmental condition. Without completion evidence, dependency ordering can degrade into trust, ritual, or optimistic planning. |
| Rollback or Return Path ↗ | A rollback or return path defines what happens when work begins too early or discovers a missing prerequisite. The path may send the process back to an unfinished predecessor, defer the dependent task, trigger remediation, or undo a partial change. Without this component, actors may continue in a known-invalid state because backing up is awkward. |
Optional components. These often strengthen the draft when the situation calls for them.
| Component | Description |
|---|---|
| Optional Critical Path Marker ↗ | A critical path marker highlights the dependency chain whose delay or failure controls the whole process. It is useful when several dependency-valid orders exist but some chains create disproportionate schedule or risk exposure. |
| Optional Exception Override Rule ↗ | An exception override rule defines when a dependency may be bypassed, who owns the risk, and how the system returns to validity. This preserves pragmatism without letting exceptions silently destroy the ordering logic. |
Common Mechanisms¶
| Mechanism | Description |
|---|---|
| Dependency Graphs ↗ | A dependency graph is a representation mechanism. It shows predecessor-successor relations in a form that can be inspected, tested for cycles, and updated. The graph is not the archetype; it is one way to represent the structure that the archetype governs. |
| Topological Sort ↗ | Topological sort is an algorithmic mechanism for producing a valid order from an acyclic dependency graph. It is useful in build systems, package managers, workflows, and planning tools. It should not be drafted as a standalone solution archetype here because it implements the broader intervention rather than replacing it. |
| Critical Path Method ↗ | Critical Path Method implements a time-sensitive variant of Dependency Ordering. It identifies which dependency chain controls total duration and where slack exists. Its value is not merely scheduling; it helps focus coordination attention on the prerequisite chain that most constrains progress. |
| Prerequisite Matrix / Prerequisite Matrices ↗ | A prerequisite matrix lists each unit of work against required predecessor conditions, owners, evidence, and allowed next actions. It is especially useful when dependencies cross teams or disciplines and cannot be inferred from a simple linear checklist. |
| Deployment Runbooks ↗ | A deployment runbook operationalizes Dependency Ordering in systems operations. It orders technical actions, readiness checks, monitoring steps, and rollback paths so later actions are not attempted before required technical states exist. |
| Curriculum Prerequisite Maps ↗ | A curriculum prerequisite map uses Dependency Ordering in learning design. It sequences activities so later tasks depend on capabilities already developed and verified. The mechanism may include placement tests, mastery gates, or remediation loops, but the underlying logic is prerequisite structure. |
| Treatment Sequencing Protocols ↗ | A treatment sequencing protocol orders clinical actions around diagnostic, stabilization, consent, contraindication, and safety prerequisites. It implements the archetype by ensuring that irreversible or high-risk interventions do not begin from an invalid clinical state. |
| Manufacturing Process Plans ↗ | A manufacturing process plan sequences preparation, tooling, inspection, transformation, and assembly steps around physical and quality dependencies. It prevents defective output caused by performing a later transformation before the required earlier state exists. |
Parameter / Tuning Dimensions¶
Dependency granularity determines how small the units in the map should be. Coarse maps are easier to maintain but can hide blockers. Fine-grained maps reveal more structure but create overhead.
Order strictness determines which relations are hard prerequisites, soft preferences, or conventions. Too much strictness slows the system; too little strictness permits invalid progression.
The readiness evidence threshold determines what counts as proof that a prerequisite is satisfied. A high threshold protects safety and quality, while a low threshold preserves speed but increases risk.
Exception policy determines when a dependency can be bypassed and how the bypass is governed. No exceptions can freeze a system; casual exceptions destroy the intervention.
Parallelization policy determines which branches can proceed independently once hard prerequisites are satisfied. Good Dependency Ordering should enable safe parallelism rather than defaulting to a single serial chain.
Maintenance cadence determines how often dependencies are reviewed. Dependencies can change as designs, laws, suppliers, environments, teams, and technologies change.
Invariants to Preserve¶
The main invariant is prerequisite satisfaction: no dependent action proceeds unless the conditions it relies on are already true or explicitly waived.
A second invariant is dependency traceability. Each hard order constraint should point to a real prerequisite, not merely tradition, rank, preference, or habit.
A third invariant is valid state progression. The system should move from valid state to valid state, rather than producing out-of-domain, unsafe, or procedurally invalid intermediate states.
A fourth invariant is parallelism preservation. Dependency Ordering should not turn all work into a single sequence. Independent branches should remain independent.
Target Outcomes¶
A successful Dependency Ordering intervention reduces rework because missing prerequisites are caught before downstream effort begins. It reduces invalid sequences because actions are attempted only from states where they can succeed or be interpreted.
It also improves coordination. Participants can see what they are waiting for, what can proceed independently, and what evidence is required to advance. In safety-critical contexts, it protects people from irreversible or high-risk action before diagnostic, legal, technical, or consent conditions are met.
Tradeoffs¶
The main tradeoff is validity versus speed. Prerequisite checks slow apparent early movement but prevent waste and failure later.
Another tradeoff is explicitness versus maintenance overhead. A dependency map improves coordination only while it remains current.
There is also a tradeoff between safety and flexibility. Hard prerequisites protect the system, but if they are overused they can block adaptive action.
Finally, there is a tradeoff between partial-order complexity and simple-sequence clarity. A simple sequence is easy to follow, but a partial order may be more accurate and faster because it allows independent work to proceed in parallel.
Failure Modes¶
Over-serialization occurs when soft preferences are treated as hard prerequisites. The process becomes slower without becoming safer.
A hidden cyclic dependency occurs when two or more units each wait on the other. This requires redesign, a base case, or an explicit iteration rule; otherwise the system may deadlock.
A stale dependency map occurs when the system changes but the map is not updated. The process then blocks valid work or permits invalid work.
Checkbox readiness occurs when people satisfy the form of a prerequisite check without producing the actual required condition. This is common when signoff rituals replace evidence.
Exception drift occurs when bypasses become routine. The ordering rule then loses authority and the system returns to informal sequencing.
Neighbor Distinctions¶
Dependency Ordering is distinct from Stage-Gate Progression. A stage gate may enforce prerequisites, but Stage-Gate Progression centers on criteria-based advancement through gates. Dependency Ordering centers on prerequisite structure, whether or not there is a formal gate.
It is distinct from Pipeline Staging. Pipeline Staging divides work into ordered stages for specialization, throughput, or handoff. Dependency Ordering imposes order because later work is invalid without earlier conditions.
It is distinct from Order-Sensitive Configuration. Order-Sensitive Configuration controls sequence because sequence changes the meaning or function of a whole. Dependency Ordering controls sequence because a later action requires a predecessor state.
It is distinct from Queue Discipline Design. Queue discipline chooses service order among waiting items. Dependency Ordering decides whether an item is ready to be served or acted on at all.
It is distinct from Canonical Ordering. Canonical Ordering creates a stable order for comparison, serialization, or reproducibility. Dependency Ordering creates a prerequisite-valid order.
It is also distinct from Dependency Exposure. Exposure reveals dependencies; ordering uses them to govern progression.
Variants and Near Names¶
Prerequisite-Gate Ordering is a recognized variant where explicit gates prove prerequisites before advancement. It should remain under Dependency Ordering when the gate exists mainly to verify readiness. If the gate logic becomes mostly about approval, certification, or staged governance, it belongs nearer Stage-Gate Progression.
Critical-Path Dependency Ordering is a candidate variant where the dependency chain controlling duration or risk receives special attention. It remains a variant unless path-length governance develops distinct cross-domain components and failure modes.
Near names include prerequisite ordering, dependency sequencing, and precedence ordering. Topological sort, sorting, dependency graphs, prerequisite matrices, and runbooks should be treated as mechanisms or artifacts rather than standalone archetypes.
Mastery-Gate Progression is a promotion candidate for later review. It uses dependency order but may deserve separate treatment in learning contexts because assessment validity, remediation, and learner progression introduce distinct concerns.
Cross-Domain Examples¶
In software deployment, a release may require database migration, integration tests, observability checks, and rollback readiness before production rollout.
In construction, foundation curing must precede framing, even if crews and materials are available earlier.
In education, advanced coursework depends on demonstrated prerequisite capabilities rather than on calendar time alone.
In clinical procedure, diagnosis, stabilization, consent, and contraindication checks precede high-risk intervention.
In legal procedure, filings, notice, jurisdictional requirements, and discovery may need to occur before a hearing or judgment can validly proceed.
In manufacturing, surface preparation and inspection must precede coating or assembly steps that would lock in defects.
Non-Examples¶
Alphabetizing a bibliography is not Dependency Ordering. It creates a stable presentation order, but one entry does not depend on another.
First-come-first-served ticket handling is not Dependency Ordering when tickets are independent. It is a queue discipline.
A ceremonial executive signoff is not Dependency Ordering unless the signoff verifies a real prerequisite condition.
A single rigid checklist is not necessarily Dependency Ordering. It becomes this archetype only when the checklist reflects actual prerequisite relations.
A process where every operation is genuinely order-independent does not need Dependency Ordering. It may need Order-Independent Processing instead.