The platform dashboard reported another reused component. The lending domain reported three weeks in the integration queue. A second domain had already cloned retrieval and evaluation to meet its deadline. Both statistics were true, and together they described a boundary that did not work.

The platform called itself a product, but domains received a catalogue, an API and a ticket queue. Domains said they owned use cases, but they could not see change evidence, test the dependency or export evaluation records. The slogans concealed missing product-to-product terms.

An AI platform creates leverage only when a domain can consume a stable operating capability without surrendering the context and authority needed to own its outcome. The domain supplies decision population, workflow, data meaning, human authority, adoption and benefit capture. The platform supplies reusable capability with observable service, evidence, change and exit properties.

Two symmetric failures define the design problem. A platform that absorbs domain workflow becomes a central delivery team and bottleneck. Domains that fork identity, retrieval, evaluation and observability create inconsistent evidence, duplicated operations and invisible common exposure.

The strong rival is vertical integration. One domain team should own the full stack when context is highly specific, reuse remains unproved, common-mode exposure is limited and platform coordination costs exceed credible benefit. An element moves to the platform after its contract, consumer set, operating evidence and economics stabilise, not because centralisation is fashionable.

This article’s AI platform-domain boundary contract treats platform and domain as two product ownership systems. It connects them through seven planes without creating joint ownership of the outcome. Every dependency becomes measurable, testable and escapable.

Original synthesisWrite the boundary across seven planes

The consumer plane prevents the platform from owning a generic use case. It names the domain decision, population and workflow outcome. The domain product owner controls adoption, human configuration and capture. The platform knows which promises its service supports without inheriting the business consequence.

The capability plane describes what is stable and what may vary. Versioned interfaces, supported configuration and prohibited assumptions make consumption predictable. A domain that steps outside the envelope owns a fork rather than a supported configuration, and that difference becomes visible before failure.

The evidence plane lets a domain validate the dependency in context. It covers provenance, representative evaluation, conformance and control records with enough portability to investigate incidents or switch implementation. Platform evidence cannot prove domain outcome, but missing platform evidence can make domain approval impossible.

The service plane links platform capacity and reliability to a domain decision window. Availability alone is insufficient when freshness, queue time or degraded behaviour makes the workflow unusable. Support has a response clock and an escalation route rather than a generic ticket promise.

The authority plane separates platform change and stop rights from domain workflow authority. The platform can stop an unsafe shared service. The domain can stop its use, alter its threshold or invoke fallback. Residual-risk acceptance stays with the role that owns that risk object.

Change and incident terms prevent a provider update from invalidating domain approval silently. Every material change states compatibility, test duties, rollout, rollback and affected consumers. Incident command can shift with severity, but the transition rule is defined before an outage.

Economics and exit make the dependency contestable. A domain can see allocation and marginal cost, export data and evidence, test alternatives and understand retirement duties. Chargeback volume is not proof of efficient reuse; the receipt connects service consumption to avoided duplication and supported outcomes.

Modularity separates design rules so components can change without uncontrolled system effects.[1] Organisational modularity similarly connects flexibility and knowledge allocation.[2] The seven planes turn those principles into a live producer-consumer contract.

Element placementClassify stable core, configurable service, domain edge and assurance

Every capability element receives one of four classifications. A platform invariant protects a property that must remain common, such as identity, provenance semantics or incident identifiers. A configurable platform service offers a supported envelope. A domain-owned component carries context-specific logic or workflow. An independently assured control preserves a conclusion whose credibility depends on separation.

Classification follows stability and specificity. A common interface with several consumers and predictable service evidence is a platform candidate. A changing decision policy whose meaning depends on local customers, law or workflow remains in the domain. Reuse aspiration is not evidence of stability.

The stable-core/context-edge split is often more useful than moving an entire capability. Retrieval identity, access, provenance, telemetry and evaluation harness can be shared. Document policy, source ranking, decision threshold, human intervention and benefit capture can remain domain-owned. The interface states which configuration can vary and which conformance tests must pass.

