Architecture and governanceThe decentralisation rival is real, but incomplete

Radical decentralisation has a strong case. Give each product team an approved budget and a security baseline, let it select the fastest stack, and consolidate only after customer demand is proved. This preserves local fit, reduces waiting and avoids a central platform built around imagined requirements. Where experiments are cheap and consequences are contained, the approach can be superior to premature standardisation.

It fails when identities, tool authority, context stores, evaluations, logs, incidents and supplier contracts fragment faster than the enterprise can observe them. A product team may optimise its workflow while creating an unpriced exit dependency. Several teams may buy the same capability through incompatible interfaces. An incident may cross domains without a shared trace or stop mechanism. Consolidation after demand becomes expensive because customer behaviour and operational knowledge have already formed around the local stack.

The platform answer can also fail. Central services become a queue. Common standards expand into domain design. Product teams build shadow infrastructure to escape lead time. Abstraction layers promise interchangeability but add latency, cost and debugging difficulty while no switch is rehearsed. Delivery lead time and developer burden are therefore control outcomes. A common core that people routinely bypass is not common in practice.

Modularity research provides a useful discipline. Baldwin and Clark describe option value created through design rules. Schilling examines modularity drivers and system boundaries. Yoo, Henfridsson and Lyytinen describe layered modular digital architecture, while Tiwana, Konsynski and Bush connect platform architecture with governance and environmental change. These ideas support explicit interfaces and separable choices; they do not prove that more modules or more abstraction always produce value.

Platform boundaryUse design rules to preserve separable choices

A design rule specifies what another component may rely on. For an AI production system, useful rules include the identity attached to a tool call, the trace fields needed to reconstruct a decision, the version keys that join model, context and workflow, and the failure semantics of a state transition. The rule is valuable because teams can change an implementation without renegotiating every neighbouring component. It is dangerous when it freezes an immature assumption or describes only the happy path.

The CIO should distinguish semantic stability from technical uniformity. Every domain may need to express delegated authority in the same terms, yet different identity services may enforce it during an acquisition transition. Every consequential decision may need a joined evidence record, yet a high-volume service and a research environment may use different trace stores. The invariant is the meaning, test and evidence. A shared implementation is a separate economic and operating choice.

Interfaces need version and retirement policy. An adapter that supports every historical contract becomes another concentrated platform. A breaking change without migration evidence pushes domains into frozen releases. Publish compatibility windows, test fixtures, telemetry for remaining use and a funded retirement route. Platform teams should know which consumers depend on an interface before changing it; domains should know when an old contract stops receiving support.

Modular boundaries also distribute failure. A model-plane outage should not silently corrupt tool state. A context-plane entitlement failure should prevent retrieval rather than fall back to an unscoped source. An evidence-plane delay should trigger an explicit operating decision for high-consequence action. Contracts therefore include degraded modes, timeouts, idempotency and stop behaviour. Resilience comes from known failure boundaries, not from drawing more boxes.

Finally, design rules should be observable. Conformance tests prove a component can speak the contract. Production evidence shows whether it does so under load, change and incident. The CIO needs both. A domain that passes a tool schema test but repeatedly calls outside its delegated limit is not conformant in operation. A platform that publishes a recovery interface but cannot restore decision state has not supplied the promised capability.

The original constructSeven planes of an AI production platform

Cross-plane integrityGovern the joins where consequence changes

Most material failures appear at plane boundaries. The interaction says advice while the tool layer executes. The orchestration checkpoint records success before the downstream transaction commits. The model router changes an endpoint without selecting the compatible evaluation set. Context is retrieved under a human entitlement and then retained in service state beyond that entitlement. A trace captures the model response but not the identity and policy decision that authorised action.

Create a small set of cross-plane transaction records. A consequential action should join the initiating human or system identity, delegated authority, workflow and checkpoint version, model configuration, context provenance, tool request, result, evaluation state and incident reference. Not every field needs to sit in one database. It needs a stable correlation contract and retention boundary that allows authorised reconstruction.

Change management should use the same joins. A supplier model release can alter output distribution without changing the orchestration version. A context index rebuild can change retrieved evidence without a prompt change. A tool API can modify failure semantics while passing schema validation. Release evidence should declare which planes changed, which evaluations were rerun, which assumptions remain and who can roll back. “No code change” is not evidence that system behaviour is unchanged.

Incidents also travel across planes. Triage begins with the observed customer or operational effect, then follows the joined record through action, policy, state, context and model. Domain responders need enough local detail to contain quickly. Enterprise responders need shared severity, evidence and escalation semantics to recognise correlated exposure. A common ticketing tool alone cannot create that understanding if the underlying events name different systems and consequences.

Technical optionality depends on cross-plane integrity because a switch tests the joins as much as the components. The alternative must accept the identity and context contracts, reproduce tool behaviour, reconstruct state and emit evidence the operating team can use. An endpoint that produces similar text while losing an action limit or trace relationship is not an equivalent target. Behavioural comparison must cover consequential joins, not just sample outputs.

Five governance modesStandardise the obligation before the implementation

Mode selectionRoute by consequence, reuse, coupling and operating evidence

Start with consequence. If a capability determines identity, tool authority, incident severity or the evidence needed to reconstruct enterprise loss, it likely needs an invariant. That does not settle implementation. Next test reuse and operating scale. Broad repeatable demand, specialist reliability needs or concentrated scarce expertise can justify a shared service. Demand that merely looks similar in an architecture catalogue may diverge once domain latency, state and customer obligations are included.

Coupling changes the answer. A local context assembler with limited external effect can remain federated. A service that controls identity and transaction limits across domains may require stronger shared semantics and operation. Coupling should be demonstrated through change and incident paths, not inferred from how many teams use a component. A popular library may be loosely coupled; a rarely used emergency-stop service may be tightly coupled to enterprise risk.

Use developer burden as evidence about the selected mode. A shared service with repeated exceptions may have the wrong interface or scope. A federated capability with inconsistent incident joins may lack a sufficiently precise contract. A supplier service that needs extensive local wrappers may no longer offer the economics that justified management. The response is to revisit the route, not to declare teams non-compliant without examining the design.

Mode can change over the lifecycle. A bounded exception may reveal stable domain requirements and become federated. Several federated implementations may converge enough to support a shared service. A shared service may split when one domain’s consequence or delivery clock differs materially. A managed supplier may become an invariant-backed federation after exit. Record the observation and decision that justify the transition so architecture does not drift through organisational fashion.

Technical optionalityDecompose what must move

Optionality has at least eight assets. Code and configuration capture prompts, routing and orchestration. Context and data include source rights, indexes, lineage and decision-time snapshots. Evaluations include cases, expected behaviours, judges and thresholds. Tools include schemas, permissions and transaction semantics. State includes memory, checkpoints and in-flight work. Identity and policy include credentials, delegations and enforcement. Telemetry includes trace semantics and incident joins. Operating knowledge includes runbooks, troubleshooting, capacity practice and supplier-specific expertise.

Each asset can have a different portability state. Code may be exportable while evaluation results cannot be replayed. Data may be downloadable while entitlement metadata is lost. A tool interface may be standard while the supplier runtime controls retry and state. Open weights may be available while serving expertise, accelerators and fine-tuning data remain concentrated. The CIO should record the asset-level evidence and name the switching trigger, target alternative and acceptable loss.

The organisation should price optionality. Multiple implementations create integration, testing, skills and control burden. An adapter that is never exercised can make delivery slower without buying a real switch. Conversely, a deeply integrated supplier may be economically sound when switching is improbable, consequence bounded and exit obligations credible. Optionality is an option whose premium should be compared with concentration exposure and strategic use.

A switching rehearsal is the strongest evidence. Export configuration, context, test suites, state and runbooks. Replay a representative workload. Compare behaviour, economics, latency and control outcomes. Cut over a bounded population. Prove rollback. Record which losses are acceptable and which invalidate the alternative. This moves the conversation from architecture claims to operating capability.

Dependency and exitJoin contracts, technical exports and operating knowledge

A supplier exit clause can secure access to data and assistance, but it cannot by itself produce a runnable alternative. Technical export may omit hidden configuration, entitlement relationships, evaluation history or in-flight state. The operating team may know how to diagnose the current runtime but not the target. The CIO should reconcile legal rights, technical artefacts and human capability in one exit plan, with owners and dates for each gap.

Concentration is not limited to a vendor. A serving framework may be open while one cloud supplies the accelerators. Fine-tuning data may be portable while only one team understands the pipeline. A standard tool protocol may exist while downstream systems depend on a vendor’s retry behaviour. A second provider may share the same upstream infrastructure. Dependency mapping should identify the resource, knowledge and correlated failure behind the product name.

