01
Configuration baseline
Release a build package containing CAD/drawing, BOM, software where relevant, material, process and controlled deviations.
Evidence route
Build index with revision/date and issuing authority
NPI configuration control
Prototype iteration control: preserve the learning between revisions.
Fast iteration loses value when CAD, BOM, build instructions, samples, test results and decisions diverge. PartVerity assigns revision authority, build genealogy, issue status and approved change records so each build advances the product rather than creating parallel truths.
Decision premise
Iteration question: which exact configuration produced the evidence, and who authorised the next change?
Engineering control
Six controls for revision-safe prototype loops
Speed comes from clear baselines and decisions—not from skipping the record that tells the next team what changed.
02
Build genealogy
Link every physical sample or assembly to supplier, route, lot, setup/orientation, rework and configuration baseline.
Evidence route
Unique build/sample ID and traveller
03
Issue register
Separate observed facts, test failures, DFM questions and improvement ideas; assign severity, owner and status.
Evidence route
Numbered issue log linked to evidence
04
Change approval
Describe reason, affected requirements, parts/documents, verification needed and implementation point before release.
Evidence route
Approved engineering change and effectivity
05
Result transfer
Attach raw data, conclusions, photographs, NCRs and unresolved limits to the exact tested configuration.
Evidence route
Signed test/build report and decision minutes
06
Next-build gate
Verify that required changes are incorporated, old files withdrawn and the new build objective is explicit before order release.
Evidence route
Pre-build checklist and configuration acknowledgement
Decision matrix
Iteration event to configuration response
Not every learning requires a design revision, but every implemented change needs an authorised record.
| Iteration event | Control response | Evidence link |
|---|---|---|
| Supplier proposes DFM change | Numbered request and requirement-impact review | Approval plus updated released files |
| Test exposes failure | Contain samples, record facts and define investigation | Sample IDs, raw data and issue record |
| Quick rework for learning | Mark reworked sample and restrict conclusion scope | Rework record and test annotation |
| Parallel prototype routes | Keep distinct build baselines and comparison criteria | Route-specific genealogy and results |
| Revision moves to pilot | Freeze baseline and transfer open risks | Pilot release index and open-item register |
Claim boundaries
Iteration habits that destroy traceability
Overwriting CAD without preserving the tested revision.
Reusing sample names such as ‘latest’ or ‘final’.
Applying supplier changes before authorised disposition.
Carrying lessons into production through memory instead of controlled records.
Technical context
Use guidance to frame the review—not to replace project evidence.
External context for lifecycle stages, configuration management, approvals and cross-functional visibility. PartVerity applies these principles to supplier-led prototype builds.
Autodesk NPI process guide