Part Submission Warrant (PSW) works like the cover page of the entire PPAP package. It summarizes what you are submitting, why you are submitting it, and on what basis you can say: “we are ready for serial production.” By definition, it summarizes the PPAP documentation and is typically required for each part number, unless the customer specifies otherwise.

Here’s the key point: PSW is short, but the consequences of getting it wrong usually aren’t. A mismatch in the part number, submission level, drawing revision, or a vague “reason for submission” can block approval—even if the rest of the package is mostly in good shape.

In this article, we’ll focus on practical issues and real mistakes, but first let’s set the foundation: what PSW is (and what it isn’t), what you actually declare with your signature, and what the customer checks before they mark it as “Approved”.

Part Submission Warrant in practice: what it is and why you need it

PSW = a summary of PPAP (and a formal supplier declaration)

Put simply, PSW is the form that summarizes the entire PPAP submission. In most cases it’s a single page that captures the key information about the part, the production run, the reason for submission, and the submission level you are providing to the customer.

And this is where the word “warrant” matters—you warrant it. Not “I’m sending it because I was asked,” but: “I confirm these samples are representative and were produced using a process that meets PPAP requirements; and I confirm they were produced at the stated production rate.”

In practice, signing the PSW means something like this:

• the samples you submit are not “hand-picked”—as one participant once called them during a training: “the prettiest candies”—they come from the final, intended process that is meant to run in serial production,

• the results (across the whole PPAP documentation) meet the requirements of the design record(s)—and if they don’t, you state it clearly and describe the deviation,

• you have objective evidence in the documentation and you can show it when asked.

That’s why the Part Submission Warrant is the first filter. The customer reads it to confirm the submission makes sense and is formally consistent—before anyone starts checking measurement reports and the rest of the attachments.

PSW is not “the customer signing off on your quality”

Here’s another point many people miss: if the customer signs the PSW on their side, they are not taking responsibility for your data. Some companies state it directly: approving the PSW means the documentation and physical samples have been accepted into the approval process—but the supplier remains responsible for the content and correctness of what was submitted.

So even with an “Approved” status, keep in mind that PSW is still your declaration. If anything is inaccurate or “massaged,” it will come back—usually sooner rather than later.

What the customer sees on the PSW (and checks first)

PSW has quite a few fields, but a handful of them get attention immediately because they reveal inconsistencies right away. In typical PSW guidance (in a PPAP context), you’ll see areas such as:

• customer part number / part name,

• drawing change level and approval date,

• reason for submission (initial, design change, tooling change, material source change, additional manufacturing location, etc.),

• submission level (Level 1–5),

• the declaration section.

One thing to note: these fields are highly “cross-functional.” They touch the drawing, change level, quality, and sometimes logistics. That’s exactly why Part Submission Warrant can expose internal misalignment faster than an audit.

Submission levels: where they come from and why there’s so much confusion

On the PSW you enter the Requested Submission Level—what the customer expects for that submission. And yes: Level 1 is typically “PSW only,” Level 3 is “PSW + samples + complete documentation,” and Level 5 is “complete documentation available for review at the supplier.”

The most common misunderstanding? People assume: “Level 1 = easy mode, I just send one page.” Then the customer asks for evidence and the topic comes back like a boomerang—because in many organizations Level 1 defines the submission scope, not the absence of an obligation to have the full supporting documentation on file. (You don’t email it, but you still need to have it in your system.)

Pro Tip!

If your company works like this—“Quality prepares the PSW, Engineering prepares everything else”—do one simple thing: before submitting the PSW, run a quick number check: drawing revision / change level (both the customer’s and your internal change level, if applicable). Sounds basic, but this is exactly where mismatches happen—and later nobody wants to “own” them.

Why all this matters: PPAP is about serial production, not prototypes

AIAG describes PPAP as an industry standard designed to confirm that a supplier can produce parts consistently during the actual production launch, at the required production rate, and in accordance with the design record/specification.

PSW ties that into a single statement: “yes, these parts come from the serial production process,” and “yes, we have objective evidence in the documentation.”

