Each rule is a native dbt check that returns one row per violation. Run it with dbt check <rule_name>, for example dbt check fct_undocumented_models.

Documentation#

Documentation Coverage#

fct_documentation_coverage

-- project-wide: fails when the share of documented models is below `documentation_coverage_target`
select count(*) as total_models,
       count(*) filter (where is_documented) as documented_models,
       round(documented_models * 100.0 / nullif(total_models, 0), 2) as documentation_coverage_pct,
       {{ evaluator_pct_by_model_type('is_documented', 'documentation_coverage_pct') }}
from {{ evaluator_models() }}
having documentation_coverage_pct < {{ var('documentation_coverage_target') }}

fct_documentation_coverage (source) calculates the percent of enabled models in the project that have a configured description.

This check returns a single row, and so warns on dbt check and dbt build (by default), only when documentation_coverage_pct is below documentation_coverage_target (default 100%). It always looks at the whole project, even when you use --select. You can set your own threshold by overriding the documentation_coverage_target variable. See overriding variables section.

Reason to Flag

Good documentation for your dbt models will help downstream consumers discover and understand the datasets which you curate for them. The documentation for your project includes model code, a DAG of your project, any tests you've added to a column, and more.

How to Remediate

Apply a text description in the model's .yml entry, or create a docs block in a markdown file, and use the {{ doc() }} function in the model's .yml entry.

Tip

We recommend that every model in your dbt project has at minimum a model-level description. This ensures that each model's purpose is clear to other developers and stakeholders when viewing the dbt docs site.

Undocumented Models#

fct_undocumented_models (source) lists every model with no description configured.

Reason to Flag

Good documentation for your dbt models will help downstream consumers discover and understand the datasets which you curate for them. The documentation for your project includes model code, a DAG of your project, any tests you've added to a column, and more.

How to Remediate

Apply a text description in the model's .yml entry, or create a docs block in a markdown file, and use the {{ doc() }} function in the model's .yml entry.

Tip

We recommend that every model in your dbt project has at minimum a model-level description. This ensures that each model's purpose is clear to other developers and stakeholders when viewing the dbt docs site. Missing documentation should be addressed first for marts models, then for the rest of your project, to ensure that stakeholders in the organization can understand the data which is surfaced to them.

Undocumented Source Tables#

fct_undocumented_source_tables (source) lists every source table with no description configured.

Reason to Flag

Good documentation for your dbt sources will help contributors to your project understand how and when data is loaded into your warehouse.

How to Remediate

Apply a text description in the table's .yml entry, or create a docs block in a markdown file, and use the {{ doc() }} function in the table's .yml entry.

sources:
  - name: my_source
    tables:
      - name: my_table
        description: This is the source table description

Undocumented Sources#

fct_undocumented_sources (source) lists every source with no description configured.

Reason to Flag

Good documentation for your dbt sources will help contributors to your project understand how and when data is loaded into your warehouse.

How to Remediate

Apply a text description in the source's .yml entry, or create a docs block in a markdown file, and use the {{ doc() }} function in the source's .yml entry.

sources:
  - name: my_source
    description: This is the source description
    tables:
      - name: my_table