Creating a new Business View workflow

When creating a new Business View, the Data Architect agent follows a five-phase sequential workflow. Each phase is a distinct checkpoint.

1. Intent

The agent begins by asking what you want to accomplish. You describe your business objective, the metrics you care about, and the questions you want to answer. You can also upload supporting files at this stage, including PDFs, images, Excel spreadsheets, schema diagrams, or handoff packets that contain join guides and key business questions (KBQs).

Based on your description and any uploaded materials, the agent captures the industry vertical, key metrics, and key business questions. These inputs influence downstream decisions, including join recommendations, column naming conventions, and the starter questions generated for the published BV.

When the agent encounters ambiguity at this stage, it asks clarification questions with pre-populated multiple-choice options rather than requiring you to type free-form answers.

2. Tables

The agent identifies and profiles the tables needed for the Business View.

• For Snowflake and Redshift sources: The agent connects directly to the data source, auto-discovers available tables, and profiles them. No pre-loading is required. The agent analyzes column types, detects primary and foreign keys through naming patterns and cardinality analysis, classifies tables as fact or dimension, distinguishes between snapshot-based and event-based tables, and performs data quality profiling (null percentages, unique value counts, value distributions).

• For all other sources: You select from datasets that have already been loaded into Tellius.

The distinction between snapshot and event tables is important for downstream join logic.

Data Architect agent classifies tables into these categories during profiling. When the agent detects that a generic join recommendation would produce row explosion on a snapshot table, it flags the issue and corrects the join strategy before presenting the plan, either by adding a time-window condition or by recommending pre-aggregation.

The agent presents the table list for your review. You can accept, modify, or reject these recommendations.

If a required table is not present in the data source, the agent can surface alternatives from available tables or generate a derived dataset on-the-fly via SQL, adding it to the YAML plan automatically.

3. Joins

The agent proposes a join graph that connects the selected tables. Each proposed join includes a plain-language rationale explaining why the join is suggested, the join keys being used, the join type (left outer or inner), and the inferred cardinality (1:1, 1:N, N:1, or M:N).

The join graph is displayed visually in the Diagram tab as an entity-relationship diagram. Join lines connect tables with cardinality labels and confidence percentages.

Many-to-many (M:N) relationships are a common source of row explosion and double counting in Business Views. When the agent detects an M:N relationship, it flags it with an explicit warning and suggests resolution strategies before anything is built. Typical suggestions include introducing a bridge table, selecting a deduplication key, or pre-aggregating one side of the join.

The agent handles composite key joins where the relationship between two tables requires matching on multiple columns simultaneously, not just a single foreign key.

You review the proposed join graph and approve or modify it. Modifications can be made conversationally (for example, "change the join between the fact table and the territory dimension to use TERRITORY_ID instead of REGION_CODE") or by directly editing the YAML in the right panel.

4. Columns

The agent generates calculated columns based on the key business questions captured. Each generated column includes the formula, a classification of whether it is a row-level or report-level calculation, and a plain-language explanation of what it computes.

Calculated columns can be refined conversationally. For example, if the agent generates a formula for TRx_Per_Call that counts all call types, you can instruct it to change the formula to count only in-person calls by typing the instructions in the chat.

If you have existing calculated column logic written in DAX (used in Power BI) or Excel formula syntax, you can provide it to the agent and it will translate it into Tellius-native syntax. This is particularly useful when migrating analytics from an existing BI environment into Tellius. You do not need to manually rewrite every formula; describe what the formula does or paste the original DAX/Excel expression, and the Kaiya agent handles the conversion.

Kaiya-only vs general calculated columns

• General calculated columns are persisted in the Business View schema and are available across all Tellius modules (Vizpad, Search, Insights, and Kaiya). These are standard computed fields that become part of the BV definition.

• Kaiya-only calculated columns are computed at query time within Kaiya conversations only. They are not materialized in the BV schema and do not appear in Vizpad or Search.

This distinction allows the agent to create complex, context-specific calculations that are useful for Kaiya’s analytical workflows without adding clutter to the BV.

5. Metadata import

If you have external metadata documented, you can upload it during this phase and the agent will use it to populate column descriptions, business definitions, and synonym mappings. Supported metadata sources include:

• dbt model files (descriptions, meta tags, column-level documentation)

• CSV data dictionaries (column mappings, business definitions, synonym tables)

• SQL column comments (extracted directly from the source schema)

• PDF or image attachments (schema diagrams, requirements documents, ERD screenshots)

The agent treats imported metadata as source-of-truth. It only fills in fields that are missing from the imported metadata. It will never overwrite existing definitions.

6. Validate

Before publishing, the agent runs a comprehensive set of pre-publish validation checks against the Business View. The validation results are presented as a structured report with an overall status, a validation scorecard, and a detailed results matrix.

Validation checks

The validation engine runs multiple individual checks. Each check produces a status (OK, WARNING, CRITICAL, or UNABLE TO VALIDATE) and a recommendation priority:

Validation Check	What It Verifies
Null Analysis	Percentage of null values across all columns in the joined view
Data Type Consistency	All join keys have compatible data types across the tables being joined
Double Counting Detection	Checks for duplicate rows in the joined view that would cause metrics to be counted more than once
Fan Trap Detection	Identifies join patterns where a single dimension fans out through multiple fact tables, causing inflated aggregations
Join Cardinality Classification	Confirms that join cardinalities (1:1, 1:N, N:1, M:N) match what was specified in the plan
Formula Validation	Verifies that all calculated columns produce valid results without errors
Join Key Validity	Confirms that specified join keys exist in both tables and that referential integrity is maintained
Row Count Validation	Compares expected row counts against actual row counts after joins to detect unexpected expansion or contraction
Chasm Trap Detection	Identifies join patterns where two fact tables connect through a shared dimension, which can produce incorrect cross-join results

If validation passes, the agent confirms with a message. If issues are found, the agent explains each issue in plain language and proposes fixes before allowing you to publish.

7. Publishing a Business View

After validation passes, the agent asks whether you want to publish the Business View. When you confirm, the agent executes the YAML plan and creates (or updates) the BV in Tellius.

A confirmation message is displayed in the chat with the following information:

• The Business View name and unique ID

• The list of changes applied (new tables added, new joins created, new columns added, schema modifications)

• The publication status

• The base table and all joined dimension tables

Once published, the Business View is immediately available for use in Kaiya, Vizpad, Search, and all other Tellius modules.

If validation surfaces issues during the publish attempt, the agent reports the specific error, proposes a fix, and re-validates after the fix is applied. This iterative cycle continues until validation passes completely.