anchor.diff:  
   `score`::
   
  -    This records the time taken to score a particular document via it's Scorer
  +    This records the time taken to score a particular document via its Scorer
   
   `*_count`::
       Records the number of invocations of the particular method.  For example, `"next_doc_count": 2,`
  
positive.code: 
  ==== Understanding MultiTermQuery output
  
  A special note needs to be made about the `MultiTermQuery` class of queries.  This includes wildcards, regex and fuzzy
  queries.  These queries emit very verbose responses, and are not overly structured.
  
  Essentially, these queries rewrite themselves on a per-segment basis.  If you imagine the wildcard query `b*`, it technically
  can match any token that begins with the letter "b".  It would be impossible to enumerate all possible combinations,
  so Lucene rewrites the query in context of the segment being evaluated.  E.g. one segment may contain the tokens
  `[bar, baz]`, so the query rewrites to a BooleanQuery combination of "bar" and "baz".  Another segment may only have the
  token `[bakery]`, so query rewrites to a single TermQuery for "bakery".
  
  Due to this dynamic, per-segment rewriting, the clean tree structure becomes distorted and no longer follows a clean
  "lineage" showing how one query rewrites into the next.  At present time, all we can do is apologize, and suggest you
  
negative.code: `build_scorer`::
  
      This parameter shows how long it takes to build a Scorer for the query.  A Scorer is the mechanism that
      iterates over matching documents and generates a score per-document (e.g. how well does "foo" match the document?).
      Note, this records the time required to generate the Scorer object, not actually score the documents.  Some
      queries have faster or slower initialization of the Scorer, depending on optimizations, complexity, etc.
      {empty} +
      {empty} +
      This may also show timing associated with caching, if enabled and/or applicable for the query
  
  `next_doc`::
  
  