Arc Skills / Standards and development assurance
Review a safety argument against its evidence
This task examines the logic linking safety claims, assumptions and configuration-specific evidence. Arc Skills returns a claim-evidence review that names the exact inference a test or analysis does, and does not, support.
Use this skill
Use Arc Skills to review this safety argument for the stated system baseline and modes. Trace each top claim through subclaims to evidence, then challenge the inference with plausible counterexamples.
Inputs:
- Claim structure, context and operating conditions.
- Hazard analysis, evidence IDs, versions and deviations.
- Hardware/software configuration and approval scope.
Return claim-by-claim findings with supported scope, hidden assumption, counterexample and the evidence or wording needed to resolve each gap. Do not treat a narrow test as proof of a broader claim.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Argument and claim IDs | Defines propositions being tested | Claim-evidence map |
| Hazards and architecture | Provides credible counterexamples | Assumption/defeater list |
| Test/analysis records and versions | Checks claim scope and configuration | Supported or open inference |
Command inhibition is narrower than no energization
Illustrative engineering example.
A synthetic heater safety case claims C1: “The heater cannot energize in service mode.” Test T4 on controller version V3 forces service mode and observes a zero heater command. The power switch can still short closed; no fault test or isolation analysis is supplied.
| Claim/subclaim | Evidence | Supported inference | Gap or action |
|---|---|---|---|
| C1: no heater energization in service mode | T4 command test on V3 | None at the physical energization boundary | Power-switch short remains a counterexample |
| C1.1: controller suppresses command | T4 records zero command in tested transition | Supported for V3 and exercised transition | Check other transitions and current release version |
| C1.2: power path isolates faults | No evidence supplied | Unsupported | Provide design/fault analysis and targeted verification or narrow C1 |
The test is valid for a command-level proposition. The top claim is about delivered power and therefore includes paths outside the controller command. The shorted switch is a specific defeater, not proof that it will occur.
A narrower claim could be written if the project does not credit physical isolation, but changing the top claim changes the safety case and may leave the hazard untreated. Review the hazard control decision first; then obtain the hardware evidence or maintain the explicit gap. Formal acceptance belongs to the named safety authority.
Read claims as propositions with boundaries
- State each claim’s system, phase, configuration and exact asserted behavior.
- Follow support through subclaims to a test or analysis at the same boundary.
- Challenge the inference using credible faults, common causes and changed modes.
- Record whether to add evidence, narrow wording or revisit the control architecture.
Questions about this task
Is a passed test enough to support a safety claim?
Only to the extent that its setup, fault cases and measured outcome match the claim. A passed nominal test cannot establish behavior under an untested short circuit.
What makes a counterexample useful?
It names a credible way the claim can fail despite the cited evidence, allowing the team to test, analyze or explicitly exclude that path with justification.
Sources and further reading
- NASA Systems Engineering Handbook: Lifecycle, requirements, verification and technical-management guidance.
- NASA Fault Tree Handbook with Aerospace Applications: NASA-hosted guidance for fault-tree gates, cut sets and reliability block diagrams.