If the plan changes during execution, that change must be notified, or the prior approval no longer holds

What it is

What a person approved is one plan. After it starts the agent reroutes — adds a step, swaps an object, turns inward into outward — and if the change is quiet, the approval no longer covers what is running. Notify mid-execution plan change: when a change happens, hand the person the diff, and new outward nodes must not run until they are approved again.

“You clicked agree just now” does not automatically extend to a sequel they have not seen.

Why it happens

Approval is consent to a concrete path, not a blank cheque for this agent. Reroute mid-execution is common on a capability boundary: object missing, swap; tool failed, detour. A detour may move risk from inward to outward. If the process view only shows the current tool, people see the new step and may not know it was not in the approval. Notice wants a diff: relative to the approved copy, what was added, dropped, which step’s object changed. Without a diff, people can only review the whole again, which is as if approval never happened.

Position and remainder must change with it, or the skeleton still points at the old plan.

Studying it

After start, plant a reroute (swap recipient, add an outward step). Compare: silent reroute, a badge “plan updated,” a diff plus new outward nodes held for re-approval. Dependent variables: whether people intervene before the new outward step, whether they still believe the old plan is running, time to re-approve. Independent variables: whether the diff can be opened, whether new outward defaults to halt.

Still believing the old plan is running is the subjective mark of notice failing.

Where it stops holding

A reroute that does not change object, verb or outwardness (a purely internal retry) can be logged without interrupting, but should remain inspectable on the plan rail. The displayed path must be real: notifying a fake change is as bad as not notifying a real one. Editable is surgery before execute; this is the approved copy expiring during execute. Grain too fine makes the change notice itself a flush.

Applying it

• Diff against the approved copy. When the diff touches object, verb or outwardness, interrupt and hold new outward nodes.
• Put only the diff in the notice, do not re-paste the whole plan. Offer “continue on the original approval (reject the reroute)” and “accept the reroute.”
• Check: approve send to A, reroute while running to B. There must be another halt before B goes. If B goes straight out, approval was quietly extended. Ask the operator “who did you approve sending to” — if they still say A, notice has not entered awareness.

Related

• Same group: L4.14.1 Showing the plan before execution moves correction cost from after to before · L4.14.2 The plan must be editable by the user, not only approved or rejected · 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.07 Pre-action Confirmation · L4.06 Permission Boundaries of Agents
• Search terms: plan revision · stale approval · replanning