How to mark up an engineering drawing:the colour code, and the loop it runs on

Two people, and a loop that does not end at the hand-off

The convention only makes sense once you know who is holding the pen. There are two roles, and they swap the document back and forth.

The cycle runs in five steps, and steps four and five repeat.

1. 1

   Mark up

   Checker

   Red for information to be drawn or modelled. Blue for comments that are not to be drawn. The markup goes to whoever will produce the final documentation.

2. 2

   Transpose and print

   Back drafter

   Work the markup into the model, highlighting each item orange on the original as it is actioned. Print a clean PDF and self check it against the markup for completeness. Questions for the checker go on the new print in green pen.

3. 3

   Back check, two documents at once

   Checker

   Highlight the original markup green while confirming the same action on the new print in yellow. Anything still wrong, or anything new, is marked on the new print in red and blue. That print now becomes the next markup.

4. 4

   Action again

   Back drafter

   Carry out the changes as in step two, add any further questions, and produce a new print for back checking.

5. 5

   Review again

   Checker

   Review and re-mark as in step three. Repeat steps four and five until no new markups remain and every question has been answered.

Notice what this rules out. There is no version of the process where the checker hands over a markup and assumes it landed. The proof that a change was made is a highlighter stroke on a specific document, made by a named role, at a named step.

The colour code, one colour at a time

Nine colours, each with exactly one job. Pick one to see what it means, who writes it, and where it lands in the cycle.

The part most teams get wrong: back checking is two documents

Ask a drafting team how they back check and you will usually hear a single-document answer. They mark the new print, or they mark the old markup. The convention above asks for both at once, and the reason is worth spelling out.

During back checking the checker holds the original markup in one hand and the new print in the other. Green highlighter goes on the original markup, confirming that the instruction has been discharged. Yellow highlighter goes on the new print, confirming that the drawn result is correct. Two different claims, on two different documents.

Keeping both means an unhighlighted item on the original markup is an instruction nobody actioned, and an unhighlighted item on the new print is a change nobody verified. Collapse it to one document and you lose the ability to tell those two failures apart. That distinction is the whole reason for the blue highlighter, which exists precisely to circle the instructions that never made the crossing.

Pens: what the mark asks for

The pen sets intent. Red and blue travel from the checker to the back drafter; green is the only colour that travels back.

Highlighters: how far the mark has got

The highlighter sets state. Orange belongs to the back drafter; yellow, green and blue belong to the checker.

Keep the spare colours genuinely spare. The moment a fifth colour acquires an informal meaning on one job, the convention stops being portable between teams.

Seven conventions that save a revision

Most wasted cycles do not start with a disagreement about engineering. They start with a mark nobody could read, or a colour that did not survive the scanner.

Repeat instructions

Where the same item is drawn many times, mark up one example and say how it repeats. Mirror. Copy. Repeat on each part. Marking all twelve is slower for the checker and no clearer for the drafter.

Remove, demolition and stripout

Hatch the equipment in red pen and add a note saying what is going. For a whole area, block it in with an un-assigned highlighter colour so the region is never mistaken for one of the assigned states.

Set-out dimensions versus drawn dimensions

A dimension used only to locate something, and not shown on the finished drawing, is marked in blue. A dimension that is meant to appear on the drawing is marked in red. Same number, different instruction.

Text, and who has to read it

Write clearly and in block capitals. The back drafter may not have English as a first language, and a scrawled note is a guess waiting to happen. Long passages belong in a separate text file supplied alongside the markup, in uppercase throughout.

STET, for when the checker is wrong

Hand markups only. When the checker marks something in error, writing STET beside it tells the back drafter to ignore the mark and leave the item exactly as it was. Without it, a crossed-out instruction is ambiguous: was it retracted, or is the crossing-out itself the instruction?

Re-markup on an issued markup

Marking up on top of a markup that has already gone out? Take a black and white photocopy of it first, then mark the copy in red and blue. The greyed original stays legible underneath and the new layer reads as new.

Scan in colour, always

This is the one that quietly undoes everything else. Scan or photocopy markups in colour. A monochrome scan flattens red, blue and green into identical grey strokes, and with them every distinction between draw this, do not draw this, and please answer this.

What happens to the colour code after the paper is filed

The convention is sound. What it cannot do is survive its own medium.

None of this state is queryable. Nobody can ask which drawings still carry open red marks, how long the oldest one has been open, or which back drafter has the longest queue. The answer exists, on paper, in a drawer.

It also does not travel. Once the marked-up print is filed or scanned to greyscale, the entire status field is gone. The drawing register records that a revision happened. It does not record that three instructions were raised, two were actioned, and one was circled in blue because it never made the crossing.

This is the same problem we spend our time on at DrawingHub, one layer up. A drawing carries a great deal of structured information. Most of it sits in the title block, the revision table and the markup, and almost none of it is machine-readable by the time it reaches the system that is meant to manage it. Moving markup to PDF editing software, as this convention itself recommends where possible, is the first step. Making the resulting state searchable is the next one.

An audit you can run this week

If you want to know whether your own markup practice holds up, five questions will tell you.

1. 1Pull the last five marked-up prints. Can you tell, from the colours alone and without asking anyone, which instructions were actioned and which were not?
2. 2Ask two checkers what the yellow highlighter means. If the answers differ, the convention is not written down anywhere that matters.
3. 3Check how markups are being sent. If any of them went out as a monochrome scan, the colour code was already lost before it arrived.
4. 4Find one drawing that went through more than two markup rounds. Ask what caused the extra rounds. Legibility and repeat instructions account for most of them.
5. 5Ask whether anyone can produce a list of drawings with open markups. If the answer involves walking to a filing cabinet, that is the gap worth closing first.

The convention is the easy part

Any team can adopt a colour code in an afternoon. Pin it above the plotter, agree that green pen runs back the other way, and stop sending monochrome scans. That alone will remove a revision or two from most jobs.

The harder question is what happens to all of that recorded intent once the print is filed. Every mark on a checked drawing already carries who raised it, what it asked for, and whether it was discharged. That is a record. It is simply written in pigment, on paper, where nothing can read it back.

Further reading

• ISOISO 7200:2004 — Technical product documentation: data fields in title blocks and document headers
• ASMEASME Y14.35 — Revision of engineering drawings and associated documents
• BSIBS 8888 — Technical product documentation and specification
• DrawingHubWhat is actually in a title block, and why OCR keeps getting it wrong