Replan

AG Arch uses Replan when the intended outcome is still correct, but the current route toward it is no longer the right one.

The key distinction is:

the goal stays the same; the path changes.

Replanning is therefore not a new task and not a new authorization by default. It is a controlled return to planning using the reality and evidence now available.

Why replanning is needed

The original plan is created from the best available information at that moment.

But execution can reveal things that were not known before.

For example:

• an assumption may be wrong;
• a dependency may behave differently than expected;
• the system state may have changed;
• an intermediate action may produce an unexpected result;
• one execution path may fail while another valid path exists.

AG Arch uses those new facts to update the plan instead of continuing mechanically with an outdated one.

Replan starts from current reality

Replanning does not return to the original starting point.

AG Arch first establishes:

What is true now, after everything that has already happened?

That may be different from the reality observed before execution began.

For example, the first attempt may have changed a configuration file even though the running service did not adopt the new value.

The new plan therefore begins from:

configuration changed, runtime still unchanged

not from:

configuration has not been changed.

This prevents recovery from repeating actions that have already happened or making decisions based on stale assumptions.

Existing evidence becomes planning input

Observe & Prove may have already revealed exactly where the previous path broke down.

That evidence is useful input to replanning.

AG Arch can use:

• observed system state;
• failed validations;
• execution receipts;
• dependency behavior;
• previous handoffs;
• partial results.

The recovery loop therefore does not discard evidence once verification fails.

It feeds that evidence back into the next plan.

Replan stays inside the existing mandate

AG Arch can replan autonomously when the revised path still fits within the existing governed mandate.

For example, the original plan may have been:

update configuration → verify service

Evidence then shows that the service needs an additional reload step.

If the existing mandate already allows the system to reload that service, AG Arch can revise the plan to:

update configuration → reload service → verify runtime state

No new human decision is required.

The route changed.

The authority did not.

Replan is not permission to expand scope

A revised plan may uncover a path that would technically solve the problem but lies outside the existing mandate.

For example:

The service cannot adopt the new configuration unless another production system is modified.

That is no longer just a planning change.

AG Arch has reached an authority boundary.

The recovery path must then move from Replan to Re-authorize.

This separation matters because otherwise replanning could become a hidden way for an autonomous system to expand its own scope.

A new plan can change sequence, method, or capability needs

Replanning may change:

• the order of actions;
• the chosen execution method;
• intermediate checks;
• dependency handling;
• validation steps;
• which capability is needed next.

But AG Arch continues to preserve the existing:

• intent;
• success criteria;
• Human Authority;
• governed mandate;
• proof requirements,

unless the evidence shows that one of those also needs to change.

If another capability is required, the revised plan can lead into Reroute.

Replanning can happen more than once

Complex autonomous work may encounter several changes in reality.

AG Arch can therefore replan more than once.

But repeated replanning is itself information.

If the system repeatedly fails to find a valid path, AG Arch should not loop indefinitely.

Traceability allows it to see that the same problem is recurring and move toward a different recovery decision, such as:

• Reroute;
• Re-authorize;
• Safe Stop.

The purpose of replanning is adaptation, not endless retry.

Example — changing a system configuration

The intended outcome remains:

• the approved configuration is active;
• the service uses it;
• the service remains healthy;
• unrelated configuration remains unchanged.

The first plan is:

1. update the configuration; 2. verify the running service.

Execution changes the configuration successfully.

Observation shows that the running service still uses the old value.

AG Arch now knows something the original plan did not account for:

The service does not reload this configuration automatically.

The current reality becomes:

• configuration source contains the correct value;
• running service still has the previous value;
• service remains healthy.

If the existing mandate permits a service reload, AG Arch replans:

1. reload the service; 2. observe the active configuration; 3. verify health; 4. confirm protected settings remain unchanged.

The intent has not changed.

The success criteria have not changed.

Human Authority has not changed.

AG Arch has simply replaced an invalid execution path with one that fits the reality now known.

What Replan changes

Replan changes:

the route toward the outcome.

It does not automatically change:

the outcome itself

or

the authority under which the work operates.

When the next valid path requires broader authority instead of merely a better plan, AG Arch moves to the next recovery mechanism: