L4.14.1show the plan before executiondesignresearch

Showing the plan before execution moves correction cost from after to before

Aliases: pre-execution plan · prune the future · correction even earlier

What it is

In-process intervention moves correction from the finale to before a crossing; one slice further forward is showing the nodes that will be walked before anything runs. Show the plan before execution lets a person change an object, drop a step, pin an outward act, before the first tool call. Cost stays on the draft, not in the world.

A plan is a path that has not happened. Seeing it is pruning the future, not doing archaeology on wreckage.

Why it happens

Correction cost rises with world boundaries already crossed. A pre-execution plan keeps that count at zero. What a person changes in this moment is intent, not compensation. If the decision-selection stage in supervisory control is visible to the person, action implementation has not started; the plan view is that stage’s UI. It divides labour with the process view: plan is will-do, process is doing. Without will-do, people can only chase doing.

If the plan is only generated once it is already running, this forward move does not exist. Agents that think while they run weld decision to action; correction can only be in-process or after.

Studying it

Hold the same multi-step task, compare: run with no plan, a read-only plan before execute, a plan editable before execute. Dependent variables: outward error count, steps changed before the first call, total time. Independent variables: whether the plan includes objects, whether outward nodes are marked, whether a person must confirm to start.

The primary endpoint remains outward error. Time going up and outward error going down is cost moving as designed, not failure.

Where it stops holding

A short task a glance explains: a plan view is friction. A plan too fine to review fails the forward move — grain is separate. A plan rewritten after it starts, without notice, voids the prior approval. If the plan shown and the path run are not the same, approval is empty. In-process correction is still needed, because a plan will not exhaust the world; it only sees earlier the stretch that can be seen earlier.

Applying it

  • Multi-step tasks that include outward acts default to a plan before they run. Mark outward nodes on their own.
  • Starting must pass a beat where a person has seen the plan. Auto-start equals no pre-execution.
  • Check: write a wrong object into the plan. The person should take it off before start, zero outward acts. If the error is always found in-process or at the finale, the plan has not yet moved correction to before execute.

Related

  • Same group: L4.14.2 The plan must be editable by the user, not only approved or rejected · L4.14.3 If the plan changes during execution, that change must be notified, or the prior approval no longer holds · L4.14.4 The plan's abstraction level must match the user's capacity to judge; a too-fine plan cannot be reviewed · L4.14.5 The plan the system shows must match the path it actually runs, or approval is empty
  • Nearby: L4.12 Task Progress and Intermediate-state Visibility · L4.08 Visibility of Task Progress · L4.07 Pre-action Confirmation
  • Search terms: plan preview · pre-execution review · supervisory control

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L4.14.1