Two domains both stayed inside their local vendor limit. Both passed their own evaluation and incident reviews. The enterprise still could not explain its total dependency, because the vendor identities differed across registers, failure categories could not be compared and exceptions never left the domain.

Local compliance had produced enterprise blindness. The response was not necessarily to centralise every decision. Central teams lacked workflow knowledge and could not own the customer outcomes. The missing architecture was a boundary contract: common identity, provenance, incident semantics and exposure evidence, alongside declared local choices.

Federation is neither a soft synonym for decentralisation nor central policy with delivery pushed outward. It partitions one recurring decision. The enterprise fixes the properties whose divergence would create common failure or destroy interoperability. Domains decide the properties whose quality depends on local meaning, consequence and operating trade-offs.

Fragmentation appears when variation has no typed interface. Local teams fork shared assets silently, evidence cannot travel, exceptions remain invisible and aggregate exposure cannot be reconstructed. Federation succeeds when local fitness and enterprise coherence are both observable.

Original synthesisThe three-zone federation architecture

The three-zone federation architecture is this article’s synthesis. It separates enterprise invariants, versioned contract space and domain sovereignty. Each recurring decision receives a boundary clause rather than relying on a generic council, shared tool or hub-and-spoke picture.

The invariant zone is intentionally small. Identity must mean the same thing if attribution and access cross domains. Incident terms need comparability if enterprise response depends on them. A common provider register and exposure schema can reveal concentration. The zone does not contain every desirable practice or one universal workflow.

The contract zone makes variation legible. Shared retrieval, evaluation, routing or observability can expose versioned interfaces and configurable parameters. Domains know which behaviour is mandatory, which can change, how conformance is proved, what evidence crosses the boundary and what happens when the shared service changes.

Domain sovereignty protects the knowledge central teams cannot cheaply acquire. Data meaning, customer consequence, decision population, workflow state and benefit capture often differ materially. The domain owns those decisions and supplies evidence that enterprise constraints remain satisfied. Local accountability cannot be used to externalise risk.

Polycentric governance shows how multiple centres of authority can operate under shared rules.[1] Work on commons also highlights rules, monitoring and graduated institutional responses rather than one universal form.[2] Federation applies this logic to typed organisational decisions and shared technical dependencies.

Specific knowledge supports placing decisions near those who hold it.[3] Formal and real authority can still diverge when information or execution sits elsewhere.[4] Each zone therefore names owners, evidence and operating access, not just a policy label.

Transnational organisation has long faced simultaneous integration and local responsiveness.[5] AI federation sharpens the problem because models, vendors, data and telemetry can create invisible shared exposure while outcomes remain highly local.

Boundary clauseWrite a federation contract for every recurring decision

The contract begins with the decision object and consequence. It names the exact thing whose authority is split, such as source admission to a shared retrieval service or permission to change an evaluation taxonomy. Broad subjects such as “data governance” hide several decisions with different owners and migration conditions.

The invariant states the enterprise property that cannot vary. The local option set states what domains may choose. Prohibited variation closes the gap between principle and control. Policy theatre says “human oversight”; a contract states who can intervene, which evidence must be visible, which actions are available and which event proves the control operated.

Two accountable roles sit on opposite banks. The enterprise role owns the invariant, aggregate evidence and any shared dependency. The domain role owns local configuration and outcome. Input and challenge roles can be added without creating shared accountability. Each owner needs information, authority and execution access.

The evidence bridge defines schema, provenance, cadence, minimisation, destination and permitted use. It also carries exceptions. A central view does not need every customer record to see common vendor exposure or failed conformance. Local evidence retains enough provenance for independent review and remediation.

Service dependency and response time make the boundary operable. A domain cannot own a high-frequency decision if every local change waits for a central API decision. The shared provider publishes service, version, cost, change and recovery rights. Escalation joins the relevant owners when the contract or service cannot meet consequence.

