Reinspection

What happens when an inspection is rejected — clearing rules, cycle tracking, and punch resolution gates.

When any reviewer (Checker or Approver) rejects an inspection, it cycles back to the Performer for reinspection. How much each party must re-judge depends on the reinspection mode configured in your project's Inspection Policies. Previous verdicts, notes, and evidence are always kept for the audit trail and stay viewable in the comparison column — reinspection only decides what must be re-judged, it never deletes records.

Failed inspection outcome showing reinspection option and linked punch items — Failed inspection — triggers reinspection cycle back to the Performer

When Reinspection Triggers

Trigger	What Happens
Any reviewer fails an item	The inspection goes straight back to the Performer to fix — a Checker's rejection does not move forward to the Approver
Approver rejects	Same — cycles back to the Performer

The reinspection counter increments each time the inspection cycles back.

Re-Judging Modes

Each party role has a configurable mode that determines how much they must re-judge on reinspection. Nothing is deleted — items that must be re-judged are simply shown as pending until the party records a fresh verdict; previous records stay viewable in the comparison column.

Mode	Effect	When to Use
Re-do everything	The party re-judges every item from scratch (shown as pending). Previous records kept.	When you want the performer to re-evaluate everything without bias from prior results
Re-do failed only	The party only re-judges items they previously failed. Passed/N/A items carry forward.	When you only need the failed items re-checked — saves time on large checklists
Carry everything forward	Nothing needs re-judging — previous verdicts carry forward. The party can still update any item.	When you want to keep prior results and selectively update — useful for minor corrections

Default Configuration

Party	Default Mode
Performer (first party)	Re-do everything
Checker (middle parties)	Re-do failed only
Approver (final party)	Re-do failed only

Configure Per Role

Reinspection modes are set in Admin → Inspection Policies and can be configured at the organization level (defaults) with project-level overrides. Each party role has its own setting.

Reinspection Limits

Policy	Default	Effect
Max Reinspection Cycles	Unlimited	When set, the Reinspect button is disabled once the limit is reached. A tooltip explains why.

If the limit is reached, the inspection stays in its current state and cannot be cycled back. This prevents endless inspection loops on problematic items.

Punch Resolution Gate

Punch Items Block Reinspection

When the "Require Punch Resolution Before Reinspection" policy is enabled, the Performer cannot submit their reinspection until ALL linked punch items are resolved (Fixed or Closed).

The flow with punch resolution:

Inspection fails → punch items created for failed items
Assignee fixes the issues → marks punch items as Fixed
ALL sibling punch items must be Fixed
Only then can the Performer record reinspection verdicts
On successful reinspection advancement → Fixed punch items auto-close

Punch Item Rules During Reinspection

The Performer can only FIX punch items — they cannot close them directly
ALL sibling punches (from the same inspection) must be Fixed before any single punch can close
Auto-close fires when the Performer advances during reinspection AND all punches are Fixed

The Reinspection Cycle

text

Next Steps

Punch List Lifecycle — How punch items move through their status workflow
Multi-Party Flow — The sequential review process
Completed View — What the final outcome looks like