@kapa.ai Elementary's column anomaly tests partition data by event time and evaluate only a recent detection window. This works for incremental models, where new data lands in recents partitions, but it cannot catch bad data written to historical partitions that fall outside the test window - which is exactly what happens when a non-incremental model is fully rebuilt and a corrupted value lands on a record dated weeks ago. What is the recommended pattern for detecting and handling this type of anomaly on non-incremental models

The knowledge sources do not explicitly mention a dedicated recommended pattern for detecting anomalies in historical partitions of fully-rebuilt (non-incremental) models. However, based on what the knowledge sources do say, I can piece together the most relevant guidance: How Elementary Handles Non-Incremental Models For regular tables and views (i.e., non-incremental models), Elementary recalculates the full

training_period

on every test run. [training_period docs] This is actually an advantage over incremental models in your scenario: because the entire training window is re-queried each run, a corrupted value written to a historical partition within the training window will be reflected in the metrics on the next test run. The key constraint is the

training_period

window itself — data older than that window is simply not evaluated. Recommended Patterns 1. Extend the training_period to Cover Historical Partitions If your model is fully rebuilt and corrupted data could land on records dated weeks ago, extend the

training_period

to cover the relevant historical range:

models:
  - name: your_model
    tests:
      - elementary.column_anomalies:
          timestamp_column: event_date
          training_period:
            period: day
            count: 90  # extend to cover the historical range you care about
          detection_period:
            period: day
            count: 2

Since non-incremental models recalculate the full

training_period

on every run, a corrupted historical value within this window will shift the metrics (e.g., min, max, average, standard deviation) and may be flagged as an anomaly. [training_period docs] 2. Use exclude_detection_period_from_training To improve detection accuracy (so that anomalous values in the detection window don't dilute the training baseline), set:

exclude_detection_period_from_training: true

This prevents the detection period values from influencing the expected range. [detection_period docs] 3. Force a Metrics Backfill After a Full Rebuild After a full model rebuild, force Elementary to recalculate all cached metrics so the dashboard reflects the updated data:

dbt test --vars '{"force_metrics_backfill": true}'
dbt run --select elementary

This ensures that any changes to historical partitions are picked up and not served from a stale cache. [force_metrics_backfill] Important Limitation to Be Aware Of Elementary's anomaly detection is statistical — it compares recent buckets against a learned baseline. If a corrupted historical value shifts the aggregate metric for its time bucket (e.g., lowers the average for that day), it will be detected as an anomaly in that bucket. However, if the corruption is subtle enough not to move the aggregate significantly, it may not be flagged. For catching specific bad values at the row level, a threshold-based dbt test (e.g.,

not_null

,

accepted_values

, or a custom test) would be more reliable as a complement to anomaly detection. In summary: for non-incremental models, extending

training_period

, enabling

exclude_detection_period_from_training

, and running

force_metrics_backfill

after rebuilds are the most applicable patterns from the knowledge sources. A fully dedicated "historical partition anomaly detection" pattern is not explicitly documented. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.