No, the table alerts_v2 is not supposed to be dropped and recreated at each run. It is designed as an incremental model, meaning it should be updated with new data rather than being fully dropped and rebuilt every time. If you observe that alerts_v2 (or similar Elementary tables) are being dropped and recreated on each run, this is not the intended behavior and could be due to a misconfiguration, such as running dbt with the --full-refresh flag or having materialization settings overridden in your dbt_project.yml file. This behavior is similar to other Elementary tables like dbt_invocations and dbt_run_results, which are also incremental and should not lose historical data unless a full-refresh is triggered or materialization is overridden. If you want to preserve historical data, avoid running dbt with --full-refresh on Elementary models, or exclude Elementary when running full-refresh commands (e.g., dbt run --exclude elementary --full-refresh) [Elementary tables and incremental behavior](https://slack.com/archives/C02CTC89LAX/p1668519863054579). If the table is being dropped and recreated, it can cause issues such as resending old alerts, since the state of which alerts have already been sent is lost [Alerts tables and state](https://slack.com/archives/C02CTC89LAX/p1707161726122729).