The plan the system shows must match the path it actually runs, or approval is empty

What it is

What a person approved is the nodes on the screen. If what runs is another chain — a step dropped, an extra outward, an object swapped for a near-synonym — the approval covers a script, not the performance. Shown plan must match the path run. When they disagree, pre-execution review, editable, re-approval of changes all fall through, because the object was wrong from the start.

The process view wired to the scheduler is truth after it starts; this is before start, when the plan generator and the scheduler must be the same structure.

Why it happens

Plans are often narrated by a language model; execution is implemented by a tool scheduler. If the two are not aligned, the narration is cleaner and easier to approve, and the scheduler walks another set. This is the pre-execution version of fake steps: a fake window gives certainty of having reviewed. Aggregation may show fewer internal hops; it may not show an outward node the scheduler does not have, nor hide one it does. Diff notice presupposes a true approved copy; if the copy was fake from the start, a diff cannot be computed.

Studying it

Deliberately fork plan narration from the scheduler (plan has no send, scheduler has a send). Compare: no check, automatic diff before start, diff and refuse to start on fork. Dependent variables: whether an outward act not in the plan happens, whether people report “I approved so it is safe,” when the fork is found. Independent variables: whether the check sits after generation or before schedule, whether the fork is shown to the person.

The primary endpoint is how often an outward act outside the plan happens. If it happens, approval is empty.

Where it stops holding

A legal reroute after start takes change-notice; it is not inconsistency before start. Internal hops aggregated away still count as consistent if the outward-node sets match. Fake reasoning narrative in-process is another window. Grain can be right and the nodes still invented; what is reviewed is still fake.

Applying it

• Before start, check the set of nodes the scheduler will run against the plan on screen. If the sets disagree, do not start, and show the person the diff.
• The plan generator must not write a separate “handsome” narration for approval; approval and schedule share a data source.
• Check: leave send out of the plan, leave it in the scheduler. If the mail goes, consistency is not done. After the halt, the person should see “not in the plan, but will send” before start — if they do not, the check was not exposed.

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.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
• Nearby: L4.12 Task Progress and Intermediate-state Visibility · L4.08 Visibility of Task Progress · L5.01 Types of Explainability
• Search terms: faithful plan · plan versus execution · approval