Drawings, specifications and field questions

Before anything is laid out, someone has to work out exactly where it goes. That sounds obvious, but on a real project the information is spread across hundreds of drawing sheets, a specification of several volumes, shop drawings from dozens of suppliers, addenda, bulletins and answers to earlier questions. The pieces do not always agree. This lesson covers how a field engineer turns the contract documents into reliable layout information: reading the set for the work at hand, comparing disciplines, finding conflicts, writing questions that get useful answers and keeping track of which information is current. CON-120 taught how to read construction drawings; here the focus is on using them in the field under time pressure.

Which documents govern

The contract documents are meant to be read together, and most contracts say that what is required by one is required by all. When they conflict, the contract usually sets an order of precedence. Standard forms differ, and owners often modify them, so the field engineer should know what the project's own contract says.

The duty to report discrepancies is important. Most standard contracts, such as the CCDC 2 stipulated price contract in Canada and the AIA A201 general conditions in the United States, make the design team responsible for the design but require the contractor to review the documents and report errors, inconsistencies or omissions it discovers. The contractor is generally not expected to check the design as an engineer would, but a contractor who notices a conflict and builds one version anyway may share responsibility for the result. CON-220 covers construction contracts and law.

Reading the set for the work at hand

A field engineer preparing to lay out the level 2 deck of Larkspur Commons does not read the whole drawing set. He or she builds a work package of every sheet and document that affects that area and that pour. A practical checklist helps.

Each sheet should be checked for its revision and date against the drawing register. Building from a superseded sheet is one of the most common and most avoidable causes of layout errors. Many contractors stamp or watermark superseded sheets and keep a single current set on site; digital platforms show the latest revision by default, but people still print old sheets or work from screenshots.

Overlaying the disciplines

Most conflicts appear where disciplines meet. The structural engineer places a beam; the mechanical engineer routes a duct through the same space; the architect shows a bulkhead at a height that clears neither. Building information models and clash detection catch many of these conflicts before construction (CON-260), but models are rarely complete for every trade, and many conflicts still reach the field.

A field engineer can find many problems by overlaying sheets for the same area: structural over architectural to compare gridlines, slab edges, openings and wall positions; mechanical and electrical over structural to see sleeves near beams, columns and post-tensioning; and shop drawings over the design drawings to confirm that what is being fabricated matches the intent. Digital tools make overlays easy, but the habit matters more than the tool.

Common types of conflict that field engineers find on a project like Larkspur Commons include gridline offsets between architectural and structural drawings, dimension strings that do not add up, slab openings shown on one discipline but not another, elevations that differ between plans and sections, sleeves through beams or tendon bands, embeds missing from the structural drawings, and details that cannot be built in the space shown.

Checking dimension strings

Dimension strings should add up to the overall dimensions they sit beside. When they do not, either a segment is wrong, the overall is wrong or something was moved during design and not updated everywhere. A quick arithmetic check of every dimension string in the area is one of the most effective reviews a field engineer can do, and it takes minutes. The example checks four strings on the level 2 plan.

# Check that dimension strings add up to the overall dimensions (level 2 plan, grid line C, mm)
strings = {
    "Grid C overall, 1 to 9": (62400, [7800, 7800, 7800, 7800, 7800, 7800, 7800, 7800]),
    "Grid C, 1 to 4 detail string": (23400, [7800, 7800, 7800]),
    "North wall, outside face to outside face": (62900, [250, 7800, 7800, 7800, 7800, 7800, 7800, 7550, 7800, 250]),
    "Corridor, grid 4 to grid 6": (15600, [6050, 1800, 7700]),
}
tol = 3  # mm allowed for rounding on the drawing
for name, (overall, parts) in strings.items():
    s = sum(parts)
    diff = s - overall
    flag = "OK" if abs(diff) <= tol else "QUERY"
    print(f"{name:42s} sum {s:6d}  overall {overall:6d}  diff {diff:+5d}  {flag}")

Grid C overall, 1 to 9                     sum  62400  overall  62400  diff    +0  OK
Grid C, 1 to 4 detail string               sum  23400  overall  23400  diff    +0  OK
North wall, outside face to outside face   sum  62650  overall  62900  diff  -250  QUERY
Corridor, grid 4 to grid 6                 sum  15550  overall  15600  diff   -50  QUERY

Two strings do not close. The north wall string is 250 mm short of its overall dimension, and one bay in the string reads 7550 instead of 7800, which suggests a typing error on the drawing. The corridor string is 50 mm short, which could be a wall thickness change that was not carried through. Neither should be resolved by guessing. Mei writes one question for each, proposing the likely answer, and lays out nothing that depends on those dimensions until they are answered.

Writing a good question

