An enterprise ranks eight first-wave AI initiatives by executive enthusiasm and demo quality. Each arrives at delivery and discovers the same missing identity service, ambiguous case state, unavailable risk reviewer and unrehearsed recovery path. The roadmap contains priorities, but no executable order.

A dependency-first sequence starts elsewhere. It asks what must be true for one operating outcome to work lawfully, technically and economically; which evidence must be learned before the next commitment; which scarce capacity several programmes share; and which apparent prerequisites are merely inherited procedure. The result is a causal graph, not a queue of attractive proposals.

Dependencies are not all gates. Some must exist before operation. Some produce information that changes a later decision. Some can be developed in parallel because they are cheap to reverse. Some shared capabilities serve several outcome paths. Some edges express only a cheaper preferred order. Others disappear when the workflow, control or ownership boundary is redesigned.

Order of commitmentReadiness belongs to the path, not the node alone

A node may be technically mature and still be unready for its outcome path. A model endpoint can pass evaluation while the case identity it needs is unstable. A workflow can be mapped while authority to execute remains unresolved. A shared platform can operate while its first consumer has no adoption capacity. Readiness is relational.

Classical critical-path work formalised dependencies in project scheduling.[1][2] Transformation sequencing borrows the discipline of explicit precedence but avoids invented durations. The central question is causal: what condition, information or capacity must precede a consequential commitment, and what evidence proves that relation?

Each node records outcome contribution, committed consumer, accountable owner, readiness evidence, integration state, reversibility, cost range, exposure, expiry and proof receipt. Each edge records mechanism, type, strength, supporting evidence, failure consequence and substitute route. A label such as “data dependency” is inadequate until it specifies which data, for what transition, at what quality and why no bounded substitute is safe.

Readiness cannot be self-certified by the team seeking funding. Evidence comes from a consumer test, interface demonstration, control decision, capacity plan, recovery rehearsal or completed operating receipt. GAO’s technology readiness guidance separates technology maturity from integration and system readiness and emphasises evidence-based assessment.[5] The graph applies that caution to organisational and operating dependencies as well.

Node evidence expires. A security review, policy version, staffing commitment or model evaluation may no longer support a delayed release. The node records validity and the trigger for reassessment. This prevents a roadmap from treating last year’s approval as permanent readiness while the dependency environment changes.

A dependency audit begins with an edge challenge, not a status meeting. The upstream owner states the condition supplied, the downstream owner states how the condition enters the operating mechanism, and an independent challenger asks what would fail if the edge were removed. The group then inspects the evidence, substitute and expiry. This simple protocol separates causal necessity from senior preference. It also exposes one-sided claims: a platform team may declare an interface ready while the consumer cannot use its identifiers, or a control team may require a report whose underlying assurance purpose is already met by earlier events.

Edge strength should be expressed through observable consequences. A hard edge names the prohibited or impossible transition. An information edge names the later choice and the observation that could change it. A capacity edge names the scarce service, proficiency and demand window. A shared-enabler edge names the service contract and consuming paths. A preference states the cost of reversing the order. A suspected false edge names the original intent and the proposed replacement. This creates an auditable reason for sequence without pretending that every relation is equally certain.

Portfolio authority matters because readiness evidence can decay between funding and use. The graph owner can reopen an edge when a policy changes, a supplier version moves, a specialist allocation is withdrawn or the target population expands. Reopening does not erase earlier work; it changes what the evidence still supports. The owner may narrow the consumer, repeat a rehearsal, substitute a manual boundary or stop the tranche. Without that authority, expiry dates become annotations while teams continue against stale assumptions.

Original synthesisThe six-edge dependency grammar

The transformation dependency graph is this article’s synthesis. Six edge types prevent every arrow from becoming an unquestioned prerequisite. Classification changes the action: hard gates must be satisfied or substituted; information edges may justify experiments; capacity edges require allocation; shared enablers require named consumers; preferences can be reordered; false dependencies should be redesigned away.

A hard prerequisite is rare and consequential. Identity before an authorised account write may be hard. An approved recovery path before an agent performs a non-trivial external action may be hard. “Complete the enterprise data platform” is not hard unless the target outcome genuinely requires every promised feature. A narrow evidence service may be a safe substitute.

An information prerequisite earns funding by reducing a later decision error. A shadow test may estimate exception demand before workforce consolidation. A prototype may reveal whether domain evidence can be reused before integration. The output is not a demo; it is a named observation with a decision rule. When the observation arrives, the next commitment changes.

