A Reproducible Step-by-Step Robot Maintenance Record: Inputs, Observations, Exceptions and Owner

Robot maintenance case records work best when they are reproducible. A technician should be able to read a past entry, see what was put into the job, what was observed on the cell, where the work deviated from plan, and who owned each step. On this maintenance case site we treat each entry as a small operational document rather than a brief status note. That means inputs are listed before work begins, observations are written while the asset is still in the service state, exceptions are recorded even when they do not stop the job, and a named owner is attached to the record so later reviewers know who to ask. Two W3C references shape how we frame that structure: the PROV Model Primer describes how entities, activities, agents and responsibility can be expressed so a result can be traced back to the process that produced it, and the Data Catalog Vocabulary (DCAT) Version 3 shows how datasets and their descriptive metadata can be published in a standard way so they remain discoverable and reusable.

Why reproducibility matters in a maintenance case file

A repair note that says only "replaced gripper seal and tested" cannot be reproduced. Months later another engineer may face the same vacuum loss symptom and have no way to know which seal batch was used, what torque pattern was applied, whether the robot was in a restricted work area during the swap, or why the test cycle ended early. Reproducibility in this context does not mean every job is identical; it means every job leaves enough evidence that the sequence can be followed. The PROV primer explains provenance as a description of the entities and activities involved in producing or influencing an object, together with the agents and plans behind them. In maintenance terms the "object" is the returned-to-service robot cell and its record. If we capture the parts, tools, documents, people and steps as entities and activities, the record itself becomes something another shift can audit.

Readers who track repeat faults will find the same concern in our write-up on robot fault recurrence and no-fault-found reviews, where a missing input list made a later comparison impossible. The goal here is narrower: build one entry format that any technician can repeat without extra supervision.

Inputs: what entered the job before a tool touched the robot

Inputs are everything supplied to the activity. In a gripper service case they include the replacement seal kit identifier, the lubricant specification, the approved procedure document version, the lockout device number used to isolate hazardous energy, calibration sheets for the torque driver, and the software baseline on the controller before download. Writing inputs first forces the technician to confirm they exist. If the seal kit carries no batch code, that absence is itself an observation and should be written as "input identifier unavailable; kit label unreadable," not silently skipped.

The PROV view helps here because usage is a relation between an activity and the entity it consumed. A maintenance activity uses the seal kit; the activity did not create it. If a used kit came from a partially depleted store, the record can note the remaining quantity as context. For a gripper job the input block might list: cell identifier, robot serial, axis or tool number, procedure ID, part numbers, tool IDs, energy isolation set, and PPE checked at the boundary. When inputs are recorded this way, a later reviewer can ask whether a different batch behaved differently without guessing. This habit also connects to our note on service handover and hazardous energy control, where the isolation set is one of the most frequently omitted inputs.

Observations: what was seen while the asset was in service state

Observations are written during the work, not reconstructed from memory at the end. They cover physical state, measurements, audible or visual cues, controller messages, and any condition that differs from the procedure's expected picture. For a vacuum gripper case the observation set could include the measured vacuum level before disassembly, the condition of the old seal face, debris found on the manifold screen, the presence or absence of oil film, the torque values achieved on reassembly, and the controller alarm history at the moment testing began.

Each observation should carry enough context to be interpreted later: where it was taken, under what mode, and by whom. "Vacuum 42 kPa" is weak; "vacuum at gripper port 42 kPa in manual reduced-speed mode after seal replacement, before payload test" is usable. If an observation is borderline, say so: "seal lip wear appears moderate rather than severe; no crack observed under 10x loupe." PROV treats generation as the relation where an activity produces an entity, and a measurement record is one such generated entity. Treating the reading as a generated output rather than a casual note keeps it available for the next person.

Exceptions: the deviations that did not become incidents

An exception is any point where the job departed from the written plan but still continued. It may be a missing step because a tool was unavailable, a skipped verification because the area was not safe, a substituted part from a different but compatible batch, a controller message cleared and not reproduced, or a test stopped early for a reason unrelated to the fault. Exceptions matter because they explain why two records for the same procedure differ.

Many teams record only failures. A reproducible method records exceptions even when the robot returned to service normally. Suppose—hypothetical example—a technician finds the specified torque driver is out of calibration and uses a second driver with a valid certificate instead. The robot passes the test. No incident occurred. Yet the record must say which driver was used, because a future audit of torque values depends on it. Exceptions are where responsibility is easiest to lose, so the owner of the decision must be named next to the exception itself, not only at the end of the form.

Owner and responsibility: one name per step, not per shift

A maintenance record often names the person who signed the work order, but reproducibility needs finer attribution. Each major block should have an owner: who gathered the inputs, who made the observations, who authorised the exception, who ran the test, and who released the cell. The PROV primer describes agents and responsibility as part of provenance; in our case records the agent is the technician, the lead, or the planner, and their role in the activity is explicit.

This is not about blame. It is about knowing whom to ask when a later entry shows the same exception pattern. If three different gripper jobs list the same missing input, the owner of the first exception may be the only person who remembers why the store was short. Attaching ownership per step also supports DCAT-style publication: when these case records are exposed as catalogued datasets, the responsible agent metadata travels with the description, and consumers of the catalogue can see who stands behind a given entry. Our related discussion of approval separation in robot repair records covers why inspection and repair approval should not collapse into one signature.

Publishing the record as a reusable catalogue entry

After the work is closed, the same entry can be described with standard vocabulary so it is not trapped in a local folder. DCAT Version 3 defines a schema for describing datasets and data services in a catalog using RDF, which supports discoverability and federated search across sites. A maintenance case dataset—perhaps one export per month—can carry a title, an identifier, a description of what the cases cover, the responsible agent, and the distribution format.

The internal case text stays human-readable: inputs, observations, exceptions, owner. The catalogue layer adds machine-readable metadata without changing the operational record. This two-layer approach means a planner searching for all gripper cases from a given line does not read every file; they query the catalogue description, then open the few entries that match. Because DCAT preserves backward compatibility and adds classes for versioning and dataset series, a site can start with a simple export now and later mark previous versions of a case set without rewriting the original entries. The practical method stays the same on the floor: write inputs before starting, observe while working, log exceptions honestly, sign each block, then publish the batch with enough metadata that another site or another year can find it.