Who accepts the workcell before a robot resumes?

Google Cloud’s robotics ecosystem article, dated October 30, 2026, describes a division between cloud planning and on-device control. The related ER2 public-preview announcement dates to October 27. Those dates are separate; an ecosystem account does not establish production acceptance.

This division raises a procurement question: after a task is interrupted, who must establish that the workcell is ready to continue? What follows is Open Market Notes’ proposed delivery and acceptance framework, not a report of incidents, defects or customer performance involving those products.

Extend delivery boundaries to resumption

Procurement discussions tend to concentrate on normal operation: whether a model understands the task, an arm executes the movement and a business system records completion. All three can pass separate tests while leaving a gap. After human intervention, a moved workpiece or a cancelled task, do the assumptions behind the original plan still hold?

The agreement needs specific conditions, rather than a general declaration that the system has recovered. Where is the workpiece? What state is the fixture in? Which steps have finished, and which observations justify the next ones? Restored software availability answers only part of that inquiry.

Consider a hypothetical packing station. After an arm puts down a component, a worker moves it to another tray during troubleshooting. The model supplier confirms service availability, the equipment supplier confirms healthy motion control, and the integrator confirms that the task remains queued. None of these statements yet establishes which tray should receive the next operation. Repeating the old instruction would confuse component health with continuity of the task.

This example makes no claim about a particular product. It suggests that acceptance should include an observable handoff: who updates task status, who checks the changed scene and who authorizes continuation under defined conditions. The executing system should distinguish a fresh confirmation from a judgment retained from before the interruption.

Separate investigation from authority to resume

Root-cause work may involve several suppliers. Differences between model output, sensor observations, controller feedback and business records may remain unexplained for some time. Requiring blame to be settled before any operational decision risks turning a workcell stoppage into a contract dispute.

A more useful arrangement would define two paths. Investigation retains relevant versions, times and evidence. Resumption has an appointed owner who decides against agreed site-acceptance conditions. This is a governance proposal, not a legal allocation of liability or a relaxation of machinery-safety requirements.

Listing a contact is insufficient. That owner’s authority, required inputs, acceptable evidence and escalation route should form part of delivery. Where nobody can verify a required condition, acceptance should allow the task to remain unresolved rather than treating missing information as a pass.

Test the whole handoff

Buyers could ask suppliers to design controlled interruption exercises together. The purpose is not to create danger, but to use test methods approved by qualified site personnel to examine how information and decisions move. In simulation or appropriately isolated test conditions, a changed workpiece location could test whether old task state is recognized as stale and whether a site confirmation actually becomes part of the new execution basis.

The record should cover the interval from detecting a mismatch, through ownership transfer, to satisfying resumption conditions. One component’s response time does not measure this interval. Necessary human work and waiting should also enter the delivery assessment, so that the economic case includes the support work needed to operate the system.

Laboratory samples, retail shelves and factory components require different conditions. A supplier may provide general capability, while the buyer must specify acceptable interruption, rework and takeover arrangements. Stating these constraints also helps distinguish business requirements from model defects later.

Preserve the jointly tested version combination

When separate teams update the model, controller or task system, a previously accepted handoff may no longer describe the running combination. We recommend retaining the versions, interface meanings and site assumptions covered by joint acceptance, then retesting affected handoffs after a relevant change. Separate supplier test reports alone may leave an integration question unanswered.

Coordination has a cost. A fixed, simple station may not justify an elaborate process; depth should reflect consequences and environmental variation. Procurement can compare the evidence and ownership of recovery alongside price without imposing one heavyweight regime everywhere.

Google’s articles supply technical context, not proof that one responsibility model works universally. Contracts and trials should establish whether the operator can observe a completed handoff, and whether someone has explicit responsibility when it remains incomplete. That evidence may be more useful to delivery decisions than another demonstration of normal operation.