One enterprise required every prompt, workflow change and evaluation to pass through a central AI team. Its queue lengthened, domain context degraded and local teams routed around it. Another let each domain buy its own gateway, evidence store and monitoring. Delivery moved faster until provider exposure, data movement and incident impact became impossible to see in aggregate.

Both organisations treated ownership as a binary choice. Centralisation promised consistency but moved domain decisions to a team that could not own their consequences. Decentralisation protected local speed but reproduced fixed costs and fragmented control. The durable question is narrower: which properties must remain invariant across the enterprise, which services earn reuse, and which decisions require local authority?

A federated operating boundary answers at the capability level. Identity protocol may be mandatory. A model-routing service may be an optional paved road. A domain evaluation implementation may be locally owned under common evidence contracts. Workflow thresholds and customer outcome measures may remain entirely in domain space.

The boundary is not drawn once. It changes as demand, providers, regulation, cost, domain knowledge and system consequence change. Each placement has an owner, consumer contract, evidence tests, exception route and review trigger. Disputes move through an explicit mechanism rather than through platform backlog or silent circumvention.

Original synthesisThe four-zone federated AI operating boundary

The federated AI operating boundary is this article’s synthesis. Four zones distinguish mandatory shared truth from optional reuse, contracted domain implementation and genuinely local space. Placement is not a maturity ladder. The same domain may consume a paved road for model access, federate evaluation and own its workflow locally.

An enterprise invariant is kept deliberately small. Identity proof, audit lineage, prohibited-action enforcement or a provider-risk record may need common behaviour because local divergence destroys attribution or aggregate control. The central owner defines the invariant, operates or certifies the mechanism and provides an exception path for conditions it did not anticipate.

A paved road earns adoption rather than relying on prohibition. It combines a reusable service, tested defaults, documentation, service level, cost transparency and portability. Domains can choose an alternative if they meet the required invariants and contract tests. This consumer right forces the platform to remain a product, not a compulsory queue.

Contracted federation is useful when local knowledge and change rate matter but enterprise evidence must remain comparable. A credit domain may build its own evaluation and threshold logic while emitting a common evidence schema, observing security rules and contributing provider telemetry. The enterprise sees exposure without owning the credit decision.

Local domain space includes choices whose reuse value is low and context dependence high. Vocabulary, workflow sequencing, customer communication, exception policy and outcome measures often belong here. Local ownership still carries evidence, risk and security duties. “Local” means accountable authority, not exemption.

An invariant must pass a strict qualification test. The enterprise owner states the harm caused by divergence, the smallest behaviour that prevents it and why contract conformance or substitution cannot provide equivalent protection. “Consistency” alone is insufficient. If identity attribution requires one protocol, the invariant names the proof and enforcement point without absorbing domain workflow or customer policy.

The invariant also carries a service obligation. Mandatory consumption makes its failure an enterprise dependency, so reliability, capacity, recovery, versioning and incident response require an accountable product owner. Domains receive notice, evidence and escalation rights even when they cannot substitute the mechanism. A rule with no operating owner becomes central policy that local teams must interpret on their own.

Every capability record preserves the boundary reasoning. It names consumers, reuse economics, divergence mechanism, local knowledge, change rate, aggregate exposure, service level, cost, portability, exception path and owners. Assumptions have review triggers. A new provider concentration, repeated local exception or platform incident can reopen placement without restarting the whole governance debate.

Modularity research shows the value of stable design rules that allow independent work behind interfaces.[1] Architectural innovation also warns that changing relationships among components can disrupt established knowledge even when components appear familiar.[2] The four zones make both interfaces and relationship ownership visible.

Boundary decision fieldPlace capabilities through competing information and risk needs

Reuse economies pull a capability inward. Identity integration, provider connections, evaluation infrastructure and telemetry can carry fixed costs that should not be rebuilt by every domain. Reuse is proved through named consumers and shared requirements, not by calling a component foundational. Demand variability also matters because a common service can pool capacity or create contention.

Divergence consequence is different. Some variation destroys enterprise control: incompatible identity, missing audit lineage or bypassed prohibited-action policy. Other variation is the purpose of federation: domain thresholds, workflow choices or customer interventions should differ when outcomes and obligations differ. The boundary states what may vary and how consequence is observed.

Domain knowledge and change rate pull authority outward. A generic platform team cannot reliably own credit adjudication, clinical escalation or maintenance policy. When vocabulary, evidence and workflow change through local learning, a central queue loses context and delays improvement. Stable interface contracts let the domain move without altering enterprise invariants.

Blast radius and aggregate-risk visibility can pull evidence inward even when implementation stays local. Separate domain gateways may hide common provider concentration, shared data exposure or correlated model failure. A central telemetry contract can reveal those patterns without centralising every release or business threshold.

Substitutability changes the platform obligation. A compulsory service with no alternative, opaque cost and weak service is an enterprise invariant or monopoly, not a paved road. If the service is truly mandatory, leaders should govern it as such and accept its failure consequence. If alternatives are safe, portability and escape tests protect domains from platform tax.

Placement also depends on coordination latency. A capability can have strong reuse economies and still belong in federation if every change requires domain evidence that the centre cannot acquire quickly. Conversely, a rapidly changing provider interface may benefit from central ownership even when domain workflows change faster. The record separates the change rate of the shared mechanism from the change rate of its local use.

Blast radius is assessed in both directions. A central service can create common failure across domains. A local service can create enterprise harm through common data, provider or external action. Ownership alone does not reduce blast radius; isolation, fallback, observability and authority do. The chosen zone states who detects, contains and recovers the relevant failure.

Organisation design can be understood as placing information-processing capacity where uncertainty must be resolved.[5] Strategic alignment research similarly connects business and technology choices rather than treating infrastructure as separate.[6] The field places authority where the relevant information and consequence can be owned.

Consumer rightsA paved road is a product, not a compulsory toll booth

The central queue failure usually begins with good intentions. A platform team tries to assure quality by reviewing prompts, workflows and evaluations. Domains supply context through tickets. The team becomes a translator and bottleneck, while decision accountability remains unclear. Domains then bypass the queue through unmanaged tools, making control weaker than before.

A paved road offers a narrow service contract. It names functionality, availability, latency, capacity, recovery, security, evidence, support, cost and change policy. Defaults are tested and documented. Consumers receive version notice, incident communication, usage evidence and a route to influence the roadmap. Product ownership includes reliability and adoption, not merely build.

The platform-tax negative control makes consumption visible. A mandatory service may cost more or perform worse for one domain because its workload is unusual. Chargeback shows fixed and variable cost, cross-subsidy and domain-specific support. The domain can challenge placement with measured evidence rather than arguing from preference.

Escape is constrained, not casual. A domain alternative must satisfy enterprise invariants, contract tests, telemetry and provider-risk duties. It has an owner and expiry if the exception is temporary. Portability tests confirm that data, evidence and configuration can move without recreating a hidden proprietary dependency.

Contract tests are executable where possible. Identity assertions, evidence lineage, schema compatibility, prohibited actions, telemetry completeness, recovery and export can be tested against versions. Domain-specific outcome tests remain with the domain. A central template that says “human review” without authority, information, capacity, timing and intervention rights is rejected because the words do not establish an operating control.

Consumer councils provide evidence, not shared veto over every roadmap choice. Domains report service friction, demand variation, incidents, cost and planned change. The platform owner decides product priorities within the service contract and publishes trade-offs. If a change breaches consumer rights or an invariant, the dispute path can pause it. This is faster than turning routine product management into enterprise consensus.

Platform research describes foundations that support complementary innovation.[3] That logic requires a relationship with complementors. A central service that dictates domain workflow while offering no rights, service commitment or exit is not enabling complements. It has absorbed authority it cannot exercise responsibly.

The platform’s completion receipt is consumer evidence: named domains adopted it, service objectives held under real demand, costs matched the allocation contract, incidents recovered, versions moved without breaking consumers and at least one escape or portability path was tested. Internal component milestones do not establish a paved road.

Local detail and shared exposureReveal aggregate risk without erasing domain context

Local sprawl is not merely duplicate spend. Separate gateways, stores and monitoring can prevent the enterprise from seeing shared providers, common model families, concentrated data transfers and correlated failure. Each domain may appear within tolerance while the portfolio depends on one external control plane or identity service.

The aggregate-risk telescope collects a narrow evidence set: provider and model identity, data category, action consequence, volume, incident, dependency, evaluation version and recovery status. Domains retain detailed cases and outcome interpretation. The central view reveals concentration and common-cause exposure without turning domain telemetry into central decision authority.

Comparability is designed. A common field such as “high consequence” needs a typed definition and local evidence. Otherwise domains emit labels that look consistent and mean different things. Shared schemas include provenance, version and permissible aggregation. Central analysts can follow an aggregate signal back to accountable domain evidence.

Aggregate telemetry follows minimisation and purpose. The enterprise does not need every customer record to see provider concentration or recovery weakness. It needs typed exposure, consequence and incident evidence linked to an accountable domain. Retention, access and onward use are constrained so shared visibility does not become an ungoverned central data lake.

Provider risk may justify an invariant register and centrally negotiated rights. It does not require one model choice for every domain. Third-party-risk principles address governance, assessment, due diligence, contracting, monitoring, continuity and exit.[11] Domains contribute use-specific consequence while the enterprise sees concentration and lifecycle obligations.

NIST AI risk resources frame governance, context, measurement and management as connected activities.[7][8] The Generative AI Profile adds considerations specific to generative systems.[9] The federated boundary uses common evidence duties while allowing domain-specific measures and controls.

Portfolio exposure and ownership remain distinct. A central risk function can require additional evidence, constrain a provider or prohibit an unsafe pattern. It does not choose the domain threshold or customer intervention unless it owns that business decision. Escalation joins the relevant authorities rather than transferring all accountability to the platform.

Boundary movementExceptions expire, produce evidence and change the rule

An exception is a bounded experiment in boundary placement, not a quiet waiver. The domain states why the current service or invariant fails its use, which alternative it proposes, the population, risks, contract tests, owner and expiry. Enterprise owners state which properties remain mandatory and what evidence can justify reintegration or a permanent boundary change.

Approval is proportional to blast radius. A read-only evaluation experiment may run under telemetry and data controls. A consequential write path needs authority, recovery and prohibited-action enforcement. The exception cannot create a second identity scheme, unobservable provider exposure or an indefinite local store through a broad label such as “innovation”.

Evidence during the exception includes outcome, service, cost, incident, control and portability results. If the local alternative outperforms the paved road, the platform can improve, recognise a contracted federation or change its placement. If the alternative creates unacceptable aggregate risk, the domain must reintegrate or stop. Either result teaches the boundary.

Exception expiry is enforced at access and funding where practical. Credentials, provider accounts and data routes have end dates. The owner cannot renew by silence. Extension states continuing value, burden, new consumers and the next decision. Repeated exceptions with the same mechanism may show that the central contract is wrong rather than that domains are undisciplined.

Boundary disputes join product and decision authorities. The platform owner presents reuse, reliability and cost. The domain owner presents outcome, knowledge and change evidence. Risk and security present divergence consequence and aggregate exposure. A designated enterprise arbiter decides placement, scope and expiry without taking the underlying business decision away from its owner.

The dispute record states the contested property, evidence, temporary operating state, decision rights and appeal trigger. Work can continue inside a safe boundary while the placement question is resolved. The arbiter cannot solve delay by moving a credit, clinical or operational decision to the platform team; it can only determine the enterprise contract and which accountable owner may implement within it.

Repeated disputes are design signals. Domains may be exploiting unclear escape rights, or the platform may be trying to standardise an outcome it cannot own. Reviewing dispute patterns can split an oversized invariant, improve a paved road, strengthen a contract or recognise legitimate local variation. Governance learns from friction rather than treating every challenge as non-compliance.

Polycentric governance offers a useful lens for multiple centres of authority operating under shared rules.[4] Federation has negotiation cost, inconsistent experience and contract maintenance. Those costs are accepted where local information matters, while narrow interfaces and adjudication keep negotiation from becoming permanent ambiguity.

Worked counter-caseShared credit infrastructure without centralised credit accountability

Consider a credit domain introducing an AI-assisted review workflow. Enterprise identity authenticates people and services. Central model routing records provider, version and cost. A shared evidence schema carries provenance, entitlement and evaluation receipts. Common telemetry exposes incidents and concentration. These are invariants or paved roads because reuse and aggregate risk are material.

The credit domain owns case workflow, policy interpretation, decision thresholds, evidence relevance, override authority, customer communication, outcome evaluation and release. These choices depend on product, customer, regulation and risk appetite. A technology platform team can provide tooling and enforce contracts, but it cannot accept credit consequence or own the decision.

Control by template fails when a central guardrail merely says “human review required”. Meaningful review needs a named authority, information, time, capacity, intervention options and consequence. The domain designs that operating control and provides evidence through the enterprise schema. The invariant concerns proof and prohibited actions, not one generic screen.

The domain can use a local evaluation implementation under contract. It covers required outcome and subgroup evidence, records cases and versions, supports independent review and exports aggregate exposure fields. The central team certifies contract conformance and may challenge a provider or common failure. It does not set the domain’s acceptance threshold.

Cost follows consumption and responsibility. Shared identity and telemetry have transparent allocation. Model-routing charges show usage and fixed core cost. Domain workflow, evaluation and change capacity remain in the credit budget. Cross-subsidy is declared where an enterprise resilience option benefits all consumers. This prevents the platform tax from disappearing into a central budget.

Current model-risk guidance emphasises a risk-based approach tailored to model use and organisational profile for models within its scope.[10] AI adoption evidence also points to skills, management and complementary organisational change, not merely access to technology.[13] The worked stack assigns control and learning to the owners who can act on them.

The stack produces paired receipts. The platform reports service, provider, cost, incident and portability evidence. The credit domain reports decision, outcome, override, customer and control evidence. A shared identifier joins the records without confusing their owners. When an aggregate provider issue appears, the enterprise can constrain exposure while the domain decides how affected credit work should continue.

Release authority remains explicit. The platform can reject a non-conforming identity, evidence or telemetry contract. It cannot approve the credit threshold merely because the technical tests pass. The domain can approve the workflow only inside enterprise invariants and its own risk authority. A joint record shows both decisions and the conditions that would reopen either one.

Boundary success is measured in operating terms: platform adoption without coercive bypass, domain change without lost evidence, comparable aggregate exposure, met service commitments, visible cost, resolved exceptions and accountable outcomes. This evidence supports later movement between zones and reveals when federation overhead exceeds the local value it protects.

Interactive instrumentPlatform-Domain Boundary Designer

The designer returns one ownership route, accountable owner and required contract. It does not generate a centralisation score. A capability may be central because divergence destroys enterprise control, paved because reuse is strong and alternatives safe, federated because local implementation needs common evidence, local because knowledge and change dominate, or prohibited because no zone can contain its blast radius.

ConclusionCentralise invariants, not every consequential decision

The centralisation debate becomes tractable when ownership is assigned capability by capability. Enterprise invariants protect shared truth and control. Paved roads earn reuse through service, cost and consumer rights. Contracted federation preserves local implementation behind comparable evidence. Domain space keeps workflow and outcome authority close to the work.

Placement responds to reuse, divergence consequence, domain knowledge, change rate, aggregate-risk need, blast radius and substitutability. These forces can point in different directions. A shared telemetry contract can reveal provider concentration while evaluation remains local. A common identity protocol can coexist with different customer workflows.

The platform must behave as a product. Domains see service levels, costs, change rights, recovery and portability. A mandatory component is governed honestly as an invariant. Local alternatives satisfy the same narrow evidence and security duties. Exceptions have owners, tests, expiry and a decision that can improve the central road or redraw the boundary.

Federation carries negotiation and interface cost. Narrow contracts, typed evidence and explicit adjudication prevent that cost from becoming ambiguity. Aggregate views preserve local provenance. Central risk can constrain common exposure without taking domain decisions. Domain teams can learn rapidly without making security or provider risk invisible.

The durable boundary is revisable. Consumer evidence, service performance, incident patterns, local outcomes and changing economics can move a capability between zones. What remains stable is accountability: the enterprise owns invariants and shared exposure; platform teams own reusable services; domains own business workflows, thresholds and consequences. Every move transfers its service, cost, evidence and recovery duties with it. The placement record makes that transfer visible to every affected consumer and authority. Its evidence remains auditable and independently reviewable.

Evidence spineReferences

1. Baldwin, C. Y. and Clark, K. B. (2000), Design Rules, Volume 1: The Power of Modularity, MIT Press. doi:10.7551/mitpress/2366.001.0001.
2. Henderson, R. M. and Clark, K. B. (1990), ‘Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms’, Administrative Science Quarterly, 35(1), 9–30. doi:10.2307/2393549.
3. Gawer, A. and Cusumano, M. A. (2014), ‘Industry Platforms and Ecosystem Innovation’, Journal of Product Innovation Management, 31(3), 417–433. doi:10.1111/jpim.12105.
4. Ostrom, E. (2010), ‘Beyond Markets and States: Polycentric Governance of Complex Economic Systems’, American Economic Review, 100(3), 641–672. doi:10.1257/aer.100.3.641.
5. Galbraith, J. R. (1974), ‘Organization Design: An Information Processing View’, Interfaces, 4(3), 28–36. doi:10.1287/inte.4.3.28.
6. Henderson, J. C. and Venkatraman, N. (1993), ‘Strategic Alignment: Leveraging Information Technology for Transforming Organizations’, IBM Systems Journal. doi:10.1147/sj.382.0472.
7. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
8. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
9. National Institute of Standards and Technology (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. doi:10.6028/NIST.AI.600-1.
10. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
11. Basel Committee on Banking Supervision (2025), Principles for the Sound Management of Third-Party Risk. Bank for International Settlements.
12. European Union (2022), ‘Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector’. EUR-Lex.
13. OECD, Boston Consulting Group and INSEAD (2025), The Adoption of Artificial Intelligence in Firms: New Evidence for Policymaking. OECD Publishing.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.