Procedures

A procedure guides a Technician through planned work — maintenance, calibration, cleaning, or part replacement. Unlike a troubleshooting task, a procedure's steps are not solutions: they are information steps that explain the work, and observation steps that capture data along the way. Each run leaves a record of who did the work, when, on which asset, and what was observed.

Structuring a Procedure

A well-structured procedure follows a few rules:

• One section per step. Each step covers a single logical section of the work — safety, preparation, the work itself, verification. Don't combine unrelated actions in one step.
• Safety first. Hazard warnings and PPE confirmation belong in the first step, before any work begins.
• Capture data where it matters. Where the Technician must record a reading, a part used, or a confirmation, use an observation so the value is saved with the session and appears in Task History.
• Verify at the end. Close with a step that confirms the work is complete and the equipment is back in service.
• Reuse common sequences. Sequences shared across procedures — lockout/tagout, restart, escalation — belong in their own task, run as a subtask.

Example: Filter Replacement

The general sequence of a filter replacement procedure might be:

1. Information step: safety warnings and required PPE.
2. Information step: shut down and isolate the equipment.
3. Information step: remove the housing and the old filter, with a diagram of the assembly.
4. Observation step: record the part number of the replacement filter.
5. Information step: install the new filter and reassemble the housing.
6. Observation step: record the pressure reading after restart, as a number.
7. Observation step: confirm the equipment is back in service — Yes or No.

At the end of the procedure, a script can compare the recorded pressure to setpoints on the asset, send the record to a CMMS or other external system, or notify support if the confirmation is No.