anchor.diff:  Let us imagine that we have configured a job and it has been running
   for some time. After observing its results we decide that we can employ
   rules in order to get rid of some uninteresting results. We can use
  -the update-job API to do so. However, the rule we added will only be in effect
  -for any results created from the moment we added the rule onwards. Past results
  -will remain unaffected.
  +the {ref}/ml-update-job.html[update job API] to do so. However, the rule we 
  +added will only be in effect for any results created from the moment we added 
  +the rule onwards. Past results will remain unaffected.
   
   ==== Using rules VS filtering data
   
  
positive.code: skip results for domains that we consider safe. Using a rule with a scope allows 
  us to achieve this.
  
  First, we need to create a list with our safe domains. Those lists are called 
  `filters` in {ml}. Filters can be shared across jobs.
  
  We create our filter using the {ref}/ml-put-filter.html[put filter API]:
  
  
negative.code: 
  ==== Specifying rule scope
  
  Let us assume we are configuring a job in order to detect DNS data exfiltration.
  Our data contain fields "subdomain" and "highest_registered_domain".
  We can use a detector that looks like `high_info_content(subdomain) over highest_registered_domain`.
  If we run such a job it is possible that we discover a lot of anomalies on 
  