Engineering Document Review Checklist: What to Check Before You Approve
Why Reviews Need a Checklist
Most engineering document reviews are performed from memory. The reviewer opens the drawing, reads, and comments on whatever catches their attention. The result is inconsistent coverage: formatting comments on documents with interface errors, and "approved" stamps on documents nobody checked against the datasheet. A checklist does not replace engineering judgment — it guarantees the judgment gets applied to the same things every time.
Use this checklist as a starting point and tailor it per document type. It pairs well with our free CRS template for logging what you find.
Before the Review Starts
- Is the package complete? All sheets, attachments, and referenced documents present. Incomplete packages should be returned, not reviewed.
- Is this the correct revision? Confirm you are reviewing the latest transmitted revision — reviewing a stale file wastes the whole cycle.
- What changed? For resubmissions, obtain the change summary and the previous comment sheet. Re-reviewing from scratch produces contradictory comments.
- Are previous comments incorporated? Verify each closed comment from the prior revision actually appears in the document before looking for anything new.
Technical Content
- Compliance with specifications — the document meets the governing specs and standards it cites, at the correct revision.
- Design inputs are current — datasheets, loads, process conditions, and vendor data referenced are the latest issued.
- Interfaces — tie-in points, battery limits, and cross-discipline interfaces match the counterpart documents.
- Calculations traceable — results in the document match the supporting calculation, at a matching revision.
- Constructability and operability — can it be built, accessed, and maintained as drawn?
- Safety and regulatory requirements — code compliance, safety distances, fire ratings, environmental permits reflected.
Document Quality
- Title block correct — document number, revision, project, and purpose-of-issue code.
- References valid — every referenced document exists, at the cited revision.
- Holds clearly marked — every HOLD has a reason and an owner; a drawing full of unexplained holds is not reviewable.
- Legibility and units — consistent units, readable at issue scale.
Comment quality determines whether resolution is fast or painful:
- One issue per comment. Compound comments get half-resolved.
- Verifiable wording. "Section 4 is unclear" cannot be closed; "Section 4 omits the design pressure; add per DS-1104" can.
- Cite the requirement. Every technical comment should reference the spec, code, or document that makes it a requirement rather than a preference.
- Categorize. Technical / editorial / clarification — so the author triages correctly and leads can see review substance at a glance.
After the Review
- Log every comment in the comment resolution sheet with an ID, category, and criticality — the lifecycle discipline we describe in What Is a Comment Resolution Sheet?
- Assign the review code honestly. A "B — approved with comments" on a document with an unresolved technical issue converts your comment sheet into evidence against you.
- Track your open comments to closure — the reviewer who raised a comment is the only person who should close it, a rule we explain in Role-Based Permissions in AEC Collaboration.
Making the Checklist Stick
A checklist enforced by willpower degrades under deadline pressure. Teams that keep review quality consistent bake the process into their tooling: structured comments, mandatory categories, role-based close-out, and automatic carry-over between revisions. That is what Contrat.io does for AEC and EPC review workflows — try it free for 30 days, no credit card required.