A capacity prerequisite often exposes correlation across programmes. Several verticals can each have credible business cases while relying on the same model validators, risk reviewers, change window or customer-operations queue. If allocation is not reserved, all schedules are fiction. The graph treats the scarce service as a node with demand, proficiency, coverage and an accountable allocator.

A shared enabler is justified through consumption, not architectural elegance. It names the first vertical, the next consumers, the minimum service contract, allocated funding and an expiry. A common identity assertion, evaluation service or event schema can create reusable value, but only if a bounded operating outcome proves the mechanism and later consumers actually need it.

A preference should not acquire veto power. Building a gateway before every vertical may simplify later operations, but a controlled direct route could test value first. Conversely, learning in one vertical may reduce the cost of the gateway specification. The graph marks the preferred order and preserves the feasible alternative.

A false dependency is an invitation to redesign. A legacy report may be called mandatory even though the underlying control intent can be met by authoritative events earlier in the flow. A monthly committee may appear to be the only approval route because decision authority is unclear. The owner tests the intent and substitutes a stronger mechanism rather than funding obsolete coordination.

Evidence-bearing pathProve the smallest consequential outcome first

The evidence-bearing critical path is not the longest schedule. It is the smallest dependency-complete sequence that can produce a consequential operating outcome, test its main causal assumptions and create reusable evidence while keeping later choices open. It ends at a customer, control and operating receipt, not an installed component.

Path selection starts from the outcome and works backwards through hard and capacity edges. It then asks which uncertain edges merit information-producing probes. Preferences are excluded from the required path unless their cost or exposure effect is material. False dependencies are challenged. Shared enablers are sized to the minimum contract required by the committed consumer.

This avoids building horizontal foundations before any vertical proof. A full platform may eventually be correct, but the first tranche should serve a named outcome and teach something about identity, evidence, evaluation or control that another consumer can reuse. The tranche has an expiry: if the vertical does not consume it or the reuse hypothesis fails, funding does not continue by default.

The path also avoids a demo jumping the graph. A visible agent may appear ready because its conversation succeeds, yet it remains blocked if case state is inferred, action authority is broad or recovery is manual. Launching early creates containment work and misleading adoption. The correct action is to satisfy the hard edge, use a read-only substitute or defer the initiative.

Coupling and iterationExpose cycles, then choose a break strategy

Transformation graphs often contain genuine cycles. A workflow design needs an event schema, the schema depends on observed workflow, and evaluation requires cases produced by both. Design-structure research makes coupled tasks and iteration visible rather than forcing them into a false linear order.[3][4]

A cycle is not automatically a planning failure. The team identifies the smallest coupled set and chooses a break strategy. It may use a provisional interface, a synthetic case set, a read-only shadow, manual instrumentation or a narrow segment. The substitute must preserve the evidence needed to revise the design. Pretending the cycle does not exist merely moves iteration into late rework.

Some cycles reveal circular authority rather than technical coupling. A control owner refuses a design without production evidence, while production cannot begin without control approval. A bounded shadow or live cell can produce the necessary evidence under a different authority boundary. The graph records who may authorise that exception and its expiry.

Other cycles are created by funding. A shared service requires committed consumers, while vertical teams will not commit until the service is funded. Co-funding a minimum bridge can break the cycle when each party has an explicit contract and stop rule. A central budget without consumers hides the cycle instead of resolving it.

Cycle evidence should record the iteration that is expected rather than presenting a single pass as completion. For each coupled set, the team states the provisional decision, the observation it will produce, the tolerable number of revisions and the authority to settle the interface. A synthetic case set can establish technical compatibility, but it cannot prove operational variation. A read-only shadow can measure that variation, but it cannot prove recovery from an authorised action. The chosen break must match the uncertainty it claims to resolve.

A substitute is safe only within a declared boundary. Manual review may stand in for a future control for fifty cases, yet fail at scale or during absence. A provisional schema may support one consumer while omitting semantics needed by the next. The graph carries those limits forward, so an expedient does not silently become an enterprise standard. When the receipt arrives, the team either converts the substitute, extends it with fresh evidence or restores the original edge.

Shared capabilitiesA bridge is funded by named traffic

The foundation-first failure begins with a broad platform promise and no bounded consumer. Capabilities accumulate, interfaces expand and teams report readiness through internal milestones. Customer and operating evidence remains distant. The rival objection is correct: a dependency roadmap can become an infrastructure shield against market learning.

