Revision Control in Practice: What the Standards Don't Tell You

Revision control is one of engineering drawing's most codified practices. Title blocks are standardised. Revision tables are standardised. Issue codes and status designators are standardised. And yet revision-related errors remain one of the leading causes of rework, coordination failures, and contractual disputes in capital projects.

The standards describe the schema. They don't describe the system.

What revision control is supposed to prevent

Revision control exists to answer one question unambiguously: which version of this drawing should be used, right now, for this purpose?

When that question has a clear answer — when every consultant, contractor, and site supervisor is working from the same revision, verified against the same source — projects run. When it doesn't, they accumulate silent errors. Work gets done against a superseded design. A change made in week four isn't reflected in the drawing issued in week six. Two contractors coordinate to different revision states.

The naming convention trap

Most teams start with a naming convention. PROJ-STRUCT-001-REV-A.pdf. This is not revision control. It is revision labelling. There is a significant difference.

A naming convention gives each revision a name. Revision control gives each revision a position in a lineage: issued after what, superseding what, approved by whom, for what purpose. The name is a label on the envelope. The control is the postal system.

Without the system, you get what teams always get: multiple files with similar names, no authoritative record of which was issued when, and a significant amount of tacit knowledge held by individuals rather than the organisation.

When those individuals leave, the tacit knowledge leaves with them.

How approval workflows break

In most drawing management systems, approval is a status field. Someone with the right access changes the field value. This creates two problems.

First, status is decoupled from action. The approval event and the status update are two separate moments that require two separate acts of discipline. One is forgettable. Over long projects, it gets forgotten.

Second, approval is often a proxy for review. When approvals accumulate pressure — end of month, before a major submission, during mobilisation — the check becomes cursory. The field gets updated because the deadline requires it, not because the review was complete.

Supersession and the ghost drawing problem

A drawing that has been superseded should not be accessible as if it were current. In most systems, it is. It lives in the same folder, has a similar name, and appears in search results alongside the current revision.

Ghost drawings are superseded drawings that continue to be referenced. They appear in older packages, in contractor systems, in legacy coordination drawings. When someone encounters a ghost drawing, they often don't know it's a ghost. They act on it.

The fix is not to delete old revisions — the historical record is essential. The fix is to make the distinction between current and superseded unambiguous and enforced by the system, not by convention.

What durable revision control requires

The infrastructure for revision control that actually works is not complex. But it must be structural, not aspirational.

It requires:

• A canonical issue record that is the source of truth, not a copy of it
• Approval that is an event with an audit trail, not a field update
• Supersession that is visible and enforced — a user should not be able to access a current and a superseded version without understanding the difference
• Access to the register that does not require updating a separate document

These are not novel requirements. They are the requirements the standards were written around. The gap is in the tooling that implements them.

Conclusion

The issue is not isolated to one drawing, one review, or one handover event. It reflects how engineering control either holds together across delivery or breaks down when the record is forced to be reconstructed after the fact.

For teams working in standards, the practical requirement is the same: decisions, revisions, and issuance states need to remain attributable, traceable, and defensible all the way through the project record.