> ## Documentation Index > Fetch the complete documentation index at: https://docs.anomalyarmor.ai/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > The building blocks of data observability Data observability answers a simple question: **Can I trust this data?** When a dashboard shows unexpected numbers, you need to know if it's a real business trend or a broken pipeline. When an executive asks about yesterday's revenue, you need confidence that the data is fresh and complete. Data observability gives you that confidence. ## The Problem Data pipelines fail silently. Unlike application errors that crash loudly, data problems often go unnoticed until someone makes a bad decision: | Scenario | What Happened | The Cost | | ------------------------------------------- | ------------------------------------------- | ------------------------------------- | | Marketing spends \$50K on wrong audience | Pipeline dropped demographic column | Wasted ad spend, wrong targeting | | CEO quotes wrong revenue in earnings call | ETL job failed, dashboard showed stale data | Stock price impact, credibility loss | | Product team ships feature to wrong segment | Upstream table had schema change | Development time wasted, wrong launch | Data observability prevents these scenarios by monitoring your data like you monitor your applications. Without monitoring: silent failure leads to 3am debugging. With AnomalyArmor: alert fires immediately, team fixes before impact Without monitoring: silent failure leads to 3am debugging. With AnomalyArmor: alert fires immediately, team fixes before impact ## The Building Blocks AnomalyArmor monitors data through these interconnected concepts: How AnomalyArmor concepts fit together: Database → Discovery → Assets → Schema Changes, Freshness, Metrics → Alerts How AnomalyArmor concepts fit together: Database → Discovery → Assets → Schema Changes, Freshness, Metrics → Alerts Tables, views, and other data objects that AnomalyArmor monitors How AnomalyArmor finds and catalogs your data assets Detecting and tracking structural changes to your data Monitoring when your data was last updated Tracking statistical properties and detecting anomalies How you get notified when issues occur Embedded status indicators for dashboards and docs AI-powered search and documentation Classifying and organizing your assets ## How They Work Together **Discovery** scans your databases and catalogs **Assets** (tables, views, columns). Once cataloged, AnomalyArmor monitors each asset for: * **Schema changes**: Columns added, removed, or type-changed * **Freshness violations**: Data not updated within your SLA * **Metric anomalies**: Unexpected changes in row counts, null rates, or distributions When issues occur, **Alerts** notify your team through Slack, PagerDuty, email, or webhooks. **Report Badges** embed this status directly in your dashboards and documentation, so consumers always know if data is trustworthy. **Intelligence** helps you explore your catalog with natural language, and **Tagging** organizes assets for compliance and governance. ## Quick Reference | Concept | Question It Answers | Example Alert | | ------------- | ----------------------------- | ----------------------------------------- | | Asset | What data do I have? | (Cataloging, no alert) | | Discovery | What changed since last scan? | "New table detected: staging.orders\_v2" | | Schema Change | Did the structure change? | "Column removed: orders.shipping\_status" | | Freshness | Is data up to date? | "orders table is 4 hours stale" | | Metric | Is data quality normal? | "Row count dropped 60% from yesterday" | | Alert | Who needs to know? | (Routes to Slack, PagerDuty, etc.) | | Report Badge | Can consumers trust this? | (Visual indicator on dashboards) | | Intelligence | Where is X data? | (AI-powered search result) | | Tagging | What category is this? | (Classification: PII, production, etc.) | ## Common Questions ### What is data observability and how is it different from data quality? Data observability is continuous visibility into data health: schema, freshness, row counts, distributions. Data quality is often a one-time or batch check (is this value in the expected set?). Observability catches problems *as they happen* - including ones you didn't predict - while quality checks validate specific known rules. AnomalyArmor does both: observability by default, rule-based quality checks layered on top. ### Do I need to configure every monitoring concept manually? No. Schema drift and freshness are automatic once discovery runs - no per-table setup. Metrics and custom rules are opt-in where you want them. Most customers get value from the automatic monitoring on day one and add explicit metrics to their most critical tables over the first week. ### How does AnomalyArmor decide what's anomalous without me defining thresholds? For metrics, AnomalyArmor builds a statistical baseline from 7-14 days of historical values and flags new readings outside that baseline's expected range. For schema changes, "anomalous" is literal - the structure differs from the previous discovery. For freshness, it learns your typical update cadence and alerts when a table misses it. ### Can I start with just one concept and add others later? Yes. The most common starting point is schema drift + freshness on production databases - zero-config, high signal. Add metrics and report badges once the alerting cadence is calibrated. Tagging and compliance usually follow. ## Next Steps Start monitoring in under 15 minutes Understand the foundation of data observability