Detection and resolving issues

When validation or the data architect agent's own analysis surfaces a problem, it does not simply report the error. The agent performs root cause analysis, explains the problem in business-readable language, and proposes one or more resolution options for you to choose from. Some issues are:

Duplicate Rows (Grain Mismatch)

This is one of the most common issues in Business View construction. It occurs when a fact table has a finer grain than the joins support. For example, if a fact table contains records at the HCP × Month × Territory × Product × Plan grain, but only HCP and Date dimensions are joined, then the Territory, Product, and Plan foreign keys remain unresolved. This causes the same HCP + Month combination to appear multiple times in the joined view (once per Territory/Product/Plan combination), leading to inflated metric values.

The agent performs a root cause analysis by examining the fact table's foreign keys and identifying which ones are not joined to any dimension. It then checks whether the missing dimension tables already exist in the data source. If they do, the agent proposes a structured plan to add the missing dimension tables and their corresponding joins.

Once you approve the plan, the agent updates the YAML, publishes the modified BV, and offers to re-run validation to confirm the issue is resolved.

Division by Zero in Calculated Columns

When validation or data profiling reveals that a calculated column contains a division where the denominator can be zero, the agent flags it as a critical issue and presents multiple solution options with the exact formula for each.

Schema Case Mismatch

When working with Snowflake sources (which use uppercase column identifiers by default), the agent may detect that the YAML configuration references column names in lowercase while the actual database schema uses uppercase. This causes join key errors during validation because the field names do not match.

The agent identifies all mismatched field names, lists the required updates (for example, brand_id → BRAND_ID, platform_id → PLATFORM_ID), and asks for confirmation before applying the changes across all join specifications, source column lists, and model column references in the YAML. After the updates are applied, the agent runs a dry-run validation to confirm all references resolve correctly before publishing.