anchor.diff:  
   Other safeguards are tracked in the meta-issue {GIT}11511[#11511].
   
  -[float]
  -=== Loss of documents during network partition (STATUS: ONGOING)
  +
  +[float]
  +=== Relocating shards omitted by reporting infrastructure (STATUS: ONGOING)
  +
  +Indices stats and indices segments requests reach out to all nodes that have shards of that index. Shards that have relocated from a node
  +while the stats request arrives will make that part of the request fail and are just ignored in the overall stats result. {GIT}13719[#13719]
  +
  +[float]
  +=== Jepsen Test Failures (STATUS: ONGOING)
  +
  +We have increased our test coverage to include scenarios tested by Jepsen. We make heavy use of randomization to expand on the scenarios that can be tested and to introduce new error conditions. You can follow the work on the master branch of the https://github.com/elastic/elasticsearch/blob/master/core/src/test/java/org/elasticsearch/discovery/DiscoveryWithServiceDisruptionsIT.java[`DiscoveryWithServiceDisruptionsIT` class], where we will add more tests as time progresses.
  +
  +[float]
  +=== Document guarantees and handling of failure (STATUS: ONGOING)
  +
  +This status page is a start, but we can do a better job of explicitly documenting the processes at work in Elasticsearch, and what happens in the case of each type of failure. The plan is to have a test case that validates each behavior under simulated conditions. Every test will document the expected results, the associated test code and an explicit PASS or FAIL status for each simulated case.
  +
  +== Unreleased
  +
  +[float]
  +=== Loss of documents during network partition (STATUS: UNRELEASED, v5.0.0)
   
   If a network partition separates a node from the master, there is some window of time before the node detects it. The length of the window is dependent on the type of the partition. This window is extremely small if a socket is broken. More adversarial partitions, for example, silently dropping requests without breaking the socket can take longer (up to 3x30s using current defaults).
   
  
positive.code: To prevent this situation, the primary needs to wait for the master to acknowledge replica shard failures before acknowledging the write to the client. {GIT}14252[#14252]
  
  [float]
  === Safe primary relocations (STATUS: ONGOING)
  
  When primary relocation completes, a cluster state is propagated that deactivates the old primary and marks the new primary as active. As
  cluster state changes are not applied synchronously on all nodes, there can be a time interval where the relocation target has processed the
  
negative.code: chasing the primary being quickly sent back and forth between the nodes, potentially making them both go OOM. {GIT}12573[#12573]
  
  [float]
  === Do not allow stale shards to automatically be promoted to primary (STATUS: UNRELEASED, v5.0.0)
  
  In some scenarios, after the loss of all valid copies, a stale replica shard can be automatically assigned as a primary, preferring old data
  to no data at all ({GIT}14671[#14671]). This can lead to a loss of acknowledged writes if the valid copies are not lost but are rather
  