Architectural innovation research shows that unchanged components can be recombined in ways that alter system knowledge.[3] A platform update can therefore break a domain even when its API contract remains syntactically stable. Behavioural, data and workflow compatibility belong in the boundary.

Communication structures also shape the systems organisations produce.[4] A central integration queue is not incidental; it reflects an architecture in which only the platform team can complete the product. The contract moves configuration and conformance to domains where possible while keeping stable shared rules automated.

Information-processing demand grows with uncertainty and interdependence.[5] Where coordination consumes more effort than reuse saves, vertical integration may be the better temporary classification. The product records that decision and the evidence that could later justify platform movement.

Specific knowledge should influence decision placement.[6] The domain retains contextual choices, but platform owners can still constrain unsupported use and protect common exposure. A boundary succeeds when each side can act without transferring knowledge that is expensive or unsafe to centralise.

Choose an interaction mode, not a permanent relationship label

Team Topologies distinguishes platform, collaboration and facilitation interactions and emphasises reducing cognitive load for stream-aligned teams.[7] Those modes can coexist at one boundary over time. A domain may collaborate while a new interface is discovered, consume the stable service after conformance exists, and receive short facilitation when adopting a new capability. Calling every contact a partnership hides whether the platform is actually consumable.

Collaboration is deliberately temporary and has an exit condition. The teams identify the uncertain interface, the people required to resolve it and the evidence that will end joint discovery. If collaboration becomes the ordinary release path, the platform has absorbed domain delivery or the service contract is incomplete. Persistent meeting load appears as a product defect in the continuation receipt.

Self-service is also an evidence claim. A catalogue entry is not self-service when access approval, configuration, conformance, capacity and support still require private negotiation. The domain should be able to discover supported behaviour, provision a bounded environment, run its representative pack, observe service state and request help through a stated route. Automation is useful because it enforces the contract, not because it removes all human contact.

A platform team should measure time to safe first consumption, successful changes without producer intervention, conformance pass rate, support response, incident recurrence, evidence portability and domain outcome contribution. Adoption count alone can rise while every consumer accumulates manual coordination and switching risk. Measures stay segmented by service class and consumer context so a high-volume easy domain does not hide a consequential weak one.

The domain has reciprocal duties. It declares realistic demand, maintains representative tests, stays within the configuration envelope, sends outcome and incident evidence, funds exceptional requirements and retires unsupported versions. Product treatment is not a licence to shift any inconvenient work to the platform. It is a balanced exchange of explicit promises between owners.

End-to-end serviceConnect platform indicators to the domain decision promise

A green platform can support a failed workflow. An API may meet availability and latency objectives while stale context, incomplete provenance or an overloaded review queue produces unusable decisions. Platform service indicators are necessary operating evidence, not the final user outcome.

The promise chain starts with the domain user objective and works backwards. It identifies the decision window, required freshness, acceptable degradation, evidence completeness, fallback and recovery. Platform indicators then measure the contribution that the producer can control. Domain indicators cover integration, workflow, human use and outcome.

Google SRE guidance connects service objectives to user-relevant behaviour.[8] Product-focused reliability goes further by modelling user objectives across several services rather than optimising one component.[9] The contract uses this chain to decide whether a green platform actually supported the domain promise.

The platform publishes capacity and queue behaviour by supported service class. A domain declares demand, criticality and decision window. If demand exceeds the contract, the parties choose capacity investment, admission control or a domain fallback instead of allowing silent latency to become a local incident.

Support response is a product property. Without a service-time promise, a domain may rationally clone retrieval or evaluation to protect its outcome. Fork evidence appears in the continuation receipt and triggers a choice: repair platform service, formally accept the domain component or retire the unsupported duplicate.

