The strong rivalBest-of-breed autonomy protects innovation

Central platforms can lag provider changes, impose lowest-common-denominator interfaces, slow experiments and become a powerful bottleneck. A specialised team may need configuration, data locality or runtime control that the shared route cannot expose. Forced uniformity can drive shadow systems rather than reduce them.

Allow low-consequence exploration and genuinely specialised work to use direct tools under a thin baseline of identity, data, spending and evidence controls. Make the exception time-bounded, name the owner, restrict data and action, meter use and define the path back, replacement or exit.

Platformise repeated burdens only when the shared solution is demonstrably better. Several document-grounded assistants may need the same identity, entitlement, source anchoring, evaluation, deployment and tracing while retaining their own corpora, domain tests and decisions. That recurring seam is a promising paved route.

Competition disciplines the platform. Compare delivery time, quality, incidents, cost and user effort with credible direct or domain alternatives. Compliance by decree cannot compensate for a route that misses necessary capability or service levels.

Original constructThe eight-plane Platform Contract Stack

Every route crosses every relevant plane. An excellent SDK with no evidence or exit is incomplete; a strong control plane with no usable journey is not self-service.

Internal product boundaryThe Platform Service Contract

Each paved route names its users and recurring job, supported outcome and exclusions, input, output, tool and context interfaces, inherited controls, domain responsibilities, service levels for quality, latency, availability, cost and evidence, tenancy, security, privacy, retention, evaluation, release, rollback, owner, support, incident path, metering, outcome measures, portability, deprecation and exit.

The contract makes self-service testable. A product team should be able to discover the route, provision an isolated environment, connect authorised context, run required evaluations, promote a version, observe cost and outcome, and obtain incident evidence without bespoke platform engineering. Where approval is necessary, the policy, evidence and lead-time promise are explicit.

Service levels should describe the decision route, not only infrastructure. Gateway uptime means little if evaluation assets are stale or policy receipts cannot be generated. Quality, cost and latency boundaries may vary by route; the platform publishes what it supports and refuses.

A platform adoption receipt records selected route and versions, inherited controls, declared exceptions, domain-owned decisions, tests, deployment, usage, cost, outcome, incidents and renewal or exit date. It is evidence of one product’s actual adoption rather than a registration count.

Standardise without taking over the businessMake responsibility seams explicit

The platform can enforce that a credit application has an entitlement receipt and passed an evaluation gate. It cannot decide the bank’s credit threshold. It can make a human-review control available; the product owner decides where the domain requires it under applicable policy.

Control inheritance reduces repeated work only when evidence follows the release. If the platform updates a common policy gate, opted-in products receive the version, compatibility result and testable receipt. Local exceptions and pinned versions remain visible with expiry rather than silently drifting.

Paved route and exceptionOpinionated does not mean compulsory uniformity

A paved route supplies defaults, automation and support for a recurring job. It exposes bounded extension points for domain sources, evaluation scenarios, prompt or workflow policy, tools and outcome measures. Extension contracts protect upgrade and evidence paths.

When the route cannot expose a necessary provider capability, first test whether the abstraction can be extended without breaking other users. If the need is stable and domain-specific, a bounded domain capability may sit on shared control interfaces. If it is experimental or temporary, grant a direct-tool exception.

Every exception states user, task, data, provider, spend, consequence, controls, evidence, owner, expiry and exit. It cannot become a permanent shadow platform through automatic renewal. The return path may be platform adoption, a supported domain service or retirement.

Direct APIs still pass the thin baseline where policy requires it: principal identity, permitted data, budget, logging and prohibited actions. The platform learns from exception demand without hiding limitations or forcing premature standardisation.

Self-service is an observed journeyExpose tickets, approvals and hand-offs

Map discovery, access, environment, data connection, evaluation, release, observability, incident readiness, first user and first production outcome. Measure active and waiting time at each step. A portal button that opens a service ticket is discoverability, not provisioning.

