Traceability
Every row has a section and enough page or paragraph detail for another reviewer to find the requirement.
Field guide
How to create a submittal register from the project manual
The reliable method is systematic: establish scope, read Division 01, work through technical sections, capture the exact action, and verify every entry.
1. Confirm the project manual and scope
Start with the issued-for-construction documents—or clearly label the issue you have. Record addenda and later revisions so the register does not mix requirements from different document sets.
2. Read Division 01 before building rows
Division 01 often establishes format, timing, review procedures, delegation, substitutions, and closeout expectations. Capture these as rules for the register-building process, not as dozens of duplicate rows.
3. Review each applicable technical section
Look beyond the “Submittals” article. Quality assurance may require installer qualifications; products may require selection samples; execution may require field reports; closeout may require warranties and maintenance data.
4. Write a row another person can use
“Shop Drawings” is a type, not a useful description. “Power, signal, and control wiring diagrams” tells the team what must be prepared. Keep the type in its own column.
5. Verify every entry against the source
Record the page and paragraph, remove procedural noise, combine items only when they will be prepared and reviewed together, and flag unclear responsibility for discussion. Then add planned dates based on procurement and installation—not an arbitrary sequence.
Before entering the first row
Record the project, specification issue date, volume, addenda included, reviewer, and review date. Decide whether the register covers the entire project or a defined trade scope. A register without a documented source set becomes difficult to update when revised documents arrive.
Also decide how you will handle alternates, allowances, unit prices, owner-furnished products, delegated design, and closeout requirements. Consistent rules are more important than choosing one universal format.
Documents to check in addition to specifications
- Drawing notes, schedules, and referenced details
- Addenda and issued clarifications
- Owner and program requirements
- Procurement and substitution provisions
- Scope exhibits and subcontract inclusions
- Commissioning and closeout requirements
Convert specification language into a usable action.
Too vague
Submit Product Data
This repeats the type but does not identify the product, system, or required information.
Usable action
Product data for variable-frequency drives
The title identifies the subject; “Product Data” remains available as a separate classification.
Use the shortest title that remains specific. Do not paste an entire specification paragraph into the action field. Preserve the full evidence separately so the title can serve the project team while the source remains available for review.
Is it an actual deliverable?
Exclude general procedures from the row list. A paragraph explaining that the contractor must review submittals before forwarding them is important, but it is a project rule—not a separate package. Likewise, descriptions of design intent or product performance do not become register items unless the documents require evidence, information, or a physical item to be provided.
Is the requirement duplicated?
Repeated language is common. A summary article may list product data, and a later product article may describe its contents. Keep both source references if they support one requirement, but avoid creating duplicate rows unless the project will genuinely prepare and review separate deliverables.
Should items be grouped?
Group requirements that will be prepared by the same party, at the same time, and reviewed together. Split items when they depend on different suppliers, require different review disciplines, or must be released at different stages. Packaging decisions can change later; the initial register should make the underlying requirements visible.
Who is responsible?
The specification identifies requirements, not always subcontract scope. Use CSI sections and subject matter to suggest a party, then confirm against contracts and buyout strategy. Delegated-design and testing requirements deserve special attention because preparation may involve engineers, agencies, manufacturers, or laboratories.
How should dates be calculated?
Start with the required-on-site or work-in-place milestone. Subtract procurement and fabrication time, the time needed after approval, anticipated design review, possible resubmission, contractor coordination, and preparation by the responsible party. Document the assumptions rather than entering an arbitrary submit date.
A final register-review checklist
Completeness
Division 01, technical sections, quality requirements, field records, and closeout obligations received deliberate review.
Actionability
Titles are specific, types are separate, duplicates are resolved, and responsibility questions are visible.
Questions about creating a register
Should I copy the specification wording exactly?
Keep the exact wording as source evidence, but write a concise action title for the working register. This gives users clarity without losing contractual context.
Should closeout documents be included?
Yes, they should be identified somewhere in the project’s control system. Teams may keep them in the main register or a coordinated closeout log depending on their workflow.
How long does manual register creation take?
It depends on project-manual length, complexity, PDF quality, reviewer experience, and the level of source verification. The important comparison is not only initial entry time but also later cleanup and rechecking.
From one specification hierarchy to reviewed register rows
Assume Section 23 09 23 contains a paragraph titled “Shop Drawings.” Its lead-in directs the contractor to submit project-specific control documentation. Three child paragraphs list a system architecture diagram, power and signal wiring diagrams, and a points list. A literal extraction could create four rows—the parent plus each child—or one vague row called “Shop Drawings.” Neither is automatically useful.
First, preserve the parent directive and all three children as evidence. Next, ask how the controls subcontractor will prepare and transmit the information. If the architecture, wiring, and points list form one coordinated controls package with the same timing, the register may contain one action such as “DDC system architecture, control wiring diagrams, and points list.” If the points list must be reviewed earlier to support controls integration, keep it separate.
Record Section 23 09 23, the exact page and paragraphs, “Shop Drawing” as the type, the controls trade as proposed responsibility, and the grouping decision as reviewed. The example illustrates why register creation is not a simple count of specification bullets: the goal is a traceable unit of project work.
Handling revisions and addenda
Do not silently overwrite the basis of the register. Record the new document issue, identify affected sections, compare revised requirements, and note additions, deletions, or changed evidence. A stable register identifier helps preserve continuity even when the action title or source location changes.
Handling open questions
Keep unresolved items visible with an owner and next action. Examples include unclear preparation responsibility, a cross-reference to a missing section, a requirement dependent on an alternate, or language that appears to request a deliverable without stating when it is due.