Engineering and architecture
QA/QC program for engineering firms: what records to keep
By SourceX Editorial · Updated
Short answer
A QA/QC program at an engineering firm should keep records that prove what was checked, what the checker found and how each finding was closed: the quality manual, project quality plans, stage checklists, a comment log, calculation checks and release sign-offs. A review with no logged response and backcheck cannot be shown to have happened.
Key takeaways
- Keep review evidence at every milestone: concept, midpoint, pre-final check set and issued for construction.
- A comment log is complete only when each finding has a response, a disposition and a backcheck.
- Store the quality manual and checklists centrally, and keep project review evidence in the project file.
- Markups that never reach a log are the most common gap in engineering QA records.
- Consistent, linked QA records also document expert judgment that AI developers look for.
What records should an engineering QA/QC program keep?#
An engineering QA/QC program should keep records that prove three things: what was checked, what the checker found, and how the design team closed each finding. Most firms already produce this evidence in markups, emails and stamped sets. The program's job is to make it consistent and findable.
Quality assurance is the firm-level system: the quality manual, required review types, reviewer qualifications and training. Quality control is the project-level work of checking calculations, drawings and specifications. Keep records from both levels, because an auditor, an insurer or a new project manager will ask for the rule and for proof that it was followed.
- Quality manual: written procedures, review types, roles and approval authority, with a revision history.
- Project quality plan: which reviews apply, at which milestones, and who the independent reviewers are.
- Stage checklists: discipline-specific lists the reviewer completed and signed for each milestone.
- Comment log: every finding, its location, the designer's response, the disposition and the backcheck.
- Calculation checks: checker initials and dates on calculation packages, plus the discrepancies resolved.
- Release sign-offs: who released each set, when, and against which checklist version.
- Corrective actions: recurring errors, their root cause and the procedure change that followed.
Records to keep at each review stage#
Records at each review stage should match what that stage is meant to catch, so a concept review leaves different evidence from a pre-final check set. Many firms label stages by how complete the design is. The table uses milestone names, and the logic carries over to any naming scheme.
The usual failure is a rich record at one stage and almost nothing at the others. Midpoint reviews in particular tend to happen in meetings with no written output, which leaves a gap exactly where design direction was set.
| Stage | What the review checks | Records to keep | Who signs |
|---|---|---|---|
| Concept | Design basis, criteria, governing codes, major alternatives | Basis of design memo, criteria review notes, alternatives comparison with the option chosen | Project manager and senior technical lead |
| Midpoint design | System selection, interdisciplinary coordination, constructability | Comment log, coordination notes, updated basis of design | Discipline leads and independent reviewer |
| Pre-final check set | Completeness, calculations, drawing and specification consistency | Completed checklists, marked-up check set, comment log with responses, calculation check records | Independent reviewer and project manager |
| Issued for construction | Closure of open comments and final release | Backcheck record, release sign-off, list of deferred items with reasons | Principal in charge or engineer of record |
| Construction phase | Revisions issued through RFIs, bulletins and change documents; field-reported errors | Revision log tied to each RFI or bulletin, review record for each revised sheet, note of any design error and its cause | Engineer of record |
What fields belong in a QC review log template?#
A QC review log template needs enough fields to reconstruct a finding without opening the original markup. If a reader can see the comment, where it applies, what the designer did about it and who confirmed the fix, the log stands on its own.
Keep the log in a structured tool rather than a free-form document: a spreadsheet with locked columns and fixed pick lists, a register compiled from Bluebeam markups, or the review module of your project management system. Free text inside a fixed structure is fine. A free structure is not, because severity and disposition values that drift from project to project cannot be counted or compared later.
- Comment ID and review stage.
- Sheet, specification section or calculation reference.
- Discipline and reviewer role.
- Severity: critical, major, minor or editorial.
- Comment text written as a finding, not a question.
- Designer response and the change made.
- Disposition: accepted, declined with a reason, or deferred to a named stage.
- Backcheck by, backcheck date and closure status.
Where should the quality manual and project evidence live?#
The quality manual and its checklists should live in one controlled location, while project review evidence should live in the project file next to the deliverables it checked. Splitting them this way keeps procedures current and lets anyone opening a project see its review history.
Version control matters more than the tool. When a checklist changes, keep the old version retrievable, because a review from several years ago was performed against the checklist in force at the time.
| Record | Home | Update trigger |
|---|---|---|
| Quality manual | Controlled document library, such as SharePoint or a QMS | Procedure change approved by the quality lead |
| Discipline checklists | Same library, versioned | Lessons learned or a code change |
| Project quality plan | Project folder or the Deltek project record | Kickoff and any scope change |
| Marked-up check sets | Project folder, archived Bluebeam sessions | Each review milestone |
| Comment log | Project folder or project management review module | Each review and each backcheck |
| Corrective actions | Quality lead's register | A recurring error or a claim |
Illustrative: a QA log at a structural and civil firm#
Illustrative: a fictional structural and civil engineering firm keeps its quality manual in SharePoint, runs reviews in Bluebeam and tracks projects in Deltek Vantagepoint. Its COO finds that pre-final reviews are well documented, but midpoint reviews survive only as meeting notes, and IFC backchecks are recorded as a single initial on the cover sheet.
The firm adopts a shared log template with the fields above and requires the independent reviewer to close each comment in the log, not on the drawing. A typical pre-final entry reads: footing schedule on the foundation plan does not match the calculation package at one grid line; designer revised the schedule and added a note; reviewer confirmed on backcheck; closed.
After a few project cycles, the logs show which errors recur, and the quality lead adds checklist items to catch them at midpoint instead of pre-final. The firm can now answer an insurer's question about its review process with records rather than recollection.
Gaps that weaken QA/QC records#
The gaps that weaken QA/QC records are usually habits, not missing software. Each one below leaves a review that happened but cannot be shown.
- Comments made only as markups and never transferred to a log.
- Verbal sign-offs at milestone meetings with no written release.
- Backchecks recorded as initials without listing which comments were verified.
- Checklists edited in place, so older reviews cannot be matched to the version used.
- Comments closed by the designer rather than by the reviewer.
- Review sessions deleted when a project is archived or a cloud subscription lapses.
Why consistent QA records become a data asset#
Consistent QA records become a data asset because they capture engineering judgment in a structured form: a finding, the reasoning behind it and the fix an experienced reviewer accepted. AI developers building design-review and checking tools look for this kind of chain, and few organizations outside engineering firms hold it.
Value depends on linkage and rights. A log that connects each comment to a sheet, a response and a backcheck is far more useful than a folder of markups. The firm's own internal comments are usually its records, while client deliverables, client comments and outside peer reviews may be governed by contracts and need review before any licensing conversation.
If a system change is coming, export review sessions and logs before the old platform is retired. Markups stored only inside a hosted collaboration tool may not survive the migration, and they are the hardest part of the history to rebuild.
How SourceX approaches QA/QC records#
SourceX looks at QA/QC histories through the SourceX Enterprise Data Value Framework. For review logs, the drivers that usually matter most are domain expertise, human-generated signal, data cleanliness, recency and rights, while preparation cost and privacy burden reduce net value. The first conversation runs on metadata only: systems, years of accessible history, review types and known contract limits.
If a firm decides to proceed, the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery) separates firm-owned review records from client-controlled material, replaces names and project identifiers, and documents each decision in a SourceX Evidence Packet. The firm approves every step.
Frequently asked questions
How long should an engineering firm keep QA/QC records?
Retention depends on contract requirements, state rules, statutes of repose and your professional liability carrier's guidance, so there is no single answer. Many firms keep review records at least as long as the project files they support. Set the period with counsel and your insurer, write it into the quality manual, and apply it consistently.
Do we need ISO 9001 certification to run a QA/QC program?
No. ISO 9001 is one quality management standard, and many engineering firms run effective programs without certification. If you are certified, your auditor will expect documented procedures and evidence that they were followed. Either way, the same core records apply: a manual, project plans, checklists, logs and sign-offs.
Who should perform the QC review?
The QC reviewer should be qualified in the discipline and independent of the project's design team, so the check is a second set of eyes rather than a self-review. Smaller firms often rotate reviewers between project teams. Record the reviewer's role and independence in the project quality plan.
Should we keep marked-up sets once the log is complete?
Yes, where you can. The log is the searchable summary, but the marked-up set shows context such as the exact detail, nearby notes and the reviewer's sketches. Archive the final marked-up check set with the log so each can be traced to the other.
Can a small firm run a lighter version of the program?
Yes. A small firm can use one checklist per discipline, one shared log template and a single release sign-off. What matters is that every review leaves a dated record of findings and closure. The structure can grow as the firm adds disciplines and reviewers.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.