PPAP — Production Part Approval Process, AIAG 4th Edition

All 18 elements, seeded on creation

Creating a submission writes all eighteen AIAG elements immediately — numbered exactly as the manual numbers them, from 1 — Design Records through 18 — Part Submission Warrant — together with an empty Part Submission Warrant. Elements the submission level does not require are seeded as WaivedAtLevel rather than left off the record, so the warrant grid always shows the complete eighteen and states explicitly which ones the level waived.

Submission levels 1 to 5

• Level 1 — Part Submission Warrant only.
• Level 2 — a five-element subset: Design Records, Engineering Change Documents, Sample Production Parts, Customer-Specific Requirements, and the PSW.
• Levels 3, 4, and 5 — the complete eighteen.

Level 3 is the default. Worth being precise about, because vendors are usually vague here: in Qontiv, levels 3, 4, and 5 carry the same required-element set. What separates them in the AIAG manual is what you send versus what you retain at the manufacturing site, and which subset a specific customer defined — that is a shipping and customer-agreement decision, and Qontiv does not automate it. Level 1 and level 2 genuinely do change the required set.

Elements point at live records, not attachments

An element can be sourced from a controlled document, or from a typed link to the actual record in Qontiv: the process FMEA, design FMEA, control plan, process flow diagram, MSA study, SPC capability study, or engineering change order. When it is a typed link, the submission shows a resolved snapshot of that record — code, revision, status, owner, last modified — plus a count of what is inside it: PFMEA process steps, control-plan characteristics, process-flow steps. If the control plan the submission references is revision C with 47 characteristics, that is what the element shows, because it is reading the control plan rather than a copy of it.

Two details a quality engineer will check: element 16 (Checking Aids) accepts an MSA study as its source, and element 17 (Customer-Specific Requirements) carries its evidence as a set of linked customer-specific requirement records rather than as a single source document.

The Part Submission Warrant, hash-bound to the elements it covers

The PSW is a first-class record carrying the AIAG field set — organization name, part number and manufacturing plant address, customer name and part number, part name, engineering change level and date, purchase order number, checking aid number, submission level, appearance item, and submission results.

When the supplier signs it, three things happen in the same act. A 21 CFR Part 11 §11.50 electronic signature is created with the signer's password re-verified at the moment of signing and a stated meaning of PPAP PSW supplier signed. A signature record is written for the Supplier Quality role — immutable, and unique per role, so a role cannot sign twice. And a SHA-256 hash is computed over the ordered element set, including every typed source link, and stored on the warrant with its timestamp.

That hash is the lock. While it is present, element edits are refused outright — the API answers "Elements are locked — the Part Submission Warrant has been signed by the supplier." This is §11.70 signature-record linking made concrete: the signature is bound to a specific state of the eighteen elements, so the package cannot be quietly reshaped after it was signed.

What the submission gate actually checks

Submitting for review is not a status field a user can set — the update command carries no status at all, so a submission moves only through the dedicated commands. Submitting requires the transition to be legal, requires the supplier signature to exist, and requires every element the submission level demands to be in Approved, Not Applicable, or Waived-at-Level. Then it runs the customer-specific requirement rules for the customer in question, and a rule can block the submission with a written reason. A customer's own documented requirement stopping a package before it reaches them is the check most PPAP processes do by memory.

Customer counter-signature portal

A submission that has been submitted for review can issue an anonymous magic link for the customer's approver — no Qontiv account, no license. What ships, precisely:

• Hash-only token storage. 32 random bytes, URL-safe, returned to you once at issuance; only the SHA-256 hash is stored, under a unique index.
• 14-day hard cap on link lifetime, applied server-side — a longer request is capped, not honored.
• One-time use, consumed atomically. Consumption is a single conditional update decided by rows affected, so two simultaneous clicks cannot both succeed.
• Rate limited to 10 requests per 60 seconds per client IP, with no queue.
• Neutral failure. An invalid, expired, or already-used link returns 401 and lands on one indistinguishable expired page — the portal never reveals which of the three it was.
• Tenant discovery from the token itself. The link table is under forced Postgres row-level security; the single privileged lookup that resolves which tenant a token belongs to is scoped to that one row and nothing else.

The customer signs the way customers actually sign: they counter-sign the PSW in their own system and upload the signed PDF, up to 20 MB. Qontiv stores it as a controlled document named for the signer, records the customer signature as externally sourced with the signer's name and email, and moves the submission to Customer Approved — refusing with a conflict if the submission has already been customer-signed or has not yet been supplier-signed. The upload is attributed to the portal actor in the audit trail rather than to an internal user.

If your customer signs in a review meeting instead, a customer signature can be recorded directly in Qontiv — either as an in-platform password-verified signature, or as an external signature that requires the signer's name, email, and the uploaded signed document together. Either path writes the same immutable signature record.

The PSW as a printable warrant

Qontiv renders the warrant as a US Letter PDF headed AIAG PPAP 4th Edition: submission information, organization information, the eighteen-element grid with each element's AIAG number and status, the declaration, and the signature block. Until the customer counter-signs, the customer block prints PENDING CUSTOMER AUTHORIZATION. The footer carries the generation timestamp in UTC and the tenant name — and the timestamp is supplied to the renderer rather than read from a clock inside it, so the document's content is determined by the submission, not by when the render happened to run.

Repeat orders

A repeat-order submission clones from an existing submission — but only from one the customer approved, carrying forward the level, part, and customer context with a new purchase order number and a stated reason. You cannot template a repeat order off a rejected or in-progress package.

Audit trail

Every non-signature change to a submission writes an audit row with the action, the detail, the user, the timestamp, and the site — including SubmittedForReview andCustomerPortalLinkIssued. Signed events additionally bind an electronic signature record. When an auditor asks who issued the customer link and when, the answer is a query, not an email search.

Regulatory mapping

Qontiv is designed for compatibility with these standards and supplies the records and controls an auditor asks for. Your certification body audits you, not us — Qontiv itself is not certified to any of them.

Scope — what this does and does not do

• Levels 3, 4, and 5 share one required-element set. Qontiv does not derive a customer-defined level 4 subset or automate the level 5 retain-at-site distinction.
• The portal does not distribute the PSW. It presents the submission summary and accepts the counter-signed upload; the warrant PDF is generated and stored in Qontiv, and you send it to your customer with the link.
• No in-portal signing ceremony. The customer's signature arrives as an uploaded counter-signed PDF, recorded as an external signature — which is how most OEM approvers actually work, and it is recorded as external rather than dressed up as an in-platform signature.
• Dimensional results and some elements are document-sourced. Not every one of the eighteen has a typed link to a live record; where it does not, the element carries a controlled document.

Availability

PPAP is in the scope of the IATF 16949 compliance package, which is available today as a flat annual add-on purchasable at every tier including Core — the package adds clause-mapped evidence, SOPs, and validation documentation on top of the records the platform produces. See pricing for the full ladder, orrequest a demo to walk a submission against your customer's own PPAP checklist.