Add conceptual overview of model snapshots (#755)

Author: lcawl

docs/en/stack/ml/anomaly-detection/ml-concepts.asciidoc

@@ -10,6 +10,7 @@ This section explains the fundamental concepts of the Elastic {ml}
 * <<ml-buckets>>
 * <<ml-calendars>>
 * <<ml-rules>>
+* <<ml-model-snapshots>>
 * <<ml-nodes>>
 
 include::jobs.asciidoc[]
@@ -22,4 +23,6 @@ include::calendars.asciidoc[]
 
 include::rules.asciidoc[]
 
-include::architecture.asciidoc[]
+include::architecture.asciidoc[]
+
+include::model-snapshots.asciidoc[]

docs/en/stack/ml/anomaly-detection/model-snapshots.asciidoc

@@ -0,0 +1,28 @@
+[role="xpack"]
+[[ml-model-snapshots]]
+=== Model snapshots
+
+As described in <<ml-analyzing>>, {stack} {ml-features} can calculate baselines
+of normal behavior then extrapolate anomalous events. These baselines are
+accomplished by generating models of your data. 
+
+To ensure resilience in the event of a system failure, snapshots of the {ml}
+model for each {anomaly-job} are saved to an internal index within the {es}
+cluster. By default, snapshots are captured approximately every 3 to 4 hours and 
+retained for one day (twenty-four hours). The amount of time necessary to
+save these snapshots is proportional to the size of the model in memory.
+
+You can use the {ref}/ml-update-job.html[update {anomaly-jobs} API] to change
+the interval (`background_persist_interval`) and retention
+(`model_snapshot_retention_days`) of these snapshots.
+
+There are also situations where you might want to
+{ref}/ml-revert-snapshot.html[revert] to using a specific model snapshot. The
+{ml-features} react quickly to anomalous input and new behaviors in data. Highly 
+anomalous input increases the variance in the models and {ml} analytics must 
+determine whether it is a new step-change in behavior or a one-off event. In the
+case where you know this anomalous input is a one-off, it might be appropriate
+to reset the model state to a time before this event. For example, you might
+consider reverting to a saved snapshot after Black Friday or a critical system 
+failure. If you know about such events in advance, you can use
+<<ml-calendars,calendars and scheduled events>> to avoid impacting your model.