Use this checklist when reviewing an interface specification with the platform and scheduler teams. For each applicable item, point to the actual field or message definition and its revision. If the function is outside the agreed work package, record that decision.
Field names alone are insufficient for implementation. Both teams need the meaning, permitted values, producer, consumer and behavior when information is unavailable. The table lists review subjects; it does not prescribe a transport protocol or claim that particular functions are implemented.
Interface field review
| Subject | Definition to record | Contract reference / producer / consumer / evidence |
|---|---|---|
| Interface identity | Protocol/schema version and supported configuration | ______ |
| Request identity | Uniqueness scope, association with responses and retention | ______ |
| Requested operation | Supported operation and intended end condition | ______ |
| Parameters | Type, units, reference frame and allowed values | ______ |
| Preconditions | Required permissions and configuration/physical conditions | ______ |
| Admission response | Meaning of acceptance/rejection and rejection detail | ______ |
| Operation state | Defined values, permitted transitions and result association | ______ |
| Progress information | Meaning, update behavior and limits of interpretation | ______ |
| Completion result | End condition, success/failure meaning and evidence source | ______ |
| Freshness | How consumers identify unavailable or stale information, including update rules and the time basis where timestamps are used | ______ |
| Fault identity | Stable identifier, affected function and diagnostic meaning | ______ |
| Fault handling | Owner, permitted response and applicable procedure reference | ______ |
| Cancellation | Request behavior, possible refusal and resulting outcome | ______ |
| Waiting limits | Purpose, responsible timer and consequence when reached | ______ |
| Duplicate handling | Identity comparison, retention limits and specified response | ______ |
| Restart/reconnection | State preservation, initialization and reconciliation behavior | ______ |
| Trace record | Relevant request, configuration and evidence references | ______ |
| Access and change control | Authorized functions, compatibility review and change owner | ______ |
Rule 1: resolve meaning before choosing convenient names
Ask two teams to interpret an example response independently. If their conclusions differ, the definition needs work. A state such as “ready” should identify what is ready, for which operation and under which conditions. A progress value should state what it measures and what it cannot establish.
For an illustrative contract review, compare “ready = true” with: “The platform can accept the defined placement request in the reported configuration. This value does not establish instrument readiness. If it is missing or stale, the scheduler cannot treat it as current permission.” Record the platform interface as producer, the customer scheduler as consumer, and the separately agreed source of instrument readiness. A verification case can then ask whether both teams reach the same conclusion when the platform reports readiness but instrument readiness is unavailable. These are example meanings to review, not implemented LabCarry fields.
As a terminology reference, ROS 2 Actions defines separate goal, result and feedback message sections. The checklist extends beyond that example to project-specific responsibilities and evidence; it is not a ROS 2 conformance checklist. ROS 2 Actions design
Rule 2: include unavailable information
Review absent fields, unknown values, late responses and changed configuration. Agree whether a consumer rejects the message, waits, queries a record or escalates. Do not supply an ordinary “success” or “ready” value merely because a producer cannot report its actual condition.
Use the hardware interface guide for scope and responsibility. Tie position-related values to the reference and conditions in the handoff positioning guide.
Rule 3: attach a verification example
For each agreed behavior, identify a test or review record that could show whether both sides implement the same definition. Include normal, rejected and interrupted cases where applicable. Mark whether the evidence comes from an interface simulator, an assembled platform or the actual instrument, and keep the remaining checks visible.
Place the resulting cases in the hardware FAT plan. Preserve the reviewed specification and configuration revisions in the quality and traceability package. A signed interface review should identify unresolved items and who can close them.
Close each field review with a decision
A completed row needs more than a field name and a tick. Copy the record below for each disputed or missing definition, so your platform and scheduler teams can decide whether the interface is ready for implementation review.
| Record | What to capture | Your entry |
|---|---|---|
| Definition under review | Field or message path, specification revision and supported hardware configuration. | ______ |
| Meaning and ownership | Producer, consumer, units or permitted values, and the physical condition the value does—and does not—establish. | ______ |
| Unavailable-information case | One missing, stale or conflicting input; how it is recognized; and the consumer response agreed for that case. | ______ |
| Verification evidence | Case ID, expected interpretation, observed result and record reference. Identify simulator, assembled hardware or instrument evidence; mark untested cases as pending. | ______ |
| Disposition | Agreed for the named implementation scope; hold pending evidence or definition; or not applicable, with the excluded function and reason. | ______ |
| Closure | Open issue, responsible owner, target date, reviewer and the revision or evidence needed to close it. | ______ |
For example, if a placement result is available but instrument readiness is unknown, do not close the review merely because the result says “success.” Record which placement condition that result proves, which instrument condition remains unknown, and which dependent action must stay on hold. This is a hypothetical review case, not a claim about a delivered LabCarry interface.
Use the completion evidence worksheet to separate acceptance from the agreed end condition. If a timeout or reconnection leaves the physical outcome uncertain, carry the open item into the recovery release record instead of treating reconnection as permission to repeat the movement.
An agreed field definition is an input to implementation and verification. It is not a hardware acceptance result or authorization to operate the robot.