Automotive development runs on prototypes that feed the APQP path. Before the advanced product quality planning (APQP) stages formalize the process, machined prototypes validate the geometry, the material behavior, and the assembly—and the documentation from those parts carries into the program. This guide covers what prototype parts validate, what documentation they carry, and how the pre-APQP work connects to the production path.
Prototypes Feed the APQP Path
APQP is the framework that takes a part from concept to production with quality built in. Before and alongside its phases, machined prototypes provide the evidence: the design works, the materials behave, and the assembly fits. The prototype work feeds the APQP inputs—the design FMEA, the process, and the validation plan.
The consequence is that automotive prototypes are documentation-bearing parts. The material, the inspection, and the revision are recorded, because the records are what the program builds on.
APQP is a phased framework, and prototypes appear in several of its phases. In the planning phase, prototypes validate the product design assumptions; in the design phase, they support the design FMEA by testing the failure modes; and in the process phase, they feed the process validation. The prototype work is not a separate activity—it is the evidence that the APQP documentation references. The buyer should know which phase a prototype serves, because the phase sets the prototype's purpose and its records.
The documentation from each prototype flows into the APQP file. The material certificate supports the material selection; the inspection report supports the dimensional validation; and the revision record shows the design evolution. When the APQP package is reviewed, the prototype records are the proof that the design was tested, not just drawn. The buyer should keep the prototype records with the program, because they are the foundation the later phases build on.
What Prototype Parts Validate
Prototype parts validate specific things: geometry against the design, fit in the assembly, material behavior under the test conditions, and manufacturability of the features. Each prototype is built for the question it answers, and the results feed the next design revision.
The practice is to define the validation purpose before the prototype—what the part proves and what test it serves—and to produce the part for that purpose. The prototype that validates is the one built for the question.
Prototypes fall into classes, and each class validates a different thing. A fit prototype validates the geometry and the assembly; a functional prototype validates the behavior under load or motion; an appearance prototype validates the look and the finish. The classes have different material, accuracy, and documentation requirements, and mixing them is a common source of waste. A fit prototype does not need production materials, and an appearance prototype does not prove the function. The RFQ should state the class, so the supplier produces the right kind of prototype.
The validation tests are often defined in a design verification plan. The plan lists the tests, the samples, and the acceptance criteria, and the prototypes are the samples the tests consume. The buyer should connect the prototype order to the test plan: the sample count, the test conditions, and the report format are agreed before the parts are made. A prototype that arrives without a test plan is a part looking for a purpose; the plan gives it one.
The prototype part's validation scope is agreed before the order. The geometry, the assembly fit, and the material response are the typical checks, while the production process validation and the certification belong to the pilot stage; the buyer who names the prototype's questions gets the right inspection report and avoids paying for evidence the part cannot provide.
Material and Documentation for Development Parts
Development parts carry the material and the documentation the program needs: the material certificate, the inspection report, and the revision record. The documentation connects the prototype to its design intent and its test results.
6CProto's stated documentation includes material certificates, inspection reports, and dimensional data, which covers the typical set for development parts. The scope is defined in the RFQ, and the records travel with the parts.
Revision control is the documentation discipline that protects the program. Automotive development moves fast, and the drawing changes between prototype rounds. Each round must carry its revision, so the test results are tied to the geometry that was actually made. A test run on the wrong revision produces data the program cannot use, and the confusion compounds across suppliers and rounds. The buyer should state the revision control expectation—revision on the drawing, on the PO, and on the reports—before the first order.
The material and inspection records also carry the traceability the program needs. The material certificate ties the part to its alloy and lot; the inspection report ties the dimensions to the drawing revision; and the combination supports the program's quality file. The buyer should specify the records in the RFQ, including the format, so the documentation arrives with the parts rather than after a follow-up.
A Pre-APQP Validation Checklist
Before the formal APQP phases, confirm:
- The validation purpose and the test each prototype serves
- The material and its certificate for the development part
- The inspection report tied to the drawing revision
- The fit and assembly check with the mating parts
- The revision control across the prototype iterations
- The documentation handoff to the APQP inputs
The checklist completes the pre-APQP loop.
The checklist outputs feed the APQP inputs directly. The validation purpose and the test results feed the design FMEA—what can fail and how it was tested; the material and its certificate feed the material selection record; the fit and assembly check feed the dimensional validation; and the revision records feed the change management. The buyer should map the checklist results to the APQP sections, so the prototype work is captured in the program rather than left as loose parts.
The checklist also sets the sample counts. Each validation purpose needs enough samples for the planned tests, plus the parts that will be consumed or damaged. The buyer should size the prototype order from the test plan, not from a round number, so the validation is completed without reordering. The sample count is a planning decision that the checklist makes explicit.
Working with Suppliers on Development Parts
Development parts reward supplier collaboration: the supplier reviews the geometry, flags the manufacturability issues, and produces the prototype with the records the program needs. The collaboration is a review loop, not a handoff.
The practice is to share the validation purpose and the documentation requirements with the supplier, and to use the design review to catch issues while the changes are cheap. The supplier that works the loop is the one that accelerates the program.
The collaboration rhythm matters as much as the content. Automotive development runs on milestones, and the prototype orders should align with them: the design review before the order, the first article after it, and the test results feeding the next design review. The buyer should agree the cadence with the supplier—what is reviewed, when, and who decides—so the loop moves at the program's pace. A supplier that reports the first article and waits is a vendor; one that flags the risk and proposes the fix is a partner.
Change management is the collaboration's safety net. When a design change happens mid-order, the change is documented—the revision, the impact on the machining, the cost, and the schedule—and approved before the supplier proceeds. The change process protects both sides: the buyer knows what was made, and the supplier knows what was authorized. The buyer should establish the change process with the supplier before it is needed, because the process that is defined in advance works better than the one invented at the moment of the change.
When Prototypes Become Pilot Parts
The validated prototype becomes the pilot part when the program moves toward production. The transition keeps the functional geometry and the documentation standard, while the process matures toward the production intent. The prototype evidence is the pilot's starting point.
The planning note is to keep the geometry and the records consistent across the transition, so the pilot builds on the validated design rather than re-discovering it.
The transition also changes the process economics. Machined prototypes carry the cost of machining, and the pilot run asks whether the volume justifies a tooled process—casting, molding, or forging. The buyer should compare the routes at the forecast quantity before the transition, because the process change is a cost and quality decision, not just a volume decision. The prototype validated the design; the transition plan validates the economics.
The pilot run is the first test of the production process with the production intent. The pilot parts are produced with the process controls, the inspection, and the documentation that the program requires, and they validate the process before the full production commitment. The buyer should use the pilot to confirm the process capability, the yield, and the records, because the pilot is the last cheap place to find the problems. The program that pilots carefully is the one that produces reliably.
Request Development-Part Support
Automotive development parts are evidence-bearing prototypes: geometry, material, and documentation feeding the APQP path. The support confirms the validation purpose, the material, and the records.
6CProto's CNC machining service produces development prototypes and test parts, and the automotive industry page describes the application context. The engine component article covers the production side. Request development-part support through the quote page with the validation purpose and the documentation requirements, and the engineering team can confirm the prototype and the records.
Conclusion
Automotive prototypes feed the APQP path with geometry, material, and documentation. Each part is built for the question it validates, and the records carry into the program. The prototype work is the evidence the program builds on.
Project input checklist
- Validation purpose and test per prototype
- Material certificate and inspection report
- Fit and assembly check
- Revision control across iterations
- Documentation handoff to the APQP inputs
FAQs
How do prototypes connect to APQP?
They provide the evidence the APQP phases build on: geometry validation, material behavior, fit, and the documentation that feeds the design and process inputs.
What does an automotive prototype validate?
Geometry against the design, fit in the assembly, material behavior under test, and manufacturability. Each prototype is built for the question it answers.
What documentation do development parts carry?
Material certificates, inspection reports tied to the drawing revision, and the revision records. The scope is defined in the RFQ and travels with the parts.
When does a prototype become a pilot part?
When the program moves toward production, keeping the functional geometry and the documentation standard while the process matures toward the production intent.