Practical checklist
What this article covers
A role matrix for what changes are clouded, reviewed and issued; office-specific rules are decisions to agree, not universal standards.
Agree who identifies a change, who applies its revision marking, who checks the result and who authorizes the issue. These actions may involve the same person on a small project, but they should remain distinct decisions.
This suggested matrix organizes responsibilities without assigning legal liability or assuming every project uses the same clouding convention.
Distinguish the mark from the decision
Autodesk describes revision clouds as indicators of changed design areas. Trimble's Novapoint revision-cloud help describes drawing the mark and adjusting its arc lengths.
Those are software capabilities. Neither documentation page establishes who may approve your project's design changes, when a drawing may be issued or which historical marks your office retains.
Assign responsibilities before the markup round
| Action | Assignment to agree | Evidence to keep |
|---|---|---|
| Identify the change | Person providing the authorized direction | Instruction or decision reference |
| Apply the marking | Production author following the project convention | Drawing location and associated revision |
| Check coverage | Reviewer of the changed locations | Check result and omissions |
| Confirm issue readiness | Person responsible for the package review | Exact package and unresolved items |
| Authorize release | Authority identified by the project | Recorded release decision and intended use |
| Treat older marks | Owner of the revision convention | Retention or visibility instruction |
Add actual names or project roles when using the matrix. Do not assume the drafter gains issue authority merely by being able to edit revision properties.
Agree how a reviewer should identify the change if the marking is ambiguous. An unexplained cloud needs clarification; a clearly identified draft cloud can be reviewed without pretending it is already an issued revision.
Hypothetical example: the right change has the wrong revision reference
In this fictional documentation round, an approved view-title update belongs to revision R3, but its cloud is associated with R2 in the working drawing.
The reviewer records the location and the mismatch. The assigned production author corrects the reference according to the project instructions, then returns the drawing for checking. The checker verifies both the title change and its revision identification.
This is a production correction, not a new design approval. Whether the package is ready to issue remains a separate recorded decision.
Keep supporting answers connected
When a change follows an RFI response, use the RFI handover log to identify the response version and affected outputs. Do not infer an instruction simply because a cloud surrounds an area mentioned in an unanswered query.
If the team disagrees about removing or hiding old marks, ask the convention owner. Do not delete historical information as a generic cleanup step.
Include the matrix in the delivery agreement
Use the remote-team drawing issue checklist to connect revision checks with package readiness. Record remaining questions beside the actual file revision rather than relying on a broad “all checked” message.
Nest's outsourcing quality-control guide gives wider review context. For construction documentation support, specify the marking convention, allowed production changes and the person retaining issue decisions.
Related guides and services
Keep the production handoff connected to the wider workflow:
Need help with current production work?
Tell us which drawings, models, visualizations, or review packages need attention. We can review the assignment, confirm availability, and explain whether a project package or dedicated monthly support fits.
Book a project callSend a project brief