Chargeback follows a useful allocation unit, such as evaluated document, retrieval request or reserved capacity, but cost is interpreted with outcome and reuse. Volume incentives can reward waste. Marginal cost and avoided duplicate operation are more informative than total consumption alone.

Use queue, fork and exit evidence as boundary telemetry

Queue time measures more than delivery speed. Break it into access, interface clarification, configuration, conformance, capacity and support. Long access delay signals an entitlement problem; repeated clarification signals an ambiguous interface; conformance delay may expose poor test assets; capacity delay suggests the allocation and demand contract is weak. Each cause belongs to a different owner and repair.

A fork is not automatically insubordination. It may be the fastest rational response to an unavailable service, unsuitable recovery promise, missing feature or unacceptable coordination burden. The domain records why it forked, which shared properties it duplicated, its operating and control cost, and the condition for rejoining or formal separation. The platform treats this evidence as demand research rather than concealing it from adoption statistics.

Bypass is more serious when it avoids a control, evidence interface or approved configuration. The immediate response contains exposure. The follow-up distinguishes deliberate evasion from an unusable contract. A control that forces routine bypass may still be necessary, but its implementation has failed as a product. Repair can include a safer supported path, automated conformance or a decision that the domain must not use the capability.

Dependency concentration is tested through failure and exit exercises. The domain should know what happens when the platform is unavailable for an hour, a day or a release cycle; when a version is withdrawn; when evidence export is delayed; and when the price or service class changes. An exit plan that has never exported configuration, provenance and evaluation assets is a statement of hope.

Hostage economics appears when the nominal shared price is low but switching requires rebuilding evidence, controls and operational knowledge that the producer alone holds. The contract reports both current allocation and avoidable switching cost. Excessive switching cost triggers portability work before more consumers are added, even when the platform’s unit cost looks attractive.

The continuation review reads all four signals together. Rising queues with falling forks may mean domains have no viable alternative, not that coherence improved. Falling queues with rising bypass may mean controls became invisible. A healthy boundary shows shorter safe consumption, fewer unsupported duplicates, fewer bypasses, understood concentration and a periodically exercised exit route.

Change controlContain the shockwave before a platform update reaches a domain decision

A version can remain technically compatible and still be behaviourally breaking. A new embedding model may alter neighbourhoods. A prompt template may change abstention. A retrieval policy may shift source mix. A safety filter may move false-positive rates for one population. The platform cannot infer all domain consequences, while each domain cannot reconstruct the platform change.

The contract therefore divides the proof. The platform supplies a change description, lineage, shared regression evidence, interoperability result, affected service classes, notice period and tested rollback. Each consuming domain runs a representative pack drawn from its own population, workflow and decision thresholds. Release proceeds only when both proofs are present for the declared change class.

Representative means more than a convenient test set. It includes high-volume cases, consequential minorities, recent drift, known hard cases, fallback behaviour and evidence capture. The domain owns the claim that this pack remains relevant. The platform owns repeatability of the harness and preservation of comparable results.

The NIST AI Risk Management Framework organises work around govern, map, measure and manage functions.[10] Its Playbook supplies voluntary actions across those functions.[11] The boundary turns that cycle into release evidence: map affected consumers, measure shared and local regression, manage rollout and rollback, and govern the exception.

Machine-learning systems accumulate hidden technical debt through entanglement, data dependencies, feedback loops and configuration complexity.[12] The regression gate treats those dependencies as change paths. A seemingly local model alteration is presumed capable of travelling across evidence, workflow and human decisions until representative tests show otherwise.

Breaking changes require a migration window and dual-running path where practicable. A forced migration without comparable evidence transfers schedule risk to domains. Conversely, a domain cannot demand indefinite support for an old version without funding its isolation and retirement. The economics plane makes both burdens visible.

Emergency change uses a shorter path, not an evidence-free path. The platform records the threat or defect, affected versions, temporary control and restoration target. Domains receive a machine-readable event, test the fallback and later attach outcome evidence. Post-emergency reconciliation closes the exception or creates a funded remediation item.

