Problem Facts

Immutable input data that constraints reference but the solver doesn’t modify.

A problem fact is an immutable struct that represents input data. The solver reads problem facts when evaluating constraints but never modifies them. Examples include employees, timeslots, rooms, and skills.

The #[problem_fact] Macro

use solverforge::prelude::*;

#[problem_fact]
#[derive(Clone, Debug)]
pub struct Employee {
    #[planning_id]
    pub id: i64,
    pub name: String,
    pub skills: Vec<String>,
}

#[problem_fact]
#[derive(Clone, Debug)]
pub struct Timeslot {
    #[planning_id]
    pub id: i64,
    pub day_of_week: String,
    pub start_time: String,
    pub end_time: String,
}

Field Attributes

#[planning_id]

Uniquely identifies the problem fact. Required.

#[planning_id]
pub id: i64,

When to Use Problem Facts vs Planning Entities

Problem FactPlanning Entity
Modified by solver?NoYes
Has planning variables?NoYes
ExampleEmployee, Room, TimeslotShift, Lesson, Visit
RoleInput data / possible valuesThings being assigned

A common pattern: problem facts serve as the value range for planning variables.

#[planning_solution]
pub struct Schedule {
    #[problem_fact_collection]
    #[value_range_provider]       // Employees are possible values...
    pub employees: Vec<Employee>,

    #[planning_entity_collection]
    pub shifts: Vec<Shift>,       // ...assigned to shift.employee
}

Requirements

  • Must derive Clone and Debug
  • Must have exactly one #[planning_id] field

See Also


Last modified March 14, 2026: chore: clean up -> 0.5.17 (1cc5923)