Arc Skills / Verification and validation
Review verification evidence configuration and applicability
Arc Skills traces evidence through requirement, procedure, article, and build identity. It returns an applicability matrix with conditions for reuse, delta analysis, or targeted retest.
Use this skill
Use Arc Skills to review whether the supplied verification report applies to the target configuration.
Inputs:
- Requirement and Test revisions, acceptance criteria, and evidence Run
- Tested versus target article, hardware, software, and change records
- Facility setup, calibration, environment, and deviations
Return a clause-level applicability verdict with evidence locator, mechanism, and smallest closure action.
Assess each changed feature by its effect on the tested behavior; do not transfer a Pass label by version name aloneWhat you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Evidence report | Fixes tested article, firmware, procedure, and result | Identity chain |
| Target baseline | Defines current obligation and build | Difference register |
| Change record | Explains whether verified behavior is affected | Reuse or retest decision |
UI-only change versus valve scheduler change
Illustrative engineering example.
E-9 passed valve timing on firmware 1.1. The proposed target is 1.2; its change summary lists both a UI color adjustment and a scheduler change, with no timing delta analysis.
R-4: Valve shall close within 2 s after accepted close command.
E-9: Pass on Controller C2 firmware 1.1, Test T-9 rev A.
Target: C2 firmware 1.2. Change C-1: UI color. Change C-2: valve scheduler modified.| Difference | Relevance to R-4 | Applicability action |
|---|---|---|
| C-1 UI color | No known path to valve command timing | Potentially retain with controlled no-impact rationale. |
| C-2 scheduler | Directly affects close-command scheduling | E-9 alone cannot establish 1.2 timing; analyse delta or rerun. |
| Overall E-9 → target | One material path unresolved | Not established for R-4 on 1.2 pending C-2 closure. |
Version changes are assessed by the behavior they touch. The UI color change may be irrelevant if the change record shows no control-path effect; a blanket rejection of all old evidence would add unnecessary work.
The scheduler change intersects the exact timing obligation, so the old pass cannot establish current performance by itself. The report remains historically valid for firmware 1.1 while reuse for 1.2 is unproven.
Follow the tested identity
- Confirm report, Run, Test, requirement, article, and procedure revisions.
- Compare the tested and target builds at features relevant to the obligation.
- Check setup, environment, calibration, and deviations that affect the result.
- Choose a documented similarity argument, delta analysis, or targeted rerun.
Questions about this task
Does any firmware bump invalidate a report?
No. Judge the actual changed path and document why an unaffected result remains applicable.
Can a passing Test ID be reused automatically?
No. The Test ID does not prove the target build and current acceptance limit match the old Run.
Sources and further reading
- NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.