Construction document control field guide: drawings, revisions, and the current set

What document control is, and why the wrong sheet is so expensive

Construction document control is the practice of keeping everyone building from the current, correct documents and tracking how those documents change. The current set is the latest drawings and specifications with every revision, addendum, ASI, and bulletin incorporated. Document control keeps that set defined, controlled, and in front of the people who build from it, and it tracks the flow of RFIs, submittals, and changes so a question or a change does not quietly leave half the team working from old paper.

Building from the wrong set is one of the most expensive mistakes on a job, and it rarely looks like a mistake while it is happening. The crew pulls a conduit run, sets a panel, or cores a slab off a sheet that was superseded three weeks ago, and the work looks clean. The cost shows up later as rework, as a clash with another trade that built off the current sheet, and as the dispute over who owns the difference. A single source of truth, clear version control, and disciplined distribution are what keep that from happening.

Document control sits next to two disciplines this guide does not repeat. How a question becomes an answer and how a product gets approved before it is ordered belong to the RFI and submittal process, covered in that guide. How the sequence and timing hold together belongs to the scheduling guide. This guide is about the documents themselves: which set is current, how a change gets into it, and how you keep the field off the superseded sheet.

What building from an old drawing actually costs

An out-of-date drawing does not fail loudly. It produces work that is correct against a sheet nobody should be using anymore, which is the worst kind of error because everyone involved was doing their job. The electrician roughs in the wall where revision 2 showed the panel. Revision 4 moved it eight feet and changed the feeder size. Now the rough-in is wrong, the inspector will not pass it, and the fix is demo and re-pull, not a markup.

The cost lands in three places. There is the direct rework: tearing out and redoing what was built to the stale sheet. There is the conflict with the trades that did build off the current set, because their work no longer lines up with yours, and someone has to lose. And there is the dispute, because the question of who pays for the rework turns on whether the current document was actually distributed and acknowledged, which is exactly what document control records.

This is why the field must have the current set, not a current set. The most common version of this failure is not a missing drawing. It is a drawing that exists, looks official, and is one revision behind. Make the current set unmistakable and make the old one impossible to confuse for it, or you will pay for the difference.

The single source of truth

A single source of truth is one current, controlled set that everyone works from, instead of scattered copies, emailed PDFs, and the marked-up roll on the truck dashboard. There is exactly one place where the current documents live, one place that gets updated when something changes, and one place the field goes to pull a sheet. Everything else is a copy, and a copy is only as good as the day it was made.

Scattered copies are how the field ends up a revision behind without anyone deciding to be. Someone prints the set for a meeting, the set revises the next week, and the printout keeps getting used because it is right there. Somebody forwards a sketch by email and it becomes the working answer for a crew that never sees the formal revision that supersedes it. None of this is negligence. It is what happens when there is no controlled set, only documents floating around.

The discipline is simple to state and hard to hold: the controlled set is the only set. When a sheet changes, it changes in the one source, the old version comes down, and the field pulls from the source rather than from a copy of a copy. If your people cannot point to the one place that is authoritative, you do not have a single source of truth. You have a pile of documents that mostly agree.

Version control and the current revision

Version control is the discipline of tracking how a document changes over the life of the job so anyone can tell, at a glance, whether they are holding the current version. Every drawing carries a revision: a number or letter and a date that says which issue this is. The current revision supersedes the one before it. Revision 4 of sheet E-401 replaces revision 3 for every purpose, and revision 3 is now history, not a second opinion.

Two things make version control real instead of decorative. The first is that the revision and date are clear on the sheet and tracked in a log, so the current issue of every sheet is known and findable. The second is that the supersession is enforced: when revision 4 publishes, revision 3 comes out of circulation. A revision number that nobody enforces is just a label on a sheet that is still sitting in the field.

The number that matters is the one on the sheet in the worker's hand against the one in the controlled set. If they do not match, stop. The most expensive minutes on a job are the ones spent installing confidently from a sheet that was replaced while it was in your bag. Check the rev before you build, not after the inspector flags it.

Pulling and voiding superseded sheets

A superseded sheet is an old revision that a newer one has replaced, and the most dangerous document on a job is a superseded sheet that still looks current. It has a title block, a sheet number, and clean lines. Nothing about it announces that it is wrong. The only thing that makes it safe is taking it out of circulation the moment its replacement issues.

