EVT vs DVT vs PVT: Deliverables and Exit Criteria

EVT, DVT and PVT are hardware-development phases used to reduce different risks before volume production. EVT asks whether the engineering architecture works. DVT asks whether the production-intent design meets its requirements. PVT asks whether the manufacturing process can repeatedly build that design at the required quality.

These names are widely used but not universal standards. Companies define gates differently. The practical value comes from written deliverables, objective exit criteria, controlled configurations and evidence-based review—not from the phase label itself.

In brief: Do not advance because a build is complete. Advance when the agreed risks have been tested, failures are dispositioned, the configuration is traceable and decision-makers approve the exit evidence.

Explore GMIC EVT/DVT/PVT manufacturing support or discuss an AI hardware development program.

EVT vs DVT vs PVT at a Glance

Phase	Primary question	Typical design maturity	Main output
EVT	Does the architecture work?	Engineering prototypes; changes expected	Verified subsystems and resolved high-risk design issues
DVT	Does the production-intent design meet requirements?	Near-final electrical, mechanical and firmware design	Requirement-level verification and release-ready design evidence
PVT	Can the factory repeatedly build the released design?	Production-intent design, tooling and process	Validated line, fixtures, work instructions and controlled pilot output

The boundaries can overlap. Long-lead tooling may start before every EVT item closes, and compliance pre-scans may occur throughout development. Any overlap should be a documented risk decision with an owner and recovery plan.

Verification, Validation and Production Readiness Are Different

Verification asks whether design outputs meet defined inputs. Validation asks whether the product meets user needs and intended use in the relevant environment. Production validation asks whether the manufacturing process can consistently reproduce the approved design.

The FDA’s design-control overview describes design inputs, outputs, reviews, verification, validation, transfer and change control as connected activities. The page is specific to regulated medical devices; EVT, DVT and PVT are not FDA-defined universal phase names. The underlying distinction between verification, validation and design transfer is useful across hardware programs.

ISO’s quality-management overview likewise emphasizes controlled processes, customer requirements, evidence and continual improvement. The applicable quality system depends on the product, company and market.

EVT: Engineering Validation Test

EVT should attack the highest technical risks while design changes remain comparatively affordable.

What EVT should prove

Core architecture and processor selection are viable.
Power rails, charging, battery protection and sleep states behave as intended.
Microphones, loudspeaker, codec and audio routing support the target workflow.
Radios, antennas and coexistence are feasible in the intended form factor.
Sensors, buttons, indicators and interfaces function.
Thermal behavior is understood under representative loads.
Firmware can initialize, control and update the major subsystems.
Mechanical envelope and critical interfaces are feasible.

Typical EVT deliverables

Requirements and risk register with test mappings.
Schematic, PCB layout, BOM and known-deviation list.
Prototype enclosure files and assembly instructions.
Firmware build, configuration and release notes.
Bring-up checklist and subsystem test reports.
Power, thermal, RF, audio and interface measurements.
Failure log with root-cause status and disposition.
Updated cost, schedule and supply-risk assessment.
EVT review record and approved next-phase plan.

EVT exit criteria

EVT can exit when critical architecture risks are closed or explicitly accepted, major subsystems meet their provisional requirements, remaining failures have credible corrective plans and the next design revision is sufficiently defined.

EVT should not exit merely because most prototypes power on. Intermittent resets, excessive sleep current, unstable RF, clipped audio, thermal throttling or an unmanufacturable stack-up can become expensive DVT failures.

DVT: Design Validation Test

DVT evaluates the production-intent design against the controlled requirements. The enclosure, PCB, components, firmware and accessories should be close enough to the intended release configuration that results remain meaningful.

What DVT should prove

Functional and performance requirements are met.
User workflows operate on integrated hardware and software.
Mechanical, environmental and reliability targets are met.
Audio, RF, power, battery and thermal performance meet acceptance limits.
Product safety and compliance plans are supported by representative units.
Design tolerances and unit-to-unit variation are acceptable.
Manufacturing test coverage can detect relevant defects.
Design documentation is complete enough for controlled transfer.