Some approvals are legitimate. Turn them into declared policy with evidence requirements, service level and status. Remove manual steps that merely translate between teams or assemble recurring control artefacts. The aim is predictable autonomy inside the contract, not zero human judgement.

Follow one product cohort from discovery to stable operation. Registration, API calls and models selected are weak adoption measures. Better evidence includes journeys completed without bespoke integration, inherited controls verified, production use, domain outcome, incidents and renewal.

Shadow platforms are diagnostic evidence. If a business unit rebuilds routing and observability because the central service misses latency, geography or feature needs, compare both routes. Repair, extend, domainise or concede the exception rather than enforcing use by decree.

Internal product evidenceUnit economics, control inheritance and retirement

Meter platform capacity, product usage, support, evaluation, incident work and shared fixed cost. Attribute incremental integration and specialist controls to adopters; keep reusable fixed capacity in the accountable portfolio. Unit economics can vary by route, consequence and service level.

Idle capacity and support can make a route uneconomic even when adoption rises. Resize, change the funding model, simplify the contract or retire the route. Avoided reintegration is observed by comparing repeated identity, release, evaluation and assurance work with credible alternatives, not asserted from “build once”.

Catalogue entries need an owner, production path, service contract, demand and exit. Remove a tool with no active consumer after checking dependencies, export and historical evidence. Deprecation names replacement, compatibility, notice, migration support and final date. Long-lived exceptions receive the same scrutiny.

Platform value combines successful production journeys, inherited control evidence, lower recurring integration, service outcomes and option value. Tool count, registered users and aggregate spend are descriptive, not proof of value. Review distributions so one popular route does not hide a costly specialist failure.

Worked platform journeyThree document assistants reveal the real shared product

Legal, operations and customer service each plan a document-grounded assistant. Their corpora, policies, user consequences and acceptance tests differ. Yet all three need service identities, tenant-isolated context, source entitlements, model routing, claim-level citations, evaluation registration, controlled release, incident evidence, cost allocation and retirement. The platform opportunity is that recurring production journey. It is not a mandate to place every document, prompt and domain decision in one central system.

Start with user and job, not architecture inventory

The service contract names product engineers and domain reviewers as users. Their recurring job is to connect an authorised corpus, configure a bounded assistant, prove its scenarios and operate it with receipts. The route supports cited decision support and explicitly excludes autonomous external action. Those choices determine the planes required and prevent a flexible orchestration tool from being presented as a complete outcome.

User research maps the current journey across teams: request credentials, negotiate data access, choose a model, implement retrieval, assemble tests, obtain security review, deploy, monitor and investigate incidents. Repeated waiting, glue code and evidence assembly become candidate platform work. Unique interpretation of contract language, service policy or customer remedies remains domain work.

Publish one source-to-answer interface contract

The route accepts versioned source descriptors, entitlement policy references, domain evaluation assets and a response schema. It returns bounded context, citations, model response, cost and provenance receipt. Stable interfaces let the platform change internal indexing or routing while compatibility tests protect consumers. Extension points allow domain metadata, retrieval filters and output validation without forking the whole stack.

The contract states unsupported layouts, languages, latency classes, providers and action types. A product with a scanned handwriting corpus does not discover after launch that the parser only supports digital text. Unsupported requirements enter an extension, domain-capability or exception decision. Honest exclusions make the paved route more reliable than a broad promise fulfilled through tickets.

Inherit identity and data controls without centralising meaning

The platform creates distinct human, service and agent principals, propagates delegation, enforces tenant and purpose before candidate generation, and generates access receipts. The domain supplies source ownership, classification, subject relationships, permitted decisions and retention rules. The platform can verify that a policy reference exists and was enforced; it cannot decide which legal clause or customer record should be available.

Each product declares its corpus and affected parties. Central isolation tests try cross-tenant names, shared terms and cache reuse. Domain tests cover contract hierarchy, service exceptions and customer-specific meaning. This seam lets the shared route prove consistent access mechanics while owners remain accountable for the policy values and source semantics that drive them.

