Write down the evidence that allows the next workflow step to begin. A response acknowledging a command and a result confirming the intended handoff answer different questions. Both need a definition in the interface agreement.
Start with one requested operation. Describe its intended end condition in physical terms, then identify the information the platform can provide and the information owned by the instrument or scheduler team. Avoid a completion label that silently combines several parties' responsibilities.
Give each response a defined meaning
An interface review should state what has been checked when a request is accepted. It should also state what acceptance does not confirm. For example, the review may distinguish a valid request from the later readiness information needed to begin a transfer. The agreed behavior depends on the project architecture.
ROS 2 Actions provides a useful terminology example: it separates goal acceptance, execution feedback and a final result, and distinguishes active states from terminal outcomes. Its action model is background for the discussion, not a declaration that a LabCarry project implements ROS 2. ROS 2 Actions design
Build a completion evidence matrix
Use the following as review questions. The labels are illustrative and must be mapped to the actual protocol; they are not advertised API fields.
| Review point | Question to resolve | Evidence owner to name |
|---|---|---|
| Request identified | Which request does this response concern? | Client and platform interface owners |
| Request accepted | What validation and admission checks have passed? | Platform interface owner |
| Ready to proceed | Which permissions and physical conditions must hold? | Each relevant equipment/interface owner |
| Executing | What progress information is available and what does it omit? | Platform controller owner |
| Object placed | What establishes the required receiving condition? | Agreed sensing or verification owner |
| Tool released | What establishes that the required release condition is met? | Tool/platform owner |
| Transfer concluded | What result closes the requested operation? | Agreed result provider |
| Next workflow permitted | What additional instrument or workflow conditions remain? | Customer scheduler/instrument team |
For each row, name the signal or record, its source, validity conditions and response to missing information. Where the project has no direct observation for a physical condition, keep that limitation explicit and agree how the acceptance plan addresses it.
Review a transfer across the responsibility boundary
Consider this illustrative review case, not an implemented LabCarry interface. The platform has accepted a plate-placement request. Its later result reports that the defined placement motion and gripper-release action finished. The instrument separately reports whether the plate is seated in its receiving position. If that instrument report is missing, a platform result alone does not establish the instrument-side condition. Record who obtains the missing evidence and which decision remains with the customer scheduler. If the project has no observation of seating, state that limitation in the completion definition instead of treating a finished motion as proof of seating.
Tie the physical conditions to the station positioning review. Use the hardware interface guide to document which party exposes each result and who advances the workflow.
Test what a consumer could misunderstand
In the acceptance plan, include cases where a request is accepted but cannot complete, a required condition is unavailable, a result arrives late, or the instrument declines the next handoff. Define the expected reported state and the owner of the next decision before running the cases.
Record the actual result against the reviewed configuration in the hardware FAT package. Keep interface promises aligned with the platform hardware scope. The customer team remains responsible for workflow sequencing and the agreed instrument software integration, including how its scheduler uses the platform's results.
If a timeout or reconnect leaves the transfer outcome uncertain, use the recovery responsibility guide to assign the evidence check, prohibited next action and release authority before another movement is requested.