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 | Check if a description is populated. Ensures objects have a description in their schema (e.g. YAML) files. | description, documentation, yaml, schema |
| name_convention | Naming | Check if object names follow casing (e.g.snake_case) or custom regex patterns. Enforces naming standards using configurable patterns. | naming, pattern, regex, conventions, prefixes |
| has_tags | Governance | Check if objects have the required tags. Ensure proper categorization for selective execution. | tags, metadata, categorization, organization |
| is_not_orphaned | Structure | Check if objects are referenced by other objects. Identifies orphaned data assets that may be unused or underutilized. | orphaned, unused, references, dependencies, lineage |
| has_unique_test | Testing | Check if dbt objects have at least one uniqueness test attached. Supports standard and custom uniqueness tests. | 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(). Identifies objects that may be using hardcoded SQL instead of leveraging dbt's dependency management. | references, upstream, dependencies, ref, source |
| code_contains_refs | Governance | Check if SQL code contains ref() or source() function calls. Strips comments before checking. Case-insensitive. | code, ref, source, references, hardcoded, sql |
| max_code_lines | Performance | Enforce a maximum line count for code. | code, lines, length, size, complexity |
| has_forbidden_code | Performance | Check if code contains forbidden patterns, such direct selects SELECT * | forbidden, code, patterns, jinja, macros |
| max_joins | Performance | Enforce a maximum number of JOINs in SQL code. Strips comments before counting. Helps reduce code complexity. | joins, code, complexity, sql, limit |
| allowed_subfolders | Naming | Enforce that objects are organized within specific allowed subfolders. Ensures consistent project structure and proper categorization by source or domain. | folder, structure, organization, path, subfolders |
| sources_have_loader | Documentation | Check if sources have a loader defined. Ensures sources document which tool loads data into the warehouse. | loader, source, etl, pipeline, ingestion |
| sources_have_freshness | Governance | Check if sources have freshness configured. 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 |
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 non-empty descriptions. Ensures column-level documentation is complete | 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. Enforces naming standards using configurable patterns. | columns, naming, pattern, regex, conventions |
| columns_canonical_name | Naming Catalog Fallback | Enforce canonical column naming by flagging invalid name patterns. Supports exceptions for allowed variations. | 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 |