Typical DVT test groups

Functional and interface verification.
Battery runtime, charging, protection and aging-related checks.
Acoustic performance, microphone consistency and loudspeaker behavior.
RF performance, coexistence and antenna detuning.
Drop, vibration, ingress, temperature and humidity as applicable.
Connector, button, clip and wear-cycle testing.
Firmware update, recovery and fault-injection testing.
Packaging and transport tests.
Compliance pre-scan or formal tests on representative configurations.
Usability validation where required by the product and market.

FDA’s 2026 human-factors guidance emphasizes intended users, uses and environments for regulated medical devices. For non-medical products it is not a regulatory requirement, but the same discipline helps prevent a technically compliant device from failing in its real workflow.

DVT deliverables

Released or release-candidate design package.
Traceability from requirements to tests and results.
Test plans, raw data, reports and deviations.
Reliability and environmental results.
Compliance strategy and evidence status.
Golden samples and cosmetic standards.
Approved component list and substitution controls.
Manufacturing BOM, drawings and assembly requirements.
Draft work instructions and quality plan.
DVT review record with open-item ownership.

DVT exit criteria

DVT should exit when required tests pass on the controlled configuration, failures are resolved or formally accepted, compliance-critical design is stable, tooling and fixtures are approved, and the production package is ready for a controlled pilot.

PVT: Production Validation Test

PVT validates the production system, not just the product design. Units should be built with production-intent materials, tooling, operators, line equipment, work instructions, programming and test stations.

What PVT should prove

The line can build the approved configuration repeatedly.
Work instructions are clear and executable.
Fixtures, programming and traceability systems function.
Incoming, in-process and final inspections detect defined defects.
Cycle time, staffing and material flow are understood.
Yield losses have recorded causes and corrective actions.
Packaging, labeling and serialization are controlled.
Nonconforming material and rework follow approved processes.
Finished units meet release requirements.

PVT deliverables

Controlled manufacturing package and revision list.
Line layout, process flow and station instructions.
Approved fixtures and calibration requirements.
Test limits, software versions and golden-unit controls.
Build records, serial traceability and material lots.
First-pass and final yield with failure Pareto.
Defect, rework and deviation records.
Capacity and cycle-time observations.
Packaging and outgoing-quality records.
Corrective-action plan and production-release decision.

PVT exit criteria

PVT can exit when the agreed quantity is built through the intended process, critical defects are absent or contained, yields and cycle times support the ramp plan, traceability is complete, and open issues have owners, risk decisions and due dates.

How Many Units Are Needed?

There is no universal EVT, DVT or PVT quantity. Build size should follow the evidence required.

Relevant factors include:

Number of design variants and use configurations.
Destructive and non-destructive tests.
Reliability duration and simultaneous test needs.
Statistical confidence and tolerance coverage.
Compliance laboratory samples and backups.
Golden samples, fixtures and software teams.
Supplier, component and tooling variation.
Expected yield and allowance for debug failures.

Start with the test matrix, allocate units to each activity, then add controlled spares. A round number chosen before the evidence plan can produce either waste or an underpowered test program.

Configuration Control: The Backbone of Every Build

Every unit should be traceable to its hardware revision, BOM, component substitutions, enclosure revision, firmware, configuration, test software and material lot where relevant.

At minimum, maintain:

Unique unit or batch identifier.
PCB and assembly revision.
BOM and approved deviations.
Firmware and bootloader version.
Calibration and configuration data.
Test station and test-software version.
Date, line and manufacturing lot.
Failure, rework and final disposition.

Without configuration control, teams can pass a test on one combination and unknowingly ship another.

Common EVT Failure Modes

Power sequencing or brownout resets.
Sleep current above the energy budget.
Antenna performance degraded by enclosure or battery placement.
Audio clipping, noise coupling or microphone-port blockage.
Processor, memory or storage headroom too small.
Thermal hot spots under sustained workloads.
Mechanical stack-up or connector-access problems.
Firmware recovery and update path not yet reliable.

The correct EVT response is usually diagnosis and design correction, not expanding test volume around an unstable architecture.

Common DVT Failure Modes

Requirements changed but the test plan did not.
Production-intent materials behave differently from prototypes.
Tolerance extremes cause acoustic, RF or assembly failures.
Reliability testing exposes weak clips, ports, seals or connectors.
Firmware and mobile applications are not version-locked.
Compliance pre-scan occurs after the layout and tooling are frozen.
Failures are averaged away instead of linked to acceptance criteria.

DVT failures often reveal integration problems between subsystems that passed independently.

Common PVT Failure Modes

Operators rely on undocumented tribal knowledge.
Fixtures produce false passes, false failures or inconsistent contact.
Programming keys, calibration or serial data are mishandled.
Rework is performed without controlled instructions.
Yield is reported without a failure Pareto or root causes.
Alternate components enter the line without adequate review.
Cosmetic limits are subjective or inconsistent.
Packaging, labels or region-specific contents are mixed.

PVT is not successful merely because the factory eventually completes the order. The process must be controlled and repeatable.

When to Stop a Build

A stop-build rule prevents teams from consuming all units after discovering a systemic defect. Define triggers before the build, such as:

Safety-critical or compliance-critical failure.
Repeated defect above an agreed threshold.
Fixture or test-software behavior that makes results unreliable.
Unapproved component or configuration mismatch.
Traceability loss.
Failure that can damage downstream equipment or units.

The stop should initiate containment, evidence preservation, root-cause review and an authorized restart decision.

The Phase-Gate Review Checklist

Review area	Questions before approval
Requirements	Are inputs controlled, testable and mapped to evidence?
Configuration	Do reports identify the exact hardware, software and materials?
Failures	Are critical issues closed and remaining risks formally accepted?
Test coverage	Were intended environments, variants and tolerance limits represented?
Compliance	Are market assumptions and design-critical items documented?
Supply chain	Are components available, approved and lifecycle risks understood?
Manufacturing	Are drawings, fixtures, instructions and test limits controlled?
Ownership	Is every open action assigned with a due date and decision authority?
Next phase	Does the next build have a defined objective, quantity and configuration?

Change Control Between Phases

Not every change requires repeating every test. The team should assess which requirements, risks, interfaces, compliance evidence and manufacturing steps are affected.

Classify the change, document the rationale, identify regression tests and update the configuration baseline. Changes to microphones, antenna, enclosure, battery, power supply, PCB layout, firmware, radio stack or production process can have effects beyond their immediate subsystem.

For related planning, see GMIC’s AI hardware development process, hardware prototype validation and AI hardware certification guide.

Frequently Asked Questions

Can EVT, DVT and PVT be combined?

Some low-risk platform adaptations may use fewer formal builds, but the questions still need answers. Combining labels does not remove the need to verify architecture, validate the design and prove manufacturing readiness.

Is a pilot run the same as PVT?

Not always. “Pilot” can mean any limited build. PVT specifically should use production-intent processes and collect evidence for production release.

Should certification happen in DVT or PVT?

Planning and pre-compliance should begin earlier. Formal testing usually needs a sufficiently stable, representative configuration. The exact timing depends on the product, market, laboratory and change risk.

What is the difference between DVT and design validation?

DVT is a program phase label. Design validation is an activity demonstrating that the product meets user needs and intended use. A DVT phase can contain both verification and validation work.

Who approves a phase exit?

Define this in the development plan. Approval commonly requires responsible engineering, quality, manufacturing and program stakeholders, with regulatory or business participation where applicable.

Treat Each Phase as a Decision

EVT, DVT and PVT work when each phase has a specific risk-reduction purpose, a controlled configuration, reproducible evidence and an explicit decision. Hardware programs lose time when phase labels replace exit criteria or when a calendar date overrides unresolved technical evidence.

GMIC supports EVT/DVT/PVT manufacturing, prototype validation and production preparation for AI hardware. Contact GMIC to define the next build around the evidence your product actually needs.

EVT vs DVT vs PVT: Deliverables, Exit Criteria and Common Failure Modes