What Files a Drafting Handoff Needs
An architectural drafting handoff needs two categories of input. Authoring inputs decide what the drawings look like: the template, the written standard and a reference set of issued drawings. Subject inputs decide what they describe: survey and existing conditions with a named governing source, coordinate origin and elevation datum, current consultant files, and a stated authoring environment. Missing authoring inputs are caught in review. Missing subject inputs are caught on site.
Drafting engagements stall on file problems far more often than on drawing problems. The drafter is capable, the scope is clear, and the batch sits still because the survey arrived in one coordinate system and the model was built in another, or because there are three files with similar names and nobody can say which is current.
These failures are mundane and they are expensive, because they consume calendar time rather than hours. A missing dimension costs a question. A wrong reference point costs a redraw.
This guide lists what has to exist and be transmitted before drafting starts, what each item is actually for, and what a provider does when it is absent. It is about the inputs rather than about the workflow, which is covered separately in the guide on how a drafting engagement runs.
The distinction that organises this list
There are two categories of input and they fail in different ways. Authoring inputs decide what the drawings look like: the template, the standard, the title block, the reference set. Subject inputs decide what the drawings describe: the survey, the existing conditions, the design model, the consultant files.
A missing authoring input produces work that is technically correct and looks wrong, and it is caught in review. A missing or contradictory subject input produces work that looks right and is wrong, and it is caught on site.
The second category is the dangerous one, and it gets less attention because it is somebody elses department.
The template, and what it has to carry
The template is the file the drawings are authored in, and it should carry the title block, the sheet sizes, the text styles, the line weights, the dimension styles, the layer or category structure and the view naming conventions.
What usually happens is that a template exists and carries about half of that, with the rest applied by hand each time by somebody who knows. A provider receiving a half complete template will fill the gaps with sensible defaults, and sensible defaults are not the practice standard.
The cheapest test is to open the template on a machine that has never touched a project from the practice and see what is missing. Anything that only appears when a live project file is open lives in habit rather than in the template.
The written standard, or a recognised one
The standard is the part of the answer the template cannot carry: what gets drawn against what gets noted, how details are cross referenced, how much annotation is expected, how revisions are clouded and tagged.
Practices without a written standard are not unusual and it is not a failing, it is a consequence of everybody who needs it already knowing it. It becomes a cost only at the moment work leaves the office.
The United States National CAD Standard, published through the National Institute of Building Sciences, exists to be that document where a practice has not written its own. It incorporates the AIA CAD Layer Guidelines together with drawing set organisation and sheet identification conventions, which are exactly the parts that a template does not carry.
The reference set, which answers what documents cannot
An actual issued set the practice considers correct. Not a specification of correctness, which nobody writes completely, but a worked example that demonstrates it.
It resolves questions no standard anticipates: how much is enough annotation, where the practice is exacting and where it is relaxed, what the drawings look like when they are finished rather than when they are compliant.
One good reference set removes more ambiguity than any amount of written instruction, and providers who ask for it early are working from evidence rather than from assumption.
The existing conditions, and their level of trust
This is the input that causes the most expensive surprises, because existing conditions arrive with wildly different reliability and are all handed over as though they were facts.
A recent measured survey is trustworthy. A point cloud is trustworthy about geometry and silent about what is behind a wall. A set of scanned prints from decades ago describes what was intended, not necessarily what was built. Field notes are trustworthy about the things somebody thought to measure.
What a provider needs is not only the material but a statement of which source governs when two disagree. Without it, the drafter picks one, and the choice is invisible in the returned drawings.
Why the governing source has to be named
Because contradictions are guaranteed in existing building work and somebody has to decide. If the practice does not decide, the decision is still made, just by the person least equipped to make it and without anybody recording that it happened.
The practical form of this is one line in the brief: where the survey and the archive drawings disagree, the survey governs, and every discrepancy is logged and returned with the batch.
That single line converts a class of silent error into a list somebody can read.
Coordinates, elevation datum and units
The most boring item here and the one that produces the most rework. A project has a coordinate origin, an orientation between project north and true north, an elevation datum and a unit system, and all four have to be stated rather than inferred.
When they are inferred wrongly, the drawings are internally consistent and disagree with the survey, the civil drawings and the consultants. Nothing looks wrong until two disciplines are overlaid.
This is also where linked files go wrong. A model linked by origin and a model linked by shared coordinates produce different results, and the difference does not announce itself in a plan view.
The consultant files, and when they arrive
Structural, mechanical, electrical and plumbing files are inputs to architectural documentation whether or not anybody has planned for that. Documentation errors concentrate at the boundaries between disciplines rather than inside any one of them.
What matters for a handoff is which consultant files exist, which are current, and which are still expected. A provider drafting against a superseded structural model produces a coordinated looking set that coordinates with the wrong thing.
Where coordination is genuinely being checked, it happens in an environment built for it. Navisworks is the common one, combining models from different disciplines and finding conflicts before anybody builds. Reviewing sheets alone does not find them.
File format, and the cost of translation
The rule is simple and frequently broken: the work should be authored in the environment the practice will keep it in. A provider who converts into another application and back has created a coordination problem while appearing to solve a capacity one.
Translation loses things quietly. Parametric elements become dumb geometry, styles are remapped to near equivalents, and the result prints correctly and resists every future change.
So the format question is not about compatibility, since almost everything is nominally compatible. It is about whether the practice is receiving something it can continue to work in.
Worksharing in a model environment
In a drawing environment two people can work on two drawings without any mechanism. In a modelling environment two people working on one model requires one, and the choice of mechanism has to be made before work starts rather than discovered.
The options are that the provider works in the practice environment with its worksharing, or works in a copy and returns it for reintegration. The first requires access and trust. The second requires a discipline about who owns the model at any moment.
What cannot happen is both sides editing separate copies of the same model with the intention of merging later. That is not a workflow, it is a scheduled loss of somebodys work.
File naming and one version of truth
A naming convention that encodes project, discipline, sheet and revision, applied without exception, and one location that is authoritative.
The failure mode is familiar to everybody and tolerated anyway: several files with similar names, a folder called final, and a folder called final revised. In an internal team this survives because everybody remembers. Across an engagement it does not survive at all.
The test is whether a person outside the practice can identify the current version of any drawing from its name alone, without asking. If they cannot, the convention is decoration.
Cloud storage makes this worse rather than better, because synchronisation creates conflicted copies with helpful names appended by software, and those copies look authoritative to somebody who was not there when they appeared. One authoritative location means one, with everything else understood to be a working copy that nobody drafts from.
Revision control, and what a batch is measured against
Every returned batch has to be comparable to something specific. That means the version it started from is identified, and the version it becomes is identified, and both are recoverable.
Without it, comparative review is impossible and the practice is forced back into checking every sheet from scratch, which is the most expensive way to review and the reason engagements stop returning capacity.
Comparison itself is mechanical in a review environment such as Bluebeam Revu, which surfaces every difference between two versions. What the software cannot supply is the certainty about which two versions are being compared.
The markup that starts the work
For redline work, which is most recurring drafting, the input is a marked set. It needs to be legible, unambiguous, owned by one reviewer, and consolidated before it is sent.
Two reviewers marking the same set independently produces conflicting instructions, and the batch comes back partly right. Partly right is more dangerous than wrong because it survives a quick review.
Consolidation is a two minute job for the practice and it removes a whole round of clarification from the cycle.
A named person who answers the same day
Not a file, but an input all the same, and the one with the most leverage. Drafting questions are small, frequent and blocking: does this dimension govern, is this detail current, which of these two notes is right.
Each takes under a minute to answer and stops the batch until it is answered. A provider waiting two days for a one minute answer is not slow, and the invoice will not record where the time went.
One named person on each side, with the authority to answer rather than to relay, is worth more to the schedule than any increase in drafting capacity.
What the provider should hand back with each batch
The drawings, a statement of what changed, a list of anything marked that could not be executed and why, and a log of assumptions taken where an answer did not arrive in time.
The assumption log is the item that separates a provider who is thinking from one who is executing. Assumptions get made on every batch, and the only question is whether they are surfaced or buried.
Batch after batch with no questions and no assumptions logged is not evidence of clarity. It usually means both are happening silently.
The as built drawings service case, where the inputs are the job
On existing buildings the inputs stop being preparation and become the substance of the work. An as built drawings service is largely an exercise in reconciling sources that disagree, and the drafting is the easy part of it.
What has to travel with the material is a statement of how each source was captured and when. A laser scan taken last month, a measured survey from a refurbishment two years ago and a set of prints from the original construction are three different claims about the same building, and only one of them describes what is standing today.
Practices that supply this context get architectural autocad drawings that reflect the building. Practices that supply files without it get drawings that reflect whichever file the drafter trusted.
Point clouds, and what they do not tell you
A point cloud is trustworthy about surfaces it could see and silent about everything else. It knows where the face of a wall is. It does not know what the wall is made of, what is inside it, or whether the line it recorded is structure or finish.
That distinction matters because drafting from a cloud requires interpretation at every one of those points, and interpretation is where assumptions enter. A provider working from a cloud without guidance will produce something dimensionally accurate and occasionally wrong about what it is describing.
The useful handoff includes the cloud, the registration information, and a note of which areas were obstructed during capture, because obstructed areas are exactly where the invented geometry will be.
Title block, sheet index and the drawing register
The title block carries project identification, revision history and the sheet numbering scheme, and it is the item most often handed over as an image rather than as a working component.
The sheet index has to exist before drafting rather than after it, because it determines numbering, and renumbering a set late is a change that touches every cross reference on every sheet. A drawing register that lists what exists, what is expected and what has been superseded prevents the second most common file problem in these engagements, which is work performed on a sheet that was already withdrawn.
Neither is glamorous and both are cheap to prepare compared with the cost of not having them.
Fonts, plotting and what breaks on the way to PDF
Drawings that look correct on the machine that made them and wrong everywhere else are almost always a font substitution, a missing plot style or a line weight table that did not travel.
This is the least interesting item on this list and it produces a disproportionate number of rejected batches, because the reviewer sees a set that is visibly not to standard and assumes carelessness rather than a missing configuration file.
The fix is to send the plotting configuration with the template and to check the first PDF from the provider against a PDF of the reference set. Five minutes at the start, and it removes an entire category of false alarm.
Referenced and linked files
External references in autocad drafting and linked models in a BIM environment both create a dependency that has to survive the trip between two offices.
When a reference path breaks, the drawing opens with content missing and nobody is sure whether it was deleted or simply not found. When it resolves to the wrong version, the drawing opens looking complete and is quietly wrong, which is worse.
So references travel with the drawings, paths are relative rather than absolute, and the handoff states what should be attached and what the drawing should look like when everything resolves.
Who owns the files at the end
Worth settling at the start rather than at the end, because the answer is obvious to both sides and they sometimes hold different obvious answers.
The practice needs the native files, not only the outputs, and needs them in a state it can continue working in without the provider. Anything less converts a capacity arrangement into a dependency, and dependencies get expensive precisely when a relationship ends.
For cad drafting services this is normally uncontroversial and is still worth stating in writing, along with what happens to project material once an engagement finishes.
Access, and what a shared environment implies
Sending files is one arrangement. Giving access to a live project environment is another, and revit drafting services in a shared model frequently mean the second whether or not anybody described it that way.
That is a decision about access rather than about drafting, and it deserves a deliberate answer: what the provider can reach, what they cannot, and what happens to that access when the engagement pauses.
Practices with confidentiality obligations to clients should settle this before the first batch, because retrofitting a restriction onto a working arrangement is disruptive and tends to be done badly under time pressure.
What none of this transfers
None of these inputs move the responsibility. Rendimension provides drafting support. We do not stamp, we do not seal and we are not the architect of record. A licensed professional reviews the work, takes responsibility for it and issues it.
That is why the review obligation is permanent rather than transitional, and why the practice needs review capacity budgeted alongside drafting capacity. The scope of what we produce is described on the architectural drafting services page.
A handoff checklist
Template that carries the standard. Written standard or a recognised one. Reference set of issued drawings. Existing conditions with a stated governing source. Coordinate origin, north orientation, elevation datum and units. Current consultant files with a list of what is still expected. Authoring environment named, with no translation. Worksharing mechanism agreed. Naming convention and one authoritative location. Revision baseline identified. Consolidated markup with one owner. One named person on each side who answers the same day.
Twelve items, none of them drafting, and the drafting goes well when they are in place.
The honest summary
Authoring inputs decide whether the drawings look like the practice. Subject inputs decide whether they are true. Missing authoring inputs are caught in review, and missing subject inputs are caught on site, which is why the boring items on this list deserve more attention than they get.
The most valuable thing a practice can prepare is not a longer brief. It is a named governing source for every contradiction and a named person who answers questions the same day.
To review what your current handoff package is missing before a first batch, request a quote.
Frequently asked questions
What is the most commonly missing input in a drafting handoff?
A statement of which source governs when existing conditions disagree. Surveys, archive prints and field notes contradict each other routinely, and if the practice does not name the governing source the drafter chooses one silently and the choice is invisible in the returned drawings.
Why do coordinates matter so much?
Because a wrong origin, north orientation or elevation datum produces drawings that are internally consistent and disagree with the survey and the consultant files. Nothing looks wrong until two disciplines are overlaid, and by then the rework is substantial.
Should a provider convert files into a different application?
No. Work should be authored in the environment the practice will keep it in. Translation quietly turns parametric elements into dumb geometry and remaps styles to near equivalents, producing a set that prints correctly and resists every future change.
How should two people work on the same model?
Either the provider works inside the practice worksharing environment, or works in a copy that is returned for reintegration with one clear owner at any moment. What cannot work is both sides editing separate copies with the intention of merging later.
What should come back with every batch?
The drawings, a statement of what changed, anything marked that could not be executed with the reason, and a log of assumptions taken where no answer arrived in time. Batches that never contain questions usually mean assumptions are being buried rather than surfaced.