Command & Control

Mission Goal

Create a practical Risk Register + Safety Case Lite for your mission: identify hazards, likelihood and impact, mitigations, and clear stop rules. Then run a short “risk review” with other teams.

Why it matters

Spaceflight is a safety culture. You don’t “hope” you’re safe — you prove it with disciplined thinking: hazards, mitigations, and decision gates. This is professional responsibility in action.

Inputs from other teams

• Build/Payload: tools used, sharp edges, heat, adhesives, batteries, moving parts.
• Comms: failure consequences (lost link, wrong callouts, misunderstood instructions).
• Data/Telemetry: data loss risks, file naming/version confusion, false readings.
• Launch/Platform: handling, mounting, transport, environmental constraints.

What you must produce (deliverables)

• Risk Register (minimum 10 entries) with likelihood, impact, mitigation, owner.
• Stop Rules (minimum 5) that clearly halt work when triggered.
• Pre-Flight Safety Brief (one page): the safety story you tell before operating.

Step-by-step

1. List hazards: physical (tools), electrical (batteries), procedural (confusion), data (loss), people (fatigue).
2. Score each risk: simple 1–5 likelihood × 1–5 impact.
3. Write mitigations: what you will do to reduce likelihood or impact.
4. Assign owners: every risk has an owner who checks it.
5. Create stop rules: “If X happens, we stop and do Y.” (No debate in the moment.)
6. Run a risk review: 10 minutes with 2 other teams. Ask: “What did we miss?”
7. Update: add at least 2 new risks based on feedback.

Success criteria

• Risks cover more than hardware: people, process, comms, and data are included.
• Mitigations are real actions (not “be careful”).
• Stop rules are clear and non-negotiable.

Evidence checklist

• Risk register (10+ entries) screenshot/photo.
• Stop rules list (5+).
• Pre-flight safety brief (1 page).
• Notes from the risk review (who reviewed + what changed).

Safety & ethics

• Safety is not a box-tick — it’s permission to proceed.
• Use inclusive language: focus on systems, not blame (“process failed”, not “person failed”).
• Data ethics: don’t fabricate or “smooth” readings to look good.
• Respect privacy if photos/videos are captured during tests.

Common failure modes

• Only obvious hazards: ignoring comms/data/process failures.
• Mitigation theatre: vague mitigations (“pay attention”).
• No owners: everyone assumes someone else is handling it.
• Stop rules missing: continuing under pressure when you should pause.

Stretch goals

• Add a risk burn-down: which risks reduce after each session (and how you know).
• Create a tool safety checklist specific to your workspace.
• Run a mini “failure drill”: simulate a comms loss and practice the response.