Skip to content

Framework Architecture

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:

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 · AI Strategy & Leadership — (sets the agenda) All tracks (scopes and funds them)
02 · AI Governance & Risk 01 Bounds 03, 04, 05 (what data/models/automation are allowed)
03 · Data Readiness 01, 02 05 (nothing automates reliably on bad data)
04 · Technology Architecture & Platform 01, 02 05 (no place to build or run AI without it)
05 · Workflow Optimization & Automation 03, 04 06, 07 (redesigned work creates new behavior and skill needs)
06 · AI Adoption & Culture 05, 07 05 (makes the redesigned work actually stick)
07 · Talent & Capability Building 01, 05 05, 06 (people who can run and adopt the new work)
08 · Measurement & Value Realization 05, 06 01 (evidence to reprioritize)

The numbers in the "Depends on" and "Enables" columns are the track #s from the key table above — kept as a compact dependency notation.

Two of these relationships are deliberate loops, not one-way arrows: Talent & Capability Building both depends on and enables Workflow Optimization & Automation — the work you redesign sets the skills you need, and the skills you build set how far you can redesign — and Measurement & Value Realization feeds back into AI Strategy & Leadership. 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 Optimization & Automation on top of unready Data Readiness produces motion without value; pushing AI Adoption & Culture without Talent & Capability Building 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. The Direction layer 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

Sequence cells use the track #s from the key table above as a compact ordering notation.

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 & Value Realization pace the rest — ship something small, measure it, and let the evidence pull the next investment rather than pushing all eight at once.

Assessing maturity against the model

Each track is scored on one shared five-level ladder — 1 Nascent · 2 Developing · 3 Emerging · 4 Scaling · 5 Transformational — so the eight scores are directly comparable and you can see the whole board at once. The ladder and the full eight-track maturity matrix (anchor levels 1, 3, and 5 for every track) live in the Maturity Model. The Integrated Assessment is the how-to-run-it companion: it turns a set of scores into a prioritized investment case by naming the binding constraint and reading the profile's shape.

Using the model

  1. Assess all eight tracks on the shared five-level ladder — see the Maturity Model for the ladder and matrix, and the Integrated Assessment for how to run the diagnostic.
  2. Find the binding constraint — the lowest track that is throttling the ones downstream of it.
  3. Sequence by dependency, not by track number, using the patterns above for your organization type.
  4. Stagger intensity and let Measurement & Value Realization pace the next investment.
  5. Re-assess on a cadence — transformation is a loop through these tracks, not a line.

Last updated: June 2026 · One Step Labs