Document-Control Cue
Identity, issue, revision, and status verification for the current specification section or note.
Chapter 16
Review one residential project's notes and specifications and produce a concise requirement summary linking materials, products, performance, submittals, execution, testing, closeout, and code references to the drawing set.
These cues appear at the point of use. They identify document-control, code, cross-reference, and clarification issues before a specification requirement is misapplied in the field.
Identity, issue, revision, and status verification for the current specification section or note.
A misread of this information can cause unsafe, non-compliant, or costly field work.
Guidance for using the specification set safely and correctly on site.
Verify adopted jurisdiction and permit status before relying on a code citation found in the notes or specifications.
Manufacturer instructions supplement the project documents and do not authorize deviation from the design without approval.
Follow a specification reference to its governing drawing note or detail, and back, to confirm coordination.
Stop and record a clarification item instead of guessing which requirement, standard, or note governs.
This chapter qualifies you to review one residential project's general notes and project manual and convert them into a concise, referenced requirement summary that a later trade can use without rereading every section of the specifications. The finished work product is one specification register, one requirement table, a set of trade-specific extracts, and one specification summary, all built from the current approved general notes, discipline notes, and specification sections received for one project.
You will confirm the current issue and hierarchy of the project manual, build a specification register by division and section, extract product, performance, submittal, execution, testing, and closeout requirements, compare general notes across disciplines, verify code references against the approved project basis, compare manufacturer instructions with the drawings and approved submittals, and record every conflict, missing section, or undefined standard as a clarification item rather than resolving it yourself.
Specifications and general notes routinely contain requirements that never appear on the drawings at all — submittal procedures, testing standards, warranty terms, delivery and storage rules, and performance criteria that a reader who only studies plans will never see. This chapter builds the habit of treating the written word as equally authoritative to the drawing, and of following the project's own stated order of precedence rather than assuming one.
Every chapter from Chapter 3 through Chapter 15 asked you to follow representative specification and keynote references without fully building the specification register itself. This chapter completes that habit by requiring the full project manual to be registered, cross-checked against every discipline's general notes, and reduced to a requirement table that later chapters can use directly.
Chapter 17 uses this specification summary, together with every discipline checklist built in Chapters 3 through 15, to compare plans across trades and identify conflicts. Chapter 19 uses this same summary to extract build-ready trade scope. Chapter 20 rebuilds this discipline at full scale as one of the required capstone reviews.
This chapter covers:
This chapter does not authorize the learner to:
Any section, note, or standard that cannot be resolved during this chapter must be recorded as an RFI-style question rather than assumed.
Establish these definitions before beginning the specification register, and apply them consistently across every section and note reviewed.
| Term | Definition |
|---|---|
| Project manual | The bound or assembled written document containing the specification divisions, sections, administrative requirements, and general conditions applicable to the project |
| Division / section | The numbered organizational unit within the project manual identifying a category of work (for example, Division 09 Finishes, Section 09 65 00 Resilient Flooring) |
| Order of precedence | The project's own stated ranking of which document governs when documents conflict; not a rule the reader invents |
| Basis of design | The specific named product used to establish performance and quality criteria against which an approved equal is measured |
| Approved equal / substitution | A product formally approved through the project's submittal or substitution process as equivalent to the basis of design |
| Delegated design | A component or system whose detailed design is assigned to a specialty contractor or supplier under a performance specification, subject to engineering review |
| Hold point | A stage in procurement, fabrication, delivery, or installation that requires a review, approval, test, or inspection before work may proceed |
Confirm the following are consistent with the Chapter 1 navigation package before building the specification register:
Project name: ______________________ Project manual issue / set name: ______________________
Specification volume(s) received: ______________________ Total sections received: ____________
Current drawing set revision on file: ______________________ Active addenda / substitutions: ____________
Date reviewed: ____________ Reviewer name: ____________
Specifications, drawings, schedules, details, approved submittals, and manufacturer instructions may each control a different aspect of the same work. This chapter does not ask you to decide which document wins in general; it asks you to locate the project's own stated order of precedence and apply it, and to record every unresolved conflict as a clarification item rather than choosing an answer.
A general note on a drawing is controlling only within its stated discipline and scope. A specification section is controlling for the category of work it describes, regardless of which discipline's drawings reference it. When a general note and a specification section address the same requirement differently, compare them directly rather than assuming the more specific-sounding statement governs; record the conflict if the project's order of precedence does not resolve it.
A code reference found in the general notes or specifications must be verified against the adopted jurisdiction, permit conditions, and current approved project basis before it is treated as governing. Do not interpret a code citation as permission to redesign the work or substitute an assembly, and do not use a code reference to fill in a design detail the documents do not otherwise provide.
Specifications frequently reference outside standards for testing, tolerances, or installation methods. Confirm the applicable edition and scope of the referenced standard before treating it as a field requirement. Do not invent a tolerance, load value, or test condition because a standard is cited but its specific value is not reproduced in the project documents.
When a drawing note references a specification section, or a specification section references a drawing detail, follow the reference to its destination and confirm the destination correctly identifies the originating condition. A specification section that is never referenced by any drawing note is still binding; record it in the register regardless of whether a drawing points to it.
Record any missing specification section, incomplete product criterion, undefined referenced standard, conflicting general note, or unapproved substitution as a clarification item during this chapter. Do not resolve the conflict by selecting the requirement that seems more reasonable or more common in the trade.
BP-091 – BP-096
Document-Control / Specification Interpretation Qualification
Deliverable set: one specification register covering every section in the received project manual; one requirement table linking topic, requirement, source, affected location, submittal, hold point, test, and closeout item; a set of trade-specific extracts for site, concrete, framing, envelope, roofing, openings, finishes, cabinets, plumbing, electrical, and HVAC work; and one specification summary emphasizing requirements not obvious from the drawings.
| Component | Quantity | Source | Required Fields | Preparation / Purpose |
|---|---|---|---|---|
| Specification register | 1 | Complete project manual as received | Division, section number, title, revision, related trade or assembly | Confirms what was actually received and where each section fits |
| Requirement table | 1 | Extracted product, submittal, execution, testing, and closeout requirements | Topic, requirement, source, affected location, responsible party if documented, submittal, hold point, test, closeout item | Reduces the project manual to field-usable requirements |
| Trade-specific extracts | 11 | Requirement table, sorted by trade | Trade name, applicable requirements, source references | Delivers only the requirements relevant to a given trade |
| Specification summary | 1 | Requirement table and trade extracts | Requirements not obvious from the drawings, organized by priority | Highlights written-only requirements a drawing-only reader would miss |
| Missing-information and RFI log | 1 | Discrepancies found while building the above | Item, description, affected section or note, requested action | Records unresolved items for the document-control process |
| Check | Standard |
|---|---|
| Register completeness | Every section actually received appears in the register; every section referenced by a drawing but not received is logged as missing |
| Hierarchy identification | The project's stated order of precedence, if any, is recorded in the register; no order of precedence is invented if the documents do not state one |
| Requirement traceability | Every entry in the requirement table cites its source section or note and, where applicable, the affected drawing location |
| Standard verification | Every referenced outside standard used in the requirement table has its edition and scope confirmed before being recorded as a field requirement |
| Code cross-check | Every code reference used in the summary is verified against the approved project basis and permit documents |
| Conflict capture | Every conflicting note, undefined standard, or unapproved substitution encountered while building the package is recorded, not silently resolved |
Inspect the finished package using the same checks regardless of which division or trade is involved.
Complete the Specification Summary Worksheet in the Inspection Checklist section below before beginning Chapter 17.
Probable cause: the register was built only from sections referenced on the drawings instead of from the complete project manual as received.
Confirmation: compare the table of contents of the received project manual line by line against the register.
Correction: add every missing section to the register, including sections not referenced by any drawing note.
Reinspection: repeat the completeness check on the corrected register.
Probable cause: the section's revision was not checked against the document-control register before extraction.
Confirmation: compare the section's issue date and revision against the current addenda and substitution log.
Correction: remove the outdated entry from the requirement table and replace it with the current section's requirement.
Reinspection: repeat the register-completeness and hierarchy checks across the full requirement table.
Probable cause: a cited standard was assumed to supply a tolerance, rating, or test value that the project documents never actually reproduced.
Confirmation: locate the exact edition and section of the referenced standard and confirm whether the value in question is actually stated in the project documents.
Correction: remove the invented value from the requirement table and record the missing value as an RFI-style question.
Reinspection: repeat the standard-verification check on every entry citing an outside reference standard.
Probable cause: a general note cited a code section, and the reader treated the citation as sufficient design information without confirming the approved project basis addressed the condition.
Confirmation: compare the code citation against the permit documents and confirm whether a design detail actually exists elsewhere in the current set.
Correction: remove the assumed design detail and record the gap as an RFI-style question rather than a code-derived answer.
Reinspection: repeat the code-cross-check on every code reference used in the summary.
Probable cause: the manufacturer instruction sheet was not compared against the current wall section, detail, or approved submittal before being recorded as governing.
Confirmation: place the manufacturer instruction sheet and the governing detail side by side and identify the exact point of conflict.
Correction: record the discrepancy on the missing-information and RFI log; do not select one document over the other without an approved response.
Reinspection: repeat the conflict check once the approved clarification is received and incorporated.
This chapter ends with a controlled, referenced requirement summary ready for use, not a project manual that must be reread from cover to cover for every later chapter.
| Competency | Independent Pass Standard | Not Demonstrated | With Assistance | Independently |
|---|---|---|---|---|
| BP-091 | Locates every received general note, discipline note, and specification section and correctly confirms issue, revision, and completeness in the register | |||
| BP-092 | Correctly distinguishes named products, acceptable manufacturers, performance specifications, delegated design, allowances, and alternates in the requirement table | |||
| BP-093 | Identifies manufacturer requirements controlling installation, compatibility, warranty, service access, or testing and correctly compares them with the drawings | |||
| BP-094 | Reads performance and reference standards and testing, inspection, and commissioning requirements without inventing an undocumented value | |||
| BP-095 | Identifies code references, occupancy, construction type, energy criteria, and design loads and correctly verifies them against the approved project basis | |||
| BP-096 | Produces a complete specification summary linking product, performance, submittal, execution, testing, code, warranty, and closeout requirements to the applicable drawings and trades |
Mark one column per competency. Only Demonstrated Independently awards the competency; Demonstrated with Assistance authorizes additional supervised practice but does not complete the requirement.
| Deliverable | Status | Items Logged | Verified By | Date | Notes |
|---|---|---|---|---|---|
| Specification register | |||||
| Requirement table | |||||
| Trade-specific extracts | |||||
| Specification summary | |||||
| Missing-information and RFI log |
Total sections received: ____________ Total sections in table of contents: ____________ Discrepancies logged: ____________
Specification package declared complete: ______ (Pass/Fail) Date: ____________ Reviewer name: ____________
With all five deliverable components complete, review the finished specification package against the Acceptance Standards table and confirm every received section is registered, the project's own order of precedence has been identified rather than invented, every requirement-table entry cites its governing source, every referenced standard has a confirmed edition and scope, every code citation has been verified against the approved project basis, and every conflicting note or unapproved substitution has been recorded rather than resolved unilaterally. Complete the Specification Summary Worksheet and resolve any failed item, through the project's document-control process, before beginning Chapter 17.
You have completed the sixteenth chapter in the blueprint-reading sequence: reading specifications, general notes, and product requirements. This chapter required you to locate general notes, discipline notes, and the current project manual and confirm their issue and completeness (BP-091), interpret material specifications and distinguish named products, acceptable manufacturers, performance specifications, delegated design, allowances, and alternates (BP-092), identify manufacturer requirements and compare them with the drawings (BP-093), read performance standards and testing requirements without inventing undocumented values (BP-094), identify and verify code references against the approved project basis (BP-095), and create a complete specification summary (BP-096).
You now have a verified specification register, requirement table, trade-specific extracts, and specification summary for one residential project. That specification package carries directly into the next chapter: comparing plans across trades and identifying conflicts using every discipline checklist built so far.
Retain your completed specification package. You will reuse this exact requirement summary in Chapters 17, 19, and 20.