Elementary currently has limited support for multi‑project setups, and that’s almost certainly what you’re running into. From the shared threads: - Elementary does not fully support multiple dbt projects sharing one Elementary schema today; metadata models (like

dbt_models

,

dbt_tests

) are effectively tied to the last project that was run, and some joins (e.g.

elementary_test_results

↔️

dbt_tests

) can cause tests from “other” projects not to appear in the report, even if they exist in the warehouse tables. [[Multi‑project Slack](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684951436410779); [Multi‑project FAQ](https://elementary-community.slack.com/archives/C02CTC89LAX/p1706020470517099)] - There are also known edge cases where tests defined in one project/package but applied to models in another don’t reliably show up in the report, even though

dbt test

runs them successfully. In practice, users have had to keep the model SQL and its tests in the same project/package (or create “QA” models in that project and test those) to make them appear consistently. [[Cross‑project tests](https://elementary-community.slack.com/archives/C08HW57FGN9/p1763849802554389); [Common models package](https://elementary-community.slack.com/archives/C02CTC89LAX/p1717077482316179)] Given that, the options that are actually supported today are: 1. One Elementary schema per project - Configure a different Elementary schema for each dbt project (e.g.

project1_elementary

,

project2_elementary

) and generate separate reports. [[Multi‑project Slack](https://elementary-community.slack.com/archives/C02CTC89LAX/p1674241350877809)] - Use a single

elementary

profile with multiple targets and switch with

--profile-target

when running

edr

. [[Profile targets](https://elementary-community.slack.com/archives/C02CTC89LAX/p1674241350877809)] 2. Co‑locate models and tests in the same project - For models in your “access layer” project, define their tests in that same project (or create simple “wrapper/QA” models there that

select * from ref('your_model')

and attach tests to those). This has been used as a workaround when tests defined in a different project/package weren’t showing in the report. [[Cross‑project tests](https://elementary-community.slack.com/archives/C08HW57FGN9/p1763849802554389); [Common models package](https://elementary-community.slack.com/archives/C02CTC89LAX/p1717077482316179)] 3. Ensure Elementary metadata is up to date for the project that owns the tests - After adding/changing models or tests, run

dbt run -s elementary

(or

dbt build

including

elementary

) in the project that owns those tests before generating the report, so the metadata tables are refreshed. [[Common models package](https://elementary-community.slack.com/archives/C02CTC89LAX/p1717077482316179)] There is an open feature request to properly support consolidating results across multiple dbt projects into a single report, but it’s not available yet. [[Multi‑project issue](https://github.com/elementary-data/elementary/issues/1324)] If you can share how your two projects are structured (where the access‑layer models live vs. where their tests are defined, and whether they share the same Elementary schema), I can map that directly to one of the supported patterns above.