Read-Only Parameters: Define Configuration Ownership
ROS 2 descriptors can describe parameter properties, while running values also depend on declaration and startup configuration. Interpret read-only behaviour together with maintenance ownership. It does not automatically cover file editing, process restart or every other application configuration entry point. The following is a handover review proposal.
Identify the protected entry point
List runtime parameter services, files, launch tooling and application-specific configuration interfaces, marking where the read-only rule applies. A rejected online write does not establish that a value can never change throughout device life. Record the delivered node and client revisions rather than generalising behaviour observed through another implementation or another entry point.
For this review, identify the delivered device, software and configuration revisions first. Record unsupported, disabled and untested capabilities separately. Evidence from another model is useful context, but cannot establish what the delivered combination actually provides. Keep the original input beside the settings used to interpret it.
Define online and offline ownership
Identify changes allowed during operation and those requiring an approved stop or restart workflow. Configuration owner, approver and operator can be different people, but their responsibilities should be traceable. Hiding an interface control alone is incomplete enforcement because another authorised tool may still access the underlying configuration path.
Retain the original input and the reason for the decision, rather than a successful screenshot alone. Change only the variables agreed for the comparison, and keep the before-and-after configuration. List conditions that were not exercised explicitly; they should not silently become part of the accepted operating range.
Inspect rejection and retained values
Use approved isolated checks to inspect the response, user indication and final readback for a prohibited write. Distinguish read-only rejection from wrong type or an undeclared parameter. Otherwise maintenance staff may repeatedly retry what appears to be a communication fault. Retained running values should remain explainable after the failed attempt.
Use the three illustrated observations as starting questions, rather than as diagnoses of an installation that has not been inspected. Check record completeness, units and identity before selecting the next observation. An unresolved result is more informative than a confident explanation assembled from missing fields or unrelated test runs.
Review startup provenance separately
Keep files and overrides used at restart and compare critical values before and after. Runtime non-writability does not establish restoration of the same configuration after a restart. Service account, deployment path and launch options belong in the evidence. One online readback should not be presented as proof of permanent persistence.
Let the site owner choose an approved isolated way to exercise relevant exceptions. Record normal operation, the exceptional condition and recovery separately. The purpose is to establish how the application recognises and explains untrustworthy input, without requiring production equipment to act on deliberately invalid results.
Deliver a maintainable configuration policy
Deliver the controlled parameter list, change workflow, rejection samples and recoverable baseline, with settings outside the rule identified. Recheck behaviour after declaration changes or management-tool upgrades. Maintenance needs to know what may change, how the outcome is verified and how it is traced, rather than receiving a read-only label without its operational boundary.
Deliver the configuration, representative samples, result table and unresolved questions together. Agree who reviews subsequent changes. The receiving team should be able to select one conclusion and trace it back to its input and decision path without relying on the original author to reconstruct the missing steps.
Original documentation and further reading
Continue with related articles in this section, or use selection guides to prepare the next review. Apply the device-specific documentation and agreed operating conditions when implementing a test.