What Is the Operations Boundary Between Provider and Customer

Quick Answer: The operations boundary is the shared-responsibility line that assigns each day-two AI-infrastructure function to the provider or the customer. If a cell is empty, the customer still owns that work when a job fails overnight.

Enterprises often treat this line as a vendor comparison. A GPU catalog does not say who patches the host, who pages on ECC errors, or who rolls back a serving image. The useful artifact is a scope table both sides can operate.

The sections below define typical provider scope, typical customer scope, and the gaps that create dual writes or silent ownership. Treat the rest as a definition of the line, not a provider shortlist.

What does the operations boundary include and exclude?

The boundary includes functions that keep capacity usable after the cluster exists: facility health, host and fabric care, control-plane baselines, identity, model artifacts, job logic, quota, and incident command. It excludes labels such as fully managed. Those words do not assign a pager.

Tenancy is the environment the line sits on, not a row you can skip. Private AI infrastructure gives the boundary a fixed place to live. The line still has to be written after that place exists. An SLA credit is not the boundary. Credits refund a fee. They do not say who reruns the job or who rolls back a digest.

Which functions sit on the provider side versus the customer side?

Use one table for the stack. Provider and customer are roles, not company names. A row can move when you self-operate hosts or when you hand day-two care to an operator. The definition does not change: every function has one operating owner, or you discover the gap at 2 a.m.

Read the table as a definition of default ownership, not as a scorecard for shopping operators. If you self-operate, most host rows move to the customer. If you buy managed AI infrastructure, those host rows typically move to the provider. Model quality does not move with them.

What still belongs to the customer when hosts are managed?

Managed hosts do not absorb application work. You still own identity design, image signing, model deploy, eval gates, and the product SLO. Complementary controls stay with you: who may assume a role, where keys live, and which repo may change a serving chart.

Platform Decision Matrix: Enterprise AI Cluster Orchestration

Quota inside the cluster is usually customer scope even when the provider owns the rack. The provider can add a node. It cannot let Team A evict Team B unless you handed over that policy. An AI infrastructure platform is the control surface for that policy. It does not patch firmware or take the quality page. Labeling, prompt policy, and any environment you still administer stay customer-owned unless a row says otherwise.

Where does the operations boundary fail in practice?

The line fails when two groups write the same object, or when nobody writes it. Dual writes show up as two charts or two patch calendars. Empty cells show up as a healthy node and a failed job with no commander.

1. Control-plane overlap: provider and customer both change the same add-on. Pick one Git owner per layer before the first upgrade.
2. False “up”: the node answers a ping while ECC or a stuck driver makes every job unusable. That is still an infra row if the contract said GPU health is provider scope.
3. Silent data movement: traces and checkpoints leave the named region because logging was “just observability.” Observability is in scope. The export path is a customer control unless you assigned it.
4. Quota folklore: hallway priority instead of a written cap. The provider sees a full rack. You see one team starving another.
5. Incident split without a join rule: infra Sev1 and model Sev1 page different people who never share a bridge. The boundary needs a join right, not two mute rotas.

How should teams write the boundary so an incident has one owner?

Write one row per function, one operating owner, one evidence artifact, and one escalate path. The owner performs the work; the payer is not enough. If both sides can change a layer, split the layer until only one side commits.

1. Copy the function list above and mark provider, customer, or joint. Joint still needs a single incident commander.
2. Attach evidence: patch calendar, admin log, quota policy, or eval gate. A row without evidence is an empty cell.
3. Name the page destination for infra symptoms versus quality symptoms, plus who may join the other bridge.
4. Record the freeze: who stops customer deploys during a host change, and who stops host changes during a launch.
5. Re-read the table after the first real incident and move any row that did not match what happened.

Do not turn the writing exercise into a bake-off. The output is a line both on-call rotations can run. A blank row is already an assignment to staff yourself.

FAQ

What is the operations boundary in one sentence?

It is the assignment of each day-two function to the provider or the customer so a failure has one operating owner. Hardware SKUs, SLA credits, and slide adjectives are not that assignment. If you cannot name who patches, who pages, and who rolls back a digest, you do not have a boundary yet. You have a purchase.

How is this different from a managed-provider comparison?

A comparison scores operators against each other on coverage and evidence. The operations boundary defines who runs which function after any operator is chosen, including you. You can complete the table with no vendors in the room. If the meeting is ranking desks, you left the definition task and started a buying task.

Who owns a job that fails while the node looks healthy?

Start on the customer side: code, data, digest, quota, and eval. Move to the provider side only when GPU health, fabric, storage, or the agreed control plane is the cause. A healthy ping does not close the infra row if cards are unusable. A failed loss curve does not open the infra row if the node completed the steps it was given.

Does writing the boundary replace an audit control?

No. The table is an operating map. Audit still wants access logs, deletion evidence, and complementary controls you actually run. A signed boundary helps an auditor see who should produce which artifact. It does not certify a framework and it is not legal advice. Empty rows remain your gap even when the map looks neat.

Who pays when a gap sits between the two sides?

The customer pays in outage time and rerun cost, even when a later credit appears. Credits follow the fee. They do not restore a missed batch or an inference hole. Cost drivers are coverage hours, who staffs Sev1, and how many rows you still run yourself. Fix the empty cell before you negotiate a credit percentage.

How does the OnePlus™ AI Orchestration Platform maximize GPU cluster efficiency?

The OnePlus™ AI Orchestration Platform by OneSource Cloud delivers topology-aware scheduling that aligns multi-GPU jobs with physical NVLink and PCIe socket boundaries, eliminating cross-socket latency penalties. It automates job queuing, fair-share project isolation, and automated idle container termination, ensuring high continuous GPU utilization while preventing developer notebook sprawl from locking expensive compute resources.

Summary

The operations boundary is a function-by-function assignment between provider and customer, not a GPU catalog and not a vendor ranking. Provider scope typically covers hosts, fabric, and agreed baselines. Customer scope covers identity, models, jobs, quota policy, and quality. Write every row and treat an empty cell as customer-owned.