anchor.diff:  
   There is a `ScoreVerifier` implementation for each `Score` implementation.
   In the `assertHardWeight()` and `assertSoftWeight()` methods, the weight of the other score rules is ignored (even those of the same score level).
  +
  +[NOTE]
  +====
  +A ScoreVerifier does not work well to isolate score corruption,
  +use <<invalidScoreDetection, an `assertionScoreDirectorFactory`>> instead.
  +====
  
positive.code: [[invalidScoreDetection]]
  === Invalid Score Detection
  
  
  Put the `environmentMode` in `FULL_ASSERT` (or ``FAST_ASSERT``) to detect corruption in the <<incrementalScoreCalculation,incremental score calculation>>.
  For more information, <<environmentMode,see the section about `environmentMode`>>.
  However, that will not verify that your score calculator implements your score constraints as your business actually desires.
  
  A piece of incremental score calculator code can be difficult to write and to review.
  Assert its correctness by using a different implementation (for example a ``EasyScoreCalculator``) to do the assertions triggered by the ``environmentMode``.
  Just configure the different implementation as a ``assertionScoreDirectorFactory``:
  
  [source,xml,options="nowrap"]
  ----
  
negative.code:   </scoreDirectorFactory>
  ----
  
  This way, the `scoreDrl` will be validated by the ``EasyScoreCalculator``.
  
  [NOTE]
  ====
  This works well to isolate score corruption,
  but to verify that the score rules implement the real business needs,
  <<testingScoreConstraints, a unit test with a ScoreVerifier>> is usually better.
  ====
  
  [[scoreCalculationPerformanceTricks]]
  == Score Calculation Performance Tricks
  