Millwork

AWI, AWS & NAAWS: Using Architectural Woodwork Standards in a Drawing Package

A standards reference becomes useful only when the drawing package identifies the governing edition, scope, quality requirement, and review responsibility.

IN THIS RESOURCE

Practical guidance for clearer documentation

Architectural woodwork standards can help a project team describe expected materials, workmanship, tolerances, appearance, performance, and review criteria. They do not work as a shortcut phrase. A useful specification and drawing package identifies the exact document and edition that govern the relevant scope, then makes the project-specific decisions visible enough for review. This guide explains how AWI, AWS, and NAAWS references commonly appear in millwork, joinery, and casework documentation without treating them as interchangeable or making a certification claim.

SECTION 01

Start by identifying the exact reference

AWI is the Architectural Woodwork Institute. AWI publishes a family of standards, including standards for subjects such as submittals, care and storage, materials, architectural wood casework, millwork, and wood trim. A reference to AWI should therefore be read as a request to identify the specific standard, edition, section, and scope that the contract documents actually cite—not as a generic instruction to apply every AWI publication.

AWS means Architectural Woodwork Standards. It is a publication title that may appear in older specifications and project records, including references to the second edition. NAAWS means North American Architectural Woodwork Standards. NAAWS is developed collaboratively by the Architectural Woodwork Manufacturers Association of Canada and the Woodwork Institute. NAAWS 5.0 became effective on September 1, 2026. A project may still be governed by an earlier cited edition, so an active project should not silently replace its stated standard with a newer one.

An acronym alone is not a complete requirement

Phrases such as “AWI quality,” “AWS compliant,” or “to NAAWS” leave important questions unanswered. The package should identify the governing publication and edition, applicable section or product scope, any stated quality grade, performance or appearance requirement, and the project documents that take priority if information conflicts.

SECTION 02

Turn the standard reference into a reviewable drawing package

A shop drawing does not need to reproduce a standard. In fact, copying a partial table or isolated note can remove the context needed to apply it correctly. The better approach is to cite the governing reference precisely, then show the particular item, material, finish, construction condition, hardware, dimensions, and interfaces that the project needs reviewed.

For example, a casework elevation may identify the item tag, room or location, finish reference, door and drawer arrangement, hardware status, and the relevant specification section. Related plans and sections can show depths, returns, service clearances, adjacent finishes, and concealed supports. The standard reference gives a framework; the drawing communicates the proposed project-specific solution.

  • Named governing standard, edition, and applicable scope
  • Current project specification, drawing, and finish references
  • Item tags and locations that connect views to the project
  • Visible material, finish, hardware, and interface decisions
  • Clear issue status, reviewer, and route for unresolved questions

Keep source information traceable

Record the source revision used for the drawing and identify any field dimension, material sample, hardware approval, or coordination decision that remains open. A standard does not make an unknown site condition known; it helps a team apply an agreed requirement once the relevant project information is available.

SECTION 03

Separate quality criteria from project responsibility

Standards can provide criteria for evaluating a defined product scope, but they do not automatically assign every design, engineering, field-measurement, installation, or approval responsibility. Contract documents and the project team’s agreed review process should identify who confirms design intent, who verifies dimensions and site conditions, who approves samples or substitutions, and who authorises an issue to proceed.

This distinction matters when a drawing develops a construction solution. A documentation team can make references visible, identify missing information, and prepare a coordinated proposal for review. It should not imply that a generic standards citation resolves a conflict in the design documents or transfers a decision that belongs to the architect, contractor, fabricator, consultant, or owner.

Do not turn a note into a certification claim

A drawing should not state that a manufacturer, installer, or project is certified or compliant unless the responsible party has the authority, contractual basis, and evidence to make that statement. MISTICO DESIGN provides technical documentation support; this article is educational guidance and is not a certification, inspection, legal opinion, or substitute for the governing published standard.

SECTION 04

Manage edition changes deliberately

Standards change. NAAWS 5.0, for example, is now effective, while existing specifications may still cite a prior NAAWS edition or an AWS edition. The right response is to read the contract documents, confirm the referenced edition, and raise a documented clarification when a newer publication is proposed. A later edition may contain useful information, but it does not automatically amend an already-issued project requirement.

During a submittal review, list the standard reference with the drawing issue and keep any agreed interpretation, deviation, or substitution in the controlled project record. This makes it easier to understand which requirement governed a particular item if the package is revised later.

Use official sources for the governing text

Consult the publisher’s current official material and the complete document cited in the project. Summaries, excerpts, old PDFs, and informal checklists can be useful orientation tools, but they are not a safe replacement for the controlling edition or for project-specific professional review.

PUT THE GUIDANCE INTO PRACTICE

Keep the project context visible.

For a millwork package, start by agreeing the current architectural references, visible finish intent, location data, and the point at which dimensions must be checked on site. This makes it easier to distinguish a proposed drawing solution from a confirmed condition, and gives reviewers a clear route for resolving the difference.

CONCLUSION

Use the right information at the right time.

AWI, AWS, and NAAWS references become valuable when they are precise. Identify the governing publication and edition, connect it to the actual product scope, make project decisions visible in the drawing package, and keep responsibility and approval routes clear. That approach supports a more dependable review process without overstating what a standards note can do.

FAQ

Frequently asked questions

Are AWI, AWS, and NAAWS the same thing?

No. AWI is an organisation that publishes multiple standards. AWS is a specific Architectural Woodwork Standards publication that may be cited in older project documents. NAAWS is the North American Architectural Woodwork Standards developed by AWMAC and the Woodwork Institute. Read the exact cited edition and scope before treating any of them as a project requirement.

What should a millwork shop drawing show when a standard is cited?

It should cite the governing document as required, connect the item to current project specifications and references, and show the material, finish, hardware, dimensions, interfaces, and unresolved decisions relevant to that item. The precise content depends on the project scope and review requirements.

Can a drafting team certify compliance with an architectural woodwork standard?

Not merely by preparing a drawing. Any compliance or certification statement needs to be made by the party with the contractual responsibility, authority, and supporting evidence. Documentation should avoid claims it cannot substantiate.

Should a project automatically use NAAWS 5.0 now that it is effective?

No. Use the edition incorporated into the project documents unless the authorised project parties issue a documented change or clarification. A newer standard does not automatically replace the cited requirement on an active project.

HAVE A DRAWING PACKAGE?

Share your references, scope, and required deliverables with MISTICO DESIGN.