Does AWS D1.1 specify how a fabricator must organize their WPS library?

AWS D1.1 does not prescribe a particular filing or numbering system for WPS documents. It requires that the WPS and supporting PQR be available for review by the inspector and the engineer. How you organize and control them is up to you — but an auditor will assess whether the system reliably puts the right WPS in front of the right welder for the right joint. If your system cannot demonstrate that, it fails the audit regardless of how the documents look individually.

Can I use the same WPS number across two different projects?

Technically AWS D1.1 does not prohibit it, but it is poor practice. If the same WPS number appears in two project packages with different revisions or supporting PQRs, it creates confusion at the welding table and potential errors in audit documentation. Use a project prefix (e.g., P2024-WPS-003 for a 2024 project) or a common WPS library system where each WPS has a unique number that is the same document across all projects.

What happens if a WPS needs revision mid-project?

You revise the WPS, increment the revision indicator, and re-submit for engineer review per the contract requirements. Welders must be notified of the revision. Any welds made under the old revision that are within the qualified range of the new revision are generally acceptable — the revision did not invalidate past work if the essential variables were unchanged. If an essential variable changed, the prior welds must be evaluated against the version of the WPS in effect when they were made.

How many WPS documents does a typical structural fab shop need?

It varies widely by shop scope. A shop doing only SMAW and FCAW-G on A36/A572 structural sections in 3G and 4G positions might need 4-8 WPS documents to cover their work. A shop doing multiple processes (SMAW, SAW, FCAW-G, GTAW root), multiple base metal groups, and high-strength steels could have 30+ WPS documents. Adding ASME IX or AWS D1.6 stainless scopes multiplies the count. Shops consistently underestimate how many WPS they need until an auditor points out uncovered conditions.

WPS Library Control Across Multiple AWS D1.1 Projects

Running parallel structural projects creates WPS document-control headaches. How QC managers organize, version, and submit WPS packages without mix-ups under AWS D1.1.

A fab shop running three structural projects at once might be welding under a dozen or more active WPS documents — different processes, different base metal groups, different thickness ranges, different client engineers reviewing them. The procedural math is not complicated, but the document-control problem is real.

Projects that run well on procedures during the bid phase run into trouble when a WPS needs a mid-project revision, when a third-party auditor asks for the WPS that was in use on a specific weld made six months ago, or when a new project engineer demands a format the shop has never produced. Managing a WPS library is not a paperwork exercise. It is quality infrastructure.

The Core Problem: One Library, Many Stakeholders

AWS D1.1 requires that the welding procedure specification and its supporting PQR be available to the inspector on the project. What the code does not specify is how to manage those documents across multiple concurrent projects, each with its own engineer of record, inspector, and audit requirements.

The trouble starts when:

The same WPS applies to multiple projects but different engineers have different revision histories
A WPS is revised for one project and the shop floor gets the new version while another project is still under the old revision
A completed project is audited and nobody can produce the specific WPS revision that was active during fabrication
An NDE rejection requires tracing back which WPS controlled the weld at the time — and the document trail is broken

None of these problems requires a complicated system to solve. They require a consistent system.

Separating the Library From the Project Package

The most functional structure for a shop with ongoing work is a master WPS library maintained centrally, separate from individual project packages.

Each WPS in the master library has:

A unique identification number that never changes (even through revisions)
A revision level (Rev. 0, Rev. 1, Rev. A, etc.)
Its supporting PQR reference
An effective date for each revision
A superseded indicator that marks old revisions as inactive

Project packages then reference the master library. The project's welding schedule or weld map says "Joint 1A: WPS-012, Rev. 2." The actual document lives in the library. If you need to show what Rev. 2 said, you pull the archived Rev. 2 document.

This separation means that updating a WPS for one project does not silently change the document referenced by another project. Each project's package contains a snapshot of the revision in use at contract award or at first weld, and any mid-project updates are formally logged.

For how to structure WPS revision control and numbering within the library, see WPS revision control best practices and WPS numbering schemes for fabrication shops.

What a WPS Package Submission Looks Like Per Project

Most structural project specifications — particularly those under AISC certification requirements or government contracts — require the fabricator to submit WPS packages to the engineer of record for review before welding begins. That submission is not the master library. It is a project-specific package.