Versioning prevents silent change. The contract states compatibility, notice, deprecation, consumer consent where required and concurrent-version rules. Conformance tests travel with the version. A shared service cannot revise evidence semantics and leave domains appearing compliant against different meanings.

Review and portability clauses allow decision migration. A common-mode incident can recentralise a previously local property. Improved evidence and stable interfaces can delegate another. A domain can exit a shared implementation while retaining invariants if data, state and evidence remain portable.

Modular design relies on interfaces that permit local change without uncontrolled system effects.[6] Organisation design research similarly links modularity, flexibility and knowledge management.[7] The federation contract combines technical interface and institutional authority.

Decision migrationPlace authority with consequence, frequency, knowledge and propagation

Centralisation is the strongest rival. It is appropriate when an error propagates across domains, a legal obligation cannot vary, interoperability is essential, a shared asset creates common-mode exposure or scarce independent expertise cannot be duplicated. The enterprise invariant can include the decision itself when distributed choice would be unsafe.

Domain placement is appropriate when knowledge is highly specific, decisions are frequent and reversible, consequences remain local and enterprise interfaces can be tested. Central ownership in this field creates translation, wait and diluted outcome accountability. Enterprise evidence still confirms that local freedom remains inside the contract.

Some decisions should split by component. The enterprise fixes provider identity, access semantics, incident vocabulary and evidence minimum. The domain selects sources, thresholds and workflow actions. Another split uses consequence: standard low-impact changes proceed locally, while elevated releases invoke joined authority.

The central-bottleneck negative control sends a reversible prompt adjustment and a high-consequence model release to one forum. The queue cannot serve local frequency or give sufficient attention to enterprise consequence. A split route uses automated conformance for the former and an evidence-rich elevated path for the latter.

Service time belongs in placement. Nominal delegation fails if the domain waits for central data access, testing or release permission. Real authority requires the ability to act inside the promised window. Shared teams publish capacity and an exception route rather than using delay as an informal veto.

The decision field is revisited after incident, legal change, vendor concentration, repeated exceptions, stable evidence or new local capability. Migration changes the owner and contract version explicitly. It does not happen through gradual habit while the formal policy remains stale.

Coherence failureDetect local forks before taxonomies and evidence cease to travel

A local fork can be rational at first. A domain copies an evaluation harness because the shared version cannot meet its release time or workflow. It changes failure labels, adds cases and removes an expensive test. Two other domains do the same. Each remains locally useful while portfolio comparison and shared maintenance collapse.

Fork detection uses asset identity, version, schema and conformance telemetry. A declared extension differs from a fork: it retains the common interface, publishes local semantics and passes the relevant tests. A fork breaks compatibility or hides change. The exception path can approve a bounded divergence while deciding whether the shared contract should evolve.

Taxonomy drift is especially dangerous because labels remain familiar while meanings change. “Hallucination”, “unsafe”, “override” or “incident” may carry different thresholds and populations. Aggregate reporting becomes false precision. Versioned definitions and mapping rules travel with evidence.

Duplicated operating cost includes separate fixes, vendor reviews, monitoring, support and incident learning. The portfolio records where common maintenance no longer reaches consumers. Shared assets must still meet consumer needs; otherwise aggressive fork control preserves a bad central service.

NIST’s AI RMF Core, Playbook and Generative AI Profile support continuing lifecycle roles, measurement and response.[8][9][10] The federation uses common evidence duties while leaving outcome interpretation with the domains that own it.

Portfolio visibilityAggregate exposure without pulling every local decision to the centre

Hidden aggregate exposure occurs when each domain remains inside its own limit while all depend on the same provider, model family, data source, identity service or recovery path. Domain controls can be correct and the enterprise position unsafe. A federation needs a narrow exposure telescope.

The evidence bridge carries provider and model identity, dependency, data category, action consequence, volume, incident, recovery and accountable domain. Local records preserve detailed cases and thresholds. The enterprise view reveals concentration and common cause without becoming a central customer-decision database.