With that foundation in place, we can move on to the mistakes. Because most PSW problems don’t come from a lack of PPAP knowledge—they come from speed, copy-paste between projects, and the fact that PSW touches several functions at once.

Mistake #1: Submission level entered “from memory”

This one is a classic: the PSW looks fine, the part number matches, someone even collected the signatures… and then the customer replies that documents are missing. Or that you sent too much—but in the wrong submission mode. And it all starts with one field: Requested Submission Level.

Submission level is not “what I have available” or “how we did it last time.” It’s a specific customer expectation. And if it doesn’t match, the rest of the package often stops mattering—because the customer doesn’t know what they’re supposed to evaluate.

What it looks like in customer emails (symptoms)

Here are typical responses you’ll see when the submission level is wrong (or was never confirmed):

• “Please resubmit as Level 3. Current package is incomplete.”

• “We requested Level 2. Why did you send Level 1 only?”

• “Level 1 accepted for PSW submission, but supporting documents must be available. Please confirm you have them.”

• “Submission level not aligned with our CSR / PO. Please correct PSW.”

Sometimes the customer won’t explicitly say “the submission level is wrong.” They’ll simply start asking for missing elements: dimensional results, MSA, capability, material test results… and suddenly you’re doing a first follow-up upload, then another, then another.

What happens next (risk and real-world cost)

Most of the time it leads to three practical consequences:

• approval is put on hold — the customer won’t move forward because the submission level doesn’t match what they received,

• a flood of clarifications — instead of closing it in one go, you get a chain of emails and document rework,

• schedule slip — because the customer reviews only when the submission is complete in the expected format.

One important detail: even if “Level 1” in your company means “we only send the PSW,” for the customer it often means: “you submit the PSW, but the supporting documentation must be available for review when requested.” If you interpret it differently, confusion starts immediately.

What to check in 2 minutes before submitting (without digging through SharePoint)

Make it a small ritual. Two minutes—seriously.

Step 1: Where did your submission level come from?
Open the customer request or portal and find the one sentence that specifies the level. If it’s not there—don’t guess. That’s the moment to ask and confirm.

Step 2: Is your PSW in the customer’s format?
Some customers accept the standard PSW form, others require their own template. If you’re not sure, check their CSR, customer requirements, or their PPAP instruction.

Step 3: Does what you’re submitting match the level?
Not “do you have it,” but “are you actually submitting it” (or is it available for review, if that’s the arrangement).
This is where issues usually show up: the PSW says “Level 3,” but the package is missing the dimensional report—or the Control Plan is still the pre-change version.

Step 4: Is the level consistent with the reason for submission?
Initial submission and a material change are a different conversation than a re-submission after rejection or a deviation. Customers often expect a different set of evidence depending on the reason.

Step 5: One sentence to the customer (if anything is unclear)
Instead of guessing the level, confirm it. That saves you three rounds of “resubmit” later.

Internal mini-check: who needs to say “OK” to the submission level?

Often the problem isn’t on the customer side—it’s internal. Everyone has a different “truth.” A simple setup that works:

• Who defines the level: the person with access to the customer request/CSR (often Supplier Quality / QA / SQE on the supplier side).

• Who confirms the package scope: the person compiling the PPAP submission (because they know what is actually ready—and in which revision).

• Who gives the final green light: the person signing the PSW (because a signature means accountability).

If those roles sit with one person—great. If they’re split, at least you know exactly where mismatches are most likely to appear.

Mistake #2: Part Submission Warrant is unsigned—or signed by “the wrong person”

This is the kind of mistake that hurts the most because it has nothing to do with part quality. (I jokingly call it a “stupid complaint”—like when someone opens a claim but forgets to enter the claimed quantity.) You have the full documentation, the samples look good (hopefully for the rest of the project too 🙂), everything seems buttoned up… and then the customer replies three minutes later: Rejected – missing signature.

And yes—it happens more often than people want to admit. Usually in two scenarios: someone submits the PPAP “in a rush,” or the PSW bounces between departments and finally ends up in an email as a “nearly finished” version.

What it looks like in customer emails (symptoms)

Typical messages:

• “PSW is not signed. Please resubmit.”