Pull the old sheets and mark them VOID. On a paper set, that means physically removing the superseded print and stamping or writing VOID across any copy that has to be kept for the record. On a digital platform, it means the system archives the prior revision and watermarks it so a worker who opens it sees, in large letters, that it is not the current issue. Either way, the goal is that nobody can mistake the old sheet for the live one.

Keep the superseded versions in the archive, do not destroy them, because the history is part of the record and you will need to show what changed and when. But keep them out of the build. The archive is for proving what happened. The current set is for building. Mixing the two is how a voided sheet ends up back in the field.

Reading a drawing revision: the cloud, the delta, and the rev block

A drawing revision is a reissue of a sheet with changes, and the sheet tells you where to look if you know how to read it. Three marks do the work. The revision cloud is the freeform outline drawn around the area that changed. The delta is the triangle, usually numbered, sitting next to the cloud to flag which revision made that change. The revision block, in or near the title block, lists each revision by number, date, and a short description of what changed.

Read the revision before you build from it. A reissued sheet does not mean the whole sheet changed. It means something on it did, and the cloud and delta point you to it. The mistake is treating a new revision as a fresh sheet to be re-read from scratch, or worse, assuming nothing important moved because the sheet looks familiar. Find the clouds, match each delta to the revision block, and confirm what actually changed against what you have already built or are about to.

Not every change comes with a cloud, and not every cloud is complete, which is why the revision description and the change document behind it matter. When the rev block cites an ASI or a bulletin number, go read that document. The cloud shows you where. The change document tells you why and how, and sometimes it carries detail the sheet does not.

Addenda, ASIs, bulletins, and CCDs: the change documents

Drawings and specs change by more than a clean reissue. They also change through documents that modify the contract documents, and each kind has a specific job. The names and the exact handling vary with the contract form, so confirm what your contract calls them and how it processes each one, but the families are consistent across most jobs.

An addendum changes the bid or procurement documents before the contract is executed, typically issued during bidding to answer bidder questions, correct errors, or add requirements. Once the contract is signed, changes come through other documents. An ASI, an architect's supplemental instruction, is issued by the architect to clarify or make a minor change to the contract documents that does not, by its own terms, change the contract sum or time. A bulletin, issued after bidding, describes a change that will likely affect cost or schedule and asks the contractor to price it. A construction change directive, AIA form G714, directs the contractor to proceed with a change before the cost and time have been agreed, when an agreement cannot be reached up front.

The discipline that ties them together: every one of these gets incorporated into the set. An ASI that nobody folds into the drawings is an ASI the field will not build to. Read each change document, mark the affected sheets, update the controlled set, and log it so the next person can trace the change from the document to the drawing. A change that lives only in someone's email is a change that did not happen, as far as the field is concerned.

The document flow: question to answer to change

Document control is not just about the drawings sitting still. It is about the flow that keeps changing them, and that flow has a shape. An RFI asks a question and gets an answer, and the answer sometimes changes the work. A submittal gets reviewed and comes back as an approved set the field can build to. A change becomes revised drawings, a new revision, or a change document that has to be incorporated. Document control is what tracks each of these from open to closed and gets the result into the set.

These three streams are the engine of how a set evolves on a live job, and they are covered in depth in the RFI and submittal process guide. The point here is the handoff. When an RFI answer, a submittal review, or a change produces a new instruction, that instruction has to land in the controlled set and reach the field, or the flow stalls at the last step and the field keeps building from what it had.

The failure is almost never that the question never got asked or the submittal never got reviewed. It is that the answer came back and nobody closed the loop to the drawings. The RFI is answered, the answer changes a dimension, and the sheet never gets the revision, so the field installs to the old number. Track the flow all the way to the sheet. An answer that does not reach the current set is an answer that did not arrive.

Tying the RFI answer back to the drawing

An RFI answer often changes the work, and document control is what makes sure the change reaches the sheet instead of living in the RFI log. When the design team answers an RFI with a new dimension, a routing change, or a clarification that contradicts what the drawing shows, that answer now governs, but the drawing still says the old thing until someone updates it. Until then you have two sources that disagree, and the field will follow whichever one it happens to have.

