Continuous verification keeps requirements connected to verification methods, cases, results and evidence throughout iterative hardware development. Teams verify the questions appropriate to each product stage, then increase formality as the design matures. It is not constant qualification testing. It is a controlled evidence loop that exposes wrong assumptions early and keeps accepted proof aligned when requirements change.
Hardware teams cannot copy software continuous integration literally. A structural test article takes time to manufacture, thermal-vacuum facilities are limited and some tests are destructive. The transferable idea is shorter feedback: define what each iteration must prove, collect trustworthy evidence and preserve its relationship to the exact requirement and configuration.
What is continuous verification?
Continuous verification is the repeated planning and performance of verification activities as the system evolves. Early activities may use inspection, calculation, simulation, breadboards or engineering models. Later activities use controlled procedures, representative articles, calibrated equipment and formal review. The evidence chain remains connected across those stages.
The word continuous describes the feedback loop, not an attempt to test every property at every moment. Teams choose activities that retire the most important uncertainty at the current maturity, preserve what the result actually demonstrates and revisit the evidence when its requirement, design or configuration changes.
NASA's product-realisation guidance describes implementation, integration, verification, validation and transition as iterative and recursive processes. That is compatible with continuous verification: the right side of the systems-engineering engine is not reserved for one final event after design has stopped.
Flow's writing on agile safety-critical development argues that product maturity and requirement detail should grow together. The important qualification is that evidence must be labelled honestly. A concept test that informs design is not automatically certification evidence.
How is verification different from validation?
Verification asks whether the realised product conforms to specified requirements. Validation asks whether the product, in its intended environment and use, fulfils stakeholder expectations and mission needs. A subsystem can verify against its specification and still contribute to a system that is operationally wrong.
Continuous verification should therefore remain connected to validation learning. If an integrated demonstration shows that the mission concept is flawed, the team may need to change stakeholder expectations, system requirements and lower-level verification work. Closing requirements faster is not useful if the requirements describe the wrong product.
Why does verification often happen too late?
Programmes frequently write verification methods into a matrix but defer the real planning. The test team receives a mature design and discovers that requirements are ambiguous, acceptance criteria conflict, access points are missing or the available article cannot reproduce the required condition.
Document separation makes the problem harder. Requirement text, procedure, result and evidence live in different systems. A requirement changes, but the test case still reflects the old threshold. Before a review, engineers manually reconstruct status and debate which report applies to which configuration.
Continuous verification brings those decisions forward. The person writing or changing a requirement considers how it can be proven. Verification engineers influence architecture and instrumentation while choices are still reversible. Evidence status changes with the design instead of being rebuilt at the gate.
What should be verified in each hardware iteration?
| Product stage | Typical learning objective | Representative evidence |
|---|---|---|
| Concept | Physical and mission feasibility | First-principles analysis, trade study, simple simulation |
| Technology demonstration | Critical function or performance principle | Breadboard test, material coupon, prototype data |
| Integrated prototype | Interfaces, behaviours and system interactions | Hardware-in-the-loop, engineering-model test, integrated analysis |
| Qualification | Design compliance across required environments | Controlled qualification procedure, result and anomaly closure |
| Acceptance and operations | Article conformity and mission readiness | Acceptance test, inspection, as-built record and operational validation |
The table is illustrative, not a universal lifecycle. The programme's standards, contract and risk classification determine the required evidence. The principle is to make each iteration answer a meaningful question and preserve the limits of what that evidence proves.
What belongs in a continuous verification model?
A reliable model distinguishes several objects that spreadsheets often collapse into one status cell. The requirement states the obligation. The verification method describes whether compliance will be shown by test, analysis, inspection or demonstration. A verification case defines the conditions and expected result. A procedure controls execution. A result records what happened. Evidence supports review. Closure is the authorised conclusion.
Configuration applies across the chain. A passed result on engineering model one may not support a flight design after a material change. The record should identify the hardware, software, model, calibration and environment that produced the evidence.
Anomalies also need a path. A test can meet its primary criterion while exposing a secondary issue. Continuous verification connects the anomaly, disposition and any changed requirement or re-test rather than treating pass or fail as the complete story.
How should verification respond to requirement changes?
Every requirement change should trigger an assessment of its verification chain. A wording clarification may leave the method and evidence valid. A new threshold can alter stimulus, instrumentation, sample rate, uncertainty, expected result and test-article suitability.
The programme should show the old and proposed requirement, identify affected verification items and decide whether existing evidence remains valid. If the evidence no longer proves the approved statement, closure should reopen or carry an explicit limitation. Silent reuse creates false confidence.
This is why verification must participate in requirements change impact analysis. The test team should not learn about the new baseline when the procedure is already at the facility.
How does continuous verification work with formal reviews?
PDR, CDR, qualification and acceptance reviews remain useful control points. Continuous verification changes what the team brings to them. Instead of assembling a static matrix immediately before the gate, reviewers see a current record of planned methods, completed activity, open anomalies, evidence maturity and unresolved change.
NASA's V&V plan outline illustrates the need to define organisation, responsibilities, methods, facilities, schedules and reporting. A continuous workflow keeps that plan connected to execution while preserving the formal baseline expected at reviews.
What controls are needed for safety-critical hardware?
Iteration does not waive assurance. Safety-critical work may require independence, approved methods, qualified tools, representative environments, calibrated equipment, configuration control and formal authority. Early experiments should be isolated from human or mission risk and labelled as development evidence.
Teams should define which evidence can influence design, which can support a review and which can close a requirement. They should also control who may change a requirement after verification planning and who can accept a result. More frequent activity only improves safety when the evidence is trustworthy and the organisation responds to what it learns.
What metrics show whether the process is working?
Simple coverage percentages can mislead. One weak test linked to many requirements can make a dashboard look complete. Better measures include requirements with an approved method, cases with objective acceptance criteria, evidence valid for the current configuration, reopened closure after change, anomaly age and the time between a requirement update and verification review.
Teams should also track learning. Did an early activity change the requirement or architecture while the cost of change was still low? Did integrated testing expose an interface assumption before qualification? Those outcomes show whether the feedback loop is improving decisions.
How should a team introduce continuous verification?
- Select one active subsystem and define the requirement baseline and applicable configuration.
- Separate requirement, method, case, procedure, execution, result, evidence and closure records.
- Identify the highest-risk assumptions and define an early activity for each.
- Connect every activity to the requirement and decision it is intended to support.
- Run requirement changes through verification impact assessment before approval.
- Review evidence maturity and limitations at the cadence of the development iteration.
- Expand only after owners trust the status and can reproduce the closure rationale.
How Arc supports continuous verification
Arc connects requirements to verification methods, test cases, configurations, procedures, executions, results and evidence inside the programme model. Teams can see planned coverage and approved closure without reducing the lifecycle to one checkbox.
When a requirement changes, Arc can expose affected verification work before the branch merges. Agents can help propose cases, flag missing coverage and monitor stale evidence, while engineers approve methods and closure. The objective is a current evidence chain throughout development, not a last-minute verification spreadsheet.
Related reading
Use the requirements traceability matrix guide for a practical evidence structure, and compare agile and waterfall hardware development for the wider iteration model.
Frequently asked questions
What is continuous verification in hardware development?
Continuous verification is the practice of planning, running and maintaining requirement-linked verification throughout iterative development instead of waiting for one late test phase. Evidence rigour grows with product and baseline maturity.
Is continuous verification the same as continuous testing?
No. Testing is one verification method. Continuous verification also includes analysis, inspection and demonstration, plus the traceability, configuration, review and evidence needed to support requirement closure.
Can continuous verification work in safety-critical programmes?
Yes, when early evidence is labelled honestly and formal assurance controls increase with maturity. Iteration does not remove qualification, independence, configuration control or approval obligations.
What happens to verification when a requirement changes?
The team assesses affected methods, cases, procedures, configurations, results and evidence. Any closure that no longer supports the changed requirement should be reopened or explicitly justified.
What should a verification record contain?
It should identify the requirement and baseline, method, case or analysis, applicable configuration, procedure, execution, result, anomalies, evidence, reviewer and closure status.