Use early reviews to test requirements and major interfaces, intermediate reviews to coordinate developing systems and details, and late reviews to resolve remaining inconsistencies and verify prior comments. The milestone names and required deliverables come from the project agreement—not a universal percentage rule.
Define what the percentage means for this project
Agree on a submission matrix before the review: which disciplines participate, which drawings and references are expected, what is still provisional, and what decisions should be made. A package can be advanced in one discipline and preliminary in another.
The matrix below is a planning aid for document review. It is not a contract requirement, a universal definition of design completeness, or a substitute for an owner’s submission standard. Design-build, phased permits, renovations, and specialist packages can use different checkpoints.
For an example of project-specific requirements, NASA’s Facility Project Requirements, section 3.6, defines 30/60/90 submissions for its design-bid-build work and treats other delivery approaches differently. Use the requirements that actually govern your project.
Use a milestone matrix to set expectations
| Checkpoint | Bring to the review | Questions to resolve | Useful output |
|---|---|---|---|
| Early / around 30% | Program and criteria, available site information, developing layouts and system concepts, known constraints. | Are requirements understood? Do major systems and spatial interfaces have a plausible place in the design? Which assumptions need validation? | A decision and assumption register with owners and next review dates. |
| Intermediate / around 60% | Developing consultant drawings, schedules, outline or draft specifications, calculations and details appropriate to the agreed scope. | Do disciplines describe compatible locations, levels, openings, service needs, and installation conditions? | Coordinated interface decisions and a log of missing or provisional information. |
| Late / around 90% | The near-complete issue required by the agreement, current specifications, supporting references, and earlier comments. | Do plans, schedules, details, and specifications agree? Are unresolved decisions and prior comments reflected in the package? | Specific corrections, responsible designers, and a plan to verify the final issue. |
| Release / final check | The intended issue, document register, resolved comments, and required submission information. | Did the agreed changes reach all affected documents? Are remaining limitations and required approvals identified? | A checked issue register and a traceable record of closure and remaining actions. |
Early review: expose decisions before details multiply
Start with requirements, constraints, and the major interfaces between disciplines. Identify what the owner needs the facility to do, which conditions are known, and which assumptions need investigation. Review the stated design criteria with the responsible professionals.
Do not classify every undeveloped detail as a defect. Ask whether its absence prevents the decision this milestone is meant to support. Record genuinely missing prerequisites separately from work scheduled for a later issue, with an owner and a date to return to it.
Intermediate review: connect the developing systems
Trace the interfaces now described in more than one document. An equipment location may establish a structural support, utility connection, access requirement, and envelope opening. The review should connect these dependencies before each discipline completes its detail in isolation.
Compare datums and units before reporting elevation conflicts. Match equipment tags across plans, schedules, and diagrams. Check that preliminary specifications are being edited for the project as decisions become firm. Ask each affected discipline to identify the information it still needs from others.
Late review: reconcile the package and earlier comments
Focus on consistency across the intended issue: drawings against specifications, references to details, schedule requirements, and the incorporation of earlier decisions. Follow a corrected requirement through all dependent documents rather than checking only the sheet mentioned in the response.
Keep unresolved owner selections, deferred work, and proposed changes visible. A percentage label should not hide an open decision. Agree which items prevent the intended release and which can proceed under the project’s documented process.
Use the full review checklist for coverage and the review process guide for response and closure responsibilities.
Carry one review record between milestones
Keep the original question, source issue, response, affected revisions, and verification evidence together. When a comment moves to a later milestone, state what is missing and who owns the next step. Do not erase the context by replacing a detailed comment with “carried forward.”
A new issue can also change a previously settled requirement. Reopen the affected question and check its dependencies. A DD-to-CD change narrative explains what changed between issues; this milestone plan explains what each review is meant to achieve.
Match the AI scope to the maturity of the set
When using Groundbook, identify the milestone and known exclusions in the review instructions. Separate files to check from supporting references, and explain which elements are provisional. Review potential findings in that context before treating an incomplete early-stage detail as an omission.
For a later issue, include the relevant current requirements and prioritize the schedules, details, and interfaces affected by the revision. The project team still assesses design adequacy and decides whether the package is ready for its next use.