Continuity and exit are related but different. Continuity keeps an existing service operating through disruption. Exit changes the dependency. A replicated supplier region may improve continuity while increasing lock-in. A portable evaluation suite may support exit while doing little for a current outage. Operational-resilience exercises should state which objective they test, the disruption tolerated and the decision authority involved.

Switching triggers also need precision. A price increase may justify commercial negotiation rather than migration. A loss of context rights, audit access or action control may cross a red line. Persistent capability lag may shift the product thesis. Regulatory or jurisdiction change may narrow the permitted operating boundary. Tie each trigger to the assets that must move, the target alternative and the maximum transition loss management may accept.

Exit evidence decays. The supplier changes formats, the domain adds a tool, the context store grows and runbooks evolve. Rehearsal frequency should follow consequence, rate of change and concentration. Between full exercises, test asset exports, schema compatibility and evaluation replay separately. An old successful cutover is historical evidence, not permanent optionality.

Control as delivery evidenceMeasure the burden that creates shadow platforms

Platform lead time should be measured from a domain’s ready request to usable production capability, including evaluation and control evidence. Developer burden includes integration work, documentation gaps, incompatible releases and debugging across layers. Exception demand shows where the common core does not fit. Shadow deployment shows where formal control has lost practical authority. These are not reasons to relax consequence boundaries; they are signals to repair the service or choose federation.

A central evaluation team that adds weeks to every change can weaken control by encouraging teams to bypass it. The CIO can standardise evaluation contracts, reference cases, trace joins and release thresholds while allowing qualified domains to execute tests. Enterprise assurance can sample and challenge. High-consequence systems may still require independent validation, but the requirement should be tied to consequence rather than applied as a uniform queue.

Run cost and change cost need a joined view. Cheap inference can sit inside an expensive orchestration and review path. A reusable service may lower duplication while raising coupling to its release cycle. A federated capability may cost more per domain while preserving customer speed. FinOps allocation helps expose variable consumption, but finance and architecture must also account for platform teams, controls, incident capability, exit preparation and the cost of retained expertise.

Decommissioning is part of the platform product. Duplicate vector, prompt and agent platforms create inconsistent evidence and expand the incident surface. Consolidation needs a target contract, migration path, credential revocation, data and state handling, customer transition and proof that old workflows no longer depend on the capability. Switching off infrastructure without removing authority or reliance is not retirement.

Negative controlsEight cases the map must route

Interactive instrumentCIO Platform Control and Optionality Console

The Console records the capability, consequence, contracts, dependencies, portability assets, operating burden, economics and exit state. It returns a governance route with next evidence. It does not compress optionality into one score.

The CIO operating agendaKeep the common core small, observable and rehearsed

Start with enterprise invariants that follow consequence: attributable identity, delegated tool authority, evidence joins, incident severity, version and retirement records. Publish them as testable contracts. Decide separately whether each contract needs a shared implementation. This prevents a control requirement from becoming a universal platform mandate by default.

Give shared services product disciplines: users, service levels, roadmaps, compatibility, support, cost allocation and retirement. Track lead time, developer burden and exception demand beside availability. A service with excellent uptime and poor adoption may not be controlling the enterprise. Fund contract test kits and reference implementations so federation is a supported route rather than an informal exemption.

Maintain an asset-level dependency register for material systems. Link it to supplier reviews, operational resilience, incident exercises and the finance view of variable cost. The Basel operational-resilience principles and, where applicable, outsourcing guidance support mapping dependencies, tolerance, continuity and exit. Their scope should not be stretched into a universal legal obligation, but the operating questions are useful beyond regulated banking.

Schedule switching and recovery rehearsals according to consequence and concentration. Use bounded production populations where safe. Record losses in behaviour, evidence and operations, not only cutover duration. A failed rehearsal is valuable if it changes architecture, contract or risk acceptance before a forced exit. A rehearsal that never reaches context, state or tool authority is theatre.

Finally, retire duplication. Every platform creates owners, credentials, interfaces, traces and habits. A portfolio that only adds common services eventually has more control planes than it can govern. The CIO agenda is therefore subtractive as well as constructive: establish a small core, let domains move behind dependable contracts, manage suppliers honestly, expire exceptions and prove that redundant authority is gone.