Every shared-enabler tranche therefore has at least one committed vertical consumer, a second plausible consumer, a minimum service contract, allocated funding, operating measures and an expiry. The first vertical proves the service under real demand. The next consumer tests reuse. If reuse does not materialise, the architecture and allocation are reconsidered.

Allocation reflects usage, option value and reliability obligations rather than forcing the first consumer to carry the entire enterprise bet. Central funding may pay for the reusable core; vertical funding pays for domain integration and adoption. The ledger prevents shared cost from disappearing and prevents a local business case from booking benefits that depend on unfunded common services.

Third-party dependencies require the same clarity. The Basel Committee’s current third-party-risk principles address governance, risk assessment, due diligence, contracting, monitoring, continuity and exit across the lifecycle.[12] A provider relationship is not a single procurement node; it is a set of conditions that can affect several outcome paths and substitute routes.

Portfolio collisionScarce roles and change windows are dependency nodes

Several vertical programmes may independently reserve the same reviewers, architects, data stewards, legal specialists or release window. Local plans show available capacity because each sees only its own demand. The dependency graph consolidates claims on the scarce node and records service assumptions by proficiency, timing and exception load.

Allocation should follow consequential path evidence, not sponsor seniority. A programme with a near-complete path and strong receipt may take the first slot. Another may run a shadow track that produces information without consuming the scarce authority. A third may narrow its population. The allocator records the displaced learning and outcome, not merely the selected project.

Capacity can be created, substituted or protected. Training may expand proficiency but has lead time. External review may be possible but introduces third-party controls. A deterministic check may reduce review demand without replacing authority. A reserved buffer may protect incident and appeal work. Each substitute changes another edge and is assessed at the path level.

Change windows also couple otherwise independent work. Two releases can compete for the same system-of-record freeze or operating rehearsal. Combining them may reduce disruption but increase rollback ambiguity. Separating them may delay value but preserve causal evidence. The edge is a sequencing preference or capacity condition depending on the actual constraint, not on calendar convention.

Counter-caseA regulated path proves one outcome and three reusable components

Consider a regulated onboarding transformation. The target outcome is an authorised account activation with customer communication, evidence, control and capacity receipts. The first path contains case identity, governed evidence assertions, workflow state, early deterministic controls, a bounded model-assisted ambiguity step, authorised execution and recovery.

Identity and authority are hard prerequisites for the account write. Evidence reuse is initially an information edge because the team must learn which assertions downstream policy accepts. Risk-review capacity is a capacity edge. A common evaluation service is a shared enabler with onboarding as the first consumer and complaints as the named next consumer. A full agent platform is only a preference.

The sequence begins with an instrumented vertical slice. A narrow segment uses the identity and evidence core, runs model assistance in shadow and measures exception demand. The observation determines staffing and the live decision boundary. A recovery rehearsal must pass before authorised execution. The live cell then produces customer, control, workforce and economic receipts.

The reusable components are not declared by intention. Identity assertions are reused only after the next vertical consumes them. The evidence contract carries provenance, entitlement and correction. Evaluation provides comparable cases and outcome linkage. Each component has an owner, service target, allocated cost and a version tied to the operating receipt.

A legacy monthly report is challenged as a false prerequisite. The control owner states its intent, and authoritative events plus monitoring provide earlier evidence. The report remains during the bounded test, then retires after equivalence and recovery are proved. This removes a dependency without weakening accountability.

Revised model-risk guidance requires a risk-based approach tailored to model use and organisational profile.[11] NIST’s Core and Manage resources connect governance, context, measurement, prioritisation, response and recovery.[8][9][10] The graph places those requirements on the relevant nodes and edges rather than adding one late approval.

The path is re-evaluated after every receipt. High exception demand may make capacity the next node. Strong evidence reuse may justify the second consumer. Weak outcome movement may stop workflow expansion while preserving useful identity components. The roadmap advances from operating evidence rather than maintaining its original rank.

Reversibility and learningParallel work is rational when uncertainty is the dependency

Irreversibility raises the value of waiting for information when uncertainty matters.[6] Waiting need not mean inactivity. Two cheap reversible tracks can test competing interfaces, evidence sources or workflow boundaries before one receives scale capital. Parallelism is valuable when it produces discriminating evidence rather than duplicate delivery.

Each track has a learning question, bounded cost, expiry and merge decision. If both are built as production systems, optionality becomes waste. If neither has a receipt, parallelism becomes theatre. The graph states which observation will select, combine or stop the tracks and who owns that decision.

