Chapter 3. Problem facts and planning entities

Each of the domain classes in the employee rostering planning problem can be categorized as one of the following:

A unrelated class: not used by any of the score constraints. From a planning standpoint, this data is obsolete.
A problem fact class: used by the score constraints, but does not change during planning (as long as the problem stays the same), for example, Shift and Employee. All the properties of a problem fact class are problem properties.
A planning entity class: used by the score constraints and changes during planning, for example, ShiftAssignment. The properties that change during planning are planning variables. The other properties are problem properties.
Ask yourself the following questions:
What class changes during planning?
Which class has variables that I want the Solver to change?
That class is a planning entity.
A planning entity class needs to be annotated with the @PlanningEntity annotation, or defined in Decision Central using the Red Hat Business Optimizer dock in the domain designer.
Each planning entity class has one or more planning variables, and should also have one or more defining properties.
Most use cases have only one planning entity class, and only one planning variable per planning entity class.