• we have a few layers of models: denormalized (d_ series -> each line is a transaction) and analytic (a_ series -> each line is an aggregation/summary)
• d_ series tables should be named with the business entity you're modeling

like "d_client_instances" or "d_client_accounts" -> note that those both start with "d_client_" because they form a cohesive series of tables

• a_ series table naming should follow an "a_bbyc" approach:
• a = time dimension (granularity), like "monthly"
• b = primary measure, like "direct_labor"
• c = other dimensions (granularity), like "by_instance"

so you end up with "a_monthly_direct_labor_by_instance"

Nish: I haven't enforced the "a_" prefix yet, but the naming pattern stands. so you see our internal helper models named like this. "daily_direct_labor_by_instance"

there are other layers as well, like t_ transform layers, but we don't have to get too specific at this stage.

New additions to naming conventions and folders.

Given the broad usage of our models, we have organized our warehouse in the inverse manner as recommended here by dbt. That is, folders are first grouped by area of business concern, and then within each area there is a staging, an intermediate, and a core folder. Read this document for details about each of these classifications. In summary, staging models are the building blocks , intermediate models are used in creation of a core model, core models are the main models that we run queries against.