Skip to main content
All field notes
Turnaround & reliability

Punch lists that close themselves

2026-06-02 · 5 min read · By Kash Mohammed, President

Every turnaround ends the same way: a walkdown, a clipboard, and a punch list. Then the list becomes an artifact of its own, emailed around, re-numbered, split into contractor copies, and reconciled in a nightly meeting that exists mostly to argue about which version is current.

The list is not the problem. The problem is that the list is a document, and documents drift from reality the moment someone stops updating them.

Why punch lists rot

A punch list rots for predictable reasons:

  • It is a copy of the truth, not the truth. The real state of an open item lives in the field, in a repair record, or in an inspector's head. The spreadsheet is a snapshot that ages by the hour.
  • Closure is a reporting act, not a work act. A fitter finishes a flange, but the item stays open until someone remembers to tell the list owner, who updates a cell, who circulates a new version.
  • Nobody owns the reconciliation. Three contractors keep three lists. The owner's list is a merge, and merges lose items.
  • Evidence lives elsewhere. The item says "reinstall insulation, verified." The photo that proves it sits in someone's phone.

None of this is a discipline failure. It is a structural failure: the list and the work are separate systems, and humans are the synchronization layer.

Derive the list, don't maintain it

The fix is to stop maintaining a punch list and start deriving one. If every finding, repair, and reinstatement task is a record with a status and a required acceptance, the punch list is simply a query: show me everything on this unit that lacks a closing sign-off.

Run that way, three things change:

  1. Closure happens at the point of work. The inspector accepts the repair on the record, in the field, and the item disappears from the open list in the same motion. No phone call, no cell update, no version bump.
  2. The list cannot fork. Contractors, the owner's team, and the turnaround manager all query the same records. There is one list because there is one source, and it is always the current one.
  3. Evidence attaches where it belongs. The photo, the NDE result, the torque sheet, each lands on the item it proves. When the item closes, the proof closes with it.

What the nightly meeting becomes

The reconciliation meeting does not vanish, it changes character. Instead of arguing about versions, the team looks at a live count of open items by system and by trade, and spends the time on the items that are actually stuck: waiting on parts, waiting on scaffolding, waiting on a decision. That is a planning conversation, not a bookkeeping one.

What field capture has to support

Deriving the list only works if closure is easier than the workaround. That puts real requirements on the capture tool:

  • Offline first. Punch items get closed in places with no signal. If the app needs coverage, people fall back to paper and the drift returns.
  • Fast enough for gloves and ladders. Closing an item should take seconds: open, photo, sign, done.
  • Sign-off with identity. An acceptance is only worth something if the record shows who accepted, when, and against what evidence, and if that entry cannot be quietly edited later.

The payoff at closeout

A derived punch list pays off twice. During execution, it removes an entire category of coordination work. At closeout, it removes the scramble: the moment the last item carries its acceptance, the closeout package for that system already exists, because every closed item brought its evidence with it.

intelliPROJECTS treats punch items this way, as live records with attached evidence and field sign-off rather than spreadsheet rows, with intelliSPEC's mobile capture working offline so closure happens where the work does. If your last outage ended with three competing lists, that is the structural difference worth evaluating.