The Evolution of IV&V — and What Modern Software Delivery Requires

Independent verification and validation has always been a methodology shaped by the software delivery practices of its era. That is easy to miss when IV&V is treated as a procurement requirement rather than a discipline, but anyone working inside the practice knows it — the shape of milestone reviews, the structure of traceability packages, the cadence of findings reports, all of it reflects the way software used to get built. What is happening now is the third reshaping in the discipline’s history, and it deserves to be named that way rather than as a gap or a failure.

Three Eras

IV&V emerges in aerospace and defense in the 1970s and 1980s, driven by the recognition that complex systems whose failures have catastrophic consequences cannot be verified by the teams that build them. NASA formalizes the practice in the early 1990s, building on a decade-plus of prior work across NASA, DoD, and the nuclear programs. The cadence is milestone-based because the software is milestone-based. Flight-software builds ship on program timelines measured in years, and IV&V’s rhythm matches — PDR, CDR, TRR, findings packages timed to program gates.

The practice expands through the 1990s and 2000s as federal agencies take on large-scale IT modernization. Civilian-agency programs, DoD business systems, tax and benefits modernization efforts — IV&V moves beyond safety-critical flight software into enterprise IT. The methodology stays milestone-based. Sprint reviews replace some of the formal gates, but the underlying rhythm is the same: the prime delivers a thing, IV&V reviews the thing, findings roll up to the program office. Evidence is documentary — requirements specs, test plans, test results, traceability matrices, compiled into packages and handed over.

Then the ground moves. Primes adopt CI/CD, containerization, trunk-based development. Kessel Run, Platform One, and their civilian-agency counterparts ship continuously. What actually gets shipped diversifies — no longer a quarterly release candidate but features, hotfixes, incremental releases, and configuration changes, all on varying cadences, often overlapping. IV&V methodology, contracts, and tooling remained oriented around milestone-based evidence production. The gap wasn’t that IV&V fell behind; it was that the ground underneath IV&V moved faster, and in more shapes, than the milestone model could follow. That is the tension the discipline is working through now.

What Continuous Delivery Requires of Verification

The old model assumed there was one kind of shipped thing, produced on a predictable cadence, that could be assembled and handed over for review. That assumption no longer holds. A hotfix goes out in ninety minutes. A feature rolls out over a two-week sprint. A configuration change deploys at midday. An incremental release of a subsystem lands while a larger release is still in progress. Each is a real unit of shipped work, each has real verification implications, and each happens on its own timeline.

When there is no single category of shipped thing, there is no single category of thing to verify. Milestone-based IV&V was built around the assumption that verification activity synchronized to release events. That synchronization does not hold when shipping is continuous and diverse. The question becomes: how does IV&V engage with whatever the team actually ships, whenever it ships?

The replacement for milestone-based evidence is real-time preview environments for whatever the team ships. Every shipped unit — whatever its shape, whatever its cadence — can be instantiated as a live environment bound to that specific change, available from the moment the change is produced. The preview is the verifiable thing, not a compiled package assembled for the purpose of review. IV&V, the prime’s internal review process, and anyone else who needs to verify engage with a running system on their own schedule.

This aligns IV&V’s cadence with shipping cadence instead of milestone cadence. A hotfix gets verification appropriate to a hotfix — fast, targeted, matching the change’s risk profile. A feature rollout gets verification appropriate to its scope. A major release gets the deep review IV&V was designed for. The intensity of verification matches the change; the mechanism — a real-time preview environment, with events attested under the actor’s identity and recorded in a shared evidence log — is the same across all of them.

Three Configurable Patterns

Continuous IV&V — the umbrella term for alongside-delivery verification — is not a single shape. Different programs contract IV&V differently, and the tooling has to match the governance reality rather than force one model on everyone. PreviewProof provides three configurable patterns, each mapped to a governance context that already exists in federal practice.

Integrated IV&V places IV&V as a Testing stage inside the prime’s workflow, between internal feedback and final approval. Prime and IV&V engage with the same preview environment. IV&V’s stage is a gate stage: the workflow cannot advance until it completes. IV&V authors its test cases in its own context, executes them against the preview the prime is shipping, and records results in the shared evidence log. This pattern fits programs where IV&V has blocking authority — safety-critical flight software, high-criticality DoD programs, program-mandated concurrence requirements. One workflow, one preview, IV&V as a gate.

Parallel IV&V runs a separate workflow on a separate preview environment against the same shipped unit. Both workflows advance independently. Neither gates the other. The prime’s preview and the IV&V preview coexist while IV&V’s testing is active; each has its own lifecycle. IV&V authors and executes its own test cases against its own preview, and its findings land in the shared evidence log alongside the prime’s. This pattern fits advisory programs — much of civilian-agency modernization and mid-size DoD work — where IV&V concurrence is recorded and visible but does not block the prime’s cadence. Two workflows, two previews, one shipped unit, concurrent operation.

Asynchronous IV&V instantiates a preview against a previously-shipped unit on IV&V’s own schedule, potentially long after the prime’s delivery has closed. The preview is fresh; the unit under verification is the one the team originally shipped. IV&V’s test cases run against that preview, attested under IV&V identity, and recorded in the same evidence log. This pattern fits retrospective verification, sampling-based IV&V, and post-release validation. It also covers adjacent use cases — 3PAO control testing, audit reproduction, incident response — where the structural need is the same: a fresh preview against a previously-shipped unit, for independent purposes.

The three options differ in workflow shape and preview lifecycle. They do not differ in the evidence model. In each, IV&V authors its own test cases under its own identity, executes them against the shipped unit the prime’s tests also reference, and records findings in the shared evidence log. Test independence is preserved by authorship and execution, not by separate tooling.

The Evolution Continues

IV&V has adapted before. Milestone-based delivery produced milestone-based IV&V; enterprise modernization expanded the practice without changing its rhythm. Continuous delivery produces something different — not one new model, but a family of configurable patterns that match different governance contexts. The discipline of verification has not changed. The cadence, the shape of the unit being verified, and the tooling required have.

IV&V contractors have deep verification expertise that has been constrained, in recent years, by tooling designed for an older delivery model. What continuous delivery offers the practice is not faster assembly of milestone evidence packages but real-time preview environments for whatever the team ships, available for verification as the work happens — and the configurability to fit the governance pattern the program actually operates under. That is where the expertise lands where it matters: inside the development cycle, while corrections are still cheap.