Module 10: Design Coordination, Markups, RFIs, and Revision Management
Learning Objectives
- Distinguish design reviews, redlines, markups, coordination comments, RFIs, technical queries, decisions, action items, transmittals, registers, revisions, responses, verification, and closure.
- Apply a controlled issue lifecycle from discovery through authorized decision, revision, verification, and closeout.
- Select the appropriate communication mechanism for a design issue without turning every coordination matter into an RFI.
- Maintain traceable issue, drawing, and document records that identify responsibility, status, due dates, responses, and revision references.
- Explain why screenshots, chat messages, informal calls, and uncontrolled copies are inadequate as the final record of consequential design decisions.
Design Review
A design review is a structured examination of design information against the project brief, applicable requirements, discipline criteria, interfaces, constructability needs, and issue-stage objectives.
Redline
A redline is a marked correction or instruction placed on a drawing, print, PDF, model view, or other design representation to communicate a proposed change or review finding. A redline is not automatically an issued revision.
Markup
A markup is an annotation added to a document or model view to communicate comments, questions, proposed changes, dimensions, emphasis, or review observations. Redlines are one form of markup.
Coordination Comment
A coordination comment records an interface issue, inconsistency, clash, missing input, or coordination request that can be addressed within the project's design-coordination process without necessarily requiring a formal RFI.
Request for Information
A request for information, or RFI, is a controlled request for clarification or missing information when the requester cannot proceed reliably from the current contract or design information and an authorized response is required under the project's communication procedure.
Technical Query
A technical query is a structured technical question seeking clarification, confirmation, or specialist input. Projects may treat technical queries and RFIs differently; the governing contract and communication procedure control the formal meaning.
Decision
A decision is an authorized determination that resolves a question, selects an option, accepts or rejects a proposal, or establishes the basis for subsequent work. The decision record should identify who had authority to make it and what information it affects.
Action Item
An action item is a specific task assigned to a responsible person or discipline with a required output, status, and due date. An action item is not itself the technical decision unless the assigned task includes authorized decision-making.
Transmittal
A transmittal is a controlled record of information formally sent from one party to another, commonly identifying the documents, revisions, purpose or status of issue, date, sender, recipient, and related references.
Drawing Register
A drawing register is a controlled index of project drawings that typically records drawing number, title, discipline, current revision, status, issue date, and other document-control metadata.
Issue Register
An issue register is a structured record of coordination or design issues containing identifiers, descriptions, locations, references, ownership, priority, status, responses, decisions, revision links, and closure evidence.
Revision
A revision is an identified change to controlled information that creates a new traceable state of a drawing, model, schedule, specification, or other project document.
Superseded Document
A superseded document is a previously valid issue that has been replaced by a later controlled issue and must not be used as the current instruction unless specifically required for historical or contractual reference.
Current Document
A current document is the latest authorized information state for the defined purpose and status within the project's document-control system. Current does not necessarily mean approved for every use.
Response
A response is the recorded answer, instruction, clarification, or disposition provided to an issue, RFI, query, or review comment by the appropriate responsible or authorized party.
Verification
Verification is the check that the agreed response or decision has been correctly incorporated into all affected information and that consequential cross-discipline impacts have been addressed.
Closure
Closure is the controlled status indicating that an issue's required response, authorized decision, implementation, and verification have been completed to the project's defined acceptance criteria.
A Coordination Record Has Three Different Layers
Professional coordination is clearer when the team separates:
- observation: what is wrong, unclear, conflicting, missing, or risky;
- decision: what the authorized party has determined should happen;
- implementation evidence: which drawings, models, schedules, specifications, or other records were revised and then verified.
A comment such as "move duct" is incomplete if it does not establish why, who is authorized to confirm the new route, what other disciplines are affected, and which controlled revision implements the change.
Observation–Decision–Implementation Chain
A coordination issue is not closed merely because someone has replied; the authorized decision must be implemented and verified in the affected information.
Minimum Information for a Useful Coordination Issue
A coordination issue should normally record enough information for another team member to find, understand, assign, resolve, and verify it. Useful fields include:
- unique issue ID;
- concise title and full description;
- building, level, room, grid, zone, or coordinate location;
- affected drawing, sheet, detail, model element, specification, or schedule reference;
- current source revision or issue status;
- responsible discipline or named owner;
- related disciplines or reviewers;
- required decision or action;
- priority or severity;
- due date or required-by date;
- status;
- response and decision;
- supporting attachments or viewpoints where useful;
- implemented revision reference;
- verifier and verification date;
- closure note.
The exact schema may vary, but the record must remain searchable and traceable.
Priority and Severity Should Describe Different Questions
Projects often confuse priority and severity.
- Severity describes the consequence if the issue remains unresolved, such as a life-safety conflict, major geometry conflict, constructability problem, documentation inconsistency, or low-impact drafting defect.
- Priority describes how urgently the issue must be acted upon relative to programme, procurement, authority review, site work, or other dependencies.
A high-severity issue discovered early may have a different action priority than a lower-severity issue blocking tomorrow's concrete pour. Projects should define their own scales and escalation rules.
Coordination Comment, Technical Query, or RFI?
Use the least formal mechanism that still preserves the required authority, traceability, and contractual process.
A coordination comment is often appropriate when the issue is internal to the design team's normal coordination process and the responsible discipline can resolve it within its scope.
A technical query may be appropriate when specialist clarification is needed but the project has a defined query route distinct from formal RFIs.
An RFI is appropriate when required information is missing, contradictory, or unclear and the requester needs an authorized clarification under the project's formal procedure before proceeding.
Do not create an RFI solely because an issue is inconvenient or because two disciplines have not yet completed routine coordination. Conversely, do not keep a consequential ambiguity in informal chat when the contract or project procedure requires formal clarification.
RFI Versus Coordination-Comment Decision
Choose the communication path by the authority and record required, not by habit or software.
- Internal interface can be resolved by responsible design discipline
- Normal clash or coordination comment
- No change to contractual interpretation required
- Decision remains inside agreed design scope
- Current information is missing or contradictory
- Requester cannot proceed reliably
- Authorized clarification is required
- Project procedure or contract requires formal RFI
An RFI Is Not a Design-Authority Shortcut
Issuing an RFI does not transfer design responsibility to the requester or automatically authorize the responder to change another professional's design. The response must come from the party with the relevant contractual and professional authority, and any resulting design change must be incorporated through controlled revision.
Markup Quality Determines Resolution Speed
A useful markup should identify:
- the exact location and drawing or model reference;
- the source revision being reviewed;
- the observed condition;
- the proposed correction or question;
- dimensions or geometry only when verified and within the reviewer's authority;
- related issue ID;
- responsible discipline;
- any known downstream impact.
Avoid dense freehand comments with ambiguous arrows, unlabeled screenshots, or marks separated from the source drawing number and revision. A markup is an aid to communication, not the authoritative revised drawing.
Meeting Minutes Are Not a Substitute for Controlled Design Information
Coordination meetings are useful for discussing interfaces and reaching decisions, but the record should clearly distinguish:
- information discussed;
- decision reached;
- person or role authorizing the decision;
- actions assigned;
- due dates;
- affected documents;
- unresolved items;
- references to issues, RFIs, or revision numbers.
A decision in meeting minutes still needs to be incorporated into the controlled drawings, models, schedules, or specifications that govern subsequent work.
Why Screenshots and Chat Messages Are Weak Final Records
Screenshots, instant messages, and informal calls can be useful during rapid coordination, but they are weak as final decision records because they may omit:
- project and discipline context;
- drawing or model revision;
- exact location;
- complete conversation history;
- decision authority;
- status and due date;
- affected documents;
- final implementation;
- verification and closure.
A screenshot may accompany a controlled issue, but the issue record should contain the searchable metadata and authoritative response.
Do Not Treat 'Replied' as 'Resolved'
A response can be incomplete, unauthorized, technically inconsistent, or not yet incorporated into the drawings. An issue reaches closure only after the required decision is authorized, affected information is revised, cross-discipline impacts are checked, and the implementation is verified.
Controlled Coordination Issue Lifecycle
- Discover the issue through review, clash detection, site feedback, calculation, model federation, drawing comparison, or another reliable source.
- Log the issue with a unique ID, location, current drawing or model reference, description, responsible discipline, priority, and due date.
- Assign the issue to the party responsible for reviewing and proposing a response.
- Review the relevant design basis, constraints, codes, specifications, interfaces, and previous decisions.
- Record a proposed response or options without presenting an unauthorized proposal as a final decision.
- Obtain the required decision from the party with the appropriate contractual and professional authority.
- Revise every affected drawing, model, schedule, specification, register, or related information container.
- Check cross-discipline effects, including spatial coordination, structural interfaces, access, fire or life-safety interfaces, quantities, procurement, and constructability where relevant.
- Verify that the agreed response is correctly implemented in the referenced revision.
- Close the issue with the implemented revision and verification evidence, while retaining the history for audit and future reference.
Design Coordination Issue Lifecycle
Issues move from discovery to closure only through an authorized decision, controlled revision, cross-discipline check, and verification.
A response is not closure. The responsible party must authorize the decision where required, the affected controlled information must be revised, and implementation must be verified before the issue is closed.
Issue discovered → Log ID, location, reference, owner, priority and due date; Log ID, location, reference, owner, priority and due date → Responsible discipline reviews evidence and interfaces; Responsible discipline reviews evidence and interfaces → Propose response or clarification; Propose response or clarification → Required decision authorized?; Required decision authorized? — Yes → Revise all affected controlled information; Required decision authorized? — No → Responsible discipline reviews evidence and interfaces; Revise all affected controlled information → Check cross-discipline impacts; Check cross-discipline impacts → Implementation verified?; Implementation verified? — Yes → Close issue with revision evidence; Implementation verified? — No → Revise all affected controlled information
- Issue discovered: terminator
- Log ID, location, reference, owner, priority and due date: data
- Responsible discipline reviews evidence and interfaces: process
- Propose response or clarification: document
- Required decision authorized?: decision
- Revise all affected controlled information: process
- Check cross-discipline impacts: process
- Implementation verified?: decision
- Close issue with revision evidence: terminator
Revision Control Preserves the Chain of Authority
A controlled revision system should allow a reviewer to answer:
- What changed?
- Why did it change?
- Who prepared, checked, and authorized it?
- Which prior revision did it replace?
- What status does this issue carry?
- To whom was it transmitted?
- Which related documents were changed with it?
- Which revision is currently valid for the intended use?
Revision identifiers are project conventions. Numeric, alphabetic, or coded schemes can all work if the project defines them consistently and prevents ambiguous reuse.
Revision-Control Sequence
A design change becomes usable only after preparation, checking, authorization, issue, and controlled replacement of the prior state.
Revision, Status Code, Purpose, and CDE Workflow State Are Different
These controls answer different questions and should not be collapsed into one field:
- revision or version: which identified information state is this?
- status or suitability code: what use is permitted for this information?
- purpose of issue: why is the information being transmitted or published?
- common data environment workflow state: where is the information within the controlled production workflow?
- issue date: when was that controlled information state formally issued or transmitted?
The exact codes and labels are project-specific. ISO 19650 implementations commonly distinguish controlled workflow states equivalent to work in progress, shared, published/authorized for the defined purpose, and archived; organizations may implement different labels while preserving the same control intent. A workflow state is not a substitute for a suitability/status code, and a purpose such as review, coordination, construction, or record information should not be inferred from the revision identifier alone.
A numerically or alphabetically later revision can still be unsuitable for construction if its permitted use is only coordination, review, or another restricted purpose.
Document-Control Metadata Map
Revision, permitted use, issue purpose, workflow state, and issue date are related controls but answer different questions.
Operational CDE State Example
Consider a coordinated pump-room layout. The same information container can carry several independent metadata values:
- revision/version: 07 — the seventh identified controlled state under the project's convention;
- status/suitability: “coordination use only” — it is not yet authorized for construction;
- purpose of issue: multidisciplinary coordination review;
- workflow state: shared — it has left the originating team's work-in-progress area for controlled coordination;
- issue date: 2026-10-05 — the date this particular controlled state was issued.
After comments are resolved, a later revision may move to a published or otherwise authorized workflow state for a defined use. Its revision, status/suitability, purpose, and issue date must each be updated according to the project information standard. Do not copy these example labels or numbering as universal ISO codes.
Working information should remain within the originating team's controlled production space; shared information is exposed for coordination or review; published/authorized information is released for its stated use; and archived information preserves superseded history. The common data environment should make those distinctions visible and prevent accidental use of an inappropriate state.
Drawing Registers and Transmittals Work Together
The drawing register describes the controlled population of drawings and their current metadata. A transmittal records a particular act of sending specified documents to specified recipients for a specified purpose.
A good document-control process uses these records together:
- the register identifies the current controlled state;
- the transmittal proves what was issued, when, to whom, and for what purpose;
- the receiving party can compare the issue against the register;
- superseded information remains historically traceable without appearing current.
BCF and Structured Model-Based Issue Exchange
For BIM projects, the buildingSMART BIM Collaboration Format, or BCF, provides an open mechanism for exchanging model-based issues and viewpoints between compatible tools. It can associate an issue with model objects, location viewpoints, comments, assignment, and status without requiring every coordination message to be embedded in a proprietary model file.
BCF is a useful technology for structured issue exchange, but it does not define the project's contractual authority, approval matrix, or professional responsibilities. The project still needs agreed roles, statuses, naming, response times, and closure criteria.
Responsibility and Status Matrix
Every issue needs an owner and a state; responsibility and progress are separate dimensions.
Document-Control Terminology Is Project-Specific
International information-management standards provide principles for controlled information exchange, versioning, and organization, but exact revision codes, status codes, RFI forms, transmittal formats, response times, and approval workflows depend on the contract, employer or owner requirements, common data environment, and project execution procedures.
Issue Review Case: Reopen Closure After an Upstream Revision
A beam–service issue was closed against two identified revisions. A later structural issue changes the beam depth. Preserve the earlier closure record, but reopen the affected coordination check against the new basis.
Record the trigger revision, impacted decision, responsible reviewers, and documents requiring verification. The prior reply remains historical evidence; it does not automatically authorize a solution against changed geometry. Close the reopened issue only after the approved resolution is incorporated and checked in the current information set. This makes closure revision-specific and prevents a dashboard's green status from concealing a stale decision.
- A coordination issue progresses through observation, authorized decision, controlled implementation, verification, and closure.
- Coordination comments, technical queries, and RFIs are related but not interchangeable; use the route required by the project's authority and contractual process.
- A reply is not closure, and a markup is not an issued revision.
- Drawing registers, transmittals, issue registers, revision identifiers, and document statuses create the audit trail needed to know what information is current and suitable for use.
- Informal messages can accelerate discussion, but consequential decisions must be captured in controlled project records and incorporated into the authoritative information.
References
- ISO 19650-1:2018 — Information management using BIM: Concepts and principles — International Organization for Standardization; framework for exchanging, recording, versioning, and organizing project information.
- ISO 19650-2:2018 — Information management using BIM: Delivery phase of the assets — International Organization for Standardization; managed information processes and exchanges during delivery.
- ISO 19650-4:2022 — Information management using BIM: Information exchange — International Organization for Standardization; detailed process and criteria for information exchange.
- ISO 11442:2006 — Technical product documentation: Document management — International Organization for Standardization; basic rules for management of technical documents.
- BIM Collaboration Format (BCF) — buildingSMART International; openBIM standard for model-based issue communication and coordination.