The submittal register: what it holds, and why it should be generated

A submittal register is the planned list of every submittal the specification obliges the contractor to make on a job. One row per obligation: which section of the spec created it, what the item is, what form the submittal takes, who produces it, how long it takes to get, how long the reviewer is contractually allowed, and therefore the last date it can leave your office without putting the installation at risk. It is forward-looking, and it exists before anything has been submitted.

The submittal log is the other half, and a different kind of record. The log tracks what has happened to each obligation — sent on this date, returned with this action, resubmitted, closed. The register can be produced from documents you were handed on day one. The log can only be produced from events, which is why nobody can generate one, and why it goes stale the moment somebody answers an email instead of updating it.

The record shape, field by field

Written out as the record it is, the register is unremarkable — which is the point. Its usefulness comes from every row carrying the same fields, so the set can be sorted, filtered and dated backwards from the programme.

Two rows decide whether the register is worth having. The review cycle allowance is a contract term and varies by project — read it off the conditions of contract for this job rather than reusing last job's number. The latest submission date is the only field that turns a list of obligations into a schedule somebody can be measurably late against.

Why the register is derivable and the log is not

A specification is a structured document pretending to be prose. Sections are numbered, sections contain a submittals article, and that article uses a small, repetitive vocabulary of obligations. That structure is what makes the register machine-derivable. The extraction method belongs to turning a specification book into a submittal list, and it is separate work from defining the record.

• The spec knows what. Section, item and type are stated in the document, so a first-pass register can exist the day the spec book arrives rather than the week before the first package is due.
• The spec does not know who. Responsible party comes out of buyout and changes when a package is re-let. A register that hard-codes the subcontractor at extraction time is wrong by the second award.
• The spec does not know when. Required-on-site dates come from the programme, so the register becomes a schedule only once somebody joins it to the activity list in Primavera or Microsoft Project.
• Where a drawing schedule and a spec section create different obligations for the same item, the register needs a rule rather than a fresh judgement each time — which is what the contract's order of precedence is for.

The log resists the same treatment because its content is events with actors and timestamps. Nothing in the contract documents tells you that the mechanical sub sent revision B on a Tuesday, or that the engineer returned it marked revise-and-resubmit. That has to be captured as it happens, through one write path, which is why the log and the email thread end up disagreeing wherever there are two ways to record the same event.

The parts a machine can be trusted with, and the parts it cannot

Extraction is dependable on fields printed in the document and unreliable on fields that require knowing how this job is being built. Draw that line explicitly before anyone signs off a generated register.

1. Accept machine output for section, item and type, then have one person read it against the spec's contents page to catch sections that produced no rows. A section with zero rows is either genuinely obligation-free or an extraction miss, and only a human tells which.
2. Never accept a machine-assigned responsible party. It follows the buyout package boundary, and getting it wrong sends chase emails to a subcontractor who does not hold the scope.
3. Treat every deferred item as a human decision. An item whose design is incomplete, or whose approval sits with an outside authority, cannot be dated from the spec alone — deferred submittals and who owns the clock covers what that state has to hold.
4. Re-run the extraction after each addendum instead of patching rows by hand, and diff the outputs. The diff is the addendum's real effect on your obligations.

The register answers what you owe and by when. The log answers what you have done about it. One spreadsheet holding both is how a project ends up with two versions of the truth and an argument about which was current.

Who prepares it, and who owns each column afterwards

On most contracts the contractor prepares and issues the register, often within a fixed number of days of award, and the design team reviews it for completeness rather than authoring it. Automation leaves that division intact: generating rows does not transfer the obligation to get them right. What changes is where the effort goes — from typing to reviewing.

• Project manager owns the required-on-site dates, because they come from the programme and move when it moves.
• Procurement owns responsible party and lead time, and is the first to learn that a quoted lead time has slipped from 8 weeks to 16.
• Document control owns the register-to-log link, so every submission is raised against a register row rather than as a loose transmittal — the record that has to survive is set out in what a transmittal must record to be evidence.
• A date that decides money is a familiar shape on a job: the same logic runs through the off-hire note, where one recorded date decides who pays for idle plant. A register row without a defensible date is an obligation nobody can prove was met on time.

Closeout depends on it too. Approved product data, test certificates and warranty documents all begin as register rows, and at handover each has to be tied back to what was actually installed — the same evidence burden as what a field markup has to carry to become an as-built.

Generating the register and running a review queue over it is narrow work of the kind we scope under AI agents and automation — a person approves each row, then it lands in Procore, Autodesk Construction Cloud or wherever the job lives, which is the pattern argued for in AI agents in production. The rest of this silo sits under drawings, specs and construction document intelligence, inside our construction and contracting work.

• submittals
• specifications
• document ai
• project controls