Aggregate metrics need compatible denominators and versions. A domain-safe label is not comparable unless the decision population and exposure unit are defined. The enterprise constraint may therefore set the schema and response threshold while domains own underlying data and remediation choices.

Operational-resilience principles emphasise dependencies, tolerance, incident management and learning.[14] Regulatory responsibilities across the AI value chain can also make clear allocation and post-market response important for systems within scope.[13] ISO/IEC 42001 provides a management-system context for continuing roles and improvement.[15]

The recentralisation case begins after a common-mode incident. A previously local provider-selection decision becomes an enterprise invariant until concentration, alternative routes and shared recovery are controlled. The migration record states the temporary authority, evidence, affected domains, service time and condition for delegation to resume.

Recentralisation is not punishment for local failure. It is a response to changed propagation. It can be narrow and time-limited. If the enterprise can later enforce provider constraints and exposure evidence through contracts, selection can return to domains inside the new envelope.

Operate federation from paired receipts

A federation review should begin with paired receipts rather than a list of councils. For each decision, the enterprise receipt shows invariant conformance, shared service performance, exceptions and aggregate exposure. The domain receipt shows local outcome, operating fit, intervention, adoption and capture. A missing half remains visible; one strong record cannot stand in for the other.

Evidence must travel at the speed of the decision. A monthly roll-up cannot support an incident response that needs minutes, while continuous customer-level replication may be unnecessary for portfolio review. The contract names event and batch cadences, delay tolerance, freshness and the action that stale evidence prevents. Consumers can distinguish absence from a genuine zero.

Provenance includes the producing system, contract version, domain, population, transformation and accountable owner. Aggregate analysis retains a route back to local evidence without granting unrestricted central access. This design permits independent challenge and correction while respecting data minimisation, confidentiality and jurisdictional duties.

Exceptions are first-class federation events. They state the invariant affected, local reason, population, compensating control, exposure, owner, decision, expiry and reintegration or migration route. The portfolio aggregates mechanisms, not just counts. Several exceptions caused by one service limitation can justify a shared change; one severe exception can justify containment.

Exception approval is proportional. A reversible local test under existing identity and evidence contracts may proceed through a rapid route. A change that removes provenance or expands a shared provider dependency requires enterprise authority. Service time for both is published so the exception path does not become another hidden bottleneck.

Contract changes use consumer evidence. The shared owner proposes a version and explains behaviour, migration, cost, recovery and deprecation. Domains test representative workflows and can challenge incompatibility. The enterprise decides invariant changes; domains decide local adoption inside the support window. Forced immediate migration is reserved for a documented unsafe state.

Conformance tests cover institutional properties as well as API shape. They verify identity, authority, provenance, required events, prohibited actions, version mapping, state export and exception expiry. A technically valid response can still violate the federation contract if it obscures who acted or prevents the domain from exercising its outcome authority.

Shared services carry consumer rights. Domains need service levels, cost visibility, change notice, recovery information, portability and an appeal or escalation route. Without these rights, the contract is central command disguised as federation. With no shared obligations, the service becomes a loose library that cannot protect enterprise coherence.

Domain accountability also has duties. A domain cannot cite sovereignty while omitting evidence, retaining an expired fork or exceeding an enterprise exposure limit. It must operate local controls, respond to incidents, fund adaptations and accept consequence. The enterprise owner can constrain contract breach without taking over the domain’s customer or economic decision.

Measure the boundary itself. Queue time, contract-test failure, exception age, version lag, mapping errors, bypass, fork incidence, consumer appeal and migration duration reveal whether federation works. Local outcome and shared exposure provide the consequence. The number of shared tools or governance meetings is not a boundary-quality metric.

