anchor.diff:  
   [source,java]
   ----
  -public final class TinkerGraphStepStrategy extends AbstractTraversalStrategy<TraversalStrategy.OptimizationStrategy> implements TraversalStrategy.OptimizationStrategy {
  +public final class TinkerGraphStepStrategy extends AbstractTraversalStrategy<TraversalStrategy.VendorOptimizationStrategy> implements TraversalStrategy.VendorOptimizationStrategy {
   
       private static final TinkerGraphStepStrategy INSTANCE = new TinkerGraphStepStrategy();
  -    private static final Set<Class<? extends OptimizationStrategy>> PRIORS = new HashSet<>();
  -
  -    static {
  -        PRIORS.add(IdentityRemovalStrategy.class);
  -    }
   
       private TinkerGraphStepStrategy() {
       }
  
positive.code: 
  IMPORTANT: `TraversalStrategy` categories are sorted within their category and the categories are then executed in the following order: decoration, optimization, finalization, and verification. If a designed strategy does not fit cleanly into these categories, then it can implement `TraversalStrategy` and its prior and posts can reference strategies within any category.
  
  Another example `OptimizationStrategy` in action is provided below.
  
  [source,groovy]
  g.V().has('name','marko')
  
negative.code: image:traversal-strategy.png[width=125,float=right] A `TraversalStrategy` can analyze a `Traversal` and mutate the traversal as it deems fit. This is useful in multiple situations:
  
   * There is an application-level feature that can be embedded into the traversal logic (*decoration*).
   * There is a more efficient way to express the traversal at the TinkerPop3 level (*optimization*).
   * There is a more efficient way to express the traversal at the graph vendor level (*vendor optimization*).
   * There are are some final adjustments required before executing the traversal (*finalization*).
   * There are certain traversals that are not legal for the application or traversal engine (*verification*).
  
  