Completion certificates: what each one asserts, and who carries it.

1. The certificate chain

Naming varies by operator and contract, but the underlying chain is consistent: a construction statement, an acceptance by the receiving party, a readiness statement for commissioning, and a readiness statement for service.

Some projects insert a mechanical completion notice ahead of the certificate, or split RFC into per-discipline acceptances. The structure matters less than one rule: each certificate must have a defined evidence set that can be checked before it is signed.

2. The evidence behind each certificate

Mechanical completion certificate

• All A-ITRs for tags inside the subsystem boundary signed and accepted.
• Subsystem walkdown completed with the client attending.
• Category A punch cleared; Category B and C listed and accepted as carry-forward.
• As-built markups captured for deviations from drawing.
• Preservation established and current where the subsystem will sit idle — see preservation work lists.

Ready for commissioning

• MCC issued for the subsystem, and for any upstream subsystem it depends on.
• Pre-commissioning complete: flushing, cleaning, drying, calibration, motor solo runs.
• Commissioning procedures approved and available for the systems in scope.
• Safety and isolation regime agreed, with the permit path established.

Ready for start-up

• All B-ITRs signed — loop checks, function tests, protection and interlock testing.
• Commissioning procedures executed and signed with recorded results.
• Punch status within the agreed RFSU threshold, with every open item categorised and owned.
• Operating procedures, spares and vendor documentation available to operations.

3. Signing authority is part of the control

A certificate is only worth the authority behind it. On a well-run project, the right to sign is a role attribute, not a convention — a field engineer can sign an ITR, a discipline lead can accept a DAC, and only a named commissioning manager can issue RFSU.

Where signing rights are informal, two problems appear: certificates signed by someone without the competence to make the assertion, and certificates delayed because the only authorised signatory is offshore for three weeks. Both are solved by explicit role-based access control with delegation that is recorded rather than verbal.

4. Partial, conditional and revoked certificates

• Partial certificate — issued for a defined portion of a subsystem so downstream work can start. Legitimate, but the excluded scope must be listed explicitly, not implied.
• Conditional certificate — issued with named exceptions attached. Every exception needs an owner and a target date, or it becomes a permanent carve-out nobody tracks.
• Revocation — after a certificate is issued, further modification to the subsystem invalidates part of the evidence. Change control must reopen the affected records rather than leaving a signed certificate describing a plant that no longer exists.

The revocation case is the one most systems handle badly. If a tag inside a certified subsystem is modified, the certificate should visibly flag the affected ITRs — otherwise the dossier says one thing and the plant does another.

5. Why certificates arrive late

1. Evidence is scattered. ITRs in one place, punch in another, walkdowns on paper. Assembling the pack takes longer than closing the work.
2. Boundaries disagree. The subsystem the ITRs were written against is not the subsystem the certificate is issued against, so the completeness check never reconciles.
3. Criteria are interpreted. If the prerequisite list lives in a procedure, two people read it two ways at the certificate meeting.
4. Punch categories inflate. Everything becomes Category A near a gate, and the gate stops discriminating between blockers and noise.

All four are structural, not effort problems. When the certificates module computes readiness continuously from the live record set, the certificate meeting becomes a signature rather than an investigation.