Mission Engineering 06: Who Does What, With Which Tools — From Paper Plans to Verified Execution

The article continues a series on Mission Engineering (ME) by introducing the Mission Engineering Thread (MET), which maps high-level mission tasks to specific executors (people, equipment, systems) and concrete actions. The previous installment defined mission tasks (MT) such as "produce coffee grounds matching the recipe" without specifying hand-grinder vs. electric grinder. MET adds that layer: which grinder, who sets it up, who operates it, how completion is confirmed, and where the grounds go next.

Two Implementations for the Same Task

A comparison of two ways to fulfill "produce coffee grounds matching the recipe":

Hand grinder: You set and operate the hand grinder, then collect and verify the grounds. Open question: how long are you occupied, and when can you switch to another task?

Electric grinder: You set and start the electric grinder; the machine grinds, then you collect and verify. Open question: does the machine still need attendance, or can you assume the operator is free after start?

The article emphasizes that swapping tools changes human workload and timing, so each variant must be re-verified.

Resource Inventory and Capability Checks

Under a "no new equipment" constraint, the author lists available resources with IDs (CF-RES01 to CF-RES05):

CF-RES01: You — verify conditions, operate tools, check, record, serve. Need to confirm which actions require continuous hands-on and familiarity with the method.

CF-RES02: Temperature-display gooseneck kettle — heat and pour, read display. Need to confirm capacity, display meaning, keep-warm function, and which phases require attendance.

CF-RES03: Hand grinder — grind per chosen setting. Need to confirm usability, setting verifiability, and grind-completion signal.

CF-RES04: Digital scale — weigh beans and monitor pour weight. Need to confirm range, display suitability, and which readings must be retained when switching weighing targets.

CF-RES05: Smartphone — view recipe, time, or log entries. Need to confirm whether app-switching disrupts current use, whether timer persists, and whether notifications interrupt operations.

The article stresses: "Has this function," "Available now," and "Free at this moment" are three different questions. A scale may weigh but be holding the dripper; a phone may log but be showing the timer screen. Actual occupancy must be traced through the operation sequence.

Task-to-Resource Allocation Draft

A mapping of each mission task (A01–A05) to concrete actions, resources, and handoff checks:

A01 Confirm conditions & method: You + family confirm agreement, view recipe on phone, check materials/tools. Handoff: version clarity and parameter accessibility.

A02.1 Prepare grounds: You weigh on scale, operate hand grinder, collect grounds. Handoff: recorded dose and setting, traceability to this batch.

A02.2 Prepare water: You fill, set, start kettle; kettle heats, you verify per device. Handoff: water ready and still meeting conditions at use time.

A02.3 Ready filter & receiver: You prepare dripper, paper, and placement per method. Handoff: if pre-wetting needed, water in place; scale free for next use.

A03 Brew: You verify prep, operate kettle with scale and timer; dripper and receiver filter and catch. Handoff: end criteria met, key records and deviations captured.

A04 Serve: You deliver coffee, log actual time; family confirms receipt. Handoff: timestamp links to this brew; evaluation agreement still valid.

A05 Collect feedback & archive: Family gives impressions, you consolidate records, flag gaps. Handoff: feedback obtained, records traceable to method; missing feedback scheduled for follow-up.

The author notes that missing micro-steps (e.g., what to do with the scale reading after weighing beans) should be added to the execution plan without necessarily creating new high-level tasks. If a missing dependency is discovered (e.g., filter prep must wait for specific water), it goes back to the mission-task layer; if it's only a resource-sharing constraint (one scale used for both bean weighing and pour monitoring), it stays in the execution plan and is not elevated to a universal task dependency.

Human vs. Equipment Occupancy

The article distinguishes "human waiting" from "human occupied." If the kettle heats without needing continuous attention, that window can be used for grinding. However, filling, starting, checking status, and pouring still require scheduling — the entire "prepare water" task cannot be treated as unattended. Hand grinding, by contrast, continuously occupies the hands; the article asks whether it can be paused and what recovery requires.

A simplifying assumption is introduced for this example: continuous manual pouring and manual phone logging each exclusively occupy the operator (CF-RES01) during their active phases; capacity = 1, each needs 1. This is a local simplification, not a claim that humans can never multitask.

Occupancy Intervals and Release Conditions

Start/end events for three key activities:

Continuous manual pour: Occupies CF-RES01 and CF-RES02 from lifting kettle for this pour segment to setting it down stable. Human released after segment; kettle retained for later brew phases. Mid-segment pause for logging not yet decided.

Manual phone logging: Occupies CF-RES01 and CF-RES05 from picking up phone and navigating to log page through read, input, save. Rule: finish one complete log entry before next human action; return to timer etc. listed separately. Allowable delay depends on how long source information persists — still to be confirmed.

Kettle heating wait: Occupies CF-RES02 from start to end of heating phase. Heating end only marks phase end; kettle stays reserved for this brew water. Human start/check actions recorded separately; whether operator can do other work during wait must be verified against device specs.

An illustration shows the difference between equipment wait (kettle heating) and active human operation. The author advises writing clear start/stop actions first, not guessing seconds. Planned vs. actual durations are kept separate, with sources and gaps logged per the method in episode 02.

Key insight: "Human hands free ≠ equipment free." Water remains in the kettle for later brewing; the kettle cannot be reassigned just because the operator set it down.

