Delivery, Commissioning and Acceptance Need Separate Evidence

Robot trading projects often blur the moment a system is delivered, the moment it is configured, and the moment someone says it works. Delivery, commissioning and acceptance can instead be documented as three different evidence events, not one signature. This article separates them using provenance ideas from the PROV Model Primer and parameter behaviour described in the ROS 2 Jazzy parameters documentation. The goal is a practical handover timeline for document custody, configuration and observation.

Delivery as custody of entities, not proof of operation

In robot trading workflows, "delivery" should be recorded as the transfer of custody over identifiable things. The PROV primer treats physical, digital and conceptual items as entities, and provenance records can describe how those entities came to exist or changed PROV Model Primer. A delivered robot trading cell, its controller image, its launch files and its parameter files are separate entities. Recommended documentation practice is to log what was handed over, in what version, and by whom, rather than treating delivery as a promise that strategies will run profitably or safely in every venue.

A useful boundary is that delivery evidence answers "which artefacts moved?" It should name the entity, the time of transfer and the agent associated with the activity. It does not need to claim the machine has been tuned. In a hypothetical example, suppose a mobile trading cabinet arrives with a controller, a Jazzy-based node set and a YAML parameter file; the delivery record lists those three entities and the receiving technician. The article later discusses commissioning separately, because moving an entity is not the same as producing a new configured state.

Commissioning as activity: parameters change the node state

Commissioning is the activity that turns delivered entities into a running configuration. According to the ROS 2 Jazzy documentation, parameters are associated with individual nodes and configure nodes at startup and during runtime without changing the code, with each parameter consisting of a key, a value and a descriptor ROS 2 Jazzy parameters. Commissioning evidence therefore records which parameters were set, whether they were declared ahead of time, and whether initial values came from command-line arguments, YAML files or the ROS 2 launch facility.

The same source explains that by default attempts to change the type of a declared parameter at runtime will fail, which prevents mistakes such as putting a boolean into an integer parameter. For a robot trading node, a recommended documentation practice is to record the parameter types alongside values so later reviewers can see that a "max_position" integer was not silently reinterpreted. The primer's view of activities as processes that generate new entities fits here: commissioning generates a new operational entity from the delivered one PROV Model Primer. The timeline keeps delivery and commissioning as two rows, not one.

Acceptance needs observation records, not only a checklist tick

In this article's vocabulary, acceptance means the counterpart has observed the configured system behaving within the bounds agreed for the handover. The PROV primer distinguishes provenance metadata from other metadata such as image size, and describes provenance in terms of the entities, people and processes involved in producing a thing PROV Model Primer. For this handover vocabulary, acceptance evidence should therefore contain who observed, what activity was running, and what records were produced, rather than only a pass/fail box.

For editorial clarity, acceptance can be split into observation windows. In a hypothetical example, an operator runs a Jazzy node set for a fixed period and records that the node started with the launch-provided parameters and that no undeclared parameters were later introduced. The observation log names the agent, the entity under test and the time window. This is recommended practice for internal handover notes; it is not claimed to satisfy any external certification.

Configuration boundaries: declared versus undeclared parameters

Configuration custody depends on knowing which knobs exist. The Jazzy source states that by default a node needs to declare all parameters it will accept during its lifetime so that type and name are well-defined at node startup, reducing misconfiguration later; alternatively a node can be instantiated with allow_undeclared_parameters set to true ROS 2 Jazzy parameters. A robot trading handover should record which mode was used, because undeclared parameters can be set even if not declared.

The documentation also describes three optional callbacks: a pre-set callback that may modify the list, a set callback used to inspect and reject an upcoming change, and a post-set callback to react to changes that were accepted. Recommended documentation practice is to note whether any callbacks were registered, since they affect how a later parameter change is interpreted. The Jazzy docs add that set-parameter callbacks should have no side-effects because a later callback in a chain may reject the update, leaving the class out of sync with the actual parameter ROS 2 Jazzy parameters. Handover notes should say whether callbacks were part of the commissioned build.

Runtime observation and the services that expose state

Observation during commissioning and acceptance relies on the interfaces that already exist. The Jazzy documentation lists default parameter services such as /node_name/describe_parameters, /node_name/get_parameter_types, /node_name/get_parameters, /node_name/list_parameters, /node_name/set_parameters and /node_name/set_parameters_atomically ROS 2 Jazzy parameters. External processes use these services, and ros2 param is the general way to interact with parameters for already-running nodes.

Recommended documentation practice is to record the queries used during observation: for example, that list_parameters was called to capture the available set, and get_parameters captured values at the observation timestamp. Because the primer says agents can be persons, software or organizations and can be associated with responsibility for an activity PROV Model Primer, the observation record can associate the query activity with both the operator and the tooling.

An original handover checklist for robot trading documents

The following checklist is an original editorial recommendation for document custody and configuration evidence, not a requirement of the cited W3C or ROS 2 sources. It keeps delivery, commissioning and acceptance as separate evidence rows:

• Delivery row: list each entity (controller image, Jazzy node set, YAML parameter file), its version, transfer time and receiving agent.
• Commissioning row: record initial parameter source (command line, YAML or ROS 2 launch) and whether parameters were declared or allow_undeclared_parameters was true ROS 2 Jazzy parameters.
• Commissioning row: note parameter types and whether dynamic typing or callbacks were configured.
• Acceptance row: store the observation window, the services queried, the observed agents and the generated log entity.
• Boundary note: state that acceptance covers the observed window only, not future market behaviour or legal compliance.

Using separate rows means a later reader can distinguish the delivered configuration from the commissioned configuration. In PROV terms, activities can change an entity's attributes to produce new entities PROV Model Primer. For readers of technical guides on robot trading process vocabulary, the practical value is a clearer record of which configuration was actually observed. The cited sources are reference material for the vocabulary and parameter model; they are not an endorsement of this checklist. Keeping delivery, commissioning and acceptance as distinct evidence makes custody, configuration and observation auditable.

For further equipment reading, browse related industry updates alongside this practical note.