Mission Engineering: Why Memorizing Steps Fails — Defining Task Inputs, Outputs, and Dependencies

Introduction: The Chaotic Morning

The article opens with a familiar rushed morning: you know the hand-drip coffee steps — prepare materials, grind beans, boil water, pour — yet still end up scrambling because the filter paper is missing or the recipe isn't at hand. Knowing each step is not enough; you must know how they connect: what each step requires before starting, what it delivers when finished, and what to do when something is missing.

Task Decomposition: Defining What Each Step Must Deliver

The author breaks the coffee mission into top-level tasks (A01–A05) and sub-tasks (A02.1–A02.3), emphasizing that the decomposition diagram shows what tasks exist, not their execution order or parallelism. An illustration (Figure 1) shows the containment hierarchy.

Specifying Inputs, Outputs, Start Conditions, and Completion Criteria

For each task, the author defines four columns: the task name, what must be present before starting, what the task leaves behind, and how to verify completion. The table below summarizes these for the coffee mission:

A01 Verify Conditions & Method — Inputs: scenario card, taste agreement, candidate recipes, material status. Outputs: chosen scenario and recipe version, pending issues. Completion: conditions affecting the run are clarified; critical gaps cannot be skipped.

A02.1 Prepare Coffee Grounds — Inputs: beans for the batch, selected recipe's dose and grind requirement. Outputs: coffee grounds for this run and dose record. Completion: verify against the clarified recipe; unclear requirements must be resolved first.

A02.2 Prepare Water — Inputs: water, required volume, temperature, and other use conditions. Outputs: water meeting the agreed conditions at preparation end, with record. Completion: check state at prep end; re-verify before brewing that it is still usable.

A02.3 Ready Filter & Receiver — Inputs: required materials, chosen method, clean and available equipment. Outputs: filter material and coffee receiver prepared per method. Completion: confirm materials are complete, placement is correct, and required prep actions are done.

A03 Complete Brewing — Inputs: all above conditions met, method defined. Outputs: coffee liquid, key operation timestamps, deviation records. Completion: the chosen method's end conditions are satisfied; taste is separately evaluated by the family.

A04 Serve to Family — Inputs: brewed coffee, agreed serving arrangement. Outputs: family receives coffee, actual serve time recorded. Completion: confirm coffee is in front of the family; "ready to serve" does not count.

A05 Evaluate & Record — Inputs: served coffee, existing records, agreed feedback plan. Outputs: verbatim feedback, adjustment suggestions, record gaps. Completion: agreed feedback obtained, records and gaps organized and traceable to this brew; if feedback is pending, evaluation remains incomplete.

The author notes that vague recipe terms like "appropriate amount" make verification impossible — such gaps must be flagged and resolved before proceeding. Also, a preparation-complete record cannot substitute for a re-check at use time, because conditions may have changed during delays.

Linking Dependencies: The Mission Thread (MT)

By asking "what does the next step need?" and "which prior step provides it?", the author constructs a Mission Thread (MT) — a sequence of tasks, events, decisions, and interactions. The MT diagram (Figure 2) shows the main flow: A01 feeds the three preparation tasks (A02.1–A02.3), whose outputs converge at a pre-brew quality gate before A03, then A04, then A05. Arrows denote sequence, not duration. The three preparation tasks are not automatically parallel.

At the quality gate (linked to CF-E01 "post-preparation usable state"), each condition is verified. Missing items are handled in two ways: if they can be resolved within the original plan, fix and re-check; if not, pause and replan — do not fix then pause. A04 records the actual serve time; A05 arranges follow-up feedback if unavailable immediately, but does not treat "scheduled follow-up" as "feedback obtained". The author stresses this is only a first-version main line; branches like interruptions or the family leaving must be added as needed.

Separating Relationship Types: Material Flow, Information Flow, and Enabling Conditions

The same pair of tasks may involve material transfer, information passing, and a go/no-go condition. The author separates these into a table to avoid conflating them:

Material flow : A02.1's coffee grounds supply A03. Check: is it the exact batch prepared? Are quantity and state suitable?

Information flow : A01's chosen recipe guides preparation and brewing. Check: do downstream steps use the same version? Are ad-hoc changes recorded?

Enabling condition : Preparation conditions pass, then enter A03. Check: which conditions were verified? Does a missing item still allow proceeding?

A diagram (Figure 3) depicts these three relationships as distinct arrows.

No Material Dependency ≠ Parallel Execution: Resource Contention

A02.1 (prepare grounds) and A02.2 (prepare water) may have no material dependency, so they could overlap. However, with only one operator, hands and attention are shared resources. The author warns against simply taking the longer duration as the combined time. A diagram (Figure 4) illustrates this potential overlap pending resource allocation.

Similarly, filter preparation (A02.3) may require water for pre-wetting, creating a hidden dependency on water readiness. Water used for pre-wetting must be accounted separately from brewing water to avoid double-counting.

Implementation-Agnostic Decomposition: Stop at Problem-Locating Granularity

Tasks are described without specifying tools (e.g., A02.1 says "produce grounds meeting the recipe", not which grinder). This "implementation-independent" level allows the task structure to remain stable if tools change, provided inputs, outputs, dependencies, and missing-item handling stay the same. If those change, the relationships are updated. The author also notes that the eight-minute morning feasibility is still unproven — actual durations, overlap potential, and wait handling must be measured.

Task Detail Checklist

To refine the task archive, the author provides a checklist for each task:

Task ID and version:
What result this step must produce:
What materials or information are needed:
What conditions must be satisfied to start:
What this step leaves for the next step:
How to confirm completion:
Which prior tasks' results are needed and why:
What to do when items are missing or interrupted:
What records must be kept and which indicators they map to:
What is still unknown and who to ask:

Conclusion and Next Steps

Returning to the chaotic morning, the remedy is to clarify exactly what is missing before brewing, then embed "what is needed to start, what is left when done, and how to handle gaps" into each task. This turns vague checks into concrete condition verification and makes adjustment points visible. The next article will take this task structure and define the "who, under what conditions, to what level" for each requirement — early serve, acceptable taste, and reliable recall.

Reference

U.S. Department of Defense, Mission Engineering Guide , Version 2.0, 2023-10-01, Chapter 5 and Sections 5.1–5.2, pp. 18–20. Used to explain that a Mission Thread (MT) contains tasks, events, decisions, and interactions, while a Mission Engineering Thread (MET) adds executors and systems. The coffee task numbering, decomposition sketches, checklists, and exception handling are pedagogical designs and do not represent formal modeling syntax or verified execution flows. https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf