Rules
Here you can find an overview of all possible rules. Use the filter below to find the rules you need, or search using Ctrl or Cmd + K.
What are Rule Categories?
Each rule has a default category that classifies what aspect of your dbt project it checks. Categories are included in structured output formats (JSON, CSV, NDJSON) but are not shown in the CLI table.
The default categories are: Documentation Naming Testing Governance Structure Performance
You can override the default category for any rule by setting category: "your_custom_category" in your rule configuration.
Manifest Rules
| Rule Name | Category | Description | Keywords |
|---|---|---|---|
| has_description | Documentation | Ensure dbt objects have a populated description. | description, documentation, yaml, schema |
| name_convention | Naming | Check if object names follow casing (e.g.snake_case) or custom regex patterns. | naming, pattern, regex, conventions, prefixes |
| has_tags | Governance | Check if objects have one/any/all of the required tags. | tags, metadata, categorization, organization |
| is_not_orphaned | Structure | Check if objects are referenced by other objects. | orphaned, unused, references, dependencies, lineage |
| has_required_tests | Testing | Enforce a configurable set of mandatory tests on dbt objects. | tests, required, mandatory, not_null, unique, validation |
| has_unique_test | Testing | Check if dbt objects have at least one uniqueness test attached. | tests, uniqueness, unique, validation, custom |
| has_metadata_keys | Governance | Check if dbt objects has the provided keys in the metadata | tests, uniqueness, unique, validation, custom |
| has_refs | Governance | Check if dbt objects have at least one upstream reference using ref() or source(). | references, upstream, dependencies, ref, source |
| code_contains_refs | Governance | Check if SQL code contains ref() or source() function calls. | code, ref, source, references, hardcoded, sql |
| code_max_lines | Performance | Enforce a maximum line count for code. | code, lines, length, size, complexity |
| code_forbidden_patterns | Performance | Check if code contains forbidden patterns, such direct selects SELECT * | forbidden, code, patterns, jinja, macros |
| code_max_joins | Performance | Enforce a maximum number of JOINs in SQL code. | joins, code, complexity, sql, limit |
| code_no_hardcoded_refs | Performance | Detect hardcoded table references (schema.table) in SQL code. Use ref() or source() instead. | hardcoded, references, schema, table, lineage |
| allowed_subfolders | Naming | Enforce that objects are organized within specific allowed subfolders. | folder, structure, organization, path, subfolders |
| sources_have_loader | Documentation | Ensures sources document which tool loads data into the warehouse. | loader, source, etl, pipeline, ingestion |
| sources_have_freshness | Governance | Ensures sources define acceptable data staleness thresholds. | freshness, source, staleness, monitoring, data quality |
| max_upstream_dependencies | Structure | Limit fan-in. How many other models a model can select from via ref() and source(). | upstream, fan-in, ref, source, lineage |
| max_downstream_dependencies | Structure | Limit fan-out. How many other models can ref() a single model. | downstream, fan-out, bottleneck, blast radius, lineage |
| property_file_colocation | Structure | Ensure property (YAML) files are colocated with their primary file (SQL, CSV). | property, yaml, colocation, directory, structure |
| max_materialization_lineage | Structure | Limit consecutive non-persisted materializations (view/ephemeral) in model lineage. | materialization, lineage, chain, view, ephemeral |
| exposure_parents_materialized | Structure | Require exposure parents to use persisted materializations (table, incremental, materialized_view). | exposure, parents, materialized, persisted, table |
Catalog Rules
Why differentiate between manifest and catalog?
These rules use both the manifest.json and catalog.json artifacts. These files can become out of sync during development (for example, when running dbtective in pre-commit hooks), especially if files are moved or renamed and only one of the commands generating manifest.json is run. For more information, see the dbt documentation on manifest.json.
To ensure your catalog is up to date, delete it from the dbt target folder and regenerate it using dbt docs generate. Future updates to dbtective will include an option to automate this process with a specific flag.
What is Fallback?
When running with --only-manifest, some catalog rules can still run using only manifest data. These rules are marked with the Fallback badge. Rules without this badge require data from catalog.json and are skipped.
See Only Manifest Mode for full details.
| Rule Name | Category | Description | Keywords |
|---|---|---|---|
| columns_all_documented | Documentation Catalog | Check if all SQL columns are documented in e.g. their yml file. Validates that database columns match documentation. | columns, catalog, database, schema, undocumented |
| columns_have_description | Documentation Catalog Fallback | Check if all documented columns have descriptions. | columns, descriptions, documentation, catalog, database |
| columns_name_convention | Naming Catalog Fallback | Check if column names follow casing (e.g.snake_case) or custom regex patterns. | columns, naming, pattern, regex, conventions |
| columns_canonical_name | Naming Catalog Fallback | Enforce canonical column naming by flagging invalid name patterns. | columns, canonical, naming, standards, consistency |
| columns_have_data_type | Documentation Catalog Fallback | Check if columns have data types defined. Supports coverage threshold (all or percentage). | columns, data types, coverage, catalog, database |