Defect Management Workflow

Overview

A defect is PreStartGo's record of something wrong with a machine — raised from a failed checklist item mid-inspection, or standalone when a fault is found during operation. Defects follow a deliberate lifecycle so every issue is tracked from capture to closure, with the evidence to prove it.

The four statuses

REPORTED → ACKNOWLEDGED → RESOLVED → CLOSED

The permitted moves and their nuances:

• Reported → Resolved directly is allowed — a supervisor can fix-and-record in one step; acknowledgement isn't a mandatory waypoint.
• Resolved → Acknowledged is the reopen path, for a fix that didn't hold. Reopening happens from Resolved — a Closed defect is final, and a recurrence after closure is a new defect referencing the old one.
• Resolving always requires notes. "Seatbelt replaced and function-tested" is an audit answer; a bare status flip isn't.
• Closing sits one authority rung above resolving — the sign-off step.

Two operator-side rules smooth honest field work: the reporter can resolve their own defect (with the mandatory note) without needing supervisor authority — the fix-it-on-the-spot case — and a defect raised by mistake can be withdrawn by its reporter within a short window of raising it, while it is still Reported. After the window, the record stands and the remedy is resolve-with-a-note. A defect that is holding its machine out of service can't be withdrawn at all.

Every transition is recorded immutably — who, when, and the notes — and none of it can be edited or deleted afterwards.

Severity, and what actually blocks a machine

Severity (Low / Medium / High / Critical) classifies how bad the fault is. Marking a defect Critical doesn't lock the machine on its own. Three things decide whether a machine can start:

1. The pre-start itself. Failing a critical checklist item fails the pre-start, and a failed pre-start doesn't unlock the machine. Every failed item also leaves a defect: the one the operator recorded, or one PreStartGo raises for them, marked Auto-raised (Critical for a critical item, Medium for any other).
2. The critical-item lock. A failed critical item also locks the machine through its defect, whatever severity the operator gave it: every later pre-start on the machine fails until that defect is closed, and closing it lifts the lock automatically. Resolving the defect, or completing its repair service, doesn't: closing is the sign-off that the machine is fit to work again. While the lock is on, the defect shows Out of Service, and anyone who can lift an Out of Service lockout can lift it early. The emergency bypass still works under this lock, so a machine that has to move can be moved; it doesn't clear the lock. A failed non-critical item never locks the machine. A critical item that fails on a service checklist locks the machine the same way, through its defect — see Services and Maintenance Workflow.
3. The Out of Service lockout — a flag a Technician or Lead sets on a defect in the app — is the hard stop for everything else: the machine fails every pre-start and refuses every unlock, for everyone, until the flag is explicitly lifted. A Technician or Lead lifts it in the app; an Administrator or the Account Owner can lift it from the console as break-glass. It is deliberately not lifted by resolving, closing, or completing a service — a person stands the machine back up.

So a machine that fails a critical item stays off the job until its defect is closed. To hold a machine for a fault the pre-start didn't catch, or past the defect's closure, have a Technician or Lead mark the defect Out of Service. Non-critical defects are the maintenance backlog, and a machine legitimately runs as pass with defects while carrying them.

Photo evidence

Photos attach at every stage — at capture (the fault as found), during repair (on the linked service), at resolution. Your organisation can make photos mandatory on defects, resolved per site, group, or organisation. All photos are immutable once attached: they're compliance evidence, not gallery items.

The repair link

The defect tracks the communication state; the repair's logistics — who, when, parts, cost — live on a linked service record with a defect-repair trigger. Completing that service auto-resolves the linked defect with a system note, closing the loop without double entry — unless a critical item on the service's checklist fails, which leaves the defect open and locks the machine through it. Resolved isn't closed: a machine locked by a failed critical item stays locked until someone closes the defect. See Services and Maintenance Workflow.

Comments and collaboration

Each defect carries a comment thread — "still a problem", parts updates, context for the next shift. Who sees the full thread follows authority: office roles and licence-holders responsible for that equipment group see everything; others see their own comments.

Edge cases

• Hired-out machines — defects belong to the machine and are visible to both the owner and the operating organisation; either side's authorised people can work them, with actions attributed across the org boundary. See Cross-Org Equipment Rental.
• The same fault found twice — a failed item that already carries an open defect prompts comment-or-new during inspection, rather than silently stacking duplicates.
• Concurrent edits — the second writer is told the defect changed rather than silently overwriting the first.

Troubleshooting