Assess SQL Changes with Data Observability

Monte Carlo Prevent brings Monte Carlo data observability context into the editor while an engineer works on dbt models or SQL pipelines. It surfaces table health, lineage, active alerts and blast radius before edits, and generates monitors-as-code. It is designed to act without being asked: when the user opens a .sql file or a file in models/, or mentions a table, dataset or model name, it runs the matching workflow and presents the result as context the engineer needs before proceeding.

It has five workflows:

1. Table health check: looks up the table, then gets its schema, freshness, row count, importance score and monitoring status, its upstream and downstream lineage and the last 7 days of alerts. It summarizes health, lineage, alerts and risk signals, leading with active alerts. For a brand-new model it parses every ref and source call, checks each upstream table's health and flags upstream tables with alerts, since the new model would inherit the issue. If change intent is present and there is an active alert, a key-asset dependent or an importance score above 0.8, it asks whether to run the full assessment.
2. Add a monitor: when a new column, filter or business rule appears, it picks a monitor type: validation for row-level conditions, metric for aggregates over time, comparison for logic that should match another table or period, and custom SQL for complex rules. It saves the YAML to monitors/<table_name>.yml, previews with montecarlo monitors apply --dry-run and applies with --auto-yes.
3. Alert triage: lists open alerts, checks the affected table, traces lineage for root cause, reviews recent queries, and can acknowledge an alert, assign an owner or add a comment.
4. Change impact assessment: mandatory before any SQL edit. It gathers importance, read volume, key-asset flags, full downstream lineage, alerts across the table and its dependents, recent queries that touch the changed columns, a local search for ref calls that Monte Carlo lineage missed, and monitors on affected columns. Risk is tiered: High for a key asset downstream, firing alerts or more than 50 reads a day; Medium for non-key downstream assets, monitors on affected columns or moderate query volume; Low otherwise. Multi-model changes get one consolidated, deduplicated report.
5. Change validation queries: only on explicit request, and only after Workflow 4 and a model edit in the same session. It writes 3 to 5 targeted queries with a mandatory row-count comparison, in the warehouse's SQL dialect (Snowflake, BigQuery, Redshift or Databricks), to validation/<table_name>_<YYYYMMDD_HHMM>.sql.

Use it whenever the work involves a dbt model or pipeline SQL: opening a model, asking about data quality, freshness, row counts or anomalies, responding to a data quality alert, or describing any change. Triggers include adding, renaming or dropping a column, changing a join or filter, tuning a threshold or constant, fixing a bug, reverting a change, or disabling a feature. Parameter changes look safe but silently change model output, so they get the same assessment as logic changes, and reverts do too, because downstream models may already depend on the behavior being undone.

The assessment must be presented before any SQL is written. Before editing a .sql or model file, the skill checks that the synthesis was run for this specific change in the current prompt; having run it earlier in the session is not enough. On High or Medium risk it asks "Do you want me to proceed with the edit?" and waits for an explicit yes; on Low it may proceed if nothing is concerning. Only an explicit acknowledgement such as "I know the risks, just make the change" skips this, and the skip is noted.

Do not invoke it for seed files, analysis files, ad-hoc SQL outside a dbt project, configuration files such as dbt_project.yml, profiles.yml and packages.yml, or tests unless the question is about data quality. If unsure whether a file is a dbt model, check for ref or source Jinja calls. Macros and snapshots are not models and do not trigger auto-context, but a pre-edit hook gates them because a one-line macro change can alter dozens of models. It does not replace environment-specific validation or expert review.

Inputs are the SQL or model file and the engineer's described change. Outputs are a risk-tiered impact report (downstream blast radius, key assets, active incidents, column exposure in recent queries, monitor coverage and a recommendation), followed by a synthesis that ties findings to code advice, such as deferring the change while alerts fire, using additive or backward-compatible schema changes for key downstream assets, or keeping the old column for a transition when a renamed column reaches the final SELECT, even if defined in a CTE. It ends with one recommendation: "Given the above, I recommend: ...". Two HTML-comment markers coordinate with plugin hooks: one confirms the impact check for each table by model name, and one reports a monitor coverage gap.

Monitor files use montecarlo: as the root key, with the second-level key matching the monitor type, in a standalone file separate from the project config:

montecarlo:
  custom_sql:
    - warehouse: <warehouse_name>
      name: <monitor_name>
      description: <description>
      schedule:
        interval_minutes: 720
        start_time: '<ISO timestamp>'
      sql: <your validation SQL>
      alert_conditions:
        - operator: GT
          threshold_value: 0.0

The project's montecarlo.yml holds only version, namespace and default_resource.

It works through the monte-carlo MCP server, using tools such as search, getTable, getAssetLineage, getAlerts, getMonitors, getQueriesForTable, getQueryData, the four create*MonitorMac generators, getValidationPredicates, updateAlert, setAlertOwner, createOrUpdateAlertComment, getAudiences, getDomains, getUser, getCurrentTime and testConnection. Tables are identified by MCONs, resolved with search. getAlerts uses snake_case parameters and a maximum 60-day window. It also uses the montecarlo CLI, and the separate monitor-creation skill offers deeper monitor guidance. Authentication is OAuth through the plugin, or header-based with x-mcd-id and x-mcd-token for older clients. It is published by Monte Carlo (monte-carlo-data/mc-agent-toolkit).