The discipline is to tie each RFI answer to the drawings it affects. Note the RFI number on the sheet, carry the answer into the next revision, and log which sheets a given RFI touched so the change is traceable both ways. A reviewer should be able to start from a sheet and find every RFI and change document that shaped it, and start from an RFI and find every sheet it changed.

Writing and tracking the RFI itself, including the aging that keeps an open question from stalling the crew, is covered in the RFI and submittal process guide. The document-control job is the back half: making the answer change the set, not just the log.

Building from approved submittals, not design intent alone

The field builds from the approved submittal and the approved shop drawings, not from the design drawings alone. The contract drawings show design intent: what the system is supposed to do and roughly how it fits. The shop drawings and product submittals show what is actually being installed, with the real dimensions, the real equipment, and the real connections, reviewed and stamped before anything is ordered or fabricated. When the two differ in detail, the approved submittal is what the installation has to match.

Document control keeps the approved submittals as part of the controlled set, in the field, current. An installer who fabricates to the design drawing because the approved shop drawing was sitting in an office inbox will build something that does not match the coordinated, reviewed detail, and the rework is on the contractor. The approved set has to be as available to the field as the drawings are.

Watch the revision on submittals the same way you watch it on drawings. A shop drawing that came back marked revise and resubmit is not approved, and building from it is building from a rejected document. The submittal register that tracks review status and approval is covered in the RFI and submittal process guide. Here the rule is narrow: build from approved, confirm the revision, and keep the approved set where the field can reach it.

Transmittals and the distribution log

A transmittal is the record of what was sent, to whom, and when. Every time documents move, a drawing set, a revision, an addendum, a reviewed submittal, the transmittal captures the sender, the recipient, the date, and exactly which documents and revisions went out. It is the receipt for the document handoff, and it is one of the most useful records on the job when a question comes up about whether the current set actually reached the people who needed it.

The transmittal answers the question that decides most document disputes: did the field have the current document at the time the work was built? If revision 4 went out on a transmittal dated the third and the rework was built off revision 3 on the tenth, the transmittal settles who owns the difference. Without it, the argument is two memories against each other, and memory loses to paper every time.

Keep the transmittals as a running distribution log, not as loose confirmations. The log shows the full history of what was issued and received across the job, so you can reconstruct who had which revision on any date. On a platform, this is the issue and distribution history. On paper, it is the transmittal file. Either way, if it is not logged, it did not happen.

Getting the current documents to the field

Distribution is getting the current documents to the people who build from them: the crew, the foreman, the subs, the inspector. Controlling the set in the office does nothing if the field is working from last month's print. The controlled distribution list says who needs what, and the job is to push every revision and change document to that list the moment it issues, then confirm it landed.

Match the document to the recipient. The electrical foreman needs the current electrical sheets, the relevant architectural and structural backgrounds for coordination, the approved submittals for what is being installed, and the change documents that touched any of it. A sub who only sees their own discipline will build a clash with the trade whose sheet they never got. Distribution is partly a coordination problem: the right people get the right current documents, and the list is kept current as crews and scopes change.

The weak link is the last hundred feet, from the office to the worker's hands. A revision sitting in a shared folder that the crew does not know about is not distributed. Distribution is not complete until the current document is in front of the person installing the work and the old one is gone. Confirm it reached them, do not assume it did.

File naming and sheet numbering conventions

Consistent file naming and sheet numbering is what makes the current document findable, and findable is what keeps the field on the right sheet. A naming convention puts the discipline, the sheet number, and the revision in the file name in a fixed order, so E-401 revision 4 reads the same way every time and sorts next to its siblings instead of scattering. When the rev is in the name, you can tell the current file from the old one without opening either.

Sheet numbering usually follows the discipline designators most of the industry shares: A for architectural, S for structural, E for electrical, M for mechanical, P for plumbing, and so on, with a number that places the sheet within its discipline. The exact scheme follows the project standard and the CAD or BIM standard the design team works to, so adopt the project convention rather than inventing one. The value is consistency, not cleverness.

The failure that naming prevents is the duplicate-with-a-different-name problem: the same sheet saved three times as E401_final, E401_FINAL_v2, and E401_use_this. Nobody can tell which is current, so somebody picks wrong. Put the revision in the name, retire the old file when the new one lands, and the question of which file to open answers itself.

The common data environment and the document platform

