dbt models that never say what one row is

This rule flags each core model whose grain is declared nowhere. A model counts as core when a dbt exposure, Looker explore or Tableau view depends on it. If none is declared, the marts count instead. Any one of these counts as declared: a uniqueness test, even a filtered one; an incremental unique_key; a primary_key or unique constraint; or a primary or unique semantic entity.

A count or a join assumes one row per key. If the table holds one row per key per day, an agent's totals are multiplied, and no query fails to warn anyone.

Declare what one row of each main table is. Declare the grain. Add a unique test on the key, or unique_combination_of_columns for a compound key. Under a contract, a primary_key constraint states it too.

Before:

  - name: dim_customers
    columns:
      - name: customer_id

After:

  - name: dim_customers
    description: One row per customer.
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

An event log whose rows are genuinely not unique on any key can go without, if its description says so. Where the testing rules already ask for a uniqueness test, one test fixes both, and the review lists the work once.

manifest.json. Consumers come from exposures in the manifest, or from LookML or Tableau files if you share them.

dbt_project_evaluator, rule fct_missing_primary_key_tests. Ours checks a subset of what it flags; theirs is stricter. dbt Labs' rule asks every model for a primary-key test. This one asks only the models behind a consumer (or the marts), and also accepts a unique_key, a key constraint or a primary semantic entity, so theirs flags strictly more.

This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.