EVT, DVT, PVT: Keeping Requirements Straight Across Builds

Picture a program engineer two weeks before the PVT gate. A reviewer points at requirement 4.2.7, a drop-survival spec, and asks which build it was verified on. The test report says DVT. The CAD says the housing rib pattern changed after that test, when the tooling vendor asked for more draft. Nobody can say, quickly, whether the DVT drop results still describe the part going into production.

This is the everyday failure of an evt dvt pvt program. The builds themselves go fine. What drifts is the link between a requirement, the design revision it was proven against, and the evidence that proved it. Each build produces new geometry, new test data and new open issues, and each of those lives in a different place: a spreadsheet, a PLM vault, a test lab's PDF, a Slack thread.

This post follows a hardware program team through all three builds. The persona is the systems or quality engineer who owns requirement closure. The job is simple to state and hard to do: prove each requirement against the right build's design, and know what must be re-verified before the next gate.

The job: proving each requirement against the right build's design

Engineering validation test (EVT), design validation test (DVT) and production validation test (PVT) are not three rounds of the same activity. Each build answers a different question, and each is built on a different design. EVT asks whether the architecture works at all. DVT asks whether the design meets its requirements. PVT asks whether the production process, with production tooling, makes units that still meet them.

So a verified requirement is really a three-part claim: this requirement, this design revision, this evidence. Drop any one of the three and the claim goes soft. "Passed drop test" with no revision attached is a rumor.

The persona here is the person who has to defend that claim at a gate: the systems engineer who owns the requirement table, the quality engineer who signs off on evidence, the mechanical lead who knows which features moved. Their job is not generating test data. It is answering three questions on demand. Which build's design was this verified against? What has changed in CAD since? What has to be re-verified before we pass the next gate?

Those questions get harder at each build, because the volume of change grows while the calendar shrinks. EVT might touch a few dozen parts. PVT changes arrive from tooling, suppliers and assembly lines, and they arrive late. A team that cannot answer the three questions at DVT will be guessing at PVT.

The rest of this walkthrough follows one program through the builds, first with the usual drift, then with requirements, CAD changes and evidence connected in Tandem.

Before: how requirements and evidence drift between EVT, DVT and PVT

The usual setup is familiar. Requirements live in a spreadsheet or a requirements tool. CAD lives in SolidWorks, NX, Onshape or Fusion, with revisions managed in PLM. Test evidence lives wherever the lab or the test engineer put it. Findings live in an issue tracker and in people's heads.

The drift happens in the seams. A requirement gets a verification status of "verified" after EVT bench testing. Three weeks later a bracket gets thicker because a thermal finding forced a heat spread change. The requirement row still says verified. Nothing connects the row to the bracket.

At DVT the same thing repeats at larger scale. Test reports are filed against a build name, not a design revision. When someone asks "which housing did this vibration test use?", the answer is reconstructed from a build log, a purchase order date and a conversation with whoever ran the fixture. That is archaeology, not traceability.

By PVT the cost shows up as gate-review theater. The team assembles a verification matrix by hand, and the matrix is already stale the day it is exported. Reviewers either accept it on trust or ask for rework, and rework at PVT lands directly on the schedule. The Verification Cross Reference Matrix guide covers why a matrix that is not tied to design revisions goes out of date so quickly.

A status column is not evidence. "Verified" only means something when it points at a specific design state and a specific piece of data. Everything else is a note that someone once felt good about the part.

EVT: turning findings into tracked geometry and material changes, and carrying open issues into DVT

EVT is where the design is allowed to be wrong. The team builds a few dozen units and finds that the enclosure runs hot near the power stage, that a snap-fit cracks, that a cable bend radius is too tight. These findings are the whole point of the build.

The failure mode is not finding problems. It is losing the thread between a finding and the geometry or material change that answers it. In the usual workflow the finding closes when someone says "fixed in Rev B," and the reasoning stays in a Slack thread.

In Tandem, the EVT finding is captured against the requirement it threatens, for example a thermal limit on the power stage, and the CAD change that responds to it is linked to that same requirement. Tandem works alongside the CAD and PLM tools the team already uses, with SolidWorks, Onshape, Fusion and NX supported off the shelf. The thicker spreader plate or the switch from one aluminum alloy to another shows up as a tracked change, tied to the requirement and to the reasoning in the review where it was decided.

Then comes the part that matters for the next build: open issues. Not every EVT finding is resolved before DVT starts. A snap-fit redesign might be proposed but not yet validated. Those open items stay attached to their requirements as carried risk, so when DVT planning begins, the team sees a requirement that is only partly addressed instead of one that looks clean.

This is the same discipline covered in Structural Requirements Traceability When CAD Changes and Thermal Requirements Traceability When Mechanical Design Changes. EVT is the build where you start the chain. If it starts broken, DVT inherits the break.

DVT: tying test results to the exact design revision they were run on

DVT is where requirements get formally verified, so the three-part claim matters most here. Every result needs a requirement, a design revision and an evidence artifact, and all three need to be findable from each other.

Take the drop-survival requirement from the opening. In DVT the lab runs a 1.2 m drop series on units built to the DVT design. The result is a report with pass criteria, photos and measurements. With Tandem, that evidence is stored and connected in the same system as the requirement and the CAD state it ran against. Tandem does not run the test and it is not a test management tool. The lab and the team's test tools do that. What Tandem holds is the connection: this evidence belongs to this requirement, on this design revision.

