Commissioning 101: a guide to digital completions

1. What commissioning actually is

Construction proves that a facility was built. Commissioning proves that it works. Between those two statements sits a body of evidence — inspection records, test results, punch items, certificates — that has to be complete, signed and traceable before anyone will accept the asset, insure it, or start it up.

The discipline is usually described with two overlapping words. Completions is the whole process of verifying and documenting that an asset is built and tested correctly. Commissioning is the phase inside it where systems are energised, brought into service and proven to function as designed. Vendors and projects use the terms loosely, which is why the same product gets called completions management software on one project and commissioning management software on the next.

What matters more than the label is the underlying shape of the work: scope is divided into systems, every system accumulates evidence, and milestones are reached when the evidence for that system is complete. Everything else in this guide follows from that.

2. The completions sequence, end to end

Terminology varies between operators and contractors, but the sequence is remarkably consistent across industrial projects:

1. Construction verification. Installation is checked against drawings and specifications, tag by tag. Static inspection records are raised and signed.
2. Mechanical completion (MC). A subsystem is confirmed as built correctly: static records complete, no outstanding Category A punch items. MC is a construction milestone, not an operational one.
3. Pre-commissioning. Cleaning, flushing, drying, calibration, loop checks and continuity testing. The system is prepared for energisation but not yet in service.
4. Commissioning. Systems are energised and function-tested under commissioning procedures. Dynamic records are raised and signed.
5. Ready for start-up (RFSU). The subsystem is proven safe and ready to be put into service, and formal care and custody typically transfers at this point.
6. Start-up and performance testing. The facility runs, and performance is demonstrated against contractual criteria.
7. Final handover. The complete documentation dossier is issued, remaining punch items are closed out, and the asset passes to the operator.

Each of those milestones is a gate, and each gate has an evidence requirement. The reason completions is hard is not that any single step is difficult — it is that thousands of small records must all be present, correct and findable at the moment a gate is called.

3. Systems and subsystems: how scope is divided

Construction is organised by area and discipline — this deck, that module, the piping crew. Commissioning cannot work that way, because a system does not start up by area. It starts up as a functional whole: the seawater cooling system, the instrument air system, the crude export system.

So the scope is re-cut. The plant is broken into systems, each system into subsystems, and every physical tag — every valve, instrument, vessel, motor and cable — is assigned to a subsystem. The subsystem becomes the unit of completion: it is what gets mechanically completed, what gets an RFSU certificate, what gets handed over.

This re-cut is the single most consequential piece of setup on a project. Get it right and progress reporting is meaningful, because "82% complete" refers to a subsystem someone can actually start up. Get it wrong — tags in the wrong subsystem, boundaries that cut through a functional loop — and every report downstream is quietly misleading, usually discovered late, during the walkdown that was supposed to be a formality.

It is also enormously laborious. A mid-sized project carries tens of thousands of tags that must be extracted from P&IDs, line lists and equipment schedules and mapped to the right subsystem. This is the work Deskely's AI drawing parser and AI population are built to compress.

4. The documents that carry the evidence

A handful of record types do almost all the work. Learn these and most completions conversations become legible:

• ITRs (inspection and test records). Signed proof that a defined check was performed on a specific tag and passed. Conventionally split into A-ITRs (static, pre-energisation), B-ITRs (dynamic, live testing) and sometimes C-ITRs (commissioning and performance tests).
• Punch items. Deficiencies found during inspection or walkdown, categorised by whether they block the next milestone (Category A) or can be carried and closed later (Category B, sometimes with a cosmetic Category C).
• Commissioning procedures (CPs). The controlled step-by-step documents that govern how a system is brought into service, with defined sign-off roles and sequence.
• Preservation records. Recurring maintenance on installed-but-not-yet-running equipment — rotating shafts, changing desiccant, dosing inhibitor — so that a pump installed two years before start-up still turns when it is finally needed.
• Walkdown records. Structured physical inspections against a subsystem boundary, typically the trigger for raising the punch list that gates a milestone.
• Certificates. The formal milestone documents — mechanical completion, RFSU, handover — each of which is only valid if the records beneath it are complete.

Note the dependency running through that list. A certificate depends on ITRs and punch status; punch status depends on walkdowns; everything depends on tags being in the right subsystem. When people say completions data is relational, this is what they mean — and it is exactly what a spreadsheet cannot enforce.

5. Why spreadsheets break down

Nearly every project starts in Excel, and for the first few hundred records Excel is genuinely fine. The failure is not dramatic; it is cumulative, and it tends to arrive in the same order:

