anchor.diff:  [[warm-tier]]
   === Warm tier
   
  -Time series data can move to the warm tier once it is being queried less frequently 
  -than the recently-indexed data in the hot tier. 
  -The warm tier typically holds data from recent weeks. 
  +Time series data can move to the warm tier once it is being queried less frequently
  +than the recently-indexed data in the hot tier.
  +The warm tier typically holds data from recent weeks.
   Updates are still allowed, but likely infrequent.
  -Nodes in the warm tier generally don't need to be as fast as those in the hot tier. 
  +Nodes in the warm tier generally don't need to be as fast as those in the hot tier.
   For resiliency, indices in the warm tier should be configured to use one or more replicas.
   
   [discrete]
   [[cold-tier]]
   === Cold tier
   
  -Once data in the warm tier is no longer being updated, it can move to the cold tier. 
  -The cold tier typically holds the data from recent months or years.
  +Once data is no longer being updated, it can move from the warm tier to the cold tier where it
  +stays for the rest of its life.
   The cold tier is still a responsive query tier, but data in the cold tier is not normally updated.
   As data transitions into the cold tier it can be compressed and shrunken.
  -For resiliency, indices in the cold tier can rely on 
  -<<ilm-searchable-snapshot, searchable snapshots>>, eliminating the need for replicas. 
  +For resiliency, indices in the cold tier can rely on
  +<<ilm-searchable-snapshot, searchable snapshots>>, eliminating the need for replicas.
   
   [discrete]
   [[data-tier-allocation]]
   === Data tier index allocation
   
  -When you create an index, by default {es} sets 
  +When you create an index, by default {es} sets
   <<tier-preference-allocation-filter, `index.routing.allocation.include._tier_preference`>>
   to `data_content` to automatically allocate the index shards to the content tier.
   
  -When {es} creates an index as part of a <<data-streams, data stream>>, 
  -by default {es} sets 
  +When {es} creates an index as part of a <<data-streams, data stream>>,
  +by default {es} sets
   <<tier-preference-allocation-filter, `index.routing.allocation.include._tier_preference`>>
   to `data_hot` to automatically allocate the index shards to the hot tier.
   
  -You can override the automatic tier-based allocation by specifying 
  +You can override the automatic tier-based allocation by specifying
   <<shard-allocation-filtering, shard allocation filtering>>
   settings in the create index request or index template that matches the new index.
   
  -You can also explicitly set `index.routing.allocation.include._tier_preference`  
  -to opt out of the default tier-based allocation.  
  +You can also explicitly set `index.routing.allocation.include._tier_preference`
  +to opt out of the default tier-based allocation.
   If you set the tier preference to `null`, {es} ignores the data tier roles during allocation.
   
   [discrete]
  
positive.code: [[hot-tier]]
  === Hot tier
  
  The hot tier is the {es} entry point for time series data and holds your most-recent, 
  most-frequently-searched time series data. 
  Nodes in the hot tier need to be fast for both reads and writes, 
  which requires more hardware resources and faster storage (SSDs). 
  For resiliency, indices in the hot tier should be configured to use one or more replicas.
  
  New indices that are part of a <<data-streams, data stream>> are automatically allocated to the
  
negative.code: === Automatic data tier migration
  
  {ilm-init} automatically transitions managed
  indices through the available data tiers using the <<ilm-migrate, migrate>> action.
  By default, this action is automatically injected in every phase.
  You can explicitly specify the migrate action to override the default behavior,
  or use the <<ilm-allocate, allocate action>> to manually specify allocation rules.
  