ITRs and checksheets: the record everything else depends on.

1. What an ITR actually is

An ITR (inspection and test record) is signed proof that a defined check was performed on a specific tag and gave the expected result. It has four parts that matter: the tag it applies to, the checks it contains, the results recorded against those checks, and the signature of someone authorised to attest to them.

The word checksheet is often used interchangeably. Strictly, the checksheet is the blank template and the ITR is the completed, signed instance of it against a tag — a distinction worth keeping, because template control and record control are different problems.

2. A-ITRs, B-ITRs and C-ITRs

Not every project uses C-ITRs; many fold those checks into B or into procedure sign-offs. What matters is that the split is defined once and applied consistently, because the mechanical completion certificate is gated on the A set and RFSU on the B set.

3. How ITRs get assigned to tags

ITRs are not assigned individually. They are assigned by rule: every tag of a given type and discipline receives a defined set of checksheets. A centrifugal pump gets its installation, alignment, lubrication and rotation records. A control valve gets its installation, stroke and loop records.

1. Classify every tag by type and discipline in the master data register.
2. Define the checksheet set that applies to each tag type.
3. Instantiate the records so each tag carries its own ITRs, in its own subsystem.
4. Verify the count — a subsystem with too few ITRs almost always means tags are misclassified.

On a large scope this assignment is the single biggest data-entry job on the project, which is why AI population exists: it drafts the structure from EPC documents so engineers review rather than create it.

4. What makes an ITR defensible

• It identifies the tag unambiguously. A record against 'pump in area 4' is not evidence. A record against a tag number is.
• The results are recorded, not just a pass box. Actual values — torque figures, pressure readings, insulation values — with the acceptance criteria visible next to them.
• The signature carries a name, role and timestamp. Who signed, in what authority, and when. A scanned squiggle without a role is weak evidence.
• Attachments stay attached. Photos, calibration certificates and test printouts live with the record, not in a parallel folder.
• Revisions are visible. If a value is corrected, the change and its author are part of the record rather than overwriting history.

5. Common ITR failures

• Templates drift. Three versions of the same checksheet circulate, and only one matches the client-approved format.
• Records exist but cannot be found. Signed, scanned, filed by date rather than by tag — technically complete, practically unusable at audit.
• Status and evidence diverge. The tracker says complete; the signed sheet was never returned from the field.
• Bulk signing. A hundred records signed in one action at the end of a shift, which any auditor will challenge.
• Missing acceptance criteria. A recorded value with nothing to judge it against proves that a measurement happened, not that it passed.

6. What changes when ITRs go digital

The immediate change is latency. A paper ITR completed in the field is visible to the office when someone carries it back and types it in — usually days. A digital ITR completed on tablet is visible on sync, and it carries its photos with it.

The structural change is that status becomes derived. Because the record itself holds the signature, subsystem progress can be calculated from signed records rather than typed into a tracker. That single shift is what makes reported progress and proven progress the same number. See ITR management for how this works in practice.