anchor.diff:    </termination>
   ----
   +
  -Planner should get a good result in seconds (and even in less than 15 milliseconds with <<realTimePlanning,real-time planning>>),
  -but the more time it has, the better the result will be.
  -Advanced use cases might use a different <<termination,termination criteria>> than a hard time limit.
  +Planner should get a good result in seconds (and even in less than 15 milliseconds with <<realTimePlanning,real-time planning>>), but the more time it has, the better the result will be. Advanced use cases might use a different <<termination,termination criteria>> than a hard time limit.
   + 
   The default algorithms will already easily surpass human planners and most in-house implementations.
   Use the <<benchmarker,Benchmarker>> to <<powerTweaking,power tweak>> to get even better results.
  
positive.code:   </scoreDirectorFactory>
  ----
  
  First, we want to make sure that all computers have enough CPU, RAM and network bandwidth to support all their processes, so we make these hard constraints:
  
  .cloudBalancingScoreRules.drl - Hard Constraints
  ====
  [source,options="nowrap"]
  
negative.code: Of course, Planner needs to be told about these domain-specific score constraints.
  There are several ways to implement such a score function:
  
  * <<cloudBalancingEasyJavaScoreConfiguration, Easy Java>>
  * Incremental Java
  * <<cloudBalancingDroolsScoreConfiguration, Drools>>
  
  
  [[cloudBalancingEasyJavaScoreConfiguration]]
  