By default, in Elementary's volume anomaly tests, the current test (i.e., the detection period) is included in the training set when calculating the expected range for anomalies. This means that the data point you are trying to evaluate for anomalies is also influencing the calculation of what is considered "normal." This can make the test less sensitive, especially if you have a small training set, because an anomalous value in the detection period will dilute the calculated average and standard deviation, making it less likely to be flagged as an anomaly. This behavior is intentional in the current implementation, but it has been recognized as potentially problematic. There is an open discussion in the community about whether this should be the default, as excluding the detection period from the training set would make the anomaly detection more sensitive and conceptually correct (i.e., only past data should inform the expected range) [Exclude detection period from training period?](https://github.com/elementary-data/elementary/issues/1491). How to change this behavior: While there is not yet a built-in configuration option to exclude the detection period from the training set, you can achieve this by using the

anomaly_exclude_metrics

parameter. For example, you can exclude the latest data point (i.e., the current detection period) from the training set with a configuration like:

yaml anomaly_exclude_metrics: "MAX(bucket_end) OVER (     partition by metric_name, full_table_name, column_name, dimension, dimension_value, bucket_seasonality     order by bucket_end asc     rows between unbounded preceding and unbounded following ) = bucket_end"

This workaround ensures that the most recent data point is not used in the training set, making the anomaly detection more accurate for your use case [Exclude detection period from training period?](https://github.com/elementary-data/elementary/issues/1491). In summary, the current test is included in the training set by default, but you can exclude it using the

anomaly_exclude_metrics

parameter as shown above. This approach is recommended if you want to ensure that only historical data is used to calculate the expected range for anomaly detection.

Certainly! Here’s a breakdown of your questions: --- ### 1. What does this config do?

yaml anomaly_exclude_metrics: "MAX(bucket_end) OVER (     partition by metric_name, full_table_name, column_name, dimension, dimension_value, bucket_seasonality     order by bucket_end asc     rows between unbounded preceding and unbounded following ) = bucket_end"

This SQL window expression is used in the

anomaly_exclude_metrics

parameter to exclude the most recent data point (i.e., the detection period) from the training set when calculating anomaly thresholds. -

bucket_end

represents the end timestamp of each time bucket. - The

MAX(bucket_end) OVER (...)

computes the latest bucket_end for each partition. - The condition

= bucket_end

is only true for the most recent bucket, so this data point is excluded from the training set used to calculate expected values. This is a workaround for the current Elementary behavior where the detection period is included in the training set by default. By using this, you ensure that the current period being tested is not influencing the expected range calculation, making anomaly detection more accurate for the latest data point [Exclude detection period from training period?](https://github.com/elementary-data/elementary/issues/1491). --- ### 2. How to add this to your config You can simply add the

anomaly_exclude_metrics

parameter to your existing test configuration like this:

yaml - elementary.volume_anomalies: # volume anomalies elementary test     tags: ["elementary"]     anomaly_sensitivity: 2     anomaly_direction: both     min_training_set_size: 3     backfill_days: 1     fail_on_zero: true     severity: warn     anomaly_exclude_metrics: "MAX(bucket_end) OVER (         partition by metric_name, full_table_name, column_name, dimension, dimension_value, bucket_seasonality         order by bucket_end asc         rows between unbounded preceding and unbounded following     ) = bucket_end"

Just add the

anomaly_exclude_metrics

line at the same indentation level as your other parameters. --- ### 3. Which model/table does the SQL where expression run over? The SQL expression in

anomaly_exclude_metrics

is evaluated over the metrics table that Elementary generates internally during anomaly detection. The available fields for filtering are: -

metric_date

-

metric_time_bucket

-

metric_value

- (and, as in your example,

bucket_end

and other partitioning fields) You can use these fields in your SQL expression to control which data points are excluded from the training set for anomaly calculation. This is documented in the [Elementary documentation for anomaly_exclude_metrics](https://docs.elementary-data.com/data-tests/anomaly-detection-configuration/anomaly-exclude-metrics). --- If you need to target a different data point or set of points, you can adjust the SQL expression accordingly, using the available fields. --- Summary: - The config you posted excludes the most recent bucket from training. - Add it as

anomaly_exclude_metrics

in your test config. - The SQL runs over the metrics table Elementary uses for anomaly detection, with fields like

metric_date

,

metric_time_bucket

, and

metric_value

available for filtering. Let me know if you need an example for a different scenario!

The error you encountered,

[UNSUPPORTED_FEATURE.LATERAL_COLUMN_ALIAS_IN_WINDOW] The feature is not supported: Referencing a lateral column alias `bucket_seasonality` in window expression ...

indicates that your data warehouse does not support referencing the

bucket_seasonality

column alias within a window function in the way the expression is written. This issue has been discussed in the Elementary community and GitHub issues. The workaround using

anomaly_exclude_metrics

with a window function that references

bucket_seasonality

is not guaranteed to work in all SQL dialects, as some warehouses (like Snowflake and others) do not allow referencing lateral column aliases inside window functions. This is a known limitation and has been acknowledged by the Elementary team and community members. There is currently no officially supported, cross-dialect solution for excluding the detection period from the training set using this method, and no alternative workaround is documented in the knowledge sources at this time. The Elementary team is aware of this limitation and is open to contributions or further research on a more robust solution [Exclude detection period from training period?](https://github.com/elementary-data/elementary/issues/1491), [Slack thread](https://slack.com/archives/C02CTC89LAX/p1740069258974599). Summary: - The error is due to SQL dialect limitations with window functions and lateral column aliases. - There is no officially documented workaround for this in the current version of Elementary. - The Elementary team is aware of the issue, but a robust, cross-dialect solution is not yet available. If you need to exclude the detection period from the training set, you may need to wait for an official feature or try to adapt the SQL expression to your warehouse's capabilities, but the knowledge sources do not provide a ready-to-use alternative.