What It Takes to Do an Architecture Control Plane Right

In July we published a white paper giving CTOs a framework for the Architecture-Led AI SDLC, built around a maturity model for the architecture control plane: the layer where an organization understands its systems, makes system-level decisions, and governs how the estate evolves. The model runs five levels, from Tribal (architecture living in senior engineers' heads and stale diagrams) to Continuous (architecture as an always-on function), with two inflections that matter most: Level 3, where a living model of the actual architecture exists and refreshes automatically, and Level 4, where expert reasoning operates over that model with the business's objectives in the loop.

Since then, the question we hear most is not whether the ladder is right. It is: what does it actually take to operate at the top of it? The question is not which tool to buy, but what the layer itself must contain to support that level of operation.

This piece is our answer. The formula below is what any organization should demand of an architecture control plane, whoever builds it. It also describes what we have built at Catio.

Start with the true shape of the problem

Anyone who has worked in systems optimization knows the structure: an objective function that defines what you are maximizing, a constraint set that defines what is feasible, and the work of finding the best solution within both. Architecture decisions have this same shape, with one addition most treatments skip. The objective function is the business: what you are trying to achieve, what you will not trade off, the goals for cost, resilience, and velocity, the compliance obligations that bound every path. The constraint set is the system you already run: services, dependencies, data flows, and the investments any proposal must respect rather than wish away. And the addition is the judgment call: the standards and strategies an organization is willing to bet on. Given the same objective and the same constraints, many defensible ways to optimize exist, and an AI left to itself will find one of them. Not necessarily yours. The difference between what AI would pursue on its own and what your organization would actually build lives entirely in that third part.

Most organizations run this optimization with all three parts implicit. The objectives live in strategy documents the engineering tools never see. The constraints live in the heads of the people who built the system. The standards live in the judgment of the architects who set them, applied one review at a time. AI then reasons in that vacuum and produces generically good answers that are convincing, well-structured, and optimized for nothing in particular.

A control plane done right makes all three explicit, durable, and present in every decision. Everything else follows from that.

Ingredient one: a living record of the system and its objective function

The first requirement is a system of record for architecture, and it must hold two things at once.

System truth: the architecture as it actually runs, continuously integrated from sources that don't go stale: the cloud estate, the source code, cost and usage, the network's observed relationships. Not a diagram someone drew last quarter. A model that refreshes as the system changes, and that is semantic rather than flat: a service connected to the products it supports, the infrastructure it relies on, and the constraints that govern it, because decisions depend on how facts connect, not just on whether a document exists.

The objective function: business and product objectives, constraints, and standards enter the same model as first-class context, along with the judgment call. This is the half most attempts skip. Encoding the objectives, the settled trade-offs, and the organization's standards is how architects steer which of the many defensible optimizations gets built.

Held together, the two halves let human and AI teams reason the way a great architect already reasons in their head, over the whole equation at once, but at the scale of the whole estate and continuously: every data point in the system, every objective and standard, available to every decision rather than to the few people who happen to hold them.

This pairing is the Level 3 inflection, and it is foundational for a simple reason: every downstream capability inherits it. Reasoning over a stale model produces confident answers about a system that no longer exists. Reasoning without the objective function produces best practice in a vacuum.

Ingredient two: expert reasoning, grounded and checked

A record alone is accurate documentation, but it remains inert. The second requirement is reasoning that turns it into decisions. Two things shape the quality of any AI answer: the context it can reach, and the reasoning approach it takes. Ingredient one supplies the first. This is about the second.

It reasons target-first and works like a team. Ask a capable model with good context how to optimize your data architecture, and it will assess what you have, find what looks suboptimal, and propose fixes. An experienced architecture team works the other way around: first it establishes the right target architecture for your organization's objectives and constraints, then measures the gap between what runs today and that target, ranks the gaps by size against the investment to close them, and recommends the highest-ROI optimization plan. That produces a better answer to the same question. And that posture has to apply to every architecture question, from a two-second lookup to a multi-month program.

Its methods are managed, measured, and improved, not hand-tuned prompts. The reasoning strategies themselves (how to run a gap analysis, how to reconcile ROI, how to sequence a roadmap, how to validate a finding adversarially) need to be identified, evaluated on how well they meet their objectives, and evolved as better techniques are learned. They also need to be reused: a technique polished on one kind of problem transfers to the next. Treating those methods as managed, versioned assets keeps the system improving instead of freezing at whoever wrote the last prompt.

It grounds every claim and grades its evidence. Every component the reasoning names should resolve against the live model. A premise the system contradicts should be challenged rather than accepted: if the question says the migration is finished and nine services are still running, the right answer starts there. Figures should be computed against real data, with the limits that apply stated alongside. And every claim headed to a decision-maker should carry its evidence tier (verified in the system, inferred from structure, or expert judgment) and its citations, so a reader knows what they can bank on and what still needs a human's eye. Scope, portfolio size, and depth derive from the mandate, never from a hard-coded number.

This is the Level 4 inflection: an expert team reasons target-first over the whole record, objectives included. Every claim is grounded and graded, every method can improve, and every answer is checked by an independent review it cannot influence before it reaches the user. Human judgment can then focus on the exceptions.

Ingredient three: a system of work

Reasoning that never reaches delivery is advice. The third requirement is the workflow that makes decisions real, and it has three jobs: delivery, governance, and lifecycle memory. Delivery: proposals reviewed by the people accountable for them, decisions recorded with their reasoning, and specs flowing to the developers and coding agents who build. Governance: delivered work verified against the intent, with exceptions, not every change, routed to the architects who own the standard. Lifecycle memory: decisions persisting as context (what was decided and why) attached to the system they shaped, so the next decision starts from everything the organization has already settled. Prior findings re-enter the next run as constraints, so an analysis re-run a month later refines the last answer instead of re-rolling it. It should change when the architecture or objectives change, not churn without cause.

That memory is what makes the whole arrangement compound. Each decision sharpens the context the next one draws on, which is how a control plane earns its keep over years rather than in one engagement.

The formula works only as a whole

The record without the reasoning is documentation. The reasoning without the record is fluent guessing: articulate, and wrong where it matters. Together, without a system of work, they produce analysis that evaporates on contact with delivery. Each ingredient is necessary. Only together are they a control plane.

And the measure of the whole is not how much it knows. It is whether the system got better, and how fast the right call lands. Drawing on our own work and what we see with customers, these figures describe the direction an architecture control plane should move an organization toward. They are practical benchmarks for progress, not a claim that every organization starts from or reaches the same numbers. We began laying out that scoreboard in Your Coding Agent Has an Architecture Problem; it belongs next to the velocity metrics, and every line of it maps back to an ingredient above.

• Mean Time to Informed Decision (MTID): about 5 minutes from any architecture question to a decision-grade answer, where informed means grounded in the live system, weighed against the objectives it serves, and shaped by human and AI judgment together. The headline number, and the one that depends on all three ingredients at once.
• Time to a committed modernization plan: less than 12 hours to a strong first draft, less than one week to a committed plan, aligned to a 2 to 3 year roadmap. MTID at the scale of a strategic call: the record and the reasoning, working together.
• Design throughput, at alignment: multiple execution-ready, system-and-objective-aligned specs per day, one for each PRD and Jira ticket, versus roughly one reviewed design a week the manual way. The reasoning is handed into the system of work.
• Medium and large tickets shipped without a system-and-objective-aligned spec: zero, versus roughly 90% today, because principal architects cannot keep up with features shipping at AI speed.
• Exception rate, not review rate: under 10%, versus over 50% today when under-specified work ships at AI speed. The share of shipped changes that diverge from a system-and-objective-aligned spec, not merely from whatever spec they happened to ship against. The system of work's governance job, and the number that lets architects stop reviewing everything.
• The rework tax, trending down: less than 5%, versus the 30 to 40% of engineering effort today going to rework from drift and technical debt. The single number the whole formula exists to attack.

A control plane done right moves all of these at once, for strategic calls and for the design behind every new feature alike. A partial one moves one or two and calls it progress.

Where this lands

This formula is the blueprint we build to. The Architecture Knowledge Base is the living record: system truth and the objective function, judgment call included, in one continuously evolved model. Archie-3, released in September, is the grounded expert layer: an architecture team spawned for every question, sized to it, reasoning target-first over the whole record and checked by an independent review before it answers. And the console, from Blueprints through the review board to specs delivered into coding tools over MCP, is the system of work that carries decisions into delivery, governance, and memory.

The white paper lays out the ladder and its levels in full. This is what it takes to climb them to the top.

Read the white paper: The Architecture Control Plane, a CTO's Framework for the Architecture-Led AI SDLC. Or bring a real decision and see the control plane run on your own system: book a demo.