Arc Skills / Technical management and design reviews

Write a risk mitigation plan

Use Arc Skills to turn a technical risk into actions that interrupt its cause or reduce its consequence. The plan separates preventive work from contingency actions and specifies what evidence will demonstrate each action’s outcome.

Use this skill

Use Arc Skills to write a risk mitigation plan.

Inputs:
- Risk ID, cause, uncertain event and consequence
- Existing controls, configuration and approved risk criteria
- Available actions, dependencies and fallback options

Return actions with mechanism, owner, deliverable, completion evidence and dependency. Define observable triggers and contingency decisions. Keep residual-risk acceptance separate from completing the actions.

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
A specific risk scenario	Identify where to interrupt the causal path	Targeted controls
Design evidence and action constraints	Choose feasible preventive work	Owners, deliverables and dependencies
Triggers and fallback authority	Plan response if prevention is insufficient	Contingency and residual-risk decisions

Prevent harness noise, then plan what happens if the test fails

Illustrative engineering example.

R-12 concerns coupling from a switching regulator into the sensor harness. The plan has to create evidence before the harness is released and retain a feasible alternative routing.

R-12: Unresolved shielding and adjacent routing may couple noise above the sensor error limit, preventing required accuracy.
Configuration: flight harness H3 and regulator P2.
Available alternative: routing H4 with confirmed physical clearance; its mass/length impact still needs checking.
Acceptance: use the controlled noise/error limits; numerical values are not supplied here.

Prevent harness noise, then plan what happens if the test fails
Action type	Action and mechanism	Owner / dependency	Completion evidence or trigger	Next decision
Mitigation	Complete shield termination agreement to remove grounding ambiguity	Interface owner; before harness release	Controlled INT-4 revision agreed by both endpoints	Electrical owner confirms the resulting test configuration
Mitigation	Test H3 with P2 under representative powered operation	Verification owner; agreed wiring and calibrated instruments	Raw data and report compare with approved limits and uncertainty rule	Review pass, fail or unresolved findings by operating case
Contingency	Evaluate H4 routing if H3 cannot meet limits	Mechanical and electrical owners; clearance evidence exists	Trigger: H3 result fails or remains unbounded at release decision	Approve H4 only after noise, mass, length and installation effects are checked
Monitoring	Check delivered shield and harness configuration against tested article	Integration owner; article available	Inspection record identifies matching routing and terminations	Assess deviations before claiming applicability
Residual risk	Reassess scenario after results and controls	Authorized risk owner; evidence completed	Assessment cites actual findings and governing criteria	Record acceptance or further action separately

“Run a test” alone is weak mitigation planning: it produces knowledge, while the shielding agreement changes the design condition. Both can be necessary, but their mechanisms and completion evidence differ.

The alternative routing is a contingency because it is considered after a defined trigger. Completing the planned tasks does not itself accept residual risk or demonstrate performance; the results and configuration comparison support that decision.

Give each action an observable outcome

Choose controls that address the cause, event, consequence or timely detection.
Define an accountable owner, deliverable, dependency and evidence of completion.
Set a physical or project-specific trigger for contingency and escalation.
Reassess exposure after evidence arrives and preserve the authorized residual-risk decision.

Questions about this task

Is “review monthly” a useful mitigation?

It can support monitoring, but it does not specify what changes exposure. Define the observable trigger, the action it starts and who can make the resulting decision.

Sources and further reading

NASA Systems Engineering Handbook: technical risk management: Background on risk scenarios, uncertainty, consequences and responses.

References inspected on 3 October 2026. The worked output is an authored example using the stated inputs.