Thanks for the added context. Based on our knowledge sources, Elementary’s schema mislabeling (showing dbt_test__audit instead of the tested table’s schema) occurs when dbt’s generate_schema_name is overridden, because tests use a built‑in custom schema name dbt_test__audit. Elementary addressed this with a fix so schema_name reflects the tested object even when the macro is overridden. [[dbt_test__audit issue](
https://slack.com/archives/C02CTC89LAX/p1673321077310119)] However, the sources don’t mention or confirm behavior with split projects (tests defined in a base project and models in a dependent project). I’m sorry, but there’s no information about this multi‑project properties/models split scenario and how it might affect schema resolution in Elementary. [[dbt_test__audit issue](
https://slack.com/archives/C02CTC89LAX/p1673321077310119)] Given known limitations, Elementary does not support multiple dbt projects writing into the same Elementary schema, and cross‑project metadata can be incomplete or overwritten, which may relate to your setup. The recommended approach is a separate Elementary schema per project. [[Multi‑project not supported](
https://slack.com/archives/C02CTC89LAX/p1691513076109829); [Per‑project schema](
https://slack.com/archives/C02CTC89LAX/p1698049255491119)] If you can, try: - Ensuring your generate_schema_name excludes Elementary from custom logic so Elementary models/tests land in the intended schema. [[Exclude Elementary](
https://slack.com/archives/C02CTC89LAX/p1712851926036669)] - Running dbt run -s elementary in each project separately, pointing to distinct Elementary schemas, and checking whether schema_name is correct in dbt_tests in each schema. [[Per‑project run](
https://slack.com/archives/C02CTC89LAX/p1691513076109829)] If you share a snippet of your generate_schema_name and how the two projects’ profiles/schemas are set, we can suggest an exact macro tweak.