Decision migration has handover conditions. Recentralisation transfers evidence, permission and service capacity to the enterprise role while preserving domain continuity responsibilities. Delegation transfers execution, support and outcome duty to the domain while maintaining the invariant evidence bridge. A split creates two objects and an interface rather than leaving one ambiguous object with two owners.

Migration also has an expiry. Temporary central authority names the safe state, repair objective, affected population and evidence needed for return. Temporary delegation names the experiment, limits and aggregate watch. Indefinite temporary placement is a warning that the contract or permanent operating model has not been decided.

Audit production state against contract state. Live service and domain versions should match authorised records, active exceptions and supported mappings. An unmatched fork, expired version or unreported dependency is an incident even before harm appears. Reconciliation makes federation observable instead of relying on self-description.

Funding follows the partition. Enterprise budgets support invariant stewardship, shared interfaces and aggregate evidence whose benefit spans domains. Platform charges expose persistent service consumption. Domains fund local workflow, adaptation and outcome ownership. Temporary recentralisation states who funds emergency capacity. Cost visibility prevents the centre from calling local variation inefficient while hiding shared fixed cost.

Workforce capability is also distributed. Enterprise stewards need contract, exposure and cross-domain incident expertise. Platform teams need consumer and reliability skills. Domain teams need local product, data and control competence. Independent reviewers need sufficient access without taking ownership. Capability gaps can justify a temporary shared intervention, but the recipient and transfer condition remain explicit.

Jurisdictional or entity boundaries may constrain evidence movement. The contract can exchange derived exposure, conformance and incident events while keeping protected records local. It names lawful purpose, access, retention and challenge. If even the minimum evidence cannot cross, the enterprise either changes the service topology, narrows the decision or accepts that federation cannot provide coherent control.

Finally, federation requires a dispute mechanism. The enterprise owner can challenge externalised exposure; the domain can challenge a shared change that damages local outcomes. A designated authority decides the boundary property, temporary state and review trigger without assuming the underlying business consequence. Recurrent disputes become design evidence for a clearer invariant, better service or different placement.

Reviewing the portfolio by contract version exposes institutional debt. Some domains may remain on expired mappings, some shared services may lack an exit route and some enterprise metrics may no longer correspond to local populations. This debt compounds silently across otherwise compliant domains. The review assigns repair, migration or retirement with dates and owners. It does not declare federation successful merely because every domain sends a representative to a central meeting.

Worked successA retrieval service fixes shared truth while domains retain workflow choice

A regulated enterprise provides a shared retrieval service to several product domains. Earlier implementations used different identity tokens, source provenance and incident labels. One domain’s source change could not be traced into another system’s exposure view. The federation contract fixes identity, provenance, minimum logging, incident semantics and aggregate dependency reporting.

The enterprise platform owner is accountable for service, version, reliability, evidence export and common recovery. The domain product owner is accountable for which sources are suitable, how retrieved material enters the workflow, decision thresholds, customer consequence, local monitoring and benefit capture. Neither can satisfy the complete decision alone.

The allowed option set includes approved source classes, retrieval settings and domain evaluation extensions. Prohibited variation includes removing provenance, bypassing identity, changing incident categories without a mapping or sending unsupported data classes. Automated tests confirm schema, permissions, lineage and incident emission before release.

Domains supply representative cases and consequence interpretation. A shared evaluation core tests retrieval quality, evidence presence and prohibited behaviours. Local extensions test workflow and customer outcomes. Results roll up through common identifiers and versions, allowing portfolio comparison without forcing one domain threshold.

The shared service publishes a compatibility window, notice, deprecation, rollback and portability route. Domains can challenge a version that breaks local performance and can remain temporarily on an earlier supported version under an exception. The exception records exposure and expiry so consumer protection does not become silent permanent divergence.

Incident evidence uses the common vocabulary and links affected source, service version, domain, action consequence and recovery. The enterprise can see correlated failure and contain the shared service. Domains decide how affected customer work continues inside the safe state. Both decisions produce receipts.