That connection pays off the first time a change lands after testing. Say a supplier asks to move a mounting boss by 1.5 mm. In the old workflow, someone has to remember that the drop test depended on that boss. With requirements linked to CAD, Tandem's change impact view identifies what the change affects and runs requirement checks against the linked CAD. The drop requirement is flagged, with its DVT evidence marked as run against the earlier revision.

The engineer then makes an informed call: the boss move is cosmetic and the evidence holds, or the load path changed and the test is partly invalid. Either way, the decision and its reasoning are recorded against the requirement.

The Test Readiness Review guide makes a related point from the other side: a test is only ready to run when the article under test and the requirement it addresses are pinned down. DVT is where that pinning stops being optional.

PVT: deciding which DVT evidence still holds after a tooling or process-driven change

PVT is where the design meets reality. Production tooling gets cut. The injection mold needs extra draft. The assembly line wants a different fastener sequence. The supplier substitutes a resin grade that meets the datasheet but changes shrinkage. Each of these produces a CAD change, and each CAD change quietly puts some slice of DVT evidence in doubt.

This is the hardest question in an evt dvt pvt program: which DVT evidence still holds? The lazy answer is "all of it, the changes were small." The expensive answer is "none of it, rerun everything." Both are wrong, and both are what teams default to when they cannot see the links.

With requirements, CAD changes and evidence in one connected system, the team can work the question requirement by requirement. A draft-angle change on the housing touches the requirements that depend on housing geometry: ingress protection, drop survival, fit to the display stack. It does not touch the battery runtime requirement. The change impact view narrows the re-verification set from "everything" to a defensible list.

For each requirement on that list, the engineer chooses one of a few honest outcomes. The change is outside the load or interface path and the DVT evidence stands, with the rationale recorded. Or the change is analyzable and a short analysis closes it. Or a retest is needed. The disposition is saved against the requirement, so the next reviewer sees the reasoning and not just a status.

This is also where process-driven changes meet formal paperwork like PPAP After Design Change and AS9102 First Article Inspection. Tandem does not generate those submissions. It holds the record of which design decisions and evidence sit behind them.

Build-gate reviews held against the requirement, the CAD change and the evidence

A build-gate review usually fails in one of two ways. Either it is a slide show that summarizes work nobody can inspect, or it is an hours-long hunt where the room waits while one engineer finds the right file.

Holding the review in context fixes both. In Tandem, a design review is held against the requirement, the architecture node, the CAD change and the verification evidence it relates to. The reviewer clicks from the requirement to the revision it was verified on, then to the later change that touched it, then to the disposition. The conversation is about engineering, not document retrieval.

For the EVT to DVT gate, the useful questions are: which requirements have open EVT findings, which design changes responded to them, and which of those responses have been validated. For the DVT to PVT gate: which requirements are verified, against which revision, and which later CAD changes put that evidence in question. For the PVT exit: which production-driven changes occurred, and what was the disposition of each.

Two existing guides cover the formal side of gates. The Production Readiness Review guide walks through proving that the design being released is the design that was verified. The Change Control Board guide covers how changes get dispositioned. Tandem does not replace the board or the review. It makes sure the people sitting in them are looking at connected facts.

Ask one question at every gate: for each requirement we are about to call closed, can we show the revision, the evidence and every change since? If the room can't, the requirement isn't closed.

What the team ends up with, and what Tandem does not do

At the end of PVT, the program team has something the spreadsheet version never gave them: a requirement history that reads like a story. Requirement 4.2.7 was threatened by an EVT finding, addressed by a rib pattern change, verified in DVT on a named revision, put in question by a PVT draft-angle change, and closed by a recorded disposition with the reasoning attached. A new quality engineer, an auditor or the next program can read that chain without interviewing anyone.

The practical outcomes are specific. Gate prep stops being a matrix-building exercise because the links already exist. Re-verification scope is argued from the actual change instead of from fear. Late changes at PVT get an explicit disposition instead of a shrug. Open issues from EVT can't silently vanish on the way to DVT. For regulated teams, the same chain feeds documentation like the Design History File, because the rationale was recorded when the decision was made.

Now the plain limits. Tandem is the context layer above your CAD and PLM, not a replacement for either. It stores design intent and evidence, not geometry or file versions. It does not run engineering calculations, manage test cases or execute tests, manage a BOM or sync with suppliers or ERP, or act as a QMS. Your lab still runs the tests, your PLM still manages released data, and your change process still produces change documentation. Tandem connects the requirement, the CAD change and the evidence across all of it.

Conclusion

Pick one requirement from your current program, ideally one that depends on housing or structural geometry, and trace it by hand: the revision it was verified on, every CAD change since, and the evidence that still stands. Time how long it takes and note where you had to ask someone. That gap is your gate risk.

Then do it in Tandem. Link that requirement to the CAD change and the DVT evidence, and run the change impact view against the next tooling change on your list. If you are heading into a DVT or PVT gate, book a demo at tandem.inc and bring your real requirement table. The test of the tool is whether it can tell you what to re-verify before the review, not after.