The Eight-Track Model
AI transformation is not one program. It is eight interdependent workstreams that succeed or fail together. Most organizations run a subset of them — usually whichever one their loudest function owns — and then wonder why results stall. The eight-track model exists so you can see the whole board at once: what each track is accountable for, where the hand-offs are, and how to sequence the work so it neither stalls (too sequential) nor sprawls (too parallel).
This document is the architecture layer. Each track has its own track page — a core framework, practitioner guides, and assessment; this page is about how they fit together.
What each track owns¶
Every track is accountable for one decision or asset the others depend on. Read the middle column as "the thing that is this track's job to get right," and the right column as "what the rest of the organization consumes from it."
| # | Track | What it owns | Key output others depend on |
|---|---|---|---|
| 01 | AI Strategy & Leadership | Where AI is allowed to matter, and why | A funded set of priorities every other track is scoped against |
| 02 | AI Governance & Risk | The guardrails — what is permitted, by whom, under what controls | Acceptable-use, model-risk, and compliance boundaries |
| 03 | Data Readiness | Whether the data AI depends on is fit for purpose | Trustworthy, accessible, governed data |
| 04 | Technology Architecture & Platform | A coherent platform instead of point-solution sprawl | Standardized tooling, model access, and integration patterns |
| 05 | Workflow Optimization & Automation | Which work gets redesigned with AI, and how far | Redesigned, higher-leverage workflows |
| 06 | AI Adoption & Culture | Whether people actually change how they work | Real usage and behavior change, not shelfware |
| 07 | Talent & Capability Building | Whether the organization has the competencies the work requires | AI-literate people and redesigned roles |
| 08 | Measurement & Value Realization | Whether any of it is actually working | Evidence that reprioritizes investment |
These eight group into four layers, which is the clearest way to hold the model in your head:
- Direction (01 Strategy, 02 Governance) — sets intent and the guardrails around it.
- Foundation (03 Data, 04 Platform) — the technical substrate everything executes on.
- Execution (05 Workflow, 06 Adoption, 07 Talent) — where value is actually created, by changing what work happens and who does it how.
- Feedback (08 Measurement) — proves what worked and feeds it back into Direction.
How the tracks depend on each other¶
Dependencies run mostly downward through the layers, with one loop back from Feedback to Direction:
| Track | Depends on | Enables |
|---|---|---|
| 01 Strategy | — (sets the agenda) | All tracks (scopes and funds them) |
| 02 Governance | 01 | Bounds 03, 04, 05 (what data/models/automation are allowed) |
| 03 Data | 01, 02 | 05 (nothing automates reliably on bad data) |
| 04 Platform | 01, 02 | 05 (no place to build or run AI without it) |
| 05 Workflow | 03, 04 | 06, 07 (redesigned work creates new behavior and skill needs) |
| 06 Adoption | 05, 07 | 05 (makes the redesigned work actually stick) |
| 07 Talent | 01, 05 | 05, 06 (people who can run and adopt the new work) |
| 08 Measurement | 05, 06 | 01 (evidence to reprioritize) |
Two of these relationships are deliberate loops, not one-way arrows: Talent (07) both depends on and enables Workflow (05) — the work you redesign sets the skills you need, and the skills you build set how far you can redesign — and Measurement (08) feeds back into Strategy (01). Treat the looped pairs as co-evolving rather than ordered.
The binding-constraint principle: a track is only as effective as its weakest upstream dependency. Funding Workflow (05) on top of unready Data (03) produces motion without value; rolling out tools (06) without Talent (07) produces logins without usage. Find the constraint that is actually limiting outcomes and fund that, rather than the most visible or fashionable layer.
This is why "we bought the platform" or "we trained everyone" rarely moves the needle alone — each is one input to a chain, and the chain delivers value only when its binding constraint is relieved.
Sequencing patterns by organization type¶
There is no universal order. The right early sequence depends on where your binding constraint already sits. Direction (01/02) is always first to the extent of setting intent — but it should be lightweight and revisited, not a year-long strategy exercise that blocks everything else.
| Organization profile | Usual binding constraint | Recommended early sequence |
|---|---|---|
| Digitally mature / good data foundation | Execution focus and adoption | 01 → 05 + 06/07 in parallel, with 08 from day one |
| Regulated enterprise (finance, health, public) | Governance and risk exposure | 01 → 02 → 03 → then 04/05 within the guardrails |
| Data-poor / legacy estate | Data readiness | 01 (light) → 03 → 04 → then 05; defer broad rollout |
| Bottom-up tool sprawl | No coherent platform or controls | 02 + 04 to consolidate → 01 to refocus → 05 |
| Pilots that won't scale | Adoption, talent, and proof | 06 + 07 to make pilots stick → 08 to prove → 01 to reprioritize |
The common thread: sequence by dependency, not by track number. The numbering is a reading order, not an execution order.
The two failure modes¶
Almost every troubled transformation has tipped into one of these:
1. Too sequential — "waterfall transformation." Treating the tracks as phases: finish Strategy, then Governance, then Data, then Platform, then start doing the work. Two years pass, nothing has shipped to a real user, executive patience runs out, and the foundation built in the abstract turns out not to fit the work it was supposed to support. Sequential plans also starve the Feedback loop — you learn nothing until the end.
2. Too parallel — "boil the ocean." Standing up all eight tracks at full intensity at once, with no dependency awareness. Teams thrash, effort is duplicated, and foundation gaps (bad data, missing controls) surface only after execution work has been built on top of them and has to be redone. This looks like progress for two quarters and then collapses under its own coordination cost.
The synthesis: run the tracks concurrently but at staggered intensity. Every track has some activity early (even if only assessment), but you pour resources into a track only once its upstream dependencies are ready enough to make that investment pay off. Let Measurement (08) pace the rest — ship something small, measure it, and let the evidence pull the next investment rather than pushing all eight at once.
Maturity matrix across all eight tracks¶
Maturity is assessed per track on the same five-level ladder defined in the AI Readiness Assessment Framework, so scores are comparable across the whole program:
1 Nascent · 2 Developing · 3 Emerging · 4 Scaling · 5 Transformational
The matrix below shows the anchor levels (1, 3, 5) for each track. Score on evidence, not intent — what is demonstrably true today, not what is planned.
| Track | Level 1 — Nascent | Level 3 — Emerging | Level 5 — Transformational |
|---|---|---|---|
| 01 Strategy | AI is a collection of experiments with no through-line | A funded AI strategy tied to a few business outcomes | AI strategy is inseparable from corporate strategy; capital reallocates on evidence |
| 02 Governance | No policy; risk handled ad hoc per project | Acceptable-use policy and a review path exist for new use cases | Governance is automated and continuous; compliance is a byproduct of the platform |
| 03 Data | Data is siloed and built for reporting, not AI | Key domains are governed and accessible to AI use cases | Data products are AI-ready by default, with lineage and contracts |
| 04 Platform | Point solutions bought per team; no standards | A shared platform with standard model access and patterns exists | A self-serve internal platform; new use cases launch on paved roads |
| 05 Workflow | AI used as scattered personal assistance | A few end-to-end workflows redesigned and in production | Agentic and redesigned workflows are the default operating model |
| 06 Adoption | Tools rolled out; usage is low and shallow | Target teams use AI in daily work, with visible wins | AI-first thinking is the cultural norm; people redesign their own work |
| 07 Talent | AI literacy is rare and individual | Role-based enablement and internal champions exist | Capability building is continuous; roles are designed around human–AI collaboration |
| 08 Measurement | Value is asserted, not measured | Key initiatives are instrumented and attributed | Measurement closes the loop and actively reprioritizes investment |
Two patterns to watch for in a completed assessment:
- Flat-but-low (everything at 2) usually means no track has reached the threshold where value appears — pick one or two and push them to Level 3–4 rather than nudging all eight.
- Spiky (a 4 next to a 1) signals a binding constraint: the high track is being throttled by the low one. The 03→04 and 05→06/07 boundaries are the most common places to stall — working pilots that can't scale almost always trace to a Level-1 dependency next door.
Using the model¶
- Assess all eight tracks on the ladder above (see the Integrated Assessment in Running the Program).
- Find the binding constraint — the lowest track that is throttling the ones downstream of it.
- Sequence by dependency, not by track number, using the patterns above for your organization type.
- Stagger intensity and let Measurement (08) pace the next investment.
- Re-assess on a cadence — transformation is a loop through these tracks, not a line.
Last updated: June 2026 · One Step Labs