Arc Skills / Safety
Derive safety requirements from a hazard analysis
This task turns a hazard-control decision into product obligations with a trigger, response and verification context. Arc Skills returns draft safety requirements traced to the source hazard without silently approving a proposed control.
Use this skill
Use Arc Skills to derive requirements from these hazard-control records. Preserve each hazard ID, analysis revision and the status of the control decision.
Inputs:
- Hazard condition, causal path and current analysis.
- Approved or candidate control and system architecture.
- Operating modes, ownership and verification context.
Return one obligation per draft requirement, with trigger, observable response, proposed test, allocation and unresolved parameters. Keep a candidate physical-disconnect decision separate from a controller command-inhibit requirement.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Hazard and causal path | Shows what must be interrupted | Trace origin |
| Control decision and architecture | Distinguishes approved from proposed behavior | Requirement boundary |
| Modes and verification plan | Defines measurable trigger and response | Testable draft |
Service-mode inhibition leaves a physical-path decision open
Illustrative engineering example.
Synthetic hazard H-7 is unintended heater energization during ground servicing. The project has selected command inhibition as a candidate control but has not decided whether a physical disconnect is also required. The controller can report its command state.
| Trace and status | Draft obligation | Verification proposal | Open decision |
|---|---|---|---|
| H-7 / candidate control C-1 | When service mode is active, controller shall inhibit the heater-enable command | Inject service-mode entry and transitions; record command output | Approve C-1 and define transition timing if relevant |
| H-7 / physical path undecided | No product requirement drafted yet | Fault analysis of switch and supply paths | Decide whether independent physical isolation is necessary |
| H-7 / operator state | Service-mode state must be identifiable at the maintenance interface if credited | Inspect interface behavior in service procedure | Confirm whether operator action is part of selected control |
The first row is bounded to command behavior. It does not promise that the heater cannot energize after a shorted switch. The second row preserves the unresolved architecture choice instead of disguising it as a requirement or treating it as waived.
If the hazard analysis later credits physical power isolation, a separate requirement should name that mechanism and its verification. The draft command requirement must also be tied to a versioned hazard record and approved control decision before it is implemented in the model.
Derive one observable obligation per control path
- Identify the unsafe condition, phase and exact causal path to interrupt.
- Separate chosen controls from proposals or assumptions needing a decision.
- Write trigger and observable response at the allocated system boundary.
- Plan verification for normal, transition and relevant fault conditions.
Questions about this task
Should the requirement say “the heater shall be safe”?
No. State the specific behavior at an observable boundary, such as inhibition of the enable command in service mode.
What if a critical timing limit is unknown?
Leave a named parameter and decision owner. Do not invent a threshold that changes the approved hazard-control intent.
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.