Organisational learning also requires balance between exploration and exploitation.[7] A sequence dominated by shared foundations can over-exploit an unproved architecture; a sequence of disconnected demos can over-explore without accumulating capability. Evidence-bearing paths connect one operating exploitation opportunity to reusable learning for the next.

Adoption evidence likewise points beyond technology availability towards data, skills, management practice and complementary organisational change.[13] ISO/IEC 42001 specifies an organisational management system for setting AI objectives, assigning responsibilities and improving practice over time.[14] Sequencing therefore includes role transition and operating adoption, not merely technical release.

Resequencing is an explicit portfolio decision, not an informal reaction to delay. At each operating receipt, the graph owner compares the observed mechanism with the edge claim. If exception demand is higher than assumed, scarce-role capacity can move onto the critical path. If a second consumer rejects the shared contract, expected reuse falls and a vertical solution may be preferable. If a shadow test shows that a legacy approval adds no assurance, the false edge can be removed. If control evidence expires, a previously ready node returns to conditional status.

The decision record states what moved, which new evidence caused the move, which commitments remain reversible and who absorbs the consequence. Teams whose work leaves the active path are not automatically judged unsuccessful; a useful probe may have completed its purpose by disproving an expensive direction. Equally, excitement is not a reason to protect a visible initiative from adverse evidence. The portfolio rewards improved decisions and completed outcome paths, which reduces the incentive to keep every funded node alive.

Interactive instrumentTransformation Sequencing Workbench

The Workbench accepts up to eight named nodes and the evidence behind their strongest edges. It returns a sequencing route, path-critical node and missing evidence. It does not calculate dates. A node is critical because the causal path requires it, not because a schedule assigns it a long duration.

ConclusionLet evidence, not enthusiasm, move the roadmap

A transformation roadmap becomes executable when it shows causal dependencies, not only priorities. Hard conditions, information needs, scarce capacity, shared enablers, preferences and false edges require different treatment. The six-edge grammar makes those decisions explicit.

The evidence-bearing critical path works backwards from a completed operating receipt. It funds the smallest sequence that can prove a consequential outcome, tests uncertain edges and creates reusable assets without committing the whole future architecture. Shared services earn further funding through named consumption.

Cycles are mapped and broken with provisional interfaces, shadow evidence or bounded authority. Scarce roles and change windows are allocated across paths. Reversible parallel tracks buy information when uncertainty is the dependency. Blocked visible initiatives are deferred when identity, state, authority or recovery is not ready.

The graph remains dynamic. Readiness expires, consumers change, capacity moves and evidence can disprove an edge. A roadmap with stop and resequencing authority can respond. One without that authority is a presentation of intent, however precise its dates appear.

Evidence spineReferences

1. Kelley, J. E. and Walker, M. R. (1959), ‘Critical-Path Planning and Scheduling’, Proceedings of the Eastern Joint Computer Conference, 160–173. doi:10.1145/1460299.1460318.
2. Kelley, J. E. (1961), ‘Critical-Path Planning and Scheduling: Mathematical Basis’, Operations Research, 9(3), 296–320. doi:10.1287/opre.9.3.296.
3. Steward, D. V. (1981), ‘The Design Structure System: A Method for Managing the Design of Complex Systems’, IEEE Transactions on Engineering Management, EM-28(3), 71–74. doi:10.1109/TEM.1981.6448589.
4. Eppinger, S. D., Whitney, D. E., Smith, R. P. and Gebala, D. A. (1994), ‘A Model-Based Method for Organizing Tasks in Product Development’, Research in Engineering Design, 6, 1–13. doi:10.1007/BF01588087.
5. US Government Accountability Office (2020), Technology Readiness Assessment Guide: Best Practices for Evaluating the Readiness of Technology for Use in Acquisition Programs and Projects, GAO-20-48G. GAO.
6. Pindyck, R. S. (1990), ‘Irreversibility, Uncertainty, and Investment’, NBER Working Paper 3307. doi:10.3386/w3307.
7. March, J. G. (1991), ‘Exploration and Exploitation in Organizational Learning’, Organization Science, 2(1), 71–87. doi:10.1287/orsc.2.1.71.
8. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
9. National Institute of Standards and Technology, ‘AI RMF Playbook: Manage’. NIST AIRC Manage.
10. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
11. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
12. Basel Committee on Banking Supervision (2025), Principles for the Sound Management of Third-Party Risk. Bank for International Settlements.
13. OECD, Boston Consulting Group and INSEAD (2025), The Adoption of Artificial Intelligence in Firms: New Evidence for Policymaking. OECD Publishing.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.