Conformance is consumed by production permission, not stored as a report. A failed identity or provenance test blocks the route. A local outcome failure can block that domain’s release while the shared service remains available elsewhere. Aggregate exposure can constrain all domains without centralising their thresholds.

OECD work on government AI describes central coordination alongside uneven operating conditions and gaps between guidance and enforcement.[11] OECD analysis of the global governance landscape also examines fragmentation and interoperability.[12] The worked contract turns coherence into interface and evidence duties rather than another principle.

The success receipts are paired. The enterprise holds conformance, service, incident and aggregate-exposure receipts. Domains hold outcome, adoption, exception and capture receipts. Version reconciliation proves which contract applied to each production event. Federation quality is the simultaneous survival of both receipt sets.

Interactive instrumentFederation Boundary Designer

The designer returns an authority route and draft contract clause. It does not calculate a maturity score. The route can centralise an invariant, federate through a versioned boundary, preserve domain sovereignty, split by consequence or recentralise after changed common exposure.

ConclusionPreserve local fitness and enterprise coherence at the same time

Federation is a designed authority boundary. Enterprise invariants protect properties that cannot safely diverge. Versioned contracts permit controlled configuration and evidence exchange. Domain sovereignty keeps workflow, meaning, consequence and benefit with the accountable owners who understand them.

The boundary is executable because each decision has two owners, an option set, prohibited variation, an evidence bridge, a service dependency, conformance, exception, version and migration rule. A council or shared tool cannot substitute for those clauses.

Coherence is visible in common identity, comparable evidence, mapped exceptions and aggregate exposure. Local fitness is visible in outcomes, adoption, safe thresholds and benefit capture. Neither set of receipts cancels the other. Federation succeeds only when both remain credible.

Decision placement can move. Common-mode incident or law can justify narrow recentralisation. Stable interfaces and stronger domain capability can support delegation. The migration record changes authority explicitly rather than allowing real practice to drift away from formal policy.

The alternative failures are familiar: a central queue with little context, or local freedom with invisible shared risk. The federation corridor avoids both by making variation, evidence and migration part of the architecture. That is how many domains can remain different without the enterprise becoming incoherent.

Evidence spineReferences

1. 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.
2. Ostrom, E. (1999), ‘Coping with Tragedies of the Commons’, Annual Review of Political Science, 2, 493–535. doi:10.1146/annurev.polisci.2.1.493.
3. Jensen, M. C. and Meckling, W. H. (1995), ‘Specific and General Knowledge, and Organizational Structure’, Journal of Applied Corporate Finance, 8(2), 4–18. doi:10.1111/j.1745-6622.1995.tb00283.x.
4. Aghion, P. and Tirole, J. (1997), ‘Formal and Real Authority in Organizations’, Journal of Political Economy, 105(1), 1–29. doi:10.1086/262063.
5. Bartlett, C. A. and Ghoshal, S. (1989), Managing Across Borders: The Transnational Solution, Harvard Business School Press. HBR Store.
6. Baldwin, C. Y. and Clark, K. B. (2000), Design Rules, Volume 1: The Power of Modularity, MIT Press. MIT Press.
7. Sanchez, R. and Mahoney, J. T. (1996), ‘Modularity, Flexibility, and Knowledge Management in Product and Organization Design’, Strategic Management Journal, 17, 63–76. doi:10.1002/smj.4250171107.
8. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
9. National Institute of Standards and Technology (2023), ‘AI RMF Playbook’. NIST AIRC Playbook.
10. 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.
11. OECD (2026), ‘Adopting and governing AI in government’, Digital Government Outlook. OECD.
12. OECD (2024), Emerging Global AI Governance Landscape. .
13. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 16, 17, 25, 26, 72 and 73. EUR-Lex.
14. Basel Committee on Banking Supervision (2021), Principles for Operational Resilience. Bank for International Settlements.
15. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.