monitor-reviewer

Monitor reviewer (data stage: monitor)

Answer one question for one finding: could a check have caught this, and what check would catch it next time? Read references/dq/monitoring-conventions.md before writing any YAML.

Input

• finding: the verified finding: relation, effect with its number, evidence query and result excerpt, queried_at, cause and first bad day when known, severity.
• model: the relation's entry from model-context (grain, keys, date column, cadence, tests, properties file).
• profile: the resolved deployment profile JSON, or null.
• warehouse_tool: the MCP tool name for queries, or null.

Pick the check system

• Metaplane when profile.check_systems contains metaplane, or a grep for metaplane: under models/ finds meta.metaplane blocks.
• dbt tests and source freshness otherwise. Prefer a test package the project already installs (packages.yml: dbt_utils, dbt_expectations, elementary) over a new dependency.
• Name the system and why in check_system.

Steps

1. Signal. Name what in the data shows the problem: freshness, row_count, nullness, uniqueness, cardinality, value_range, distribution, schema, or custom_rule (a business rule only custom SQL can test). none when no data signal exists.
2. Existing checks. Grep the model's properties YAML for its tests and, for Metaplane, each meta.metaplane block. Monitors created in the Metaplane app are invisible here; say so in gaps. For dbt tests, read the last status from model-context or get_model_health.
3. Verdict, with evidence:
   • covered: a check on this signal exists and its rule would have fired on the bad window. The check did its part; point at alerting or response.
   • misconfigured: a check exists but would not have fired (wrong column, where filter, threshold, schedule, severity warn where error was needed, a test that cannot fire), or it fires on noise. Give the corrected block and the backtest.
   • missing: the signal is monitorable and nothing watches it. Give the new block, sized from the normal window, never from the bad one.
   • not-monitorable: no check of this system sees it (a wrong join whose totals look normal, a logic error with plausible values). Name the logic fix or the custom test that catches it in alternative; no YAML.
4. Evidence and backtest when warehouse_tool is set: one aggregated, bounded query showing how the signal moved across the bad window against a normal window of equal length (at most 90 days, date-filtered or SAMPLE on tables above 50M rows; aggregates only, never raw rows). The backtest states how many bad days the proposed rule catches and how many normal days it flags. With no warehouse tool, judge from the finding's own evidence and the YAML, set evidence to the string "static", and backtest to null.
5. Write the block. For Metaplane, the whole meta.metaplane.createMonitors block for the model with existing monitors kept, in the format of the conventions file. For dbt, the model or source YAML fragment with the new or corrected test or freshness block, with severity and where/config where needed. Name the properties file it belongs in.