Yes, when an Elementary volume anomaly test fails, the failed data point (the anomaly) is included in the training set for future runs. This means that if, for example, your row count spikes from 100 to 2000 and the test fails, the next time the test runs, the 2000 value will be part of the historical data used to calculate the expected range. As a result, if you get 2000 rows again, the test is less likely to flag it as an anomaly, since it now appears as part of the "normal" pattern in the training set. This behavior is confirmed in multiple sources: - "elementary does use the failed data point for future calculations, tho in a singular case such as yours, it should not affect the calculation that much" [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1695225048785209). - "The anomaly will be counted inside the evaluation, so if you have 1 day of anomaly of 0 rows - the next day it will be counted inside the metric." [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1690997004224019). - This is also discussed as a known limitation in the community and GitHub issues, with workarounds like using the anomaly_exclude_metrics parameter to filter out such points from the training set, but by default, failed points are included [GitHub Issue #1589](https://github.com/elementary-data/elementary/issues/1589). So, unless you specifically configure the test to exclude anomalous points from the training set, failed data points will be included in future training, potentially making repeated anomalies less likely to be flagged.

To exclude failed data points (such as a spike or drop caused by a truncate-and-load event) from the training set in an Elementary volume anomaly test, you can use the

anomaly_exclude_metrics

parameter. This parameter allows you to specify a SQL where expression to filter out certain data points from the training set, so they do not influence future anomaly detection. Example: Suppose you want to exclude any data point where the row count (metric_value) is less than 10 (which might indicate a truncate event), you can configure your test like this:

yaml models:   - name: your_model_name     tests:       - elementary.volume_anomalies:           anomaly_exclude_metrics: metric_value < 10

Alternatively, if you know the exact date or time bucket when the truncate-and-load event happened, you can exclude that specific period:

yaml models:   - name: your_model_name     tests:       - elementary.volume_anomalies:           anomaly_exclude_metrics: metric_date = '2024-06-01'

Or, for a specific time range:

yaml models:   - name: your_model_name     tests:       - elementary.volume_anomalies:           anomaly_exclude_metrics: metric_time_bucket >= '2024-06-01 00:00:00' and metric_time_bucket <= '2024-06-01 23:59:59'

How it works: The

anomaly_exclude_metrics

filter removes the specified data points from the training set, so they do not affect the calculation of expected values in future runs. This is especially useful for truncate-and-load tables, where you want to ignore the periods with zero or very low row counts due to the load process. For more details and examples, see the official documentation: [anomaly_exclude_metrics](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-exclude-metrics) and related discussions [GitHub Issue #1491](https://github.com/elementary-data/elementary/issues/1491) and [Slack discussion](https://slack.com/archives/C02CTC89LAX/p1729524423351429).