Documentation
Construction
Construction heuristic policy, nullable obligations, candidate limits, and grouped scalar construction.
Construction creates the first workable solution before local search improves it. A production config usually starts with one construction phase and then hands the result to local search.
[[phases]]
type = "construction_heuristic"
construction_heuristic_type = "first_fit"
construction_obligation = "preserve_unassigned"
value_candidate_limit = 32
Heuristic Types
| Type | Use |
|---|---|
first_fit |
assign the first doable value that improves or preserves the current construction policy |
cheapest_insertion |
evaluate bounded candidates and pick the cheapest insertion |
| list-specific constructors | route and sequence initialization where list work is present |
Generic FirstFit and CheapestInsertion use the canonical construction
engine when matching list work is present. Pure scalar targets use the
descriptor-scalar construction path.
Nullable Construction Obligation
Nullable scalar variables default to preserve_unassigned: construction may
leave None in place when that is legal and scores best.
Use assign_when_candidate_exists when construction should assign a doable
value whenever one exists:
[[phases]]
type = "construction_heuristic"
construction_heuristic_type = "first_fit"
construction_obligation = "assign_when_candidate_exists"
This separates Rust nullability from construction policy. A field can be nullable because later moves may unassign it, while construction can still be told to fill it whenever a legal value exists.
Candidate Limits
Scalar construction can use bounded candidates from model hooks or from config:
[[phases]]
type = "construction_heuristic"
construction_heuristic_type = "cheapest_insertion"
value_candidate_limit = 32
cheapest_insertion for scalar construction requires one bounded candidate
source: either candidate_values on the model or a config candidate limit.
Construction Order Keys
Scalar construction heuristics that sort entities or values declare those
capabilities on #[planning_variable]:
construction_entity_order_key = "fn_name"construction_value_order_key = "fn_name"
SolverForge re-evaluates construction order hooks on the current working solution at every construction step. Queue-style and weakest/strongest-fit heuristics therefore track live model state instead of a phase-start snapshot.
These hooks are construction-only. Local-search scalar change, pillar-change, and ruin/recreate selectors keep canonical bounded candidate order.
Grouped Scalar Construction
Use grouped scalar construction when the legal assignment is a bundle of scalar edits.
[[phases]]
type = "construction_heuristic"
construction_heuristic_type = "first_fit"
group_name = "task_operator_assignment"
value_candidate_limit = 32
group_candidate_limit = 128
group_name selects a named model-provided scalar group. group_candidate_limit
caps normalized grouped candidates after SolverForge removes illegal,
duplicate, no-op, and non-frontier edits.
See Also
- Local Search - improving the constructed solution
- Scalar Move Selectors - grouped scalar local-search counterpart