Make evaluation a versioned platform service

The platform provides scenario schemas, dataset storage, policy gates, execution, comparison, approval and rollback evidence. It includes common security, privacy, injection, latency and receipt tests. Domain teams provide representative tasks, consequential cohorts, acceptance thresholds, forbidden behaviour and reviewers. A model or retrieval release cannot bypass the registered suite.

When a common policy gate changes, the platform evaluates opted-in products against the new version and issues evidence. Affected teams see compatibility, failures and deadline. Products may remain temporarily pinned under an approved exception where consequence permits it. Control inheritance is real only when a platform release produces testable, traceable change across consumers, not an email asking each team to repeat manual checks.

Provide a production execution contract

The route defines queues, state, retries, idempotency, tool boundaries and rollback even when the first assistant only answers questions. Retrieval, model and downstream services have explicit timeout and fallback semantics. A request correlation identifier links source selection, evaluation version, model, output and cost. The product team does not invent these mechanics for each provider.

If a future domain tool changes external state, it joins through a separate action contract with authorisation, deterministic validation, transaction receipt and human review where required. The platform supplies the execution pattern. The domain owns whether the action is permissible for the business decision. This prevents the existence of a tool API from becoming implicit permission.

Expose provider capability rather than hiding every difference

A neutral model contract covers common messages, structured outputs, usage, errors and policy metadata. Routing can move ordinary requests among supported providers. When one product needs a safety setting, regional endpoint or deterministic feature not represented, the platform evaluates an extension. It does not silently drop the field to maintain a clean interface.

Extensions have capability discovery, validation and fallback semantics. Consumers can declare a required feature so routing never selects an incompatible model. If the feature is specialised and stable, a domain route can sit behind shared identity, evaluation, evidence and cost interfaces. If experimental, a bounded direct exception may be cheaper. Provider neutrality is a managed exit option, not denial of real differences.

Turn self-service claims into journey tests

A new team should be able to provision a development tenant, connect an approved sample source, run baseline evaluations, inspect receipts and estimate cost without a bespoke meeting. Production approval may remain governed, but requirements, status, evidence and response time are visible. Documentation and examples exercise the same interfaces as automation so they do not drift into screenshots of an obsolete portal.

Synthetic journey tests run regularly from discovery to a deployable non-production service. Product telemetry measures completion, waiting, failure and help requests. If the “connect data” step opens a queue for a platform engineer to hand-write an entitlement rule, the journey records that work. The platform either automates the recurring translation, improves the contract or stops calling the step self-service.

Handle a specialised research exception

A research team needs a provider’s novel multimodal feature before the gateway exposes it. The work is low consequence, uses an approved non-sensitive dataset and has a bounded budget. The exception records principal, provider, data, endpoint, permitted operations, evaluation, logs, owner, expiry and export. Direct use still passes the thin identity and spending baseline.

The team reviews the feature at expiry. Repeated demand and stable evidence may justify a gateway extension. A durable domain requirement may become a supported domain capability. If the experiment ends, credentials, data copies and resources are removed and receipts archived. Automatic renewal would convert an evidence-gathering exception into an unmanaged shadow route.

Protect the domain boundary in consequential decisions

For the legal assistant, the platform ensures source entitlement, current version, citation integrity and an approved review step. Legal owners decide which authority controls, how clauses reconcile and what advice may be issued. For customer service, the platform checks identity and logs evidence; the product owner decides the remedy and affected-party safeguards. Infrastructure control does not grant substantive expertise.

Responsibility matrices describe deliverables and escalation without creating an ownership blob. The platform owns service defects and common-control incidents. Domain products own bad policy values, inadequate domain scenarios and outcome operations. Security and risk independently challenge both. Providers own contracted service and evidence. Incident review can then find the accountable seam rather than blaming “the platform” for every failure.