Resource Contention

When multiple actions need the same resource in the same window and capacity is insufficient, that is resource contention. Under the example's assumption, if pouring and logging overlap, the schedule cannot satisfy both; they must be sequenced or the method adjusted, then re-checked for timing limits and recording requirements. The conflict is logged as a risk to verify; overlap is not guaranteed, and even if it occurs, sequencing may resolve it — not a deadlock by default.

Handoffs Within a Single Operator

Handoffs are not only between people. The article applies the Mission Architecture Style Guide's End-to-End (E2E) connection view to trace material and information flow across five links:

<ol>
<li><code>配方记录 --版本与参数--> 你 --设置、操作--> 壶与磨豆机</code></li>
<li><code>壶与电子秤 --显示信息--> 你 --选择、录入--> 本次记录</code></li>
<li><code>磨豆机 --咖啡粉，由你移入--> 滤杯与滤纸</code></li>
<li><code>壶 --冲煮用水，由你注入--> 滤杯与滤纸 --滤出的咖啡液--> 承接容器</code></li>
<li><code>家人 --评价原话--> 你 --收集、录入--> 本次记录</code></li>
</ol>

Arrows label material vs. information; related actions are noted. This is not an execution sequence diagram nor does it imply networked devices. The serve action remains in A04; missing feedback in A05 stays flagged.

Three Critical Handoff Details

End of bean weighing → scale switches to brew use: Next step needs retained readings, cleared weighing position, ready conditions. You verify; lost readings flagged as gaps, not back-filled from recipe targets.

Water ready → about to brew: Next step needs water still meeting agreed conditions, plus evidence (volume, temperature, read time). You re-verify; unclear state triggers re-check, not reuse of an earlier "ready" label.

Brew end → consolidate method record: Next step needs this run's raw records, deviations, open items. You verify ownership and completeness; recollected entries marked as such, not mixed with live records.

An illustration shows the scale handoff check. The article warns: kettle heats faster but filter paper isn't ready → coffee still late; scale reading visible but forgotten when switching targets → data lost. Individual tools work alone; chained together they must be walked through.

Walk-Through Before Timing Claims

With the allocation table in hand, the author recommends a paper walk-through from A01 to A05: How is each task done? Where is the next input? Do two actions need the same tool at the same time? Which check lacks an owner? Any discovered wait, rework, or missing log is mapped back to the requirements from episode 05 (e.g., CF-REQ01 serve-by time, CF-REQ03 prep checks, CF-REQ04 complete records). Real occurrence and impact need a trial run.

The article cautions against subtracting overlapping planned durations to claim a hard start time (e.g., 7:20) will hit a target (e.g., 7:28). First, write the overlap conditions; then log actual start/stop times. Prep done the night before still gets its own archived entry to avoid conflating conditions.

Template for Your Own Tasks

A checklist to add alongside existing task tables:

<ol>
<li><code>关联任务与需求的编号、版本：</code></li>
<li><code>这次采用的具体动作：</code></li>
<li><code>由谁操作，用哪一件器具或哪个系统：</code></li>
<li><code>需要会做什么，怎样确认人或器具做得到：</code></li>
<li><code>开始与结束事件，计划和实际时间分别放在哪里：</code></li>
<li><code>哪些阶段占用人，哪些阶段只是器具运行或等待：</code></li>
<li><code>共享资源能同时支持几项操作，依据或假设是什么：</code></li>
<li><code>何时释放，能否暂停，允许延迟到什么时候：</code></li>
<li><code>交给下一步什么，由谁检查：</code></li>
<li><code>缺项或冲突怎样处理，还有什么待核实：</code></li>
</ol>

Example: a spare-parts pickup cannot just note "warehouse system" at "issue." Must trace who finds the physical item, who cross-checks, which terminal logs it; if two jobs depend on the same storekeeper, system-level parallel tickets don't prove site-level concurrency.

Summary

Paper says "boil water and grind beans simultaneously"; reality asks: when are your hands free, when is the kettle free, which step is still waiting? Missing actions go into the execution plan; missing tasks or dependencies go back to the task table. Only then can you tell whether the fix is a method change or a requirement renegotiation. This is still a candidate plan; the next episode will compare it with improved variants (advance prep, segmented logging) to see what each improves and what new work it adds.

References

U.S. Department of Defense, Mission Engineering Guide, Version 2.0, 2023-10-01, Sections 5.1–5.2, pp. 19–20. Explains MT/MET division, execution element allocation, and analysis detail commensurate with study purpose. URL: https://ac.cto.mil/wp-content/uploads/2023/11/MEG_2_Oct2023.pdf

U.S. Department of Defense, Mission Architecture Style Guide, Version 1.0, cover date 2025-01-06, release memo (PDF p.3), Sections 5.3–5.4 (pp. 31, 34–37). Describes its role as MEG 2.0 appendix, execution-to-task mapping, interface checks, and E2E connection view. Resource IDs, equipment configs, occupancy assumptions, tables, and textual schematics in this article are pedagogical designs, not guide originals, nor executed simulations or formal UAF/OPM models. URL: https://ac.cto.mil/wp-content/uploads/2025/01/U-Mission-Architecture-Style-Guide-Final_07Jan2025.pdf