Operational authorityHand incident command to the owner of the active failure object

An incident can begin in one plane and become another kind of event. A shared retrieval outage is initially a platform service incident. When a lending workflow starts making decisions with stale evidence, it becomes a domain outcome incident as well. One commander cannot own both risk objects merely because the same dependency appears in each.

The handshake begins with severity and scope. The platform commander owns shared diagnosis, containment, service restoration and cross-consumer communication. Domain commanders own workflow stop, customer treatment, human fallback, decision remediation and local reporting. A coordinating lead keeps time, dependency state and communications aligned without accepting either owner’s residual risk.

Stop rights are deliberately overlapping. The platform can withdraw a shared capability whose continued operation threatens several consumers. A domain can stop its integration when local evidence, law or workflow demands it. Neither side can require the other to accept an unowned consequence. Restart needs the relevant service and domain acceptance conditions, not simply a green component monitor.

Fallback is tested during ordinary operation. A manual route that takes four hours cannot protect a ten-minute decision. A cached result may preserve availability while violating freshness or provenance. The contract states fallback capacity, admissible evidence, human authority and the point at which degraded service becomes a stop.

Basel operational-resilience principles call for mapping the interconnections and dependencies needed for critical operations, managing third-party dependencies and preparing incident response and recovery.[13] For a shared AI capability, that operational path crosses organisational boundaries. The incident record therefore preserves version, input and output lineage, control state, affected decisions, operator actions and recovery proof in forms both teams can use.

After restoration, the platform produces a common cause and consumer-impact envelope. Each domain reconciles affected cases and reports decision consequences. The two records link through the incident identifier. Shared learning can improve common controls without disclosing unnecessary domain data, while local remediation stays with the outcome owner.

A recurring incident triggers reclassification. If one domain repeatedly needs a distinct recovery promise or unique control, that edge may belong in the domain. If several domains encounter the same failure, the formerly local workaround may be a candidate for the platform invariant. The contract evolves from observed dependency behaviour.

Worked applicationDraw the boundary for an AI-assisted lending document service

Consider a lending domain that uses AI to identify, retrieve and summarise documents for an underwriting decision. The platform team proposes a common document intelligence service. The domain must decide whether consumption reduces duplicated work without weakening policy, evidence or customer responsibility.

The stable platform core owns workload identity, access enforcement, source and output provenance, telemetry, evaluation harness, version lineage, capacity class and recovery mechanism. These properties are reusable across document-intensive domains and create common exposure if implemented inconsistently.

The configurable platform service includes supported connectors, retrieval parameters, model choice within an approved set, retention settings and evidence export. Each option has an allowed range and conformance test. A lending configuration is not automatically suitable for insurance or collections merely because the service accepts it.

The lending domain owns document eligibility policy, jurisdictional requirements, ranking preferences, confidence thresholds, underwriter workflow, human decision rights, customer communication, fallback and benefit capture. Those choices require product, legal and operational knowledge that the platform should not pretend to own.

Independent assurance validates controls where separation matters: access, model validation, consequential population performance and regulatory evidence. The platform supplies reusable test machinery and records. Assurance chooses its scope and conclusion rather than becoming another platform consumer.

The evidence interface joins the two proofs. For every recommendation, the domain can retrieve source identifiers, timestamps, transformation lineage, model and prompt version, policy configuration, confidence, human action and later correction. Aggregate evaluation can be compared by consequential segment without giving the platform authority over the lending decision.

A service target of 99.9 per cent availability is translated into the underwriting window. The domain requires current documents within fifteen minutes, complete provenance and a tested manual route for the most consequential cases. The platform measures retrieval freshness, latency and recovery. The domain measures decision cycle, rework, exceptions and supported quality.

Change control requires a platform regression pack plus a lending population pack before a retrieval or summarisation update. A model update that improves average answer quality but increases missed income evidence fails the lending gate. The platform can still release it to other compatible consumers through versioned routing.

Economics uses evaluated document and reserved peak capacity as allocation units. The continuation receipt compares marginal platform cost, avoided local operations, integration effort and outcome contribution. Switching remains credible because configurations, evaluation assets, provenance records and incident history can be exported in documented formats.

The first release may split stable core from context edge. Only after several domains use the service within the conformance envelope, service targets hold and exit is tested should the team call it a governed reusable platform product. The classification is an evidence conclusion, not a permanent label.

Decision instrumentDesign the boundary from current dependency evidence

The AI Boundary Contract Designer is a classification aid, not an organisational chart generator. Enter one capability element and one named consumer. Use observed queue, fork, bypass and dependency behaviour rather than aspirations. The result selects a route and identifies the contract clause most likely to be missing.

Use the route in a review involving platform product, domain product, engineering, operations, risk and finance. Resolve the missing clause, run the conformance and exit tests, then record a dated decision. Revisit it when consumers, context, exposure, service behaviour or marginal economics change.

ConclusionMake the dependency testable, governable and escapable

A platform-domain boundary is not a box diagram. It is a product-to-product contract across consumer, capability, evidence, service, authority, change, incident, economics and exit. Its quality is visible in queue time, fork pressure, representative regression, end-to-end outcome evidence, incident handshakes and credible switching.

European Union AI regulation places obligations on actors across an AI system’s value chain and addresses cooperation and documentation.[14] ISO/IEC 42001 frames an AI management system with governance and continual improvement.[15] Neither removes the need to state which product owner supplies which evidence, exercises which right and carries which outcome.

Choose a governed reusable product when stability, broad reuse, common exposure, interoperability and economics support it. Choose a configurable service when the core can be shared but domain configuration remains consequential. Keep the capability in the domain when context and workflow dominate. Split stable core from context edge when both forces are real. Repair or leave a dependency when it cannot be tested, governed or exited.

The practical test is simple. Can a named domain consume the capability, understand its limits, prove it in context, observe its service, stop it, survive its change, command its own incident and leave it without losing essential evidence? If not, the interface is unfinished, however impressive the platform catalogue appears.

Source trailReferences

1. Baldwin, C. Y. and Clark, K. B. (2000), Design Rules, Volume 1: The Power of Modularity, MIT Press. Publisher record.
2. Sanchez, R. and Mahoney, J. T. (1996), ‘Modularity, flexibility, and knowledge management in product and organization design’, Strategic Management Journal, 17(S2), 63–76. DOI.
3. Henderson, R. M. and Clark, K. B. (1990), ‘Architectural innovation’, Administrative Science Quarterly, 35(1), 9–30. DOI.
4. Conway, M. E. (1968), ‘How do committees invent?’, Datamation, 14(4), 28–31. Author archive.
5. Galbraith, J. R. (1974), ‘Organization design: an information processing view’, Interfaces, 4(3), 28–36. DOI.
6. 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.
7. Skelton, M. and Pais, M. (2019), Team Topologies, IT Revolution. Book record.
8. Beyer, B. et al. (eds.) (2016), ‘Service level objectives’, Site Reliability Engineering, Google. Online chapter.
9. Crous, C., Roth, P. and Hurd, V. (n.d.), ‘Product-Focused Reliability for SRE’, Google Site Reliability Engineering. Official resource.
10. NIST (2023), AI Risk Management Framework Core. Official resource.
11. NIST (2023), AI RMF Playbook. Official resource.
12. Sculley, D. et al. (2015), ‘Hidden technical debt in machine learning systems’, Advances in Neural Information Processing Systems 28. Google Research record.
13. Basel Committee on Banking Supervision (2021), Principles for operational resilience, Bank for International Settlements. Official publication.
14. European Union (2024), Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. Official text.
15. ISO/IEC (2023), ISO/IEC 42001:2023, Information technology: Artificial intelligence: Management system. Standard record.