Use shadow platforms as service evidence

Operations builds its own router because the central path misses a latency requirement and does not expose a local provider. Instead of banning it, architecture compares measured routes: user journey, latency distribution, failure recovery, control evidence, support cost and exit. The local service may reveal a legitimate boundary error or an avoidable reinvention.

If the requirement recurs within one domain, build a bounded domain capability that inherits common principal, policy, evaluation registration, tracing and lifecycle interfaces. If the central route can meet the SLO through a documented extension, migrate. If the shadow route lacks basic controls, contain the risk while repairing the unmet demand. Evidence, not organisational preference, determines the boundary.

Build unit economics around supported journeys

The unit may be an evaluated product release, an authorised decision journey or a thousand bounded requests, depending on the service. Include shared capacity, model and storage use, evaluation, support, incidents, evidence retention and idle commitment. Segment by route and service level. An aggregate cost per token cannot reveal that a low-volume specialist route consumes most support.

Benefits include repeated integration avoided, faster safe production, common-control inheritance, lower incident investigation and actual product outcomes. Count only observed adoption and credible alternatives. Platform fixed cost can be owned centrally, while incremental integration and consumption follow products. The funding model should not distort decisions by making direct usage appear free or the first adopter carry the entire shared build.

Issue an adoption receipt per product

At production promotion, the receipt names the paved route and platform versions, inherited controls, local source and policy declarations, domain tests, approved exceptions, deployment, service level, metering, owner, incident path and exit date. It links to the product’s outcome measures and records which responsibilities were not inherited.

Renewal examines real use, service evidence, incidents, cost and outcomes. A product that stopped using the route can exit cleanly. A product with persistent exceptions may need a domain capability or direct contract. The receipt prevents platform membership from becoming a permanent label detached from the current execution and support arrangement.

Manage versioning and deprecation as product capabilities

Interfaces declare compatibility rules and supported periods. A breaking policy, model, context or receipt change gets a new version, migration guide, test environment and rollback. Consumers can test before promotion. Emergency security changes may shorten notice but still produce impact evidence and a controlled fallback. Undeclared consumers are detected through metering and dependency records.

A catalogue item without an owner or production consumer enters retirement. The team checks active credentials, artefacts, stored data, workflow dependencies and export needs. It removes discovery entries, blocks new use, helps remaining consumers migrate and ends support on the published date. Historical receipts remain available under their retention purpose. Deprecation without final removal merely converts catalogue clutter into technical debt.

Measure outcome without claiming all product value

The platform tracks completed production journeys, time and waiting to first outcome, inherited controls, exception rate, service quality, incident burden, cost and retirement. Products report decision and customer outcomes. The platform may contribute to those outcomes but does not claim the entire business value. Attribution compares plausible delivery alternatives and exposes interaction with domain work.

Tool count, sign-ups and API volume are supporting telemetry. A route can have high usage because bypass is prohibited while providing poor service. User feedback, shadow adoption and support work test whether the contract earns preference. Outcome evidence can support investment, optimisation, domainisation or retirement without a single platform score.

Govern the platform portfolio at its seams

Review each paved route as an internal product: named users, recurring job, service contract, owner, roadmap, economics, incident evidence, extension demand and exit. Review shared planes for capacity, compatibility and control inheritance. Exceptions form a demand signal but also an expiring risk inventory. Domain capabilities must remain interoperable enough to avoid recreating every cross-enterprise control.

The final test is whether a team can reach a supported production outcome with less reintegration while retaining the capabilities and decision rights it legitimately needs. If the answer is only that tools are easier to browse, the organisation still has a catalogue. If the route is reliable, measurable and reversible, it has begun to behave like a platform.

Keep build, buy and integration inside one contract

A platform plane may be purchased, built or assembled from open components. The sourcing label does not change the service obligation. The platform owner must still define the supported interface, evidence, service level, incident path, cost allocation, portability and deprecation. A vendor portal cannot substitute for the enterprise route if products must add every control and lifecycle step around it.

