anchor.diff:    ...
   </solver>
   ----
  -
  ++
   [WARNING]
   ====
  -Don't forget to call `Solver.terminateEarly()` when your application needs to shutdown to avoid killing the solver thread unnaturally.
  -====
  -
  -Subscribe to the `<<SolverEventListener,BestSolutionChangedEvent>>` to process new best solutions found by the solver thread.
  -A `BestSolutionChangedEvent` doesn't guarantee that every `ProblemFactChange` has been processed already, nor that the solution is initialized and feasible.
  -To ignore ``BestSolutionChangedEvent``s with such invalid solutions, do this:
  -
  +Do not forget to call `Solver.terminateEarly()` when your application needs to shutdown to avoid killing the solver thread unnaturally.
  +====
  +
  +. Subscribe to the `<<SolverEventListener,BestSolutionChangedEvent>>` to process new best solutions found by the solver thread.
  ++
  +A `BestSolutionChangedEvent` does not guarantee that every `ProblemFactChange` has been processed already, nor that the solution is initialized and feasible.
  +
  +. To ignore ``BestSolutionChangedEvent``s with such invalid solutions, do the following:
  ++
   [source,java,options="nowrap"]
   ----
       public void bestSolutionChanged(BestSolutionChangedEvent<CloudBalance> event) {
  
positive.code:     }
  ----
  
  Use `Score.isSolutionInitialized()` instead of `Score.isFeasible()` to only ignore uninitialized solutions, but do accept infeasible solutions too.
  
negative.code: [[realTimePlanning]]
  == Real-time Planning
  
  To do real-time planning, combine the following planning techniques:
  
  * <<backupPlanning,Backup planning>> - adding extra score constraints to allow for unforeseen changes).
  * <<continuousPlanning,Continuous planning>> - planning for one or more future planning periods.
  * Short planning windows.
  +
  This lowers the burden of real-time planning.
  
  As time passes, the problem itself changes. Consider the vehicle routing use case:
  
  image::RepeatedPlanning/realTimePlanningVehicleRouting.png[align="center"]
  
  In the example above, three customers are added at different times (``07:56``, `08:02` and ``08:45``), after the original customer set finished solving at `07:55`, and in some cases, after the vehicles already left.
  
  Planner can handle such scenarios with `ProblemFactChange` (in combination with <<immovablePlanningEntities,immovable planning entities>>).
  
  
  [[problemFactChange]]
  === ProblemFactChange
  
  While the `Solver` is solving, one of the problem facts may be changed by an outside event. For example, an airplane is delayed and needs the runway at a later time.
  
  [IMPORTANT]
  ====
  Do not change the problem fact instances used by the `Solver` while it is solving (from another thread or even in the same thread), as that will corrupt it. 
  ====
  
  Add a `ProblemFactChange` to the `Solver`, which it executes in the solver thread as soon as possible. For example:
  
  [source,java,options="nowrap"]
  ----
  