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.
Evidence must be labelled honestly as product maturity and requirement detail grow. A concept test can inform architecture without qualifying a flight design; a simulation can retire uncertainty without proving every operating case. Continuous verification works when the ledger preserves that scope rather than turning every promising result into a green status.
How verification differs 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 verification often happens 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.
Build a configuration-aware evidence ledger
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.
The ledger and ingestion states below are Arc-recommended operating states, not NASA-defined statuses. They apply NASA's configuration-management principles to an iterative evidence workflow; each programme should tailor names, transitions and authority to its governing process.
Configuration applies across the chain. A passed result on engineering model one may not support a flight design after a material change. NASA's product-verification guidance identifies the product, verification plan and specified requirements baseline as key inputs and distinguishes verification, qualification and acceptance. The evidence record should identify the hardware, software, model, calibration and environment that produced each result.
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.
| Ledger state | Meaning | Allowed transition |
|---|---|---|
| Planned | A method and case exist, but no applicable result has been reviewed | Move to executed when procedure, article and configuration are recorded |
| Executed | The activity ran and produced a result plus supporting evidence | Move to accepted only after anomalies and applicability are reviewed |
| Accepted | An authorised reviewer concludes that the evidence supports the requirement | Remain accepted while requirement and configuration stay applicable |
| Limited | The evidence supports only stated conditions, variants or portions of the claim | Close the limitation with added evidence or revised scope |
| Reopened | A change, anomaly or provenance problem invalidated prior closure | Return through planning and review with a recorded trigger |
Record provenance and ingestion health
An evidence link is trustworthy only when the team can retrieve the underlying record and show how it entered the ledger. A filename or a green integration status does not establish provenance. Record the originating system, immutable or controlled identifier, revision, producing configuration, acquisition time, ingestion result and reviewer.
| Ingestion state | Meaning | Verification consequence |
|---|---|---|
| Current | The source resolved, expected revision and configuration matched, and required fields were captured | Eligible for technical review; not automatically accepted |
| Partial | The source resolved but metadata, attachments or relationship context were missing | Keep the evidence provisional and assign the missing context |
| Failed | The source could not be read, mapped or validated | Do not count the evidence towards coverage or closure |
| Stale | The source was previously valid but its requirement, configuration or approval basis changed | Reassess and reopen closure unless continued applicability is justified |
| Superseded | A controlled successor replaced the record for the stated scope | Preserve history but use the successor for current closure |
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.
Reopening rules should be deterministic where possible. Reassess accepted evidence when the requirement acceptance criterion changes, the verified design item changes, the applicable configuration expands, a relevant anomaly is substantiated, a tool or calibration is invalidated, or the approval basis is withdrawn. A reviewer may conclude that evidence remains valid, but that conclusion needs its own rationale.
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 the ledger supports 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.
Evidence freshness is more useful than raw coverage. Track the share of accepted claims whose requirement revision, tested configuration, procedure, toolchain and anomaly disposition still match the current baseline. Also track median time from a relevant change to evidence reassessment, the number of closures reopened by automated policy, and the age of unresolved limitations.
How to 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's verification and test capability connects requirements to verification methods, test cases, procedures, executions, results and evidence inside the programme model, while variant and configuration context helps identify where those records apply. Teams can see planned coverage and approved closure without reducing the lifecycle to one checkbox.
When a requirement changes, Arc's controlled-change workflow and traceability views can expose affected verification work before the branch merges. Within Arc's documented AI-governance boundary, agents can help propose cases, flag missing coverage and monitor stale evidence after the workflow has been configured and evaluated for the programme, while engineers approve methods and closure. The objective is a current evidence chain throughout development, not a last-minute verification spreadsheet.
Related reading
Use verification vs validation for space systems to separate the two questions, as-designed, as-built and as-tested configuration management to establish evidence applicability, and ECR vs ECO vs ECN to connect a changed baseline to implementation and reverification.
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.
Apply this to a space bid
For a funded hardware project, use this engineering method to separate current readiness evidence from planned tests. Keep proposed commitments, current evidence and unresolved customer decisions distinct.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.