Supplier change belongs in release management. New model, gateway or runtime versions run the registered common and domain suites before promotion. Contract changes trigger cost and exit review. Export tests confirm that prompts, evaluations, configuration, receipts and necessary state can move through approved forms. Portability is proven by rehearsed alternatives, not a provider-neutral wrapper alone.

Staff the platform as an operating service

Product management owns users, jobs and prioritisation. Engineering owns interfaces and reliability. Security, risk, finance and domain representatives define cross-cutting contracts and challenge evidence. Support owns triage and user communication. Clear on-call and incident boundaries prevent a model-quality issue, source-policy defect and platform outage from entering one undifferentiated queue.

Capacity planning includes provider quotas, evaluation demand, shared context infrastructure, peak model concurrency, evidence storage and human support. Route-level forecasts and admission controls keep one product from degrading others. When demand exceeds a service contract, the platform can allocate, resize or expose a lower service class rather than silently missing every consumer’s SLO.

Operational reviews should examine the whole journey, not just the component that raised an alert. A slow response may originate in entitlement checks, retrieval, provider queuing, a domain tool or evidence capture. The receipt identifies the owners and versions involved, while correlated traces make the hand-offs inspectable. This avoids a platform team absorbing every incident merely because its gateway is visible. It also stops product teams treating inherited controls as somebody else’s problem when their source selection or decision policy caused the failure.

Service improvement follows the same boundary. Shared teams repair repeatable failure modes and publish contract changes; domain teams correct local policy, evaluation and operating practice. When neither side can meet the agreed journey economically, the review considers a different paved route, a bounded domain capability or retirement. A platform earns trust by making that decision legible and reversible, including when the right answer is to expose a provider capability directly behind the thin control baseline.

Interactive instrumentAI Platform Boundary Architect

Set recurrence, shared burdens, domain specificity, self-service, contracts, economics, abstraction and lifecycle conditions. The Architect returns one of exactly five routes with the service boundary, inherited controls, local responsibilities and exit condition. It does not produce a platform-readiness or maturity score.

Exactly five outcomesChoose a service boundary, not a platform score

Use the existing paved platform route

Use when a repeated job fits an end-to-end contract, inherited controls, service levels and domain extension points.

Add a thin shared control-plane integration

Use when teams need direct capabilities but identity, data, spend, evaluation or evidence should not be reinvented.

Build a bounded domain platform capability

Use when a stable specialised job needs shared domain services while connecting to common control interfaces.

Grant a time-bounded direct-tool exception

Use for legitimate experimental or specialised capability gaps with data, spend, evidence, expiry and exit controls.

Do not platformise or retire the unsupported catalogue item

Use when demand, owner, production path, unit economics or lifecycle evidence is absent.

Negative controlsTen boundary tests

Evidence boundaryPlatform practice informs the contract, not the value claim

Production-ML research demonstrates glue code, dependencies, configuration debt, testing, integrated pipelines and lifecycle roles. Platform-engineering sources emphasise the internal platform as a sociotechnical product shaped by user-centred implementation. These lessons support the route and contract, not a universal centralisation mandate.

Kubernetes offers a control-plane and reconciliation analogy, not a blueprint for organisational authority. OpenAPI, OpenTelemetry, OpenLineage and SLSA support stable interfaces and interoperable evidence. CNCF landscape material describes ecosystem vocabulary without proving business value.

FinOps supports collaborative technology-value management, allocation and unit economics. ISO and NIST sources support lifecycle governance, measurement, identity and risk controls within scope. EU AI Act duties depend on system classification, actor, provision and applicable timing; a platform does not make every product compliant automatically.

The Platform Contract Stack, Platform Service Contract, adoption receipt and Boundary Architect are this article’s synthesis. They distinguish catalogue, portal, marketplace, shared service, paved route, control plane and platform product while keeping domain decisions local.