This specific error (

'NoneType' object has no attribute 'lower'

in

elementary-on-run-end-0

) is a generic Python/DBT error that Elementary surfaces when something expected to be a string (or relation) is actually

None

. From the knowledge sources, there isn’t a single universal root cause; it appears in several different situations: - Applying Elementary tests to ephemeral models, which Elementary does not support. [[volume test thread](https://elementary-community.slack.com/archives/C02CTC89LAX/p1681930505961219); [ephemeral note](https://elementary-community.slack.com/archives/C02CTC89LAX/p1682366505474349)] - Misconfiguration or disabling of Elementary models/`edr` folder or schema overrides in

dbt_project.yml

(e.g. custom

+schema

, conditional

+enabled

, or vars in

dbt_project.yml

) that leads to Elementary not finding the relations it expects. [[on‑run‑end disabled models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1733144647908839); [conditional enable config](https://elementary-community.slack.com/archives/C02CTC89LAX/p1697671984193989)] - Version‑specific bugs in certain Elementary releases or adapter versions (e.g. older Elementary versions, dbt‑databricks 1.11.0) that were later fixed by upgrading. [[volume anomalies bug](https://elementary-community.slack.com/archives/C02CTC89LAX/p1681930505961219); [databricks 1.11.0 issue](https://elementary-community.slack.com/archives/C08HW57FGN9/p1763382101528159); [fixed by upgrade](https://elementary-community.slack.com/archives/C02CTC89LAX/p1763387893159629)] Because the error is generic, the exact cause in your project depends on your setup (materializations, adapter, versions, and

dbt_project.yml

config). The knowledge sources do not provide a single definitive root cause for all cases, only these common patterns. To narrow it down, based on the documented cases: 1. Check that you are not running Elementary tests on ephemeral models. 2. Temporarily remove/relax any custom

elementary:

block in

dbt_project.yml

(especially

+schema

,

+enabled

with vars, or disabling

edr

) and re‑run. 3. Ensure you’re on recent versions of Elementary and your dbt adapter (and avoid known‑problem combos like dbt‑databricks 1.11.0 without upgrading to 1.11.1). [[databricks fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1763387893159629)] 4. If it persists, run with

debug_logs: true

and inspect/share

dbt.log

as Elementary support often requests in similar threads. [[debug logs var](https://elementary-community.slack.com/archives/C02CTC89LAX/p1681930505961219)] If you share your

dbt_project.yml

Elementary config, adapter and versions, and whether any failing models are ephemeral, I can map your case more precisely to the patterns above.

No. You do not need to run Elementary models on every dbt execution, but you do need the Elementary on‑run‑end hooks to run on every execution you want monitored. From the docs and Slack threads: - Elementary models (

dbt run --select elementary

): - Needed when you first install Elementary in an environment, to create the tables. [[dbt artifacts](https://docs.elementary-data.com/dbt/dbt-artifacts); [when to run elementary](https://elementary-community.slack.com/archives/C02CTC89LAX/p1685412868454149)] - Needed again when you upgrade to a new minor version of the Elementary package (schema changes). [[when to run elementary](https://elementary-community.slack.com/archives/C02CTC89LAX/p1685412868454149); [upgrade note](https://elementary-community.slack.com/archives/C02CTC89LAX/p1707224316140419)] - Outside of that, they **don’t need to be part of your regular runs**; you can exclude them (e.g.

dbt run --exclude package:elementary

) if they add overhead. [[exclude models](https://elementary-community.slack.com/archives/C02CTC89LAX/p1689861891276609); [micro‑batch example](https://elementary-community.slack.com/archives/C02CTC89LAX/p1747229110843109)] - Elementary on‑run‑end hooks: - These are what populate and update the Elementary tables with run results and metadata on each dbt invocation. [[on‑run‑end hooks](https://docs.elementary-data.com/dbt/on-run-end_hooks); [artifacts upload behavior](https://docs.elementary-data.com/dbt/dbt-artifacts)] - Elementary explicitly recommends not disabling these hooks for environments you want to monitor, because reports and alerts rely on them being up‑to‑date. [[on‑run‑end hooks](https://docs.elementary-data.com/dbt/on-run-end_hooks)] So the recommended pattern is: - Run `dbt run --select elementary`: - Once per environment on install. - On each Elementary minor version upgrade. - Let the hooks run on every dbt run/build/test you care about for observability.

Yes – that

edr:

block is only controlling Elementary models, not the on‑run‑end hooks. From the docs/Slack threads: - The recommended pattern to disable Elementary models via a var is:

yaml   models:     elementary:       +schema: elementary       edr:         +enabled: "{{ var('enable_elementary_models', false) }}"

This controls whether the

edr

subfolder models under

elementary

are built. [[FAQ models disable](https://docs.elementary-data.com/oss/general/faq)] - Support explicitly clarifies the difference: >

disable_dbt_artifacts_autoupload: true

→ prevents the hook from attempting uploads; models can still be run manually. >

edr: {+enabled: false}

→ disables the models entirely; the hook may still run but will skip uploads if tables don’t exist, and you cannot run the models manually. [[edr vs disable vars](https://elementary-community.slack.com/archives/C08HW57FGN9/p1762864662829649)] So in your config:

yaml edr:   +enabled: "{{ var('ARTIFACTS_ENABLED', false) }}"

that

edr

block is indeed for Elementary models only. If your goal is: - Disable models → use this

edr.+enabled

pattern (as you’re doing), or set it to

false

by default and only enable when you explicitly run

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

. [[FAQ models disable](https://docs.elementary-data.com/oss/general/faq)] - Disable hooks / uploads → additionally set the disablement vars, e.g.:

yaml   vars:     disable_run_results: true     disable_tests_results: true     disable_dbt_artifacts_autoupload: true     disable_dbt_invocation_autoupload: true

[[Disable hooks](https://docs.elementary-data.com/dbt/on-run-end_hooks#can-i-disable-the-on-run-end-hooks%3F); [FAQ disable hooks](https://docs.elementary-data.com/oss/general/faq)] If you tell me exactly what you want to keep (e.g. “keep test results but stop metadata models”), I can suggest the minimal combination of

edr.+enabled

and vars.