Quality assurance documentation is one of those things that every construction project needs, most project teams understand in principle, and almost no one has a consistent system for. The result is usually a combination of inherited spreadsheets, scattered PDFs, and a box of signed paper ITPs that nobody can find six months later.
This guide covers what a functional QA/QC documentation system actually looks like — from template setup to sign-off workflows and audit trails.
What QA/QC documentation covers
Construction quality documentation typically encompasses three categories:
1. Inspection and Test Plans (ITPs) The primary QA document. Structured checklists that define inspection activities, hold points, witness points, and acceptance criteria at each stage of a construction scope. Signed off by relevant parties before work proceeds.
2. Site Instructions (SIs) Formal written directions from a superintendent or contract administrator to the contractor. Used for variations, defect rectifications, clarifications, and directions that need to be on record. Each SI has a unique number, a clear instruction, and a response/acknowledgment requirement.
3. Labour and materials records Day labour dockets, plant records, and materials registers that support cost tracking, payment claims, and dispute resolution.
A complete QA documentation system manages all three, keeps them connected to the right project, and produces records that hold up under audit.
The five components of a good QA system
1. A template library
Good QA starts before the project does. Master ITP templates should be defined at company level for each trade or work type your business regularly performs — concrete, steel, hydraulics, fit-out, and so on.
Templates should specify:
- The inspection items relevant to that scope
- Which items are hold points and which are witness points
- The inspection method for each item
- Acceptance criteria (referencing the relevant standard)
- Sign-off roles (who needs to sign this document)
Templates are the most valuable asset in your QA library. A well-written concrete pre-pour ITP template that's been refined across 20 projects is worth more than any QA manual.
2. Project-specific ITP instances
When a project starts, templates are imported and made project-specific. This is where the template meets reality: the job number goes in, the client and superintendent details are added, and any project-specific variations to the standard template are made.
This is a crucial step that paper-based systems handle badly. On paper, you either reprint the template and annotate it, or you hand a generic document to the inspector and hope they understand the project-specific requirements. A digital system keeps the master template intact while letting each project customise its instance.
3. Consistent numbering and version control
Every document needs a unique, systematic number. A typical format is:
- ITP-[PROJECT CODE]-[SEQUENCE] — e.g. ITP-BRK22-014
- SI-[PROJECT CODE]-[SEQUENCE] — e.g. SI-BRK22-007
Version control matters for ITPs that are revised mid-project. If the concrete specification changes after the first few pours, the ITP needs to be updated — and the record should show which version was used for which pour.
4. A defined sign-off workflow
The sign-off process is where most QA systems break down. Paper ITPs require physical presence or printing-scanning-emailing cycles. This creates delays at hold points, undocumented witness point notifications, and signature pages that never quite catch up to the site activities.
A functional sign-off workflow:
- Inspector completes the checklist — all items filled, photos attached where required
- Hold point reached — relevant party notified (automatically, ideally)
- Relevant party reviews the completed checklist and signs off — on site via mobile, or remotely via a secure link
- Witness points — notification sent, attendance recorded or absence noted
- Document status updated — all hold points cleared, document moves to pending sign-off
- Final sign-off — principal's representative or client signs the document
- PDF generated and distributed to the recipient list
Every step should be timestamped and the record immutable.
5. An audit trail
An audit trail is a complete log of every action taken on every document — who did what, when, from what device. It's the thing that makes your QA records defensible when a dispute arises.
At minimum, an audit trail should capture:
- Document creation, editing, and status changes
- Sign-off events (name, email, timestamp, IP address, device)
- Notification events (witness point notifications sent and received)
- Any retrospective changes with a reason recorded
Common QA documentation failures
Templates that never get updated. A ITP template written in 2018 for a project that used AS 3600:2009 may not reflect the current edition or the specific requirements of your current contracts. Templates should be reviewed annually and after any specification change.
Hold points cleared verbally. "The engineer said it was fine" is not a QA record. Every hold point clearance needs a name, a signature, and a date. Without it, you have no defence if the same engineer claims the hold point was never cleared.
Witness point notifications undocumented. Sending a text to the superintendent's personal phone counts as notification to you, but it counts as nothing in an audit. Notifications should go to formal email addresses and be logged.
ITPs completed retrospectively. Filling in an ITP after the work is done is common, widely understood to happen, and genuinely problematic when it's discovered. The whole value of an ITP is that it captures a condition that no longer exists. A retrospectively completed ITP is not a quality record — it's a paper exercise.
Getting started
The best time to set up a proper QA documentation system is before the project starts. The second best time is now.
Start with your most commonly used ITP — probably a concrete pre-pour for civil teams, a structural steel erection ITP for fabricators, or a hydraulic pressure test ITP for services contractors. Build it properly as a master template. Import it into your current project. Run it once.
HoldPoint QA is built for exactly this: a company template library, job-specific ITP instances, mobile-first checklist completion, and external sign-off without the email chain. $45/month per active project (first project free).