AI at Scale Big Picture

Three layers, described three ways. Structure is the pattern the teams form on. Governance is how work flows through them and where decisions are made. Metrics is how the enterprise knows it's working. Tailored as a set, never separately.

Hover any element. The switches on the right choose what the callout shows — description, objections, technologies, or the context the decision needs. All off, no callouts.Tap any element. The switches choose what the callout shows — description, objections, technologies, or the context the decision needs. All off, no callouts.

Description Objections Technologies Context

Business units own their AI strategy and run experiments close to the work. A run layer owns what gets proven and resolves the many-to-many between units and capabilities. A capability layer, already in place, stays a tree. The line between them is where trust is either earned or lost.

The three-layer operating model. Tinted layers are the two the AI operating model adds; the grey layer is the capability foundation an enterprise already has. Teal arrows are the innovation flow — hypotheses down to fusion teams, proven solutions through coordination into the run layer, reusable services back up to every unit. Black arrows are the operating dependencies across the line.

AI operating layers capability foundation (existing) the line

Three paths through the picture

1 · Unit-specific solution

A unit sets a bet, its fusion team proves it, and the result serves only that unit. It goes to the unit's own run capacity (dashed box). The coordination band still knows about it, so no other unit builds it again.

2 · Common solution

The same experiment would help three units. Coordination decides it's tried once. At release 1 it hands to the run layer, which owns it, operates it, catalogs it in the AI library, and offers it back to every unit. The fusion team moves to the next problem.

3 · Capability change

A proven solution turns out to need a change in a capability everybody uses. The run layer sequences it against that capability team's capacity, and once made, the capability team owns it — the innovation slides down the tree instead of being held above it.

What the picture argues

Units are a graph — any unit can need any capability, and one solution can touch several. Capabilities are a tree — encapsulated, contract-bound, few dependencies. Connect the two directly and the dependencies come back; the run layer exists to absorb that many-to-many so neither side has to become the other. Every arrow that crosses the line is a contract, not a request.

The governance is decision rights, not gates. The right-hand rail is the whole of it: which decisions live at which layer. Nothing on the picture is an approval queue.

The line is the boundary between what AI adds and what it stands on. The two sides change at different speeds and are owned by different people, which is why they get different colors. Neither works without the other: the layers above have nowhere trustworthy to act without the foundation, and the foundation produces context but no new value without the layers above.

The dashed band under the line is the alternative most organizations are actually choosing: a lake or lakehouse and a set of MCP connectors laid over the existing systems. It isn't wrong, and the reads through it are real — contexts get established, insights flow up, the chat demos work. What it can't do is let orchestration attach to secure, authoritative endpoints that change the data and complete the cycle. The write arrows stop at the band. Two tiers built on an abstraction are less trustworthy and less powerful than two tiers built on a capability layer that actually owns its endpoints — which is why the bottom layer is on the picture at all.

Left off on purpose

Compliance, TRiSM and agent guardrails — the things the market usually means by "AI governance." They live inside agent & context ops if anyone asks, and are not the story. Named business units and named capabilities — those get filled in on the whiteboard; the pattern has to hold before the specifics do. Team counts and the internal structure of the run layer — one run team or several is a scale decision.

Governance is how work flows. Each layer of the structure gets a board; each board is five decision states with an exit policy and a name on it; the arrows between boards are the only places tiers touch. Same shape at every altitude, which is what makes it teachable.

Four boards, one per governance tier, banded under the same five process headers the LiminalArc model has always used. Columns are decision states — hover any for its exit policy. Left rail: the cadence that moves items across columns. Right rail: who is accountable. Teal arrows are the innovation flow between boards; the black arrow is a request that crosses the line by contract; the dashed one is the unit-specific disposition.

boards the AI layers add the board capability teams already run the line

How to read it

Start at the top board and follow the teal arrows. A bet enters at objective alignment, becomes hypotheses at investment targeting, and each hypothesis lands on the experiments board. There it is registered before it is run — that one column is the whole coordination band, made mechanical. At release 1 the hypothesis is proven or killed; at disposition someone decides who owns it, and the fusion team is free. Common results hand off to the solutions board, where the owner is settled, the work is sequenced against real capability capacity, and the solution goes into operation with spend tracking and a kill switch. What it returns feeds back up to the bet.

The bottom board is the one capability teams already run. The model changes nothing there. It only adds one arrow in — capability changes requested by contract — and takes the tree's predictability as the thing everything above depends on.

Nothing on the page is an approval queue. The controls that exist are hard, cheap and automatic — budgets, alerts, kill switches, runtime defaults, human review before production — and the model expects to lean them out as maturity earns it. That's LiminalArc's compensating-controls principle applied to AI: early controls increase flow, and they're installed knowing they'll be removed.

Where it comes from

The five process bands, the board-per-tier shape, the work-item ladder (initiative → epic → feature → story, here bet → hypothesis → solution → feature), exit policies with named accountability, and the three principles — cadences decide, compensating controls then lean-out, the flow visible in a tool — are LiminalArc's tiered governance model as taught since 2014 and formalized in the four-tier Enterprise Delivery Approach. The investment-tier columns are used verbatim. What's new is the experiments board and the solutions board: the two tiers AI puts between strategy and the tree, and the many-to-many they exist to absorb.

Metrics is how the enterprise knows the system is working — measured at every tier of the governance model, chosen by goal → question → metric, split into what you can influence now and the outcome it produces. Predictability at the bottom is the precondition for everything above.

One row per governance tier: the goal, the question it asks (left rail), four metrics marked leading or lagging, and what good looks like (right rail). Below the line are the predictability metrics the client should already have. The bottom strip is the handful of numbers that only make sense across the whole system.

metrics the AI layers add metrics the capability layer should already produce the line

How to read it

Read each row as a sentence: the goal on the left, the question in the rail, and four numbers that answer it. The leading indicators are the ones a team can move this week — ready backlogs, registered experiments, budgets set before keys are issued. The lagging ones are what the P&L owner eventually sees. LiminalArc's rule since 2013 has been to start from the goal and work backward to the metric, never to collect a number because a tool happens to emit it.

The bottom row has two halves. The runtime half — cost per unit of work, usage, conversion rate, service level — is where AI either shows up in the business or doesn't: once a solution crosses the line and a capability owns it, it sits inside a P&L, and at the end of the day it has to grow sales or reduce cost. The build half is the test underneath: if capability teams can't hit completion ratio within ten percent and velocity within twenty, then "sequenced to capacity" on the governance tab is fiction and every cycle time above it is noise. You can't measure the top layer unless you measure the bottom one.

The system strip holds the numbers no single tier owns. Idea-to-value is the one that matters to a CEO; flow efficiency says where the waiting is; the shadow-AI index is the cheapest honest measure of whether the governance is being used or routed around.

Where it comes from

Goal-question-metric, leading versus lagging, and the capability-tier numbers with their targets — completion ratio within 10%, velocity within 20%, lead time under two weeks, team stability within 10% — are LiminalArc's health metrics for predictability, published in 2013 and unchanged since. Cost to value and early ROI are the portfolio-tier metrics from the product-driven-organization model; cycle time and blocked work are the program tier's. The runtime half of the capability row — cost per unit of work, usage and conversion — is the newest addition, measuring the business impact of AI on a capability's operations rather than the build. The experiments row is Basecamp 5's stated fundamentals — hypothesis validation and innovation accounting — made concrete for the first time. The solutions row adds what AI genuinely adds: spend, health and reuse. "Prove the system, don't grade the team" is the standing rule from Managing with Metrics.