AIAG separates launch planning from the Control Plan record

Separate manuals clarify two connected control records

The direct answer in AIAG's public manual catalogue is that APQP and Control Plan are connected but no longer presented as one combined publication. APQP is identified as a third-edition manual and Control Plan as a standalone first-edition manual. AIAG's public APQP and Control Plan material says the separation emphasizes the control plan's importance in product development and can support more timely updates as systems evolve.

For operating teams, that makes a useful distinction. APQP is the broader product-quality planning and launch-governance record. The control plan is the maintained description of how relevant product and process characteristics are controlled in operation. A system can link the two without making them identical: launch milestones, risks, sourcing, design and process evidence, approvals, and readiness decisions should remain traceable to the control methods that move into production.

Planning evidence and operating controls change on different clocks

AIAG's public description of APQP 3rd Edition highlights successful launch planning and names areas such as sourcing, change management, program metrics, risk-mitigation plans, and gated management among the updates. Those elements point to program-level evidence: who owns a deliverable, when it is due, which input and acceptance criterion govern it, what risk remains, and what decision permits the program to advance.

The public Control Plan overview focuses on developing and effectively using control plans. It names clarification of requirements and APQP linkages, a Safe Launch requirement, examples for highly automated manufacturing, software guidance, and revised support materials. Those are control-record concerns: characteristics, methods, frequencies, responsibilities, reaction paths, phases, and revisions have to remain usable where the process is run. A completed APQP gate should not freeze an operating plan that later evidence shows must change.

The digital thread must preserve boundaries as well as links

A quality platform should connect customer and program requirements, special characteristics, design and process analyses, process flow, measurement and control decisions, readiness evidence, submissions, production records, nonconformities, and controlled changes. But linkage is only useful when the system preserves source, version, owner, approval, effectivity, and direction. Copying the same text into several forms can create apparent alignment while leaving teams unable to tell which record governs.

The system should also expose divergence. If a process change alters a control method, reviewers need to know which APQP deliverables, risk analyses, work instructions, measurement studies, submissions, training, and customer approvals may be affected. If a launch finding changes a requirement, the control plan should not remain silently detached. The test is a reviewable impact chain and disposition, not a dashboard that reports every artifact as complete.

What a buyer should ask a quality platform to demonstrate

Use one real product and process from planning through launch and stable production. Ask the provider to show a program requirement entering APQP, related evidence reaching a gate, a control plan becoming effective, Safe Launch handling under the organization's approved method, a changed characteristic or process, impact assessment, updated approvals, and the historical record. Introduce an overdue item, an unapproved change, and conflicting revisions to see whether the platform blocks, escalates, or merely displays them.

AIAG's catalogue establishes the identity and public scope of the manuals; it does not disclose their licensed technical content or replace an authorized copy. It also does not certify a product, prescribe one software architecture, or decide customer-specific requirements. Quality, engineering, manufacturing, supplier-quality, customer, audit, and legal owners must establish the applicable criteria. Buyers should evaluate whether software can support and evidence that approved system without claiming the tool itself creates conformity.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Quality Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.