Intelligence in Action

How monitoring context flows into Intelligence to solve real problems

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.

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:

1. Features generate context: Schema drift, freshness, and data quality monitoring continuously capture operational data about your tables
2. Intelligence aggregates context: When you select a table or ask a question, Intelligence pulls from all available monitoring domains
3. AI reasons across domains: Instead of checking each page separately, Intelligence correlates findings across schema changes, freshness status, quality metrics, tags, and lineage
4. 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.

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