Defects

A defect in IssuesId is any tracked site issue — a quality problem, a variation request, or a backcharge claim. Every defect carries a full lifecycle with role-gated transitions, so the audit trail holds up in claims, disputes, and PC sign-off.

The lifecycle

Defects move through a fixed sequence of states:

01Open — the default state when a defect is first captured. Not yet assigned to anyone.
02Assigned — sent to a trade or sub-contractor.
03Pending — work in progress, awaiting completion.
04Fixed — the trade has marked the issue as resolved.
05Trade completed — sub-contractor sign-off that the fix is genuine.
06Ready to inspect — handed back for verification.
07Closed — verified and signed off. Terminal state — closed defects can't be re-opened.

Two additional states sit outside the happy path:

→Outstanding — used as an escalation or exception flag when a defect can't progress through the normal path (e.g. blocked by a design decision, missing material, dispute resolved against the assignee).
→In dispute — set automatically by the system when an assignment is disputed. Users can't transition into this state manually; it's derived from underlying assignment activity.

Each transition is role-gated. A contractor can't close their own work, a supervisor can't be bypassed, and every state change is timestamped against the user who made it.

Capturing a defect

The capture flow is intentionally short — under 30 seconds for an experienced user.

→Photo — one or more, taken in-app or imported from camera roll.
→Location — drop a pin on the project drawing, or scan a QR code that pre-fills it.
→Voice note — dictated description; transcribed automatically.
→Raised by — who reported it. Picked from the project's reporter directory, so a tenant's complaint stays attributable months later. See below.
→Classification — what kind of defect this is (e.g. Plumbing, Tiling, Water Leak — Bathroom Membrane). Optional. See below.
→Trade and priority — drives routing and SLA timing.
→Type — what the record is: Defect, Safety, RFI, General, Maintenance, Warranty, Incomplete Works, Contract Variation, or Variation. Defaults to Defect. See below.
→Cost category — defect, variation, or backcharge. This flag follows the record into reports.

Type, Classification, and Cost category

Three fields that sound alike and do different jobs. Worth getting straight once:

→Type answers what kind of record is this? It's a fixed list of nine — Defect, Safety, RFI, General, Maintenance, Warranty, Incomplete Works, Contract Variation, Variation — and it separates a genuine defect from incomplete works, a warranty claim, or a variation that shouldn't be counted against your defect numbers at all. Defect lists filter on it.
→Classification answers what's wrong, and whose trade is it? That's the org's own taxonomy, described below.
→Cost category answers who pays? Defect, variation, or backcharge.

A leaking shower on a completed unit could be Type Warranty, Classification Water Leak — Bathroom Membrane, Cost category defect. Each field is read by a different person for a different reason.

Classification

Classification is the field the defect lists sort and filter on, and it's what the app calls the org's defect taxonomy. (The settings screens where you edit the list still call these categories — same thing.)

The field uses an organisation-wide taxonomy — a configurable list of defect types that's shared across every project in your org. New organisations are seeded with ~80 sensible defaults covering trades (carpentry, plumbing, electrical, …), failure types (chip / scratch / mark / dent, water leak — and a dozen sub-types of that), and admin entries (duplicate entry, not a builder's defect, waiting on image).

You can edit the taxonomy any time:

→Add or rename entries to match your team's vocabulary, in Organisation Settings.
→Reorder them in the picker.
→Deactivate entries that no longer apply, without destroying historical defects that used them.
→Exclude per project — an entry that's relevant on most jobs but not on a specific one can be turned off for that project, keeping the picker tight for the team on site.

Classification is optional on a defect — captures without one are still valid records. It's there to help filtering, reporting, and trade-routing, not to gate the capture flow. It shows as a column on the defect list, so an uncategorised defect reads as an em-dash rather than a blank.

Who raised it

Every project keeps a reporter directory — the people who raise defects on that job, whether or not they have a login. A reporter carries a name, a role (tenant, client, consultant, and so on), contact details, and optionally the location they're attached to.

→Reuse across projects. Start typing and the directory searches your whole organisation, so a consultant who appears on four jobs is entered once and copied, not retyped.
→Contact details are enforced where they matter. Tenant and client reporters require contact details — those are exactly the reporters you'll need to reach when the defect is disputed.
→Tenants seed themselves. A tenant who claims their unit by QR code or accepts an invite gets a reporter row automatically, linked to their user account. Edit their profile and the change follows them across every project they appear on.

On the defect form, Raised by is a picker over that directory, with an inline "add new reporter" option so nobody has to leave the capture flow. Defects raised by a tenant pre-fill to their own row.

Issued-To sign-off

Assigning a defect to a contractor tells them to do the work. Sign-off is the separate, explicit step that records someone accepting it as done.

An assignment's sign-off is in one of three states — none, requested, or signed off:

→Request sign-off — asks the configured approver to review the completed work. The approver is notified.
→Sign off — records the acceptance, against a named person and a timestamp, with an optional note. Approvers can sign off without a prior request; everyone else has to go through one.
→Revoke sign-off — reverses it, and stays in the history rather than erasing the original.

Which roles can approve is configured per organisation. The point of the separation is that "the trade says it's done" and "we accept it as done" are different claims, made by different people, and a defensible record keeps them apart.

Filtering the list

The defect list carries a filter set built for the questions people actually ask on a job, not a generic table filter:

Filter	Answers
Issue Number	"Pull up 214, 218 and 231." Multi-select with type-ahead.
Location	Anywhere in the location tree.
Type, Classification, Priority	The three descriptive fields, filtered independently.
Issued To	Whose work it is.
Cost To	Who's wearing the cost, which isn't always the same contractor.
Cost attribute	Defect, variation, or backcharge.
Reporter / Inspected By, Entered By	Who raised it versus who typed it in — different people, and the difference matters when you're chasing detail.
Contact	The person on record for it.
Logged, Fix by, In Progress, Closed dates	Four independent date ranges.

Active filters show as chips above the list, so you can always see why a list is as short as it is. Status reads as a colour-coded pill rather than a word you have to parse, and the columns are per-user — show, hide, and drag them into the order you want. The list you want at handover isn't the list you want mid-build.

Cost tracking

A defect carries two contractor links, and the distinction matters when it comes time to invoice:

→The assignee (set per assignment) is the contractor doing the work. They get the notification, they update the assignment status, they sign off when complete.
→The cost-to contractor is who gets billed for the work. It's set per-defect, separate from any assignment.

Most of the time these are the same. The split exists for the cases where they aren't — for example, when Trade A is doing the rework but Trade B caused the issue and is being backcharged, or when an internal team handles the fix but an external party is billed. The cost-to contractor field captures that intent in a structured way, so reports and exports reflect who actually pays.

The defect also carries an optional cost value and a cost code (drawn from the project's configured cost code list). Together with the cost category (defect / variation / backcharge) and the cost-to contractor, that's a complete record line for the accounts team.

Comments & notes

Every defect has a conversation thread — internal and shared comments attached to the record. Each note has:

→An author, recorded at the user level.
→A visibility scope — one of:

- internal — only your own team sees it. - shared_trade — visible to assigned trades. - shared_tenant — visible to the tenant scoped to this defect's unit. - shared_client — visible to client-role users on the project. - shared_all — visible to everyone who can see the defect.

→An optional assignment link — notes can be tied to a specific assignment thread when context matters (e.g. back-and-forth on a particular trade's rework).
→Edit tracking — if a note is edited after posting, the edit timestamp is recorded and a revision count is incremented. Recipients see "edited" markers; the platform doesn't pretend the edit didn't happen.
→Soft delete — a deleted note leaves a tombstone, not a hole. The thread shows that something was removed and when, without exposing the content.

This is the surface that replaces the old fixed "internal notes / client notes / builder response" columns. The conversation model means a defect's discussion can be longer than three messages and audited just as cleanly.

Time-in-progress tracking

The first time a defect transitions out of open — when work actually starts — the platform stamps an in-progress timestamp on the record. Once set, it's never cleared and never updated. That gives reports and dashboards a clean "time-in-progress" measure that's independent of when the defect was first captured.

The defect list endpoints support inProgressFrom and inProgressTo query parameters to filter on this date range — useful for SLA reports, aging analyses, and "what got picked up this week" queries.

Annotations

Photos and drawings support overlay markup:

→Pin — drop a numbered pin with an optional caption.
→Circle / arrow / text — call out the exact problem area.
→Voice caption per pin — speak instead of typing.

Pin colour reflects status, so a foreman scanning a plan sees open issues at a glance.

Disputes and history

If a trade disputes a defect (e.g. claims it's design intent, not a fault), they raise a dispute. The defect pauses in its current state until a supervisor adjudicates. Both the dispute reason and the resolution are recorded.

Every defect has a full history view: who did what, when, with what evidence. This view is the source of truth in claims and contract disputes.

Bulk actions

For projects with hundreds of defects:

→Bulk assign by location, trade, or filter set.
→Bulk export to CSV or PDF.
→Bulk close after a verified inspection sweep.