Reviewing Results

A completed run is at /home/<team>/optimize/<jobId>, reachable from the runs list.

This page is a proposal, not an instruction. The question you are answering is not "did it work?" but "is the improvement worth the disruption?"

What is on the page

Before and after comparison

Your current distribution against the proposed one, metric by metric, with the projected improvement.

Look past the headline percentage:

• Which metrics improved, and which got worse? Balancing one thing usually costs another. If the summary improvement is 30% but travel got worse, that is a different decision.
• Did the worst region actually improve? An average can improve while your most overloaded region stays overloaded. That is the region the change is supposed to be for.
• Is the spread tighter? Balance is about the range across regions, not the total.

The movement table

Every postal area the proposal moves, with its current region and its proposed one.

This is the most operationally important part of the page. Read it as a work plan, because that is what it becomes:

• How many areas move? Ten is a manageable change. Two hundred is a project.
• How many regions are affected? A change touching two regions is a conversation. A change touching all eight is a reorganisation.
• Are the moves adjacent? Areas moving to a region they border are operationally sensible. Areas moving somewhere they do not touch are not.
• Which clients does this actually affect? Each area is real people whose worker may change.

Result maps

Current and proposed regions side by side.

Look at shape, not just colour. Ask:

• Do the proposed regions look like territories someone could drive?
• Has any region become long, thin, or fragmented?
• Do boundaries respect the things your maps do not show — a river, a highway, a bridge with a toll, a boundary between two funding bodies?

Geography is where an algorithm's blind spots show most clearly.

Convergence chart

For the iterative approaches, how the solution improved over the run.

A curve that flattened out well before the end means the search found what it was going to find; more iterations would not help. A curve still climbing at the end means it was cut short — consider rerunning with more iterations.

AI summary

A written summary of what the run did and why. Useful for circulating, and particularly detailed for the AI-Powered approach, which explains its reasoning in plain language.

Read it as an explanation of the result, not as independent confirmation that the result is good.

Exporting

A completed run can be exported as CSV from /home/<team>/optimize/<jobId>/export. This gives you the movements in a form you can work with in a spreadsheet or hand to whoever executes the change.

For something to circulate to people who will not open the platform, generate an optimization report instead — see Reports.

Deciding

Compare against doing nothing. The relevant comparison is not "is this better than the current state" — it usually is — but "is it better by enough to justify moving clients between workers?"

Weigh the disruption honestly. Every moved area means clients meeting a new worker and staff learning a new patch. That cost is real and is not in the model.

Check it with the people who run the regions. They know the things the data does not: language needs, building access, certifications, relationships, personalities. A proposal that survives that conversation is a good one.

Consider a partial adoption. You do not have to take all of it. Taking the moves that are obviously sensible and leaving the marginal ones is a legitimate and often better outcome.

Consider a smaller approach. If the disruption is too much, rerun as a Boundary Rebalance with a deviation budget and see how much of the benefit survives.

If the result looks wrong

Next

• Hand-tune it: Preview Sandbox
• Make it real: Applying Changes
• Document it: Reports