Verification, Validation & Test
Hardware tells the truth exactly once, usually at an inconvenient moment. This page states how verification is planned, how tests are conducted, and what happens when something behaves in a way nobody predicted.
Verification Planning Before Design Maturity
Verification is planned when requirements are written, not when hardware exists. A requirement whose verification method is decided late tends to be verified the cheapest way rather than the right way.
- Verification method assigned per requirement at baseline: test, analysis, inspection, or demonstration
- Verification cross-reference matrix maintained from requirement to method to evidence to closure
- Test-like-you-fly philosophy applied, with any deviation documented and accepted explicitly
- Facility, fixture, instrumentation, and article availability planned into the schedule and budget from the outset
- Analysis used in place of test only where the analysis is validated and the rationale is recorded
Test Readiness and Conduct
A test is a controlled event with a defined configuration, a written procedure, and a defined success criterion agreed before the first data point is taken.
- Test readiness review confirming article configuration, procedure approval, instrumentation calibration, safety review, and personnel qualification
- Written, approved procedure with pass and fail criteria stated in advance
- Configuration of the article under test recorded, including any deviations from flight or delivered configuration
- Redlines to procedures controlled during execution and dispositioned afterward
- Data captured with traceability to instrument, calibration status, and environmental conditions
- Hazardous testing conducted under the controls described in the institutional safety program
Anomaly, Nonconformance and Failure Reporting
The value of a failure is in the information it releases, and that information is perishable. Reporting happens before the article is disturbed and before the explanation hardens.
- Any deviation from expected behavior recorded as a reportable anomaly, including anomalies the team believes are benign
- Article and data impounded where warranted, with the as-failed state preserved and documented
- Failure review board convened for significant anomalies, with membership independent of the performing team
- Root cause established through a structured method, with contributing and probable causes distinguished from proven cause
- Corrective action verified by retest or re-analysis; recurrence control applied to the process, not only the article
- Anomaly closure records retained and fed into lessons learned
Validation and Acceptance
Verification asks whether the system meets its requirements. Validation asks whether it meets the need. Both are required before something is offered to a customer as complete.
- Validation planned against the operational need and concept of operations, not only the requirement set
- End-to-end and mission-representative testing where the interfaces and environments permit
- Acceptance data package assembled with verification evidence, as-built configuration, nonconformance history, and open items
- Open items and waivers presented explicitly to the customer with their technical consequence stated
- Customer acceptance events supported with the underlying data available rather than summarized away
Waivers, Deviations and Residual Risk
Every program eventually asks to accept something less than it specified. The integrity of that moment determines whether the customer can trust everything else.
- Waiver and deviation requests documented with the technical justification and the risk retained
- Assessment by the assurance function independent of the program's schedule interest
- Approval at an authority level appropriate to the consequence, with customer concurrence where the contract requires it
- Waivers tracked to expiration or permanent disposition rather than left open indefinitely
- Cumulative waiver history reviewed as an indicator of process health
Where This Connects
Test discipline connects to laboratory and energetic systems safety, corrective and preventive action, lessons learned, and facilities and infrastructure.
Alignment Disclosure
Monarch Space Systems describes its systems engineering and mission assurance practices as aligned with the cited NASA directives, military and consensus standards, and industry specifications. Alignment is not a certification. The institution does not claim a NASA-approved systems engineering process, a CMMI appraisal result, an AS9100 registration, flight heritage, or any specific mission, article, or qualification outcome. Program-specific analyses, test data, and review products are contract-controlled and are not published.
Policy documentation, procedures, and control descriptions are available to customers and prospective teammates through the confidential engagement pathway or by request through institutional contact.