A well-organized submission package includes:

Cover list. A table of all WPS documents being submitted, keyed to the joint types and processes they will be used for on this project. Engineers reviewing dozens of projects do not want to hunt through a stack of loose documents — give them the index first.

WPS documents. One page per WPS (AWS D1.1 Annex M format is the common baseline). Include the revision level and effective date on the face of the document.

Supporting PQRs. Each WPS references one or more PQRs. Include the test coupon records, the mechanical test results (tensile, bend), and the independent laboratory certification. If one PQR supports multiple WPS documents, include it once and reference it from each WPS.

Welder qualifications. The WPQ for each welder who will be used on the project, current (within the 6-month continuity requirement of AWS D1.1 Clause 6.4.1). See welder continuity tracking and the 6-month rule for how to stay current without surprises.

Prequalified statement (if applicable). If any procedures are prequalified under Clause 5 rather than PQR-backed, a statement identifying the prequalified basis and confirming the joint details are within prequalified limits.

The Mid-Project Revision Problem

A WPS may need revision mid-project for legitimate reasons: a filler metal becomes unavailable, a base metal substitution is approved, the owner upgrades the NDE requirement. How that revision is handled determines whether the project documentation is clean or messy.

Non-essential variable changes (travel speed range, bead size, sequence documentation) do not require PQR requalification. Revise the WPS, increment the revision level, and issue the new document. Notify the inspector. Annotate the weld log that welds from date X forward are under Rev. 2.

Essential variable changes (new base metal group, different filler classification, process change) require a new PQR test or a second PQR to support the expanded range. If the PQR already exists in the library covering the new condition, you can reference it and revise the WPS. If it does not exist, you cannot make the change without qualification testing.

Either way, the old revision is not deleted. It is marked superseded, archived, and must be retained. The audit for a project from two years ago may require the Rev. 1 document that was in effect at the time.

See what constitutes a WPS essential variable vs. nonessential under AWS D1.1 for guidance on which changes trigger requalification.

Audit-Proofing a Multi-Project Library

When a third-party auditor or owner's inspector reviews your WPS system, they are asking two questions: (1) does a valid WPS exist for every weld I can find on this project, and (2) can you prove the WPS in use was appropriate when the weld was made?

The documentation that answers both questions is not complicated, but it has to be in place before the audit:

Weld maps or joint matrices. Every weld has a WPS number assigned. If the WPS changed mid-project, the weld map shows the effective date of the change and which welds fall under which revision. See weld maps and WPS traceability in production.

Archived revision history. Every WPS revision is retained with its effective date. The archivist must not overwrite prior revisions — superseded revisions are closed out but preserved.

Inspector sign-off at weld start. Before welding begins on a joint, the inspector confirms the WPS number on the weld map matches the document at the weld station and that the welder's qualification covers it. This is an on-the-floor step, not a paperwork step.

Calibrated control at the weld station. The welder at the station should have the current revision of the WPS, not a photocopy of last year's version, not a phone photo. If the shop issues paper copies, every copy must carry a "controlled document" stamp with the revision and issue date.

For a full checklist of what auditors and third-party inspectors look for in a WPS documentation review, see common WPS deficiencies found in third-party audits.

Software vs. Spreadsheets vs. Paper

Small shops with four or five WPS documents can manage with a well-maintained folder on a shared drive. As the library grows and projects multiply, spreadsheet-based control starts to fail:

Revision tracking breaks when multiple people edit the same file
No automatic alert when a welder's WPQ expires and the WPS they are qualified on has changed
Cross-project audit packets require manual assembly every time

A purpose-built WPS management system maintains the master library, tracks revision history, links PQRs to WPS documents automatically, flags welder continuity lapses, and assembles audit packets on demand. See how WPS Welding structures multi-project WPS libraries and audit packet generation.

The document control burden is not the point of a fab shop. Welding is. A system that makes procedure control invisible — so the QC manager can focus on the weld, not the paperwork — is what the shop actually needs.

Rule library based on AWS D1.1:2025; verify against your governing edition. Document retention and submission requirements vary by contract; AISC certification programs may impose additional requirements beyond AWS D1.1 alone.