Extracting Revision History From an Engineering Drawing

Almost every guide to extracting a revision table suggests checking that the letters run in sequence with no gaps. Applied literally, that check fires on roughly a fifth of all correct revisions, because the revision sequence deliberately skips six letters.

What the revision block contains

The revision block is a small table, conventionally in the upper right corner of an ASME-format sheet and near the title block on an ISO one. Its columns are fairly consistent even where the standard being followed is a company one: a revision identifier, a zone reference locating the change on the sheet, a description of what changed, a date, and one or more approval initials. Many blocks add a change control reference — an ECO or ECN number pointing at the engineering change order that authorised the revision, which is the field that ties the drawing to a workflow system rather than to another drawing.

The description column is the one that resists structure. It contains sentences like “WAS 12.7 ±0.1”, references to item numbers on a parts list, and shorthand that only means something inside the issuing organisation. Extract it as text and do not attempt to parse it into a change model; the value is in having it verbatim against the right revision identifier.

On the sheet itself, revised regions are marked with revision clouds and a triangular delta symbol containing the revision identifier. These are geometry, not text, and they are how you would locate a change rather than merely list it. A text extraction never sees them.

The sequence is not the alphabet

ASME Y14.35, the standard for revision of engineering drawings and associated documents, defines the sequence explicitly. Upper case letters are used in order beginning with A, omitting I, O, Q, S, X and Z. The reason is legibility on a drawing that will be photocopied, scanned and read on a shop floor: I reads as 1, O as 0, Q as O, S as 5, Z as 2, and X reads as a field somebody forgot to fill in.

When the single letters are exhausted, the revision after Y is AA, running AA through AY with the same six letters omitted in the second position, then BA, BB and onwards. After YY the sequence continues AAA, AAB through AYY. So the valid alphabet is twenty letters, not twenty-six, and the correct successor function looks like this:

ALPHABET = "ABCDEFGHJKLMNPRTUVWY"   # 20 letters: no I O Q S X Z

valid sequence, in order:
  A B C D E F G H J K L M N P R T U V W Y
  AA AB AC ... AY BA BB ... YY
  AAA AAB ... AYY

so H -> J is correct and adjacent
   R -> T is correct and adjacent
   W -> Y is correct and adjacent
   Y -> AA is correct and adjacent

Six omissions out of twenty-six means a naive alphabetical successor check flags a false gap at every transition across one of them. Over a drawing set with revisions distributed across the range, that is a large fraction of your review queue spent on correct documents — the most expensive kind of validation error, because it trains reviewers to dismiss the alert.

Detecting a genuinely missing revision

With the right alphabet, the gap check becomes useful. Map each extracted identifier to its ordinal in the sequence, sort, and look for a discontinuity. A jump from ordinal 8 to ordinal 10 is a real missing row — one revision exists that you did not extract — and that is precisely the signal the check is for, because a missing revision row usually means a missing page.

The first entry is its own small problem. Initial issue is written as -, 0, A, NEW or REL depending on house practice, and none of those is wrong. Treat any of them as ordinal zero rather than trying to force the first row into the letter sequence, and record the literal string so the document can be reproduced.

Dates give you a second, independent ordering. Revision dates should be non-decreasing down the sequence; a date that moves backwards is either a misread digit, a row extracted out of order, or a genuine administrative anomaly worth surfacing. Combining the two orderings is stronger than either — a sequence that is contiguous by letter and monotonic by date is very unlikely to be a partial extraction.

The title block as a second witness

The current revision appears twice on a correctly maintained drawing: in the revision block as the most recent row, and in the title block or sheet header as the revision of the sheet. They must agree. That gives you a check that needs no external data and no model confidence at all — extract both independently, from two different regions of the sheet, and compare.

Disagreement has three ordinary causes, and they are distinguishable. If the title block is ahead of the table, a revision row was missed in extraction or the table continued onto another sheet. If the table is ahead of the title block, the drawing itself was revised without updating the sheet header, which is a real document defect worth reporting rather than a parsing error. If they differ arbitrarily, one of the two was read from the wrong field — the sheet number and the revision sit close together and are both short strings.

On multi-sheet drawings the picture is more involved: sheets can carry independent revision levels, so sheet 3 at revision F and sheet 1 at revision D can both be current. A validator that requires one revision per drawing number will reject an ordinary drawing set. Model revision as a property of the sheet, with the drawing-level revision derived rather than stored.

Where revision tables go wrong

• The table grows in either direction. Some houses add new revisions at the bottom, some at the top. “Latest revision” is therefore not “first row” — resolve it by the sequence ordinals or the dates, never by position.
• Superseded rows are struck through, not deleted. A struck-through row is still text. Nothing in the character stream says it was cancelled, so it enters the sequence as a live revision and breaks the ordering.
• Zone references look like data. The zone column holds values such as B3 or D7, which are exactly the shape of a two-letter revision identifier. Column position, not pattern, has to decide which is which.
• Ambiguous dates. 03/04/2019 is two different dates and drawings rarely state a convention, so the date field validation rule has nothing to anchor on. A revision table gives you leverage the rest of the drawing does not: if any date in the table has a day above twelve, that resolves the order for the whole table.
• Empty tables that are not empty. A block with ruled rows and no content is a template awaiting first revision. An extraction returning phantom rows from the ruling is common, and the tell is rows with a zone and a date but no identifier.