Skip to main content

Documentation index: llms.txt. This page is also available as markdown: append .md to this URL or send Accept: text/markdown.

Review Checklist for Agent Work

Use this checklist on every change your agent makes. Each item names what to check and where to look. Most take a few seconds.

Naming​

  • Node names follow your convention. Prefixes such as STG_, DIM_, and FCT_ match the layer.
  • Each Node is in the right Storage Location. The file name starts with the Storage Location, such as TARGET in nodes/TARGET-STG_ORDERS.sql.
  • Column names are clear and consistent. One case, one style for keys such as customer_key, and no leftover source names like O_ORDERKEY.
  • No accidental renames. A renamed Node or column breaks anything downstream that refers to the old name.

Where to look: the file list in See What Changed, and the column list on the Mapping tab.

Grain​

  • You can say what one row means. For example, one row per order, or one row per customer version.
  • Joins don't fan out. A join to a table with more than one match per key multiplies rows and inflates every sum.
  • Filters are intended. Every WHERE clause should be one you asked for or can explain.
  • The row count makes sense. Compare it with the source and with the agent's report.

Where to look: the FROM, JOIN, and WHERE clauses in the diff, and the row count after a run. See Check the SQL That Will Run.

Keys​

  • The business key is the right column. On a dimension or fact, it carries @isBusinessKey.
  • The business key is unique at the Node's grain. Check for duplicates in Preview, or ask the agent to query for them.
  • Type 2 dimensions track the right columns. Only the columns whose history you want carry @isChangeTracking.
  • Facts join to the dimension's surrogate key, and only to current rows when that's what you asked for.
  • Key columns don't allow nulls. Reserved @notNull sets the column NOT NULL in the DDL.

Where to look: annotations in the SQL, and the Annotations panel for the exact names the Node Type supports. See the SQL Annotations Reference.

Check Annotation Values, Not Just Names

When a Node uses an annotation name its Node Type doesn't declare, such as @isBusinesKey, Coalesce shows a warning and suggests the closest name. The warning doesn't block a deploy, and the misspelled annotation has no effect. Treat every annotation warning in the Problems panel or coa validate as a defect. Coalesce doesn't check the values you pass, so compare those with the Annotations panel too.

Tests​

  • Keys have tests. At least a not-null test, and a unique test on the business key where the Node Type offers one.
  • Tests ran and passed in your development schema.
  • Tests check data, not just DDL. Reserved @notNull is a constraint. A Node Type test such as @not_null checks the loaded rows. Use both where they apply.

Where to look: the test annotations in the SQL, and the run output in the Code tab. See Testing Nodes and Testing Columns.

Cost​

  • Materialization fits the use. @materializationType("view") costs nothing to load but runs its query every time someone reads it. A table costs a load but is cheap to read.
  • Large Nodes load incrementally when the Node Type supports it, rather than rebuilding the whole table on every run.
  • No unbounded scans. Look for a missing filter, a SELECT * from a large source, or a cross join.
  • The agent read the rendered SQL before it ran. On a large source, coa run --dry-run --verbose shows the DML without touching the warehouse. That costs far less than a run that has to be redone.

Where to look: the rendered DDL and DML from Validate Create and Validate Run. See Check the SQL That Will Run.

Before You Ship​

What's Next?​