Draw the AI Platform Boundaries

An internal AI platform serves product engineers, applied researchers, evaluators, security and policy teams, reliability engineers, and finance operators. Map what each consumer is trying to accomplish and where repeated work or risk blocks them. A capability belongs on the platform when a shared contract measurably reduces cognitive load, duplicated risk, or lead time while preserving domain ownership. A central team's desire for uniformity is not sufficient evidence.

1. 01Name the consumer and promiseState who uses the capability, for which journey, under which support and compatibility contract.
2. 02Define the interface and authoritySpecify schema, identity, version, errors, quotas, idempotency, change approver, rollout, rollback, and deprecation.
3. 03Bind tenant and data contextCarry authenticated scope through authorization, storage, cache, telemetry, providers, policy, deletion, and billing.
4. 04Assign operating ownershipName accountable, runtime, on-call, fallback, incident, and consumer owners with escalation and handoff rules.
5. 05Publish the escape hatchPermit a time-bounded alternative when requirements do not fit, while preserving mandatory security, audit, and policy controls.

1def audit_platform_boundaries(contract, evidence):
2    contract = validate_record(contract, PlatformBoundaryContract)
3    evidence = validate_record(evidence, PlatformBoundaryEvidence)
4    if evidence.scope != contract.scope or evidence.contract_content_id != contract.content_id:
5        raise ValueError("evidence belongs to another platform-boundary contract")
6    # Compare every declared capability's plane, owner, change authority,
7    # tenant context, privilege review, telemetry, fail mode, and freshness.

example=illustrative_only
decision=PASS_BOUNDARY_AUDIT
capabilities=evaluation,identity,incident-response,model-access,observability,prompt-policy
violations=
claim=LOCAL_BOUNDARY_AUDIT_NOT_DEPLOYMENT_OR_SECURITY_CERTIFICATION

The invented charter declares six capabilities and binds each to a control or data plane, exact interface, accountable owner, runtime owner, on-call owner, change authority, fallback owner, and fail-closed requirement where applicable. Evidence adds tenant-context, least-privilege, telemetry, freshness, and digest claims. The audit reports missing and undeclared capabilities separately and never treats a complete owner field as proof that the corresponding control exists in production.

A platform earns adoption when the default path is documented, observable, supported, fast to start, safe to change, and easier than rebuilding its controls. Mandatory adoption can hide dissatisfaction and encourage shadow systems. Provide reference implementations, local test doubles, clear errors, compatibility windows, migration tooling, cost visibility, and office hours. Let consumers request an exception with a reason, owner, compensating controls, evidence, expiry, and path back—or use the exception as evidence that the platform boundary should change.

• Use consumer councils and production evidence to prioritize contract changes; central intuition is not product discovery.
• Version interfaces, policies, model capabilities, telemetry schemas, and ownership maps; coordinate compatibility rather than relying on synchronized releases.
• Run production-readiness reviews for new platform capabilities and for high-impact consumers, with explicit gaps and acceptance owners.
• Keep product developers in incident and on-call feedback loops so domain failures do not become platform mysteries.
• Split capabilities when risk class, latency path, tenant isolation, geography, scale, or consumer workflow needs a different operating model.
• Retire unused features and interfaces; platform scope should be earned continuously, not accumulated indefinitely.