Purpose and development
Start with recurring engineering work
AI platform engineering turns recurring engineering needs into supported shared capabilities. Its users are the people building and operating applications, including engineers working through agents. Start by identifying their tasks and constraints, then choose capabilities that help them complete that work. An inventory of infrastructure products is not yet a platform.
These applications contain models. Inference means applying a trained model to inputs, as explained in Machine Learning Fundamentals. Successfully executing that computation does not establish that its prediction or answer is useful. A platform can provide reliable execution and shared evaluation facilities while application owners determine whether the result meets their task requirements.
| Recurring work | Possible shared capability | Application responsibility |
|---|---|---|
| Obtain model access | Approved access paths and supported clients | Select a suitable capability for the task |
| Release an identified version | Artifact registration and deployment machinery | Define behavior and accept task quality |
| Investigate failed work | Correlated operation records and diagnostics | Explain business-logic failures and user impact |
Sharing replaces repeated implementation with a dependency on someone else's service. That exchange is worthwhile only if the service has an owner, usable interfaces, and support. Patrick Debois's platform-engineering account treats consuming teams as internal customers, with collaboration and assistance alongside APIs. Uber's Michelangelo shows how scope can grow from recurring needs. Development began in mid-2015 with model training and deployment, expanded into shared pipelines for preparing model inputs, and later emphasized developer productivity. A platform need not centralize every AI concern to be useful.
Choose the service boundary
A service boundary states what consumers can request and what the provider takes responsibility for. Specify supported users, interface behavior, owned state, operating limits, failure responses, and support. Not every reusable capability needs to become a remote service: shared code, project templates, and operated services solve different coordination problems.
| Delivery form | Upgrades and state | Enforcement and incidents |
|---|---|---|
| Shared library | Maintainer releases code; consumers adopt it and own application state. | Checks run inside the consuming application. Its operators must ensure correct integration. |
| Project template | Generator creates a starting project. Subsequent maintenance needs an explicit owner. | Generated controls can be edited or become stale; scaffolding success is not operating assurance. |
| Operated service | Service owner maintains its implementation and service-owned state. | Owner operates the promised enforcement boundary and handles service failures; consumers retain application duties. |
Backstage Software Templates illustrates the template boundary. It creates projects from parameterized skeletons and exposes execution tasks and failure logs. Those facilities make creation inspectable; they do not establish ongoing deployment health or maintenance of the generated application.
A runtime manages when work executes and how its lifetime is controlled. The platform may offer and operate that runtime, but also supplies access, release, support, and ownership arrangements around it. Choose execution machinery from task lifetime and recovery requirements. Similarly, customer-specific implementation is not automatically a shared capability: Forward Deployed Engineering explains how to validate common needs before productizing a solution.
Buying an underlying component can transfer infrastructure work without transferring the whole consumer-facing promise. Managed services may operate machines and software while the customer retains data classification and permissions. Define that division explicitly rather than treating either self-hosting or managed hosting as a complete operating model.
Turning points in shared platforms
AI platforms combine several continuing traditions. Platform as a service supplies an operated environment for deploying applications. Machine-learning operations, or MLOps, encompasses developing, releasing, and operating machine-learning systems, including their data and model dependencies. Managed model APIs move some execution work outside the consuming organization. These approaches address different parts of the same delivery problem.
These developments widened the work a platform could support. Their dates identify particular systems and accounts, not a founding date for platform engineering.
The resulting platform can support trained models, hosted models, or both. What changes is the allocation of work, not the need to connect a release decision to a running application. That connection requires an explicit distinction between managing a service and executing its workload.
Control and authority
Connect configuration to running state
The control plane creates and changes resources and configuration. The data plane, also called the execution plane here, performs the service's primary work: processing requests or running jobs. These names classify operations, not necessarily separate products. Updating a gateway's configuration is management work; forwarding a model request is execution work.
Desired state is the accepted specification of what should run. Observed state records what the system currently reports. Reconciliation repeatedly compares the two and requests changes to close the gap. A controller performs this loop. In Kubernetes, a system for coordinating containerized workloads, the Job controller creates or removes Pod objects describing containers to run. Other components schedule and run those containers. Requesting the change and executing the work are separate responsibilities, so another observation is needed to determine whether the requested change took effect.
A deployment change can therefore be accepted before dependencies resolve, workers initialize, or the new version becomes eligible for traffic. Readiness is that eligibility, established through configured checks. Expose the operation's progress and failure reason instead of making callers infer completion from an administrative success response. Long-running operation guidance separates failures that prevent acceptance from failures during execution.
If initialization stalls, the accepted specification can name the candidate while existing traffic still uses an older release. Report the requested release, the release actually in use, and when that observation was made. This lets a user distinguish an unapplied change from a failure in the running application. Ray Serve's monitoring interface, documented here in a development version, separates goal configuration from observed application and deployment status, including the state of individual serving instances.
Preserve tenant authority
A tenant is a customer or organizational scope whose data, authority, and resource allowances require separation. A tenant may contain several applications and many human users. A workload identity identifies running software; it is not automatically the identity or authority of the human on whose behalf that software acts.
Authentication establishes identity; authorization determines permitted operations on particular resources. Derive tenant context from verified credentials or session state, not a model-proposed tenant identifier. Carry that context into resource lookup, storage, and caches. A cached answer remains a protected result: finding a matching key does not make disclosure permissible. Privacy and Data Governance develops the underlying authority rules.
Check current authority for model invocation, artifacts, execution records, caches, and diagnostics—including support, maintenance, and recovery. Platform entry or an administrator title grants no blanket access.
Uber's delegated workload-identity account preserves both human and agent actors through downstream requests and supplies supported clients to propagate that context. The platform lesson is to make attributable, scoped access the usable default rather than ask every team to recreate it.
Keep three isolation goals separate. Confidentiality concerns who can access data. Resource isolation concerns whether one workload consumes another's capacity. Failure independence concerns shared dependencies that can interrupt both. Kubernetes namespaces, access policies, and quotas address different pieces; quotas do not cover every resource, including network traffic. Dedicated compute can reduce resource sharing while leaving tenants dependent on the same management or artifact service.
Model access and artifacts
Specify usable model access
A model supplies learned behavior. A provider operates or supplies access to it. An endpoint is the concrete interface through which requests reach a serving implementation. A model gateway mediates those requests through supported interfaces and access policies. It can centralize authentication and attribution without choosing models according to answer quality.
| Claim | What establishes it |
|---|---|
| Discoverable | A catalog identifies the capability and its supported use. |
| Permitted | The caller and intended processing satisfy applicable access policy. |
| Available | The actual service path can process the supported request. |
| Suitable | Application-specific evaluation supports the intended task. |
Publish a capability record that joins model reference, provider, endpoint, accepted inputs, output forms, interface limitations, input and output limits, access scope, resource allowances, lifecycle status, and support owner. This is a proposed platform contract, not a universal catalog schema. It gives consumers enough information to request access and test the relevant path. A common JSON envelope can still contain model-specific parameters and behavior; preserve the request contract and check the concrete service path.
Managed inference transfers serving and capacity work according to the service contract; self-operated serving leaves more of that work with the platform team. Neither choice transfers application authorization or appropriate data use. Supplier review must also cover data handling, incident notification, continuity, and changes to the service. Internally hosted weights still have suppliers, dependencies, and provenance risks.
Uber's shared gateway illustrates centralized identity, policy middleware, and project-level request attribution. Aperture's documentation exposes another useful boundary: usage metrics can remain available without writing request bodies to disk, but shared bridge clients attribute several people's activity to one identity. Centralization makes controls reusable; it does not automatically make attribution complete.
Identify the release and its dependencies
An artifact is an identified item used or produced by a system: packaged code, model files, configuration, or an evaluation result. An artifact registry records identities, metadata, locations, and lifecycle information. It need not contain the large files themselves. Kubeflow's Model Registry, for example, records model versions and artifact locations while the files remain in their original storage.
A storage address says where to look, not which bytes will be found. A content digest is a value computed from content that can be checked against a trusted expected value. Provenance records origins and production history; dependency links identify other artifacts involved. Neither proves that an artifact is safe. The Update Framework combines authenticated metadata, hashes, version checks, and expiry because authenticity, content integrity, and freshness are separate properties.
A release manifest joins the dependencies needed to identify a release. Extend the software release identity with model artifacts or hosted references, input-processing configuration, runtime requirements, and evaluation records. At registration, check the required metadata, provenance, ownership, permitted use, storage access, and format before accepting the item for further validation. Some model-loading paths execute code; acquisition and inspection belong inside the artifact security boundary.
Version names require interpretation. MLflow distinguishes numbered versions from mutable aliases: changing an alias changes what a later alias-based load resolves, not necessarily what an existing process has loaded. Hosted identity is narrower still. Anthropic's versioning documentation distinguishes pinned weights and model configuration from serving infrastructure that can change observable behavior. Record provider assertions accurately without presenting them as deterministic replay guarantees.
A release is more than a model name
ExampleRelease dependencies, registry metadata, stored bytes, and supplier-controlled references establish different kinds of identity.
Read the diagram as text
- Release manifest. Identifies the assembled release and dependency references.
- Packaged application. Exact code artifact and supported runtime requirements.
- Input-processing configuration. Identified preprocessing and request-construction configuration.
- Evaluation record. Tested release identities, conditions, and outcomes.
- Registered model version. Metadata, expected digest, artifact location, and lifecycle record.
- Model bytes in storage. Retrieved content checked against the trusted expected identity.
- Hosted model reference. Provider, endpoint, and model ID; pinning has supplier-specific limits.
- Release manifest → Packaged application: Release dependency.
- Release manifest → Input-processing configuration: Release dependency.
- Release manifest → Evaluation record: Assessment reference.
- Release manifest → Registered model version: Model reference: self-operated.
- Registered model version → Model bytes in storage: Storage reference and expected digest.
- Release manifest → Hosted model reference: Model reference: supplier-operated.
Dependencies also run downstream. A model's own tests can pass while an undeclared consumer depends on behavior the change removes—a central warning of the Hidden Technical Debt paper. Registration should therefore make releases discoverable to their consumers, while deployment records identify which versions those consumers actually use.
Promote and retire identified versions
Registration establishes a record, not permission for every use. Promotion makes an identified version eligible for a specified environment or purpose. The decision joins technical validation, application-owned quality acceptance, permitted-use conditions, and accountable approval. A model that loads within resource limits may still produce unsuitable predictions. Evals and Benchmarks explains the quality decision; the platform supplies the shared machinery that records and enforces it.
| Operation | Decision or action | Completion evidence |
|---|---|---|
| Register | Registry owner accepts identity and required metadata. | Retrievable record and resolvable references |
| Validate | Technical and application checks examine an identified version. | Results tied to that version and test conditions |
| Approve and promote | Accountable owners permit a specified use. | Scoped approval and eligibility in the target environment |
| Deprecate | Service owner announces a supported migration and retirement schedule. | Known consumers, notice, and migration tracking |
| Revoke | Authorized owner withdraws permission for a use. | Enforcement observed across affected consumers |
| Delete | Retention owner authorizes removal of specified records or copies. | Confirmed disposition at each named storage boundary |
Eligibility and deployment are independent dimensions. An approved artifact can be undeployed; a withdrawn artifact can still be loaded until enforcement reaches its consumers. SageMaker's approval workflow demonstrates the explicit connection: particular approval transitions trigger deployment pipelines when its documented project templates are used. Starting that pipeline is not proof that replacement finished.
Dependency lineage connects artifacts to the executions that used or produced them. ML Metadata records these relationships, enabling investigation beyond filenames. To retire a dependency, join such records with current deployments and unfinished work. Completeness depends on what integrations record. Provider retirement adds an external deadline: Anthropic documents that retired-model requests fail and recommends auditing remaining usage and testing replacements on application tasks.
Routine retirement allows migration planning; urgent withdrawal may require stopping use before a replacement exists. Retaining a recovery artifact does not authorize indefinite retention or future execution. Give retained copies a purpose, access restrictions, expiry or review condition, and disposal owner, following artifact lifetime policy. Removing a registry entry alone does not remove stored files or loaded copies.
Deployment and capacity
Control exposure and recovery
Deployment turns an eligible release into running service. Validate its dependencies and configuration, initialize it, and establish readiness before assigning traffic. A live process is not necessarily ready: it may still be loading model data. Readiness checks establish only their configured conditions, not application-answer quality.
A canary exposes a bounded portion of real use to a candidate while an existing version supplies a control. Compare version-specific results so fleet averages do not hide regressions. Define eligible traffic, observation duration, acceptable behavior, stop conditions, and the person or system authorized to promote. Small or unrepresentative samples can miss failures; there is no universal safe percentage.
Draining stops admission of new work while tracking work already accepted. Routing new requests elsewhere does not resolve requests already assigned to the deployment. Those requests may continue running; operators need to see whether they finish or require an explicit termination decision. Serving recovery distinguishes restored capacity from stream continuity; long-running version compatibility explains why unfinished work can require an older worker version.
Stopping admission leaves accepted work to resolve
Limited admission
Control request → assigned here
C1 → admitted here
After candidate admission stops
New permitted request → assigned here
C1 retained · ○ outcome pending
No new candidate admissionsThe same candidate and C1 persist across both moments. The open endpoint marks a nonterminal request; it has not moved, completed, or been canceled. Spacing does not measure elapsed time.
| Control | Target and authority | Effect and confirmation |
|---|---|---|
| Stop new admission | Named application, tenant, deployment, or service; authorized operator | Blocks new covered work; report pending and active work separately. |
| Disable agent or tool | Agent or tool scope; authorized policy operator | Takes effect at supported decision points, including child agents; does not reverse completed actions. |
| Cancel operation | Identified operation; authorized caller | Requests stopping under the runtime contract; inspect terminal status rather than assume acknowledgment means stopped. |
| Restore previous release | Affected deployment or traffic assignment; release authority | Changes future execution after compatibility and eligibility checks; verify the effective release. |
A control checked only at session creation leaves ongoing work outside later changes. Agents Need Feature Flags recommends checking kill switches at subsequent decisions and in spawned agents. Record who changed the control, its scope, when it changed, and where enforcement was observed. This makes the response inspectable without claiming interruption of an already executing tool.
Rollback restores an earlier software or configuration version, not an earlier world. Restoration requires compatibility with current state and dependencies, plus current permission. A withdrawn model may require forward repair; see rollback compatibility. Cancellation likewise does not undo committed remote effects. Preserve operation identities and investigate unknown outcomes separately. An already-delivered harmful utterance illustrates why some applications need stronger evidence before any live exposure.
Allocate usable capacity
Authorization permits work; it does not create resources. Admission control decides whether a workload may enter execution or a supported waiting state. The decision must account for the work's resource needs and the platform's commitments to other users. Request count alone can be misleading because requests differ in input size, output length, and downstream activity.
| Term | Meaning | Does not establish |
|---|---|---|
| Quota | An allowance for a named resource and scope | That hardware is idle or immediately available |
| Rate limit | A bound on work admitted over time | A bound on all work still executing |
| Concurrency limit | A bound on simultaneous work | Completion within a latency target |
| Reservation | An allocation held for work under a stated reservation contract | Physical placement or initialized workers |
| Ready capacity | Service resources able to execute the supported workload now | Unlimited throughput or suitable answers |
Kubernetes Kueue provides a concrete distinction for run-to-completion workloads: quota reservation and configured admission checks precede execution, while scheduling places the actual workers. Physical-capacity checks depend on the configured mechanisms. Its batch-oriented contract should not be mistaken for a universal inference scheduler.
Classify work by waiting tolerance and occupancy. Interactive requests need prompt progress. Batch prediction handles accumulated inputs without an immediate-response requirement. Long-running jobs occupy resources or retain obligations across many steps. A noisy neighbor degrades another workload by consuming shared resources. Separate pools, quotas, or bounded queues can protect a class of work, but reserved separation also leaves less capacity freely available to others. Declare rejection and queue-expiry behavior instead of allowing indefinite waiting.
Scaling introduces delay before capacity becomes usable. Modal's cold-start documentation distinguishes waiting for a container from initialization, including model loading. Moving initialization earlier moves the wait rather than eliminating the work. Keeping containers warm can reduce startup exposure while consuming resources. A serving group is the cooperating set of workers needed for one complete model instance; a partially assembled group may add no executable capacity. See cooperating serving groups and paying for the required service.
Reserve readiness or share occupancy
Four identical slots; one non-preemptive job per slot. B1–B4 arrive at 0 and each need 8 time units. I1 arrives at 2 and needs 2. All work is authorized with sufficient quota.
Reserved slots finish initialization before 0; batch cannot borrow them. Shared slots start cold and initialize on demand for a waiting job, holding that slot until the job starts or expires; they then stay warm. I1 must start before 7; batch must start before 20. At a tie, completion and readiness update, waiting work expires, then eligible work starts: interactive first, then arrival order and B1–B4 order.
| Outcome | Selected: 1 reserved | Fully shared: 0 reserved |
|---|---|---|
| I1 waiting | 0 units · starts at 2 | 5 units · expires at 7 |
| Batch completed by 24 | 4 / 4 | 4 / 4 |
| Idle slot-time, 0–24 | 53 | 52 |
| Initialization slot-time, 0–24 | 9 | 12 |
| Prior warming slot-time | 3 | 0 |
| Expired work | None | I1 |
Waiting: B1 (initializing), B2 (initializing), B3 (initializing), B4
Job starts and outcomes through 24
| Job | Start | Outcome at 24 |
|---|---|---|
| B1 | 3 | Completed at 11 |
| B2 | 3 | Completed at 11 |
| B3 | 3 | Completed at 11 |
| B4 | 11 | Completed at 19 |
| I1 | 2 | Completed at 4 |
One slot idle for one time unit is one unit of idle slot-time, not a currency estimate. Initialization occupies its slot even if the waiting job expires. Deadlines bound waiting only; started work can continue past 24.
Reliable shared operation
Promise outcomes at explicit boundaries
A service-level indicator, or SLI, defines a measurement of service behavior. A service-level objective, or SLO, sets its target over a stated period. The error budget is the permitted shortfall, coupled to a policy for decisions such as slowing releases. Observability develops these measurements. Here the task is to choose boundaries that reflect what platform users need, rather than merely what individual components report.
| Operation | Eligible population and successful boundary | Dependencies and owner |
|---|---|---|
| Provision service | Accepted supported provisioning requests that become usable within the declared interval | Configuration, artifacts, placement, initialization; platform service owner |
| Invoke model | Eligible calls completing the supported response contract within the latency target | Gateway, network, serving provider; model-access owner |
| Complete job | Accepted jobs producing the contracted result or explicit supported disposition by their deadline | Runtime, storage, downstream services; execution-service owner |
| Recover service | Declared failure scenarios restored to the agreed operating boundary within the recovery objective | Trusted restoration assets and usable capacity; recovery owner |
Keep unavailable observations visible and state exclusions before measuring. Server latency and client-observed completion can differ. Infrastructure availability, performance, answer quality, and end-user usefulness are separate outcomes: a successful model response can still be wrong, and healthy servers can sit behind a broken access path.
A failure domain groups components vulnerable to a common failure; its blast radius is the affected scope. Shared configuration, artifact storage, or provider accounts can couple otherwise separate applications. Inventory those dependencies and state which recovery actions need them. Static stability means continuing existing operation without management changes during a dependency failure. Pre-existing capacity and configuration can support continuity when provisioning is unavailable.
Outages can hide permission withdrawals. Declare authorization-freshness limits and stopping behavior; availability cannot justify indefinite stale permission. Recovery commitments should identify trusted restoration inputs, verification steps, acceptable loss of retained progress, and who confirms restored service.
Expose actionable diagnostics
Diagnostics are part of the service interface. A trace connects records from one logical execution; trace instrumentation supplies the mechanics. Platform consumers need to determine which configuration took effect, where work is waiting, which dependency responded, and who can resolve the problem. A dashboard of aggregate traffic does not answer those questions for one operation.
| Field group | Meaning |
|---|---|
| Tenant and operation identity | Authorized scope and stable handle for investigation; not a grant of access |
| Requested and effective release | What was accepted versus what the observed worker applied |
| Observation time and coverage | When status was observed and which components remain unobserved |
| Phase and waiting reason | Queueing, initialization, execution, or an identified blocked dependency |
| Applied limit and dependency outcome | The relevant policy decision, downstream response, or explicit unknown result |
| Support owner and restricted evidence | Where to escalate and how authorized support obtains additional detail |
Requested identity and returned identity should remain distinct. OpenTelemetry's developing generative-AI conventions provide separate requested-model and response-model attributes, along with prompt-version fields. They do not automatically identify application code, policies, retrieval indexes, or every workflow attempt; those require explicit instrumentation. A missing response-model field means identity is unavailable at that boundary, not that the requested model has been independently verified.
Likewise, a gateway can record a model's proposed tool call without proving the tool executed. The network-gateway demonstration shows inspection of traffic passing through that gateway; local actions and effect receipts require other observations. Distinguish platform failure, supplier failure, application-quality failure, and incomplete evidence before choosing an owner.
Use metadata-first diagnostic defaults. When sensitive inputs or outputs are necessary, define their purpose, readers, retention, and disposal separately. Support should receive an operation identity and scoped evidence, not unrestricted tenant access. Auditability is a reason to retain sufficient decision evidence, not permission to retain every payload.
Supported development
Make the supported path complete
A golden path, also called a paved road, is a supported way to complete recurring work with suitable defaults and integrated controls. It can span APIs, command-line tools, documentation, and human decisions; it does not require one portal. Its value comes from completing the task without making consumers assemble disconnected building blocks.
The workflow begins with discovery and access, continues through development, testing, registration, and deployment, and remains supported through inspection, stopping, and recovery. Automate repeatable handoffs, but preserve necessary approval decisions. Self-service removes dependence on a particular person's availability or unwritten knowledge; it does not grant every requested action.
Bloomberg's engineering-enablement account combines discovery with creation, deployment, runtime, and authentication support. Its directory helps teams find existing Model Context Protocol, or MCP, servers before building duplicates. MCP provides reusable capability exchange; the surrounding platform still owns the supported delivery and operating path.
Local checks establish behavior only under their tested conditions. Deployment changes identity, network access, secrets, persistent services, hardware, and concurrency. Exercise those integration boundaries rather than treating a generated project or passing local test as production readiness.
A supported extension path lets a team meet a need the default cannot serve while retaining mandatory authority boundaries. Record the extension interface, maintenance owner, support limits, and review requirements. Standardize operational obligations where possible, not every implementation choice. Amplifon's registry-and-blueprint design, still under development when presented, put authentication, cost tracking, and diagnostics into shared project templates. Teams could implement agent logic in different frameworks behind the templates' common interfaces. This separates freedom over implementation from responsibility for operating the service.
Measure usefulness and evolve the service
Access shows that someone can use a platform. Mandatory traffic shows policy compliance. Voluntary adoption suggests a choice; sustained use suggests the capability has entered recurring work. None alone establishes improved outcomes. Evaluate a bounded set of developer tasks against a credible prior workflow, combining instrumented use with structured feedback. The CNCF maturity model recommends both and warns that greater maturity consumes additional staff time and funding.
| Intended improvement | Measure against the prior workflow | Keep visible |
|---|---|---|
| Faster delivery | Elapsed time per comparable task to a working deployment | Task complexity, approval waits, and failure rate |
| Less support dependence | Waiting time and support effort per completed task | Hidden manual intervention and unresolved requests |
| Easier recovery | Operator effort and time to verified restoration | Incident severity and unresolved work |
| Less repeated integration | Work needed to adopt a shared capability in another application | Platform maintenance and exception-support effort |
Specify eligible tasks, observation periods, and team coverage before comparing results. Uninstrumented teams are unmeasured, not zero. A before-and-after improvement may reflect easier work, better staffing, or a provider change rather than the platform itself. Investigate support requests and exceptions: repetition can reveal a missing capability, a confusing interface, or an abstraction that excludes legitimate work.
Avoid rewarding activity independently of completed work. The Software Engineering + AI discussion reports anecdotes of engineers increasing token consumption to improve visible usage rankings. Tokens are the units models use to represent text; Tokenization explains why processing more of them measures usage, not accomplishment. More commits can similarly include repair work rather than useful functionality. Surveys can reveal satisfaction and friction, but self-perceived speed is not a substitute for measured delivery outcomes.
Evolution also changes obligations to existing consumers. Define stability levels, supported lifetimes, notice, migration assistance, and retirement procedures. Google's AIP-181 ties stable interfaces to support and deprecation commitments, distinguishing producer-initiated changes from consumer migration to a new version. It allows exceptional security or regulatory changes; it does not promise frozen model behavior. Use that distinction to communicate what remains stable and what users must retest.
Operating ownership
Assign and exercise responsibility
An operated capability needs people authorized and able to maintain it. Team Topologies distinguishes team responsibilities and interaction modes rather than prescribing one infrastructure hierarchy. Its service-discovery guidance describes close collaboration while needs and boundaries are uncertain, followed by service consumption through clearer interfaces. Those interfaces include response expectations, status information, support channels, and assistance. Facilitation helps teams learn to use the capability without transferring their application decisions.
| Decision | Decision authority | Implementation and confirmation |
|---|---|---|
| Technical release eligibility | Platform release owner | Platform operators validate dependencies and observe applied release and readiness. |
| Task-quality acceptance | Application owner | Application team supplies task-specific evaluation and accepts behavior. |
| Permitted use and withdrawal | Designated governance or resource owner | Access administrators enforce the decision and report affected consumers. |
| Capacity commitment | Service owner with spending authority | Infrastructure team or supplier provisions; operators verify usable capacity. |
| Service restoration | Incident lead and affected service owners | Platform and supplier operators repair their boundaries; owners confirm recovery. |
| User communication | Named incident or service communications owner | Support reports impact, restrictions, progress, and confirmed restoration. |
A runbook describes the conditions, actions, expected results, and escalation for an operational procedure. A production-readiness review establishes agreement that the service can meet its operating obligations. Neither is complete merely because a document exists. Practice realistic failures with actual tools, inspect what failed, and update the procedure. Google's incident-response guidance emphasizes prepared command, communications, and operations roles, exercises, and confirmation from affected service owners.
A managed supplier can own the underlying infrastructure while the platform team owns the service offered internally. Keep supplier escalation and change obligations alongside application and governance responsibilities. The consumer should not have to reconstruct the organization's outsourcing arrangements during an incident.
A bounded platform service contract brings the chapter's decisions together.
- Users and work — Name the consumers, recurring tasks, and application decisions the platform does not take over.
- Interface and state — Specify supported requests, owned records, release identity, and observable completion boundaries.
- Authority and limits — Declare tenant scope, protected access paths, resource allowances, readiness, and overload behavior.
- Change and recovery — Define promotion, exposure, draining, withdrawal, compatibility, retention, and unresolved-outcome handling.
- Operation and improvement — Provide diagnostics, support, accountable owners, exercised recovery, and measurements of completed useful work.
Open questions
Management-outage contracts still need testing: permitted operating duration, authority freshness, and stopping when those conditions fail.
A pinned hosted-model reference does not identify every serving behavior that influenced an answer. More useful reproducibility would combine provider change disclosure, observable serving identity, and application regression evidence without claiming access to hidden implementation state.
Dependency records become less useful when consumers appear through dynamic integrations or bypass the registration path. Progress would make missing coverage and stale relationships visible enough to support retirement decisions, rather than merely drawing a complete-looking catalog.
Shared capacity must accommodate unpredictable job duration without sacrificing interactive service or wasting reserved resources. Useful progress is workload-specific evidence of completed work, waiting, fairness, and operating expense under realistic bursts—not a universal utilization target.
Platform usefulness is hard to attribute when adoption coincides with changing models, staffing, and tasks. Stronger assessments would compare defined work across credible alternatives while including support effort, recovery, and unmeasured populations.
