No Fault Found Is Not the Same as No Evidence Collected

Maintenance teams often close a case with "no fault found" when a reported anomaly cannot be reproduced during inspection. From a recordkeeping perspective, that phrase only describes the outcome of one observation window; it does not mean that nothing was learned, nor that the evidence needed to judge the report is absent. The distinction matters because a closure note that says "no fault found" can be read later as "nothing was recorded," which erases the observation boundary and the unavailable evidence. This article treats the maintenance case record as a scope document: what was observed, what evidence could not be obtained, whether the behavior was reproducible, and under what conditions the case may be closed. The goal is better records, not machine repair instructions.

Why "No Fault Found" Is an Observation Statement, Not an Evidence Statement

A maintenance report arrives with a symptom description, an operator timestamp, and an environment context. The technician then opens a case record and performs a bounded inspection. If the reported behavior does not appear during that inspection, the honest result is that the fault was not found within the observed scope. It is not a statement that no data exists. In ROS 2 Jazzy, ros2 bag records data published on topics and services and saves it in a database so that it can be replayed and examined later; when a service is not available, ros2 bag can only record data from available services, so a missing service means the service-side evidence is unavailable rather than nonexistent (ROS 2 Jazzy documentation). The record should say which streams were captured and which were out of reach.

Scope of Observation: What Was Actually Watched

The first substantive part of a case record is the observation scope. A technician may have watched a topic list, echoed one command topic, or run a short recording; each of those bounds what can later be claimed. In the turtlesim example from the ROS 2 Jazzy tutorial, a user can list topics such as /turtle1/cmd_vel and /turtle1/pose, and choose to record one topic alone or several topics together with a custom output name (ROS 2 Jazzy documentation). For a maintenance record, the equivalent is a plain sentence: "During this visit only the command-input topic and the pose topic were recorded for 48 seconds." That sentence tells the next reader exactly what was in view.

Recommended documentation practice is to write the observation scope as a separate field, not as a footnote. The field should name the streams or signals that were opened, the duration, and the node or process state at the start of the check.

Unavailable Evidence: Naming the Gaps

Evidence can be unavailable for reasons that say something about the system. A service may be absent from the service list; introspection may not have been enabled on the relevant nodes; a recording may have been started after the reported window had already passed. In the ROS 2 Jazzy material, service data can be recorded only when services are available and introspection is configured on the client and server (ROS 2 Jazzy documentation). A case record should therefore list unavailable evidence explicitly.

Reproducibility and Replay Conditions

A replay can test whether a pattern appears under recorded inputs, but its limits must be stated. In the turtlesim example, the ROS 2 Jazzy bag tutorial notes that the path need not match exactly because that example is sensitive to timing. This is an example-specific caveat, not proof that every playback has approximate timing. For a hypothetical maintenance investigation in an isolated simulator, suppose a bag recorded during a later shift fails to reproduce an earlier reported symptom. The record should say that this bag did not capture the original incident, describe the simulator configuration and timing observations, and mark the original cause unresolved. It should not declare an operator error or an approximate replay unless evidence establishes that conclusion. A later recording cannot replace evidence from the actual failure window.

Recommended documentation practice is to mark a tentative finding differently from a confirmed cause. A tentative finding is "the anomaly did not occur during bounded observation." A confirmed cause would require a repeatable link between a specific input and the observed deviation, which this record does not establish.

Provenance: Recording Who Did What and When

A maintenance case record is also a provenance record. The W3C PROV Model Primer explains that provenance describes entities, activities, and agents, where an entity is a thing such as a document or dataset, an activity is how entities come into existence or change, and an agent is a person, software, or organization that can be assigned responsibility for the activity (PROV Model Primer). For our purpose, the bag file, the metadata file, and the case note are entities; the recording and the inspection are activities; the technician and the recording tool are agents. The primer also notes that provenance records are metadata and that provenance may be described from agent-centered, object-centered, or process-centered perspectives (PROV Model Primer).

Recommended documentation practice is to attach a short provenance block to each observation: which agent ran which tool, at what time, producing which stored entity. The ROS 2 material shows that a recorded directory contains a metadata.yaml alongside the bag file, giving a natural anchor for that block (ROS 2 Jazzy documentation).

Closure Conditions and a Practical Checklist

A case may be closed when the observation scope is written, the unavailable evidence is named, reproducibility is stated with its limits, and provenance is attached. Closure should not say "no evidence collected" merely because the fault was not seen. The following checklist is a recommended documentation practice for this site's maintenance case records, not a requirement imposed by either cited source.

• Observation scope: list the topics, services, or signals opened and the duration of the check.
• Evidence captured: name the stored recording or note, including the metadata file if present.
• Unavailable evidence: state which services or streams could not be recorded and why, for example a service not in the list.
• Reproducibility: say whether replay was tried, whether the symptom appeared, and that replay timing may differ.
• Tentative vs confirmed: use "tentative finding" for non-reproduction and reserve "confirmed cause" for a repeatable input-to-deviation link.
• Provenance block: record the agent, the tool activity, the time, and the resulting stored entity.

By keeping "no fault found" inside its proper scope, a maintenance record preserves both the limits of one inspection and the evidence that does exist. A closed case can then be read as a documented boundary, not a blank page.

For further equipment reading, browse related industry updates and technical reference articles alongside this practical note.