Skip to main content
Kata is SQLBuild’s opt-in SQL architecture policy. It compiles the project, then checks model structure, naming, dependency boundaries, joins, contracts, and test coverage. Built-in checks run offline: they do not execute warehouse SQL or rewrite source files. Findings have stable codes and concrete remediations. Kata is error-only: every retained finding blocks the command. Use it for conventions that a team has deliberately adopted, not as a collection of advisory style warnings. Tests codify behavioral expectations; Kata codifies architectural expectations for SQL models. For equivalent boundaries, repository structure, and code-shape checks in Python projects, see Fensu.

Where Kata fits

Kata is a separate command. It is not run automatically by compile or build.

Enable Kata

Commit the shared policy to sqlbuild_project.toml:
This activates the complete standard policy. Start here, then use ignore to switch off conventions the repository is not ready to enforce.
Kata evaluates no rules when [kata].select is empty. Prefixes select matching rules that are enabled by default; exact codes also select individually opt-in rules. All current built-ins are enabled by default, so SQBK selects the complete built-in catalogue.
Rule selectors are case-sensitive prefixes. They do not use * wildcards:
  • Built-in rules use SQBK<family><three digits>, such as SQBKS101.
  • Custom rules use XSQBK<family><three digits>, such as XSQBKP001.
  • select activates rules; ignore removes matching rules from the active policy.
  • An exact code activates that rule even when it is opt-in.
  • The CLI --select and --exclude flags scope models, not rules.
Inspect any built-in or configured custom rule without enabling it:

Built-in rules

All current built-ins form the standard policy and are enabled by matching prefixes.

Structure

Layers and model grammar

Joins

Column naming and types

These checks use declared contract columns, not inferred output columns.

Decision hygiene

SQBKH001 requires direct comparisons to @enum("<enum>").<MEMBER>. Normalize controlled values upstream rather than wrapping either comparison operand. A direct source-side value may be normalized in the comparison because the project does not control source casing; the enum member must still remain unwrapped.

Tests and coverage

Selecting a custom rule automatically adds SQBKX201 unless the policy ignores it. This is a static check for conventional RuleCase and evaluate_rule usage; it does not execute the tests. Thresholds default to one and can be set to zero to disable the corresponding minimum:

Naming policy

Naming and layer rules can use a closed project vocabulary:
Valid Kata layers are stg, stg_v, int_clean, int_v, int_enriched, mart, and mart_v. Configuration supplies vocabulary to active rules; it does not activate them. When SQBKR001 or SQBKH201 is active, a non-empty domains list constrains model or declaration domains respectively.

Exceptions and scoped ignores

Choose the narrowest mechanism that represents the policy:
An exact exception fails when its active rule no longer produces a fault at that file, prompting the repository to remove obsolete exceptions. Broad migration boundaries and lone-star allowances remain reasoned but are intentionally not stale-checked.

Cache and CI

Built-in policies use a persistent cache under target/kata-cache. Compiled model content, active rules, options, thresholds, naming vocabulary, and relevant project files participate in cache identity. Disable it when diagnosing cache behavior:
Run Kata directly in CI. It exits 1 when faults remain:
Generate agent guidance from the same resolved policy and verify that committed guidance remains fresh:
Kata manages .agents/skills/sqlbuild-kata/SKILL.md, .claude/skills/sqlbuild-kata/SKILL.md, and .opencode/skills/sqlbuild-kata/SKILL.md. It refuses to overwrite divergent or unowned files. See Custom Kata Rules to encode repository-specific policy and the Kata CLI reference for command output and exit behavior.