A request for information, usually called an RFI, is a formal question from the contractor to the design team about the contract documents. CON-375 covers the full documentation process, and CON-260 covers how field platforms manage RFIs. From the field engineer's point of view, the quality of a question largely determines the quality and speed of the answer.

A good question is specific, self-contained, illustrated and constructive. It identifies the exact location by gridline and level; references the sheets and details involved, with revisions; states the conflict or gap clearly; attaches a marked-up drawing, photo or sketch; proposes one or more solutions with their effect on cost and schedule if known; and gives the date by which an answer is needed to avoid delay, based on the schedule.

Field sketches, often called SK drawings or sketches, are small drawings issued by the design team or the contractor to clarify a detail. A sketch issued by the design team in answer to a question becomes part of the documents for that item. A sketch prepared by the contractor to explain a proposal does not change the design until the design team accepts it in writing. Field engineers should be careful about building from their own sketches before they are approved.

Tracking questions and answers

On a busy project dozens of questions can be open at once. A question that is answered late can delay the work just as surely as a late delivery. A field engineer therefore tracks each question against the date the answer is needed, not just the date it was sent, and escalates through the project manager when a needed-by date approaches. The example reviews part of the podium question log.

# Question (RFI) log for the podium: turnaround and items that threaten upcoming work (invented data)
from datetime import date
log = [  # number, subject, sent, answered (None = open), needed by
    (14, "Sleeve conflict at beam B4", date(2027, 3, 1), date(2027, 3, 4), date(2027, 3, 10)),
    (15, "North wall dimension string", date(2027, 3, 2), date(2027, 3, 12), date(2027, 3, 8)),
    (16, "Embed plate size at canopy", date(2027, 3, 3), date(2027, 3, 9), date(2027, 3, 15)),
    (17, "Stair 2 landing elevation", date(2027, 3, 5), None, date(2027, 3, 19)),
    (18, "Corridor width grid 4 to 6", date(2027, 3, 8), None, date(2027, 3, 12)),
    (19, "Transfer slab step at grid F", date(2027, 3, 9), date(2027, 3, 11), date(2027, 3, 22)),
]
today = date(2027, 3, 11)
done = [(n, (a - s).days, a <= need) for n, _, s, a, need in log if a]
avg = sum(d for _, d, _ in done) / len(done)
print(f"Answered: {len(done)} of {len(log)}, average turnaround {avg:.1f} days")
print("Answered late (after the needed-by date):", [n for n, _, ok in done if not ok])
for n, subj, s, a, need in log:
    if a is None:
        left = (need - today).days
        status = "URGENT" if left <= 3 else "open"
        print(f"RFI {n}: {subj}, open {(today - s).days} days, needed in {left} days -> {status}")

Answered: 4 of 6, average turnaround 5.2 days
Answered late (after the needed-by date): [15]
RFI 17: Stair 2 landing elevation, open 6 days, needed in 8 days -> open
RFI 18: Corridor width grid 4 to 6, open 3 days, needed in 1 days -> URGENT

Four of six questions are answered, at an average of about five days. One answer arrived after the date it was needed, so the work it affected had to be resequenced. Of the two open questions, the corridor width is urgent: it is needed in one day. Mei calls the architect directly, with Priya's agreement, rather than waiting for the formal process, and records the call in the log. Turnaround times vary by project and contract; many contracts set response times for the design team, and repeated late answers may support a claim for delay (CON-420).

Answers, changes and revisions

Once an answer arrives, the field engineer's job is not finished. The answer must reach everyone who needs it: the layout, the trades, the drawings on site and the model. A common failure is to receive a clear answer and then lay out from the original sheet because nobody marked it up. Good practice is to cloud and reference the answer on the current set (often called posting), notify the affected foremen, update the layout data and note in the layout log which answer the layout reflects.

Some answers change the scope or cost of the work. An answer is not automatically a change order. If an answer requires more work than the contract documents showed, the project manager must raise it as a potential change under the contract's procedures, usually within a set time. Field engineers should flag any answer that seems to add work, even if the design team says it is a clarification. CON-420 covers changes and claims.

Revised drawings bring their own risk. When a new revision arrives, the field engineer compares it with the previous one, ideally using the clouds and revision notes but also by overlay, because not every change is clouded. Any layout already set from the old revision must be checked, and marks that no longer apply should be removed or clearly crossed out so that nobody builds to them.

Specifications the field engineer must know

Field engineers sometimes treat the specification as the project manager's document, but several sections bear directly on layout and checking. The general requirements sections often describe who provides the survey control, what the contractor must lay out, how layout must be recorded and what records must be handed over. The concrete section sets tolerances, finishes and floor flatness requirements, usually by referring to standards. Other sections describe embedded items, anchors and the tolerances for steel, masonry, curtain wall and finishes.

Lesson 6 explains how tolerances from these standards interact, and why a field engineer must compare the tolerances of adjoining systems before the work starts rather than after.