Submittal Numbering and Revision Schemes That Survive a Long Job

Nobody thinks about numbering until it fails. It fails quietly, in month eight, when someone asks for "the approved VFD submittal" and there are three documents that could plausibly be it: VFD_submittal_final.pdf, VFD_submittal_final_v2.pdf, and VFD_submittal_final_v2_USE_THIS_ONE.pdf. On a job that runs three years and a hundred packages, a numbering scheme is not clerical fussiness. It's what makes the record usable.

A workable scheme answers four questions from the number alone: which project, which package, which revision, and (often) which spec section it answers. Everything else is taste.

The submittal number

The common convention ties the number to the specification section the package answers, because that's how the reviewing engineer files it:

<spec section> - <sequence>        e.g.  40 61 13 - 001

The sequence increments per section, so a second package under the same section becomes 40 61 13 - 002. Engineers like this scheme because their review log is organized by spec section already. If your client uses a construction management platform, it probably imposes exactly this format, and fighting it buys nothing.

For your own internal tracking, a plain per-project sequence (SUB-001, SUB-002) works fine, and many integrators run both: the client-facing number in their format, an internal number in yours. That's not redundancy, that's the same practice the transmittal follows, carrying both parties' project references so each side can file the exchange in its own system.

Two rules keep any scheme alive:

• Numbers are never reused and never reordered. A cancelled submittal keeps its number and gets marked cancelled. Renumbering to close a gap breaks every reference in every email that mentioned the old number.
• The type of thing is visible. Shop drawing packages, product data, O&M manuals, and test procedures often carry a type code (SD, PD, OM, TP) so the log can be scanned by kind. If your client's spec defines type codes, use theirs.

The revision scheme

The first issue and each re-issue need names. Both common conventions work; pick one per project and never mix:

• Numeric: Initial (or Rev 0), Rev 1, Rev 2
• Alphabetic: Rev A, Rev B, Rev C

The trap isn't the letters versus the numbers. It's ambiguity about what counts as a revision. The rule that holds up: a revision exists when a package is issued. Not when you edit files, not when a draft changes internally, only when a document actually goes out the door under a transmittal. Internal drafts can churn all week; the revision number moves only at issue. The moment "Rev 2" can mean either "the thing we sent" or "the thing we're working on," the log has two truths and therefore none.

The corollary: an issued revision is frozen. Whatever went out as Rev 1 stays exactly that, byte for byte, forever, even after Rev 2 supersedes it. The superseded revision isn't trash; it's the record of what the engineer reviewed and commented on. The comments on Rev 1 only make sense against Rev 1 as it was.

The log that ties it together

The submittal log is one row per issued revision: number, title, spec section, revision, date issued, date returned, response, and where the returned markup lives. Simple, and the discipline is entirely in the keeping:

• The row is written when the package is issued, not reconstructed later from sent mail
• The returned copy is attached to the revision it answers, not to a general project folder
• The response and response date come from the stamp, not from memory

A log kept this way answers the audit questions instantly and, as a bonus, tells you your own review-cycle statistics: how long this engineer actually takes, how many packages go through in one cycle. Both numbers are worth knowing at bid time on the next job with the same reviewer. What the responses oblige you to do is covered in what Approved as Noted actually requires, and the package the numbers hang off is covered in what goes in a control system submittal package.

A starting convention, if you don't have one

For an integrator without a client-imposed format, this covers a multi-site job without ceremony:

<project>-<type>-<sequence>  Rev <n>
PS12-SD-004 Rev 1

Project code, type code, per-project sequence, numeric revisions, revision moves only at issue, issued copies frozen. Write the convention down on one page, put it in the project quality plan, and the log will still be legible when someone asks about PS12-SD-004 in three years. They will.

Disclosure: I build Submittal Kit, which assigns numbers by configurable format, moves the revision only when a package is issued, and freezes every issued revision permanently. The conventions above predate any software, and the discipline is the part that matters.