Week 17 · lesson

Mission Plan Review

A mission plan review asks one question:

Can another team reconstruct what you intend to do, why each step exists, which evidence supports it, and what would stop the mission?

If the answer depends on the original authors standing nearby to explain missing logic, the plan is not ready.

Review the chain, not isolated pages

The capstone package should now connect:

stakeholder need

required product

route/capture logic

aircraft + sensor assumptions

operating constraints

risk controls

evidence package

The review is strongest when it follows that chain and tries to break it.

Four challenge passes

Pass 1: Product traceability

Pick each product requirement and ask:

  • Where is it produced?
  • Which route state creates the evidence?
  • Which artifact records completion?
  • What happens if the evidence is unusable?

A requirement with no route state is wishful thinking.

Pass 2: Boundary verification

Inspect every statement involving:

  • airspace;
  • site permission;
  • people or obstacles;
  • weather;
  • aircraft capability;
  • sensor capability;
  • endurance;
  • current rules.

Classify each statement as one of:

  • verified evidence;
  • current project assumption;
  • requires re-check before operation.

Do not let assumptions masquerade as verified facts.

Pass 3: Failure recovery

Select at least three failures and trace what the plan does next.

Examples:

  • required image rejected;
  • unexpected person enters the operating area;
  • weather margin deteriorates;
  • route takes longer than planned;
  • GNSS or positioning confidence degrades;
  • source verification changes the airspace decision.

A plan that only describes the happy path is incomplete.

Pass 4: Evidence control

Verify that:

  • every important file appears in the artifact manifest;
  • factual claims map to a source or are labeled as assumptions;
  • current versions are obvious;
  • role ownership is visible;
  • reviewer comments led to real revisions where needed.

Worked review finding

A team writes:

If battery reaches 25%, the aircraft will return home.

A reviewer should not accept that sentence automatically.

Questions:

  1. Is 25% a verified aircraft/configuration threshold or a proposed planning rule?
  2. Is return-to-home behavior actually configured and tested in the assumed system?
  3. Is the home point valid?
  4. Does the return path remain safe under the scenario?
  5. What happens if the estimated remaining energy is wrong?

A safer project statement might be:

The plan requires a verified recovery threshold and reserve margin before the mission can be considered executable. The current classroom model uses a placeholder threshold only for route analysis and does not claim the real aircraft is configured that way.

That version preserves the engineering question without inventing certainty.

Review board worksheet

Use this table during peer review.

FindingEvidenceSeverityRequired changeOwner
critical / major / minor
critical / major / minor
critical / major / minor
critical / major / minor

Severity guide

  • Critical: invalidates safety, authority, or the product.
  • Major: breaks traceability, recovery logic, or an important requirement.
  • Minor: weakens clarity or organization but does not invalidate the concept.

The review must change the plan

After the review, select at least two findings and revise the actual mission package.

Then record:

Finding → changed artifact → new evidence or logic → remaining limitation

This is the evidence that review occurred.

Phase-2 exit gate

Week 17 is complete when the team can produce one controlled package containing:

  • mission need and product definition;
  • system concept;
  • route/data table;
  • responsibility matrix;
  • source ledger;
  • artifact manifest;
  • preliminary risk register;
  • review findings and revision record.

The package does not need to prove the mission is approved for real operation. It needs to prove that the planning logic is coherent, traceable, and ready for final risk defense.