Deferred submittals: the items the register has to hold open

A deferred submittal is a portion of the design that the permit authority has agreed may be submitted after the main permit is issued, rather than with the application. In practice it is almost always a delegated-design package: the specialty contractor's engineer produces and seals it, the design professional in responsible charge reviews it against the base design, and it goes to the authority for approval before that work is installed.

The two terms get used interchangeably and mean different things. Delegated design is about who produces the design; deferred is about when it reaches the authority. A package can be delegated and not deferred, and only one of the two puts a reviewer outside your contract on the critical path.

Deferred, delegated and long-lead are three different states

Typical delegated packages are those where fabrication engineering sits with the fabricator: steel connections, precast concrete, trusses, curtain wall, metal stairs, fire sprinkler layout, seismic bracing for MEP services. Most arrive as a small sheet set numbered by the specialty engineer rather than the consultant, so an index built on the consultant's convention loses them — which is why the title block is the metadata layer of a sheet set matters as soon as these land.

The fields a deferred row needs that an ordinary one does not

• The trigger event, named. Not a date — an event: award of the package, release of a base-design sheet, a client decision. Until it fires no submission date exists, and a blank date sorts to the bottom of every view.
• The external reviewer, and their queue. The design team's review period is a contract term. The authority's plan-review queue is not, so ask for its duration at pre-application.
• The sealing engineer, and where they are licensed. The seal must be valid in the project's jurisdiction — a buyout question that has scuppered packages awarded on price alone.
• A not-yet-openable state, distinct from not started. Collapsing the two is the single reason deferred items vanish from registers.
• The base-design dependency. If the base design is revised after the package was designed against it, somebody must tell the specialty engineer which sheets moved — the job a revision comparison flagging hundreds of meaningless changes exists to do.

Why 'not started' is where these items go to die

A register earns its keep by sorting on the latest safe submission date. A deferred row has no such date until its trigger fires, so it sorts to the bottom, sorts as a blank, or drops out of the open-items filter. Nobody decided to ignore it. The view did.

An obligation with a trigger nobody owns keeps costing money quietly, the same shape as plant that stays on hire after it leaves the yard — the failure in still invoiced for plant that left site. The record exists and no one is accountable for the date on it.

The approval requirement is jurisdictional, so read your own

Deferred submittals exist because the building code as adopted in your jurisdiction provides for them, and provisions differ on which items may be deferred, who reviews before the authority sees them, and whether the work may be installed before approval. Ask the authority having jurisdiction at pre-application and get the answer in writing rather than carrying last project's across a border. This describes practice, not legal advice.

One question sits outside this page: when a sealed delegated design conflicts with the base drawings or the specification, which governs is a contract matter with a per-project answer, set out in order of precedence when the drawing and the spec conflict.

What a document system should actually do with a deferred row

1. Extract candidates from the specification and flag them for a human rather than classifying automatically — the boundary drawn in turning a spec book into a submittal list.
2. Record the trigger as a relationship to another object — a buyout package, a permit milestone, a base-design sheet — so it fires without anyone remembering to fire it.
3. Hold the external review duration as a separate, explicitly sourced field, and show on the row where the number came from.
4. Compute the trigger deadline backwards from installation and surface it on the procurement report, not only the submittal log.
5. Alert on the trigger date, not the submission date. Once a submission date is late, the sequence has already failed.

A deferred item is not an obligation nobody has got round to. It is an obligation waiting on an event, and events need owners.

How the rest of the register gets built is separate work, set out in the submittal register as a generated artefact. Building the register, its trigger relationships and the review queue over them is scoped product work of the kind we run under MVP and product builds. The rest of this silo sits under drawings, specs and document intelligence, inside our construction work.

• submittals
• delegated design
• specifications
• project controls