Browse Help topics
Back to Help
Verified Jul 23, 20265 min read

Run and improve a solve

Configure scope, starting point, search, effort, and orchestration.

Start with the standard plan

For most scenarios, begin with the Auto recipe and leave Scope, Starting Point, Search, and Effort in their automatic modes. Auto assembles a compatible plan from the scenario and available runtime rather than asking you to choose an internal solver family first.

Before running, confirm that the plan summary matches what you intend to change. A longer run can improve optimization quality, but it cannot repair invalid people, references, capacity, or contradictory requirements.

Understand the four plan decisions

Plan sectionQuestion it answersSafe starting point
ScopeWhich sessions may the solver change?All sessions editable
Starting PointWhere does the first candidate schedule come from?Default construction
SearchHow should the candidate be improved?Auto local improvement
EffortHow long and with what resource policy should solving continue?Complexity-derived effort

Scope

Auto scope lets the solver edit all sessions. Custom scope selects particular sessions. An empty custom session selection is interpreted as all sessions editable, not zero sessions, so verify the summary before running.

Scope currently controls sessions. Do not assume that unimplemented future boundaries—such as freezing arbitrary people or groups—are active.

Starting Point

Default construction builds a candidate with constraint guidance and explicit feasibility fallbacks. Use it first.

A warm start uses a saved result from the current scenario. It is useful when you want to improve an existing schedule or preserve much of its structure. A stale or incompatible warm start may be reconciled, adjusted, or rejected; GroupMixer reports what happened. Do not use a result from a different scenario as an informal substitute.

Auto search currently selects local improvement with a recommended search budget. Custom search exposes solver-family and family-specific controls. Change it only when you can explain what behavior you need and how Results will show whether it helped.

Effort

Complexity-derived effort lets Auto select a runtime from scenario complexity. Fixed total runtime gives the run a predictable time budget. Start short while validating a new scenario, then increase effort after the setup and scoring model are correct.

Parallel Auto gives independent lanes the configured full budget and returns the best incumbent. Remaining lanes may be cancelled early when another lane reaches zero objective cost. Available lane counts depend on browser worker capacity. More lanes consume more memory and CPU; one lane gives simpler resource usage.

Choose orchestration deliberately

ModeBehaviorUse it when
AutoRuns the configured plan onceNormal solving
ExtremeStarts with Auto and continues annealing polish until cancelledYou intentionally want an open-ended improvement run
Ultra ExtremeRuns source census, seed polish, session growth, and ruin/recreate orchestrationExpert investigation of difficult scenarios

Extreme is not a larger fixed effort preset: it continues until you cancel it. Some Extreme tuning can change while the run is active, so review those controls separately from the settings that are locked during ordinary runs.

Ultra Extreme is specialist orchestration. Its partial internal candidates are not presented as completed target results, and unsupported source kinds are skipped or rejected explicitly. It should not be the first response to a scenario that fails validation.

Run and watch progress

The Run section shows the active recipe, plan summary, progress, diagnostics, and latest result. Start only after the runtime catalog is ready and the scenario passes preflight validation.

When the solve completes, open the produced result or use Runs to inspect recent attempts and their linked results. A result link becomes available only when a saved result exists.

Cancel without guessing

Cancel opens three choices:

  • Back — keep solving.
  • Discard Progress — stop and discard the current progress.
  • Save Progress — save the latest valid best-so-far snapshot, then stop.

Save Progress can fail if the backend has not produced a usable snapshot or if that snapshot cannot be evaluated or persisted. In that case cancellation does not proceed automatically. Read the notification before choosing another action.

Improve an existing result

  1. Open Results and identify the evidence that needs improvement: a weighted deviation, repeated pair, contact gap, or operational roster issue.
  2. Return to the relevant scenario control. Do not change several weights and constraints at once.
  3. Use the saved result as a warm start if preserving its structure matters.
  4. Confirm Scope, especially when only future sessions should change.
  5. Run with enough effort to compare meaningfully.
  6. Compare results under equivalent scenario and scoring settings.

A lower Cost Score is better under the configured model. If you change constraints, objective weights, or penalty functions, the old and new scores may no longer answer the same question.

Keep Settings JSON advanced

Settings JSON replaces solver settings exactly after you press Apply settings JSON. It accepts several supported wrapper shapes, but still requires a valid settings object with a solver type, stop conditions, and solver parameters. Large numeric seeds outside JavaScript’s safe integer range must be quoted strings.

Use this surface for trusted reproduction or diagnostics, not routine onboarding. A parsed object can still contain values rejected later by backend validation.

Continue with Understand results. For validation, runtime, warm-start, or persistence failures, use Troubleshoot scenarios and solves.