Intelligence in Action

Intelligence is most powerful when you’ve set up monitoring across your data stack. This page walks through two real scenarios where schema drift, freshness, and data quality create the context that Intelligence uses to diagnose problems.

Scenario 1: The Broken Dashboard

A revenue dashboard shows “column not found” at 8 AM. Here’s how you’d use AnomalyArmor to find the root cause.

Timeline showing how a schema change breaks a dashboard and Intelligence diagnoses it

Step 1: Set Up Schema Drift Monitoring

Before anything breaks, you enabled schema drift detection on your gold tables:

Navigate to gold.fact_orders > Schema Monitoring > Enable

AnomalyArmor captures a baseline of every column, type, and constraint. Any future change triggers a schema drift alert.

Step 2: Set Up Freshness Monitoring

You created a freshness schedule for the orders pipeline:

gold.fact_orders: Check hourly, SLA 2 hours
staging.orders_raw: Check hourly, SLA 1 hour

Now AnomalyArmor knows when these tables should update and will alert if they fall behind.

Step 3: Set Up Data Quality Metrics

You added quality metrics on key columns:

gold.fact_orders.order_total: row_count, null_percentage
gold.fact_orders.discount_pct: null_percentage, distinct_count
gold.dim_customer.email: null_percentage

AnomalyArmor tracks these metrics on every discovery run, building a history of normal ranges.

Step 4: Something Breaks

Tuesday at 3:47 PM, a deploy removes the discount_pct column from staging.orders_raw. The ETL pipeline runs, propagating the removal to gold.fact_orders. Wednesday morning, the revenue dashboard fails with “column not found: discount_pct.” At this point, AnomalyArmor has already captured:

Schema drift: Column discount_pct removed from gold.fact_orders at 4:12 PM Tuesday
Data quality: discount_pct null_percentage metric stopped reporting (column gone)
Alerts: Schema drift alert fired at 4:12 PM, freshness alert cleared (table still updating on schedule)

Step 5: Intelligence Connects the Dots

You open the Intelligence page, select gold.fact_orders, and see the Object Profile: Findings (Critical):

Column discount_pct (FLOAT) was removed on Tuesday at 4:12 PM. This column had an active null_percentage metric that is no longer reporting. 2 downstream views reference this column: analytics.order_summary and reporting.daily_revenue.

Findings (Medium):

The removal correlates with a schema change on staging.orders_raw at 3:47 PM Tuesday, suggesting the column was dropped upstream.

You click Ask Agent and type:

You: Why is the revenue dashboard broken?

Agent: The revenue dashboard is failing because the column `discount_pct`
       was removed from gold.fact_orders.

       Timeline:
       - Tue 3:47 PM: discount_pct removed from staging.orders_raw
       - Tue 4:12 PM: Change propagated to gold.fact_orders via ETL
       - Tue 4:12 PM: Schema drift alert fired
       - Wed 8:00 AM: Dashboard query fails on missing column

       The column is referenced by:
       - analytics.order_summary (SELECT discount_pct)
       - reporting.daily_revenue (SUM(discount_pct))

       Root cause: Upstream schema change in staging.orders_raw.
       Check the deploy that went out Tuesday afternoon.

       Recommended actions:
       1. Restore the column if the removal was unintentional
       2. Update the 2 downstream views if it was intentional
       3. Resolve the schema drift alert after addressing

Without Intelligence, this investigation would involve checking the schema history page, the freshness page, the alerts page, and the data quality page separately. With Intelligence, you get the full picture in one question.

Scenario 2: The Silent Data Quality Regression

Null rates are climbing in your customer table, but nobody noticed because the table is still updating on schedule and no alerts fired.

Step 1: Context Already Exists

You previously set up:

Freshness: gold.dim_customer checks every 30 minutes, SLA 1 hour
Data quality: null_percentage on gold.dim_customer.email and gold.dim_customer.phone
Tags: gold.dim_customer tagged as PII, customer-360

Step 2: The Regression

A new data source integration starts sending records with empty email fields. The table updates on schedule (freshness is fine), no columns were added or removed (schema drift is clean), but the email null_percentage metric creeps from 2.1% to 12.4% over five days. AnomalyArmor’s data quality tracking captures every data point.

Step 3: Intelligence Surfaces It

During a routine check, you open the Object Profile for gold.dim_customer: Findings (High):

Null rate on email column increased from 2.1% to 12.4% over the past 5 days. This is outside the normal variance of +/- 0.5%. The table is tagged as PII, so this may indicate incomplete data ingestion.

Findings (Medium):

Null rate on phone column is stable at 8.2% (within normal range). No schema changes detected.

You ask the agent:

You: What's causing the null rate spike on dim_customer.email?

Agent: The null_percentage on gold.dim_customer.email has been climbing
       steadily:

       - Mar 3: 2.1% (baseline)
       - Mar 5: 4.8%
       - Mar 7: 8.1%
       - Mar 8: 12.4% (current)

       This is a gradual increase, not a sudden spike, which suggests a
       new data source or changed ingestion pattern rather than a one-time
       ETL failure.

       Context:
       - Freshness is normal (last update 12 minutes ago)
       - No schema changes detected on this table or its upstream sources
       - The phone column null rate is stable, so the issue is specific to
         email, not a blanket data quality problem
       - This table is tagged PII - the email column may be subject to
         compliance requirements

       I'd recommend checking if a new data source was added to the
       ingestion pipeline around March 3. The gradual curve suggests
       incremental records arriving without email values.

What Made This Work

In both scenarios, Intelligence didn’t just search table names. It pulled from:

Domain	What It Contributed
Schema drift	Detected the column removal and traced it to the upstream table
Freshness	Confirmed the table was still updating (ruling out staleness)
Data quality	Provided the null rate trend data and identified the anomaly
Tags	Added compliance context (PII classification)
Lineage	Mapped downstream impact (views referencing the removed column)
Alerts	Showed which alerts fired and when

Without monitoring set up, Intelligence would only have schema metadata to work with. With monitoring, it becomes a diagnostic engine.

The Pattern

Every Intelligence investigation follows the same loop:

Features generate context: Schema drift, freshness, and data quality monitoring continuously capture operational data about your tables
Intelligence aggregates context: When you select a table or ask a question, Intelligence pulls from all available monitoring domains
AI reasons across domains: Instead of checking each page separately, Intelligence correlates findings across schema changes, freshness status, quality metrics, tags, and lineage
You get a diagnosis: A single answer that explains what happened, when, why, and what to do about it

The more monitoring you set up, the more complete the picture. Start with your most critical tables: add freshness schedules, enable schema drift detection, and track a few data quality metrics. Then let Intelligence do the correlation work for you.

Common Questions

What’s the minimum monitoring setup for Intelligence to be useful?

Freshness on your most critical tables plus schema drift detection. That combination alone unlocks most diagnostic questions. Add data quality metrics next for the null-rate and row-count regressions shown in Scenario 2.

Can Intelligence catch a regression nothing alerted on?

Yes. Scenario 2 is exactly that case, no alert fires because the table updates on schedule and schema is unchanged, but the null-rate trend in data quality metrics surfaces the regression in the Object Profile. Intelligence reads trend history, not just threshold breaches.

How does Intelligence trace a broken dashboard back to its root cause?

It correlates schema drift (column removed), freshness (was the table also late?), lineage (which views reference the column), and alert history (when did the alert fire?) into a single timeline. That’s what turns “dashboard is broken” into “deploy on Tuesday 3:47 PM removed discount_pct”.

Does Intelligence work across upstream and downstream tables?

Yes. Lineage context lets it trace a problem from a gold table back to staging sources, and forward to downstream views and reports. The “blast radius” question in Ask Questions uses the same signal.

Next Steps

Set Up Freshness

Monitor table update patterns

Enable Schema Drift

Detect column changes automatically

Add Data Quality

Track null rates, row counts, and validity rules

Ask Questions

Start chatting with the Intelligence agent

Getting Started

Core Concepts

Data Sources

Detect Schema Changes

Monitor Data Health

Coverage Tiers

Get Notified

Understand Your Data

Organize & Tag

Guides

Account & Settings

Security

Help

Downloads

Scenario 1: The Broken Dashboard

Step 1: Set Up Schema Drift Monitoring

Step 2: Set Up Freshness Monitoring

Step 3: Set Up Data Quality Metrics

Step 4: Something Breaks

Step 5: Intelligence Connects the Dots

Scenario 2: The Silent Data Quality Regression

Step 1: Context Already Exists

Step 2: The Regression

Step 3: Intelligence Surfaces It

What Made This Work

The Pattern

Common Questions

What’s the minimum monitoring setup for Intelligence to be useful?

Can Intelligence catch a regression nothing alerted on?

How does Intelligence trace a broken dashboard back to its root cause?

Does Intelligence work across upstream and downstream tables?

Next Steps

Set Up Freshness

Enable Schema Drift

Add Data Quality

Ask Questions

​Scenario 1: The Broken Dashboard

​Step 1: Set Up Schema Drift Monitoring

​Step 2: Set Up Freshness Monitoring

​Step 3: Set Up Data Quality Metrics

​Step 4: Something Breaks

​Step 5: Intelligence Connects the Dots

​Scenario 2: The Silent Data Quality Regression

​Step 1: Context Already Exists

​Step 2: The Regression

​Step 3: Intelligence Surfaces It

​What Made This Work

​The Pattern

​Common Questions

​What’s the minimum monitoring setup for Intelligence to be useful?

​Can Intelligence catch a regression nothing alerted on?

​How does Intelligence trace a broken dashboard back to its root cause?

​Does Intelligence work across upstream and downstream tables?

​Next Steps

Set Up Freshness

Enable Schema Drift

Add Data Quality

Ask Questions

Scenario 1: The Broken Dashboard

Step 1: Set Up Schema Drift Monitoring

Step 2: Set Up Freshness Monitoring

Step 3: Set Up Data Quality Metrics

Step 4: Something Breaks

Step 5: Intelligence Connects the Dots

Scenario 2: The Silent Data Quality Regression

Step 1: Context Already Exists

Step 2: The Regression

Step 3: Intelligence Surfaces It

What Made This Work

The Pattern

Common Questions

What’s the minimum monitoring setup for Intelligence to be useful?

Can Intelligence catch a regression nothing alerted on?

How does Intelligence trace a broken dashboard back to its root cause?

Does Intelligence work across upstream and downstream tables?

Next Steps