• “Warrant must be signed by an authorized quality representative.”

• “Signature missing / date missing / name not legible.”

• “Submitted PSW is a draft version.”

Sometimes the customer won’t even discuss it. They simply close the submission and wait for a corrected resubmission—because an unsigned PSW isn’t a document for them.

What happens next (risk and real-world cost)

• Immediate stop — without a signature, the customer often won’t move forward, because formally there is no supplier declaration.

• Resubmission = a new workflow — in some companies it means a new portal entry, new dates, sometimes even a new “case.”

• Version mismatch risk — once the PSW comes back for correction, it’s easy to resend a different file version than the one the customer already downloaded (and then you get the question: “why did the revision change?”).

Why it happens (most common causes)

• PSW is treated like a cover page and left until the very end—when everyone is already tired of the topic.

• No clear rule on who signs — Quality, Quality Manager, an authorized representative, Project Quality… it depends on the company. Best case: define it in an internal launch / supplier quality procedure (unless a corporate procedure already exists).

• Electronic signature vs scan — one person pastes a signature image without a date; another generates a PDF where the signature “disappears” after conversion.

• Customer portal constraints — you upload the PSW, but the system requires the signature in a specific field or format.

How to avoid it (practical: what to check before submitting)

Create a simple “PSW signature” checklist and keep it next to you when you submit. No debates, no exceptions.

Step 1: Does the PSW have a signature and a date?

• signature of an authorized person (not “whoever was available”)

• signing date

• readable full name (some customers require it—because a scanned signature alone tells them nothing)

Step 2: Is the supplier-side signature in the right place?
Most Part Submission Warrant forms have sections for both the supplier and the customer. You are responsible for completing your part. The customer will fill in their section (or not) depending on their process.

Step 3: Is this the final file version?
A simple file naming rule helps, for example:
PSW_PN12345_RevC_FINAL_signed.pdf
Otherwise you end up emailing something like PSW_draft_v7_final2.pdf and everyone pretends it’s fine.

Step 4: Did the signature break the PDF?
Sounds funny, but during conversions things can disappear: the signature sitting on a layer, the date left in a comment, a stamp placed outside the margins. Open the saved PDF and check it the way the customer will: on-screen, read-only.

Mistake #3: Part Submission Warrant inconsistency vs the rest of the PPAP (PFMEA / Control Plan / dimensional report)

This is the type of issue where the customer looks at the PSW, then opens the dimensional report, then the Control Plan… and within two minutes they realize the documents are living in different realities. Most of the time, two things are out of sync:

• revisions / dates (the PSW says “Rev D,” but PFMEA and Control Plan are still “Rev C”),

• tolerances / characteristics (the drawing has changed, but the dimensional report is still based on the previous drawing revision—or you’re using a different measurement method than the requirement calls for).

What it looks like in real life (symptoms)

The PSW shows the current drawing number and revision, but the PFMEA and the Control Plan are still from before the change.

A new characteristic appears on the drawing (or a tolerance changes), and then in the dimensional report:

• the characteristic is missing altogether,

• it’s there, but with the old tolerance,

• it’s there, but the characteristic numbering doesn’t match the ballooned drawing.

The Control Plan says the characteristic is checked “every hour,” but the report only contains measurements from a single initial setup run.

These aren’t “big” mistakes, but they show up immediately during a basic consistency review.

What it leads to (risk)

This is one of the most common reasons for PPAP rejection: the customer is no longer judging your part—they’re judging the credibility of the submission package. When documents don’t line up:

• the SQE gets a clear signal: “the process isn’t under control, or the documentation isn’t keeping up with changes,”

• the submission is sent back for correction and you end up doing another round of documents: “please update PFMEA/Control Plan and resubmit,”

• sometimes you get an extra question: “were the samples produced after this change, or before it?”

And at that point things get tense, because nobody wants to own the fact that “it was only a documentation update.”

If you want to go deeper and walk through APQP/PPAP step by step using practical examples, you’re welcome to join my training: Advanced Product Quality Planning (APQP) and Production Part Approval Process (PPAP).

Dariusz Kowalczyk