Journal/Guide

The construction defect lifecycle: from open to verified close

Fixed is the most dangerous word in a defect register. It reads like an ending, and it is a claim made by the person with the strongest reason to make it. What each of the seven states is really claiming, and who is allowed to move it.

A two-colour risograph poster of seven stacked horizontal bands stepping upward like a section drawing, the final band picked out in orange
WP
Will PrinmanCo-founder
26 August 2026·5 min read

"Fixed" is the most dangerous word in a defect register. It reads like an ending. It is a claim made by the person with the strongest reason to make it, usually from their van, on the way to the next job.

That is not a slur on trades. It is the reason the states after it exist.

The seven states, and what each one is actually claiming

Most registers ship with three: open, in progress, done. Three states cannot hold a construction job, because the interesting part is the handful of steps between a trade finishing and your side agreeing they finished.

Here is the full sequence we use, with the claim each state makes and who is making it.

Open. The defect exists and nobody owns it yet. This is a queue, not a status, and a register with a lot of aged items sitting here has a triage problem rather than a trade problem.

Assigned. It has been issued to a party. The claim is yours: we have told someone. If the tool cannot prove the telling, this state is a hope.

Pending. Work is under way. On our side this is what the trade's "I'm on it" produces, and it exists for one reason: without it, a trade who has started but not finished has no way to say so except by doing nothing. That is a state everybody used to fake.

Fixed. The trade says the work is done. Nothing has been checked. On our side a trade cannot even make this claim without attaching a photo of the finished work; the button is disabled until there is one.

Trade completed. The subcontractor's own sign-off that the fix is genuine, which on bigger jobs is a different person from the one holding the tools.

Ready to inspect. It is back with you. This is the state that tells your side there is work to do, and the state that quietly fills up when nobody has scheduled the walk.

Closed. Somebody on your side looked at it and accepted it. Terminal. It does not reopen, because a state you can reverse is not evidence of anything.

Read that list back and notice that four of the seven exist to separate "done" from "accepted." That separation is the entire point. Collapse it and your register cannot tell the difference between a defect that was rectified and a defect that somebody said was rectified.

Two states that sit off the path

Outstanding is the honest escalation flag. Blocked on a design decision, waiting on a material with a twelve week lead, resolved against the assignee and going nowhere. Every job has these and the alternative to naming them is a register where forty items are technically open and nobody can remember which ones are genuinely stuck.

In dispute is not something a person sets. It is derived from the underlying assignment activity: a trade lodges a dispute, and the defect reflects it. Nobody can quietly mark something as contested to buy time, and nobody can quietly un-mark it.

Who is allowed to move what

The states are only half of it. The other half is the matrix, and it is not a permissions checkbox, it is a hard-coded set of allowed transitions per role.

Trades, tenants and clients have zero defect transitions. A trade updates their own assignment, which is a parallel record. They never touch the defect's state. That one rule is what stops a subcontractor closing out their own work the week before handover.

Your on-the-ground users drive the field-facing transitions, including ready-to-inspect through to closed, because verifying a fix is a site job and should not require a manager at a desk.

Managers and building managers add one path on top: closing from open. That is the decline route, the not-a-defect route, and it deliberately sits above field level.

Company admins are the only role that can close from any non-standard state, which is cleanup for stuck and escalated records and should feel slightly uncomfortable to use.

If a role attempts a transition it does not hold, the API refuses. There is no override and no just-this-once. When the workflow needs to bend, it bends in the matrix, where the change is visible.

The two clocks

A register that only keeps the logged date measures how long ago you noticed things.

The second clock starts on the first transition out of open, when work actually begins. We stamp it once and never clear it, so time-in-progress is a real number rather than an artefact of when someone got around to typing the defect in. Those are different questions. "We are slow to start work" and "we are slow to finish it" have completely different fixes, and one date cannot tell them apart.

Where teams collapse states and regret it

The common merge is fixed and closed, usually because someone looked at seven states and decided it was over-engineered. It is over-engineered right up until the first argument, at which point the register can only say the defect ended, not who ended it.

The second common merge is pending and assigned, which costs less but hides the trade who has started and stalled. That is the one you want visible at the Tuesday review, because it is the cheapest to unstick.

The third is treating outstanding as a bin. Once "blocked" and "nobody has looked at this in five weeks" are the same colour on the dashboard, they get the same amount of attention, which is none.

Seven states with a real matrix behind them is not bureaucracy. It is the difference between a register that records what happened and one that records what somebody typed.

You can see the whole thing running on a live job, capture through to verified close, on the construction defect management software page.