Robot Log Records as Provenance Evidence: Reading ROS 2 and PROV Together

On a robotics verification desk, a claim about new-robot behaviour often arrives accompanied by fragments of evidence: a console capture, a file on disk, a timestamped entry on a network topic. The task of separating what was published from what is inferred begins with the shape of the record itself. Two reference documents help frame that separation without supplying any robot-specific claim of their own. The official ROS 2 Jazzy logging documentation source describes how messages are emitted, tagged by severity, and routed to targets. The PROV Model Primer published by W3C describes a general data model for recording the entities, activities, and agents that produced a thing. Reading them together gives a method for treating a log line as an object with an origin rather than as a self-validating fact.

What a Severity Label Does and Does Not Say

The ROS 2 logging subsystem attaches a severity level to each message: DEBUG, INFO, WARN, ERROR, or FATAL in ascending order. A logger processes messages at or above a chosen level, and each node carries a logger whose name reflects the node name and namespace. The documentation states that logger names form a hierarchy, so an unset child defers to a parent, and changing a parent affects descendants unless they have been set explicitly. For a verification editor, the operative point is narrow: the label tells you the threshold category assigned at emission time by code running on that node. It does not by itself tell you whether the condition described was reproduced across runs, whether the node was under load, or whether another subsystem reported the same event. When a demo is described as "error-free," the raw evidence may only be the absence of ERROR or FATAL lines above the configured level in one process, not a performance guarantee.

Targets, Environment, and the Scope of Capture

By default, ROS 2 node messages go to the console on stderr, to log files on disk when storage is available, and to the /rosout topic on the network; each target can be enabled or disabled per node. Process-wide environment variables shape where records land: ROS_LOG_DIR sets the write directory if disk logging is on, ROS_HOME helps construct that path, and RCUTILS_LOGGING_USE_STDOUT switches stream output from stderr to stdout when set to 1. The scope of a published capture therefore depends on configuration that may not travel with the excerpt. A pasted console segment is evidence of what reached one stream in one process, not necessarily the full disk record or the full network topic history. Verification requires noting which targets were active and whether the pasted fragment is a partial view.

Provenance Vocabulary for a Log Entry

The PROV primer introduces entities, activities, usage, generation, agents, and responsibility as core concepts for describing how a piece of data came to be. An entity is a thing in the world; an activity is something that occurs over time and acts upon entities; usage and generation tie inputs and outputs to that activity. Agents bear responsibility for what happened. Mapping a robot log line onto that vocabulary is an editorial act, not a discovery: the log file is an entity, the emitting node during a run is part of an activity, and the process context supplies an agent attribution only insofar as configuration records identify it. The primer says provenance can be used to judge whether information can be trusted and whether the process complied with requirements, but it supplies no robot domain data and no statistics. Using its categories helps an editor ask "generated by what, when, under whose control" instead of accepting a line as an endpoint.

Derivation, Revision, and Alternate Records

PROV also models derivation and revision, plus alternate entities and specialization. A later log file may be a revision of an earlier one, or an alternate representation of the same run when the same activity is described at a different level of abstraction. In practice, a vendor may publish a cleaned console excerpt alongside a fuller disk file; the two are not the same entity even if they describe the same nominal activity. The primer's notion of specialization supports saying that one record is a narrower view than another without asserting the broader one is false. For robot-claim checks, that distinction prevents a common error: treating an abridged stream capture as the complete activity record when it is only a specialized presentation of a subset of targets.

Time, Plans, and Reproducibility Questions

Time appears in PROV as a concept for situating activities and generation events, and plans describe the steps intended to produce a result. The ROS 2 source does not publish a clock model for robot claims, but it does note that throttle and once-style APIs control how often a message is emitted, including skipping the first occurrence or limiting output rate by milliseconds. A throttled INFO line is therefore not evidence that the underlying condition occurred only once; the API was configured to report at most once per interval. When a published fact carries a date, the verification task is to record that date as the capture date and to distinguish the plan a developer intended from what the activity actually recorded. Reproducibility is a separate question the documents do not answer for any specific machine.

Separating Published Record from Editorial Inference

A verification workflow built from these two sources stays within their limits. The ROS 2 documentation describes the mechanics of severity, logger hierarchy, targets, and environment configuration; the PROV primer describes how to model origin, agency, and derivation in general. Neither asserts that a particular robot achieved a stated capability, and neither provides installation counts, certification outcomes, or test scores. A hypothetical example — suppose a team publishes a WARN-free stderr excerpt from a single node during a scripted task — would support only the inference that no WARN or above was emitted to that stream under that node's level, not that the robot is safe for unstructured use. Internal readers comparing claim types can consult demo-video claim patterns, certification scope checks, and installation figure revisions to see where a log record sits beside other evidence forms. The discipline is to print the fact with its date, scope, and source, and to mark the step from record to conclusion as inference.