Document review on AEC and EPC projects runs on two small code systems that everyone uses and almost nobody defines:
Confusing the two — or using them loosely — is a quiet source of schedule slippage and contractual risk. Here is how each set works and the rules that keep them meaningful.
| Code | Common Label | Meaning | Can Work Proceed? |
|---|---|---|---|
| A / Code 1 | Approved | No comments; document accepted as submitted | Yes |
| B / Code 2 | Approved with comments | Minor comments; incorporate and resubmit for record | Yes, incorporating comments |
| C / Code 3 | Revise and resubmit | Significant comments; document not accepted | No |
| D / Code 4 | Rejected | Fundamental non-compliance or wrong basis | No |
Exact labels vary by contract (some projects use "Reviewed — no exceptions taken" style language), but the structure is near-universal. Three rules keep review codes honest:
Each comment in a comment resolution sheet gets its own response code from the document author:
| Response Code | Meaning | What Happens Next |
|---|---|---|
| Accepted | Author agrees; change will be made | Reviewer verifies the change in the next revision, then closes |
| Accepted with Comment | Agrees in substance, with a qualification | Reviewer checks the qualification is acceptable |
| Rejected | Author disagrees, with justification | Reviewer accepts the justification or escalates to discussion |
| Clarification Needed | Comment is ambiguous or lacks basis | Reviewer restates the comment as a verifiable requirement |
The critical discipline: a response is not a resolution. "Accepted" moves a comment to Answered, not Closed. Closure happens only when the reviewer verifies the change in the revised document. Teams that let authors close their own comments have a comment log that proves nothing — the permission model we describe in Role-Based Permissions in AEC Collaboration.
A well-justified rejection is a healthy outcome — it means the requirement was tested and the document survived. What is not healthy is a rejection that ends the conversation: every rejected comment needs either the reviewer's explicit acceptance of the justification or an escalation to a named decision-maker. Rejections that just sit there are open disputes wearing a closed costume, and they resurface during commissioning or claims.
In a spreadsheet, code discipline depends entirely on people: nothing stops an author from typing "Closed", nothing flags a B-coded document with open comments, and nothing carries an unresolved rejection into the next revision. This is exactly the class of problem we built Contrat.io to remove — response codes and statuses are enforced by role, revisions inherit open comments automatically, and the code history of every document is a click away. Try it free for 30 days, no credit card required. For the fuller picture of a compliant review record, see The Ultimate Guide to EPC Document Control.