A common data environment, a CDE, is the single agreed place where project documents and data are collected, managed, and shared, so the whole team works from one controlled source instead of separate folders. The term comes from the ISO 19650 information-management standard, which defines the CDE as the single source of information for the project and organizes documents through states: work in progress, shared, published, and archived. In practice the CDE is usually a cloud document platform, commonly Procore or Autodesk Construction Cloud, that holds the current set, tracks revisions, and pushes updates out.

The platform earns its keep by automating the parts of version control that people forget. When a new revision publishes, the system archives the prior version, marks it superseded, and updates what the field sees, so the current set stays current without someone manually pulling every old print. It logs who issued what to whom and when, which is the transmittal history built in. And it puts the current documents on a phone or tablet in the field, which is where the build actually happens.

A field tool like FieldOS lives at that last step, getting the current documents and the work that depends on them into the hands of the crew and capturing what happens back. The platform is only worth what reaches the field. A CDE that the office uses and the crew cannot open has solved the office's problem and left the field on paper, which is where the wrong-sheet failures start.

Field access: the crew pulls the current sheet on a device

Field access means the crew pulls the current sheet on a device, from the controlled source, instead of building from a paper set that drifted out of date the week it was printed. Paper-set drift is the oldest version-control problem there is. The set is printed, the job revises, and the print keeps getting used because reprinting and redistributing a full set is slow and expensive. A device pulling from the source does not drift, because it shows the current revision every time it is opened.

The win is that the current document and the field are in the same place. The worker confirms the revision against the live set on the spot, marks up the device where a field condition differs, and that markup is captured against the right sheet instead of on a print that gets lost. The same device is where the as-built gets built as the work goes in, which is the difference between an as-built that is real and one that gets reconstructed from memory at closeout.

Make field access the default and the wrong-sheet failure gets hard to commit. The crew cannot install from a superseded sheet if the device only serves the current one. This is where a field tool like FieldOS does the most good: it is the live set in the worker's hand and the place the markup and the as-built start. Paper has its place for some inspections and some markups, but the source of truth should be the controlled set, not the roll on the dashboard.

Field markups and redlines

Field markups, the redlines, are the changes the crew records on the sheet as the work goes in: the route that moved around an unexpected obstruction, the device that landed a few feet off plan, the connection that got made differently than drawn. Capture them on the sheet, against the right revision, and keep them with that sheet rather than on a loose print that nobody can match back later.

The reason redlines matter is that they feed the as-built. A markup made the day the conduit was actually run is accurate. The same change reconstructed three months later from memory is a guess. Keeping the markup with the current sheet, dated and attributed, means the as-built builds itself as the job runs instead of becoming a closeout scramble.

Do not confuse a field markup with a change to the design. A redline records what was installed. If the field condition needs a design decision, that is an RFI, and the answer comes back through the flow and into a revision. The markup documents reality. The RFI changes the documents. Mixing the two, marking up a sheet to reflect a change that was never approved, is how undocumented changes end up in the record as if they were authorized.

The as-built record: mark it as you go

The as-built record set is the marked-up set that shows what was actually built, as opposed to what was drawn. The contractor maintains it during construction by marking each change near the affected item on the sheet: the routing that moved, the dimension that changed, the device that relocated, with the change-document or RFI number, the date, and a short note. At closeout this marked set becomes the basis for the record drawings, the cleaned-up set that captures the final condition for the owner.

Mark it as you go. This is the single most ignored rule in document control and the one that costs the most at the end. Waiting until substantial completion to collect markups from the subs is how closeout drags for months, because the people who knew what changed have moved on and the markups get reconstructed from memory or never get done. The as-built is a deliverable. Treat it like one from the first week, not a chore you discover at the end.

Keep the redline current as the work is installed and the as-built is mostly written by the time you are done. The change documents and RFI answers that drove field changes should already be reflected, because each one was marked when it happened. The closeout document package, including the as-builts and the O&M material, is its own discipline covered in the closeout guide. The thing that makes that closeout survivable is the as-built that was kept current all along.

The specs are documents too

Specifications are part of the controlled set, and they get version-controlled the same way the drawings do. The project manual, the bound specs organized by CSI division, says what the drawings cannot: the materials, the standards, the execution, the quality the work has to meet. Addenda and change documents modify the specs as often as they modify the drawings, so the current project manual has to carry every spec revision the same way the drawing set carries every sheet revision.

The spec gets forgotten because it is text, not lines, and the field reaches for the drawing first. But the spec controls things the drawing only implies, and a superseded spec section is as dangerous as a superseded sheet. An addendum that changed a product requirement or a testing standard governs the installation whether or not anyone updated the manual in the field. Incorporate spec changes into the controlled set and distribute them like you distribute drawing revisions.

Drawings and specs sometimes disagree, and when they do, you do not get to pick the one you like. The contract sets out how a conflict between documents is resolved, which is the order of precedence, covered next. Where the documents genuinely conflict, that order, and an RFI when it is unclear, settle it, not a field judgment call.

Conflicts and the order of precedence

When documents conflict, the contract usually sets an order of precedence: a stated hierarchy that says which document governs when two disagree. A common pattern ranks the agreement and conditions above the specifications and the specifications above the drawings, and addenda and modifications above what they amend, but the exact order varies by contract and is not universal. Read what your contract actually says before you rely on any hierarchy, because the wrong assumption about precedence builds the wrong thing with confidence.

Precedence resolves a genuine conflict. It is not a license to ignore a document you find inconvenient or to assume a higher-ranked document automatically overrides a more specific lower one. Many conflicts are not real conflicts at all; they are the same requirement stated at different levels of detail, and the more specific instruction usually controls within its scope. The order of precedence is for the cases where two documents truly cannot both be satisfied.

When the conflict is unclear or the precedence does not resolve it cleanly, do not guess. RFI it. Building to your own reading of a document conflict puts the rework risk on you if you read it wrong, and you will sometimes read it wrong. The RFI gets a written answer that governs and goes into the record, which is far cheaper than installing to a guess and tearing it out. Guessing on a conflict is one of the classic ways a document-control failure turns into a paid mistake.

Controlled access and the audit trail

Controlled access decides who can read, who can change, and who can publish the controlled documents, and it is what keeps the single source of truth from quietly forking. Not everyone should be able to publish a new revision. The whole point of one controlled set is that changes go through a defined process and a defined person or role, so the set does not get edited from five directions into something nobody can vouch for.

The audit trail is the record of who did what to which document and when: who uploaded a revision, who superseded a sheet, who downloaded the current set, who marked up what. On a document platform this is built in and continuous, and it is the same record that proves distribution and supports a dispute. An audit trail nobody can produce is an audit trail that does not help you when the question of who changed what comes up.

Back it up, and confirm the backup. The controlled set is the project record, and the project record living in one place with no copy is a single point of failure waiting to happen. The platform usually handles this, but verify it rather than assuming it. The day you need to reconstruct what the documents said is not the day to learn the backup was never running.

Document control as the project record

Beyond keeping the field current, document control is the project record, and that record is the evidence in a dispute or a delay claim. When the argument is about who owns rework, who is responsible for a clash, or whether a change was authorized, the question almost always reduces to who had what document when. The registers, the transmittals, the revision logs, and the dated markups are what answer it. Memory does not, and on a contested job memory is not trusted anyway.

Most delay and change disputes are won or lost on the contemporaneous document record, not on who argues better afterward. A transmittal proving the current revision reached the sub before the work was built, a revision log showing exactly when a sheet changed, an RFI answer dated against the work that followed it: these decide outcomes. The team that kept the record clean as the job ran has the evidence. The team that planned to assemble it later has a story.

This is also why the hedges in this guide point back to the contract. What the documents are, how they are processed, what response times apply, and how conflicts resolve are all set by the contract documents and the project procedures, and they vary. The discipline is constant: keep one controlled source, incorporate every change and pull the superseded sheets, get the current docs to the field, and as-built as you go. The specifics of how follow the contract and the project.

The closeout document package

Closeout is where the document record becomes the owner's record, and it is built from what document control kept current all along. The closeout package typically includes the as-built or record drawings, the operations and maintenance manuals, product data and warranty letters, test and commissioning reports, and the contact and equipment information the owner needs to run the building. The exact contents follow the contract and the spec, so build the closeout list from the project requirements, not from a generic checklist.

The package is only as good as the records that fed it. As-builts marked as the work went in, submittals tracked to approval, change documents incorporated into the set: these assemble into a closeout that holds together. The same records left to the end produce the closeout that drags for months while people reconstruct what happened. The work that makes closeout fast is the work you do during construction, not at the end of it.

Closeout document management is its own discipline, with its own sequence and its own failure modes, and it is covered in the closeout guide. The connection to document control is direct. A clean current set, kept controlled and as-built throughout, is most of the closeout package already written. A messy one is a closeout you finish by force.

The controlled registers: what document control tracks

Document control runs on registers: the lists that track each document type by status, revision, and distribution, so nothing falls between the cracks. The drawing register tracks every sheet and its current revision. The transmittal log tracks what was issued to whom and when. The RFI and submittal registers track open questions and approvals. The change-document log tracks every addendum, ASI, bulletin, and CCD and which sheets each one touched. A field tool like FieldOS is where these registers and the documents they track meet the crew, so the current status is visible where the work happens.

The value of a register is that it makes the state of the documents visible at a glance: what is current, what is open, what reached the field, what changed. Without registers, document control is a guess about whether everything is up to date, and the guess is usually wrong on the one sheet that matters. The register is how you know the current set is actually current and the field actually has it.

Common mistakes

• Building from a superseded drawing because the current revision never reached the field or the old print was never pulled.
• Running without a single controlled source of truth, so scattered copies and emailed sketches compete with the official set.
• Failing to incorporate an addendum, ASI, bulletin, or CCD into the set, so the field builds to a sheet the change already modified.
• Leaving the field without access to the current documents on a device, so a paper set drifts out of date.
• Leaving the as-builts to the end of the job instead of marking each change as the work goes in.
• Guessing on a document conflict instead of checking the order of precedence and raising an RFI when it is unclear.
• Logging the change documents without tying them back to the affected sheets, so the change is impossible to trace later.

Field checklist

Standards and references

Document control practice draws on a few recognized sources, but the governing authority on any given job is the contract, not a generic standard. The contract documents, commonly an AIA or ConsensusDocs family of forms, define what the documents are, how changes are processed, and the order of precedence when documents conflict. The General Conditions set out how RFIs, submittals, and changes are handled and what response times apply. Read the contract for the specifics before relying on any general rule, because these vary by project and by contract form.

The change documents have standard forms worth knowing by name. The architect's supplemental instruction, the bulletin, and the construction change directive, AIA form G714, each carry a defined meaning and a defined cost-and-time treatment, though the exact use on your job follows the contract. For information management on larger and BIM-based projects, ISO 19650 defines the common data environment as the single source of project information and organizes documents through work-in-progress, shared, published, and archived states. Sheet numbering and file naming follow the project CAD or BIM standard and the CSI-based organization of the specs.

Across all of it, three things hold regardless of which standard or platform a project uses: keep one current, controlled source of truth; incorporate every change and pull the superseded sheets; and get the current documents to the field and as-built as you go. The tools and the forms change. Those three do not.

Terms and definitions

Document control uses a vocabulary that shifts a little between contracts and platforms, so the same idea can read under different names across a drawing set, a contract, and a software tool.

The terms below are the ones that decide whether the field builds from the right documents. Where a contract defines a term differently, the contract definition governs on that job.

Document control

The practice of keeping everyone building from the current, correct documents and tracking how those documents change

Single source of truth

One current, controlled set everyone works from, instead of scattered copies and emailed sketches

Version / revision

A numbered, dated issue of a document; the current revision supersedes the prior one

Superseded sheet

An old revision replaced by a newer one, pulled from the build and marked VOID but kept in the archive

Addendum

A change to the bid or procurement documents issued before the contract is executed

ASI

Architect's supplemental instruction; clarifies or makes a minor change to the contract documents without, by its terms, changing the sum or time

CCD

Construction change directive (AIA G714); directs the contractor to proceed with a change before cost and time are agreed

Transmittal

The record of what documents were sent, to whom, and when

As-built

The marked-up set showing what was actually built, maintained as the work goes in and used to produce record drawings at closeout

Common data environment (CDE)

The single agreed place where project documents and data are collected, managed, and shared, per ISO 19650

Order of precedence

The contract's stated hierarchy of which document governs when two documents conflict

Related tools

Calculators and readiness checks for this work

Compare your options

FAQ

People also ask

• What is an RFI in construction?
• What is the critical path?
• What is an as-built drawing?
• What is construction dewatering?
• What is construction layout?