An inspection and test plan — an ITP — is the quality backbone of a construction package. It lists each activity, the specification or code it must meet, the acceptance criteria that prove it, and the exact moments where inspection or testing has to happen before the crew is allowed to keep building. Done well, an ITP is the shared agreement between the contractor, the client, and the inspector about what "good" looks like and who has to sign for it.
This template turns that agreement into a living graph. It walks a single activity from Define activity & spec through Set hold / witness points, the contractor's own check, formal inspection, and the recorded result — and then it forks. A passing result flows to Accept & release. A failing one raises a nonconformance and loops the work back for rework and re-inspection. That branch is the whole point of an ITP: it makes failure a defined path instead of an argument.
It is built for quality managers, site engineers, and subcontractor QA leads who are tired of ITPs that live as a locked spreadsheet nobody updates. Because it opens in FlowGraph as an editable graph, you can adapt the acceptance criteria to your own spec, assign each step to a real person, and keep the record of what actually happened attached to the plan itself.
How this ITP template works
The graph follows one activity through the inspection lifecycle. Each card is a step you can open, edit, and assign. Here is the flow in order.
- Define activity & spec — Name the activity being inspected (a concrete pour, a weld run, a pipe pressure test, a fireproofing application) and pin it to the governing specification, drawing, or code clause. This is the "what and against what" that everything downstream is measured by. Vague activity definitions are the root cause of most ITP disputes, so this step earns its place at the top.
- Set hold / witness points — Mark where inspection is mandatory and what kind of point each one is. A hold point stops work completely until the check is passed and signed. A witness point requires you to notify the inspector and give them the chance to attend, but work may proceed on schedule if they do not show. Each point carries its own acceptance criteria — the measurable pass/fail test — so the inspector and the crew read the same standard.
- Contractor self-check — Before anyone external is called, the contractor inspects their own work against the criteria. This is the first-line quality gate: catching problems here is cheap, catching them at the formal inspection is expensive, and catching them after cover-up is a rework nightmare. It is also the step the NCR branch loops back to.
- Notify for inspection — Once the self-check is clean, the contractor gives the required notice to the inspecting party (client rep, engineer, third-party lab, or authority). This step records who was notified, when, and against which hold or witness point — the paper trail that protects everyone if attendance is later disputed.
- Inspection / test — The formal check happens: a dimensional survey, a materials test, a coating thickness reading, a hydrostatic test, a visual weld inspection. The activity is compared to the acceptance criteria set earlier. Nothing is judged on memory — it is judged against the criteria written into the plan.
- Record the result — The outcome is logged: pass or fail, with the measured values, photos, test certificates, or inspector's signature. This is the evidentiary heart of the ITP. In FlowGraph the record lives on the card, so the plan and the proof are never separated. From here the graph branches.
- Raise NCR — If the result is nonconforming, a nonconformance report is raised. The edge is labelled nonconforming for exactly this reason. The NCR describes the defect, the clause it violates, and the disposition (repair, rework, use-as-is with concession, or reject). Its rework edge routes the activity straight back to Contractor self-check, so the fixed work re-enters the same inspection cycle rather than skipping ahead.
- Accept & release — If the result passes, the activity is accepted and released for the next operation — cover-up, backfill, the following trade, or handover. This is the sign-off that lets construction legitimately continue.
The two branches out of Record the result are what separate a real ITP from a checklist. A checklist has one line; the graph has a pass path and a failure path, and the failure path is a genuine loop that keeps re-inspecting until the work conforms.
How to use it in FlowGraph
- Open the template. Click Open in FlowGraph to load the ITP as a live graph. Viewing and editing are free and need no account — you only sign up when you want to save the plan to a vault or ask the AI to extend it.
- Set your points. Open Set hold / witness points and mark each one with its real acceptance criteria — the tolerance, the test method, the code clause, the required document. Change the labels to match your own specification instead of a generic one. Every edit is governed and carries a receipt, so you can always see what changed and why.
- Assign owners. Give each card an owner: the contractor for the self-check, the QA engineer for notification, the client's inspector for the formal check. Now the ITP is not just a plan, it is a set of accountable tasks with names attached.
- Record results as they happen. On Record the result, log the outcome, the measured values, and the evidence — attach the test certificate or photo. Because the record sits on the card, the plan and the proof travel together into any audit.
- Route nonconformances. When a check fails, follow the nonconforming edge to Raise NCR, fill in the defect and disposition, and let the rework edge carry it back to the self-check. Track the loop until the re-inspection passes and the activity reaches Accept & release.
- Extend it with AI or links. Bring your own API key and ask FlowGraph's AI to propose extra test steps, split one activity into several, or draft acceptance criteria from a spec clause — but the AI only proposes; you decide what lands. You can also link ITP cards to the drawings, submittals, or model elements they inspect, so the quality record connects to the thing being built.
Why a living graph beats a static ITP
A spreadsheet ITP is a photograph of intentions. It says what should happen, but the moment inspections start, the real story — who was notified, what failed, how many rework cycles it took — lives in emails, site diaries, and people's heads. The plan and the reality drift apart, and the drift is exactly what an auditor or a claim exposes.
A living graph keeps them together. The same artifact that plans the hold and witness points also records the results and routes the nonconformances, so there is one source of truth instead of three. You can assign steps to people, link them to the drawings and specs they enforce, and let AI suggest improvements — while every change is provenance-stamped, so you always know who edited what and when. Nothing is hidden inside a formula or a locked cell.
Most importantly, the NCR loop is visible. On a static form a nonconformance is a footnote; on the graph it is a live branch you can watch move — raised, dispositioned, reworked, re-inspected, closed. That visibility is what turns quality from a stack of forms into a process you can actually manage, and it is honest: it shows the failures as clearly as the passes.
Frequently asked questions
What is an inspection and test plan (ITP)?
An ITP is a quality-control document that maps every activity in a work package to the specification it must satisfy, the acceptance criteria that prove satisfaction, and the specific hold, witness, and review points where inspection or testing is required before construction may continue. It names who inspects, what standard applies, and what evidence gets recorded, so quality is planned in advance rather than judged after the fact.
In this template each of those elements is a step you can open and edit: the activity and spec, the points and their criteria, the record of results, and the acceptance sign-off. It is a complete inspection lifecycle for one activity that you scale by duplicating for the next.
What are hold and witness points?
A hold point is a mandatory stop: work cannot proceed past it until the inspection is passed and formally released, which is why hold points guard irreversible operations like concealing rebar or backfilling a trench. A witness point is softer — you must notify the inspector and give them a real opportunity to attend, but if they choose not to, work may continue without penalty, so the schedule is not held hostage to an absent inspector.
This template sets both on the Set hold / witness points step, and lets you tag each point with its type and its acceptance criteria. Choosing the right type for each check is a judgment call about how reversible and how risky the work is, and the graph makes that choice explicit instead of buried.
What happens when an inspection fails?
A failing result follows the nonconforming edge to Raise NCR, where a nonconformance report captures the defect, the clause it breaches, and the agreed disposition. The NCR's rework edge then routes the activity back to the contractor's self-check, so the corrected work re-enters the same inspection cycle rather than jumping the queue to acceptance.
The template models this branch explicitly because in the field it is where quality is won or lost. Making the loop a first-class part of the plan means every nonconformance has a defined path to closure, and you can see at a glance which items are still circling and which have been accepted and released.