• The register forks. One master file becomes a file per discipline, then a file per contractor, then a weekly consolidation job that someone does by hand on a Sunday.
• Evidence detaches from status. The spreadsheet says a check passed. The signed sheet proving it is a photograph in someone's phone, or a scan in a folder named after the date it was scanned.
• Status becomes a claim, not a fact. Percentages are typed in rather than derived, so reported progress reflects what people believe rather than what the records show.
• Field work is entered twice. Checks are done on paper in the field and retyped in the office, which adds latency and a second opportunity for error.
• The dossier becomes a project of its own. At handover someone has to assemble thousands of documents in the right order and prove none are missing — a task that regularly takes months and occasionally holds up acceptance.

The cost is rarely a single catastrophe. It is the steady tax of reconciliation, and the late discovery that a subsystem reported as complete has fourteen missing records.

6. What commissioning software does

Commissioning software — also called a completions management system, or CMS — addresses the structural problem rather than the symptoms. Four things change:

• One register, relationally linked. Tags, subsystems, ITRs, punch items, procedures and certificates live in one model, so a punch item raised in the field is automatically visible against the subsystem whose milestone it blocks.
• Status is derived, not declared. Completion percentages are computed from signed records. Nobody types a number into a progress cell, so the report and the reality cannot drift apart.
• Evidence is captured at the point of work. The checksheet is completed on a tablet at the equipment, with photos and signatures attached to the record itself — offline where there is no coverage, syncing when there is.
• The dossier assembles itself. Because every record is already linked to a subsystem and a certificate, the handover pack is a query rather than a filing exercise.

A useful test when evaluating any system: ask it to tell you what is stopping subsystem 21-40 from reaching RFSU. If the answer requires a person to go and look in three places, the software has not solved the problem you have.

7. Going digital without stopping the project

The obvious objection to changing systems mid-project is that commissioning is already the most schedule-critical phase, and it is a fair one. A few principles keep the transition survivable:

• Start with the tag register and subsystem breakdown. Everything else attaches to it. Loading a clean, correctly mapped tag register is 80% of a successful setup.
• Bring your own forms. A system that requires you to adopt its checksheet templates will be rejected by the people who have to sign them. Templates should be configurable to the project's approved formats.
• Pilot on one system, not one discipline. Running a single subsystem end to end — walkdown, punch, ITR, certificate — exposes integration problems that a discipline-wide pilot hides.
• Cut over at a milestone boundary. Migrating mid-subsystem creates two partial records of the same scope, which is worse than either system alone.
• Train for the field first. Office users will tolerate friction. A technician on a tank top with cold hands will not, and if the tablet workflow is slower than paper, the project quietly reverts to paper.

Projects that treat this as a data exercise rather than a software rollout tend to be the ones that succeed.

8. How to choose a completions system

Questions worth asking any vendor, including us:

• Does field execution work genuinely offline? Not "degrades gracefully" — fully offline: open, complete, photograph, sign, sync later.
• Can we configure our own checksheet and certificate templates without a change request and a services fee?
• How does data get in? Manual entry of 40,000 tags is not a plan. Ask specifically how P&IDs, line lists and equipment schedules become a populated register.
• Is status derived from signed records? If progress can be typed in, it will be.
• What does the handover dossier look like, and can you generate it today, mid-project, for one subsystem?
• Who can see what? Multi-contractor projects need role and scope-based access, so a subcontractor sees their scope and not the whole asset.
• What happens to the data at the end? The operator will want a complete, exportable record that outlives the subscription.

If you want to see how Deskely answers these, the module pages cover ITRs, punch lists, preservation and certificates in detail.

9. Glossary

A-ITR

Static inspection and test record, completed before energisation.

B-ITR

Dynamic inspection and test record, completed on a live or energised system.

CMS

Completions management system — the software holding the completions register.

CP

Commissioning procedure: a controlled document governing how a system is brought into service.

Dossier

The compiled documentation package handed to the operator at acceptance.

MC

Mechanical completion: confirmation that a subsystem is built and installed correctly.

MCC

Mechanical completion certificate, issued when a subsystem reaches MC.

P&ID

Piping and instrumentation diagram — the primary source for tags and system boundaries.

Punch item

A recorded deficiency, categorised by whether it blocks the next milestone.

RFSU

Ready for start-up: the subsystem is proven safe and ready to be put into service.

Subsystem

The functional unit of completion; the level at which milestones are certified.

Tag

A uniquely identified physical item of equipment, instrument or line.

Walkdown

A structured physical inspection of a subsystem, usually generating punch items.

10. Frequently asked questions