Mission Goal
Build a Mission Capability Plan: define what your mission can do now (baseline), what it can do next (upgrade), and what trade-offs you will make to stay reliable. This is where you turn ambition into a credible roadmap.
Why it matters
Real mission leaders don’t just build gadgets — they build capability. Capability means repeatable outcomes, known limits, and smart upgrades without breaking what already works.
Inputs from other teams
- Payload/Build: what the system can measure/do today and what components limit it.
- Comms: bandwidth/latency constraints and what messages are realistic.
- Data/Telemetry: how data will be validated, stored, and interpreted.
- Launch/Platform: constraints that cap ambition (mass/power/space/handling/time).
What you must produce (deliverables)
- Capability Statement (baseline): 5 bullet points describing what you can reliably do.
- Upgrade Roadmap: 3 upgrades, each with benefits, costs, and risks.
- Trade-off Table: at least 6 trade-offs (e.g., more sensors vs power; more data vs simplicity).
- Interface Contract: what you require from other teams and what you promise back.
Step-by-step
- Define baseline: what you can do repeatedly with today’s tools, in your real classroom constraints.
- Choose 3 “upgrade targets”: faster, more accurate, more reliable, more interpretable, more shareable, etc.
- For each upgrade: write (a) benefit, (b) cost, (c) new risks, (d) how you’d test it.
- Map trade-offs: create a table of decisions you will make and why.
- Write the interface contract: inputs you need + outputs you deliver (simple and measurable).
- Get sign-off: show it to two other teams and adjust one trade-off based on feedback.
Success criteria
- Baseline capability is honest and testable (not a wishlist).
- Upgrades include real trade-offs and realistic tests.
- Your interface contract reduces confusion and makes cross-team work easier.
Evidence checklist
- Capability statement (5 bullets).
- Upgrade roadmap (3 upgrades).
- Trade-off table (6+ trade-offs).
- Interface contract (inputs/outputs) + sign-off notes.
Safety & ethics
- Don’t upgrade into unsafe complexity (especially power, heat, moving parts).
- Be truthful about limitations: credibility beats hype.
- Respect data ethics: define what you can claim, and what you can’t (yet).
Common failure modes
- Roadmap fantasy: upgrades that ignore constraints (time, budget, tools, skills).
- Trade-offs missing: assuming you can have everything at once.
- No testing plan: upgrades described without a way to prove them.
- Interface vagueness: “we’ll send data” instead of specifying format, timing, and ownership.
Stretch goals
- Create a capability maturity ladder (what changes from Level 1 → 5 for your mission).
- Write a “what we will not do” list to protect reliability.
- Add a one-slide “investor brief”: baseline, upgrade, why it matters.
Scaffolding Example (optional)
You are allowed to reuse structures and formats from other teams — but not their decisions.
Structure: Flight Rules (write 6–10 rules)
- Rule format: “If ___, then we ___ because ___.”
- Include at least: safety, data quality, configuration control, and abort authority.
Example rule patterns
- If any unsafe condition appears, we abort immediately because safety dominates mission goals.
- If we change hardware/software, we relabel the version because we need traceability.