“Plan review” can describe several kinds of document review, including permit review. “Plan check” often refers to checking a submission against applicable requirements, especially in a permitting context. A name alone does not establish the reviewer’s authority or the scope of the work.
Compare the purpose and the deliverable
| Review | Primary question | Typical output |
|---|---|---|
| Permit plan check | Does the submission satisfy the requirements within the authority’s review scope? | Comments, correction requests, or a determination through the applicable permitting process. |
| Design QA/QC | Are the documents complete and internally coordinated for this milestone? | Checked documents and an issue record for the design team. |
| Pre-permit review | What should the project team resolve before submitting? | A prioritized list of questions and corrections for submission readiness. |
| Constructability review | What document questions could affect pricing, procurement, coordination, or installation? | Design questions and coordination actions informed by construction expertise. |
These scopes can overlap. A door-schedule inconsistency may matter to the architect, the permit reviewer, and the contractor for different reasons. A useful scope states which decisions the review is expected to support.
Where AI-assisted review fits
AI can help a reviewer identify potential errors, omissions, and conflicting requirements in the supplied documents. In Groundbook, the reviewer opens the finding and its drawing or reference links, then verifies the issue before acting on it.
The same document review can support different workflows. Before submission, a team may focus on missing references and code-related questions. During preconstruction, it may focus on equipment requirements and unresolved structural/MEP interfaces. The software output needs to be interpreted within that scope.
See the pre-permit workflow and constructability workflow for the different inputs and follow-up steps. Neither workflow changes the approvals a project requires.
Write a review brief before you buy
A short brief makes proposals and software trials easier to assess. Include:
- Milestone: what issue is being reviewed, and when must decisions be made?
- Inputs: which drawings, specifications, reports, code references, and revisions are included?
- Scope: which disciplines and issue categories are covered, and which checks are excluded?
- Responsibility: who verifies findings and who makes the final design or approval decision?
- Deliverable: do you need source-linked findings, marked-up drawings, a response record, or a formal submission document?
- Follow-up: who checks that accepted corrections reached the revised set?
For example: “Review the coordinated permit issue for inconsistent equipment requirements across MEP plans, schedules, and specifications; the discipline leads will verify findings and record resolutions before submission.” That is more assessable than “check all plans.”
Choose based on the decision you need
If you need an official review or a statutory private-review process, start with the applicable authority and qualification requirements. If you need help preparing documents, define the quality-control questions your team needs answered.
When evaluating AI software, test whether a reviewer can follow the evidence and reach a reliable decision. Use the accuracy evaluation guide to assess results, and the sample findings to see how document questions can be presented.