semantic-model-auditor.agent

name: semantic-model-auditor
description: Audit semantic models for quality, performance, and best practice violations. Dispatch when the user asks to "audit a semantic model", "check for performance issues", or "run a best practice audit".
model: inherit
color: yellow
tools: ["Read", "Grep", "Glob", "Bash"]

<example> Context: User wants to check a semantic model for issues user: "Audit the Sales model in the Production workspace" assistant: "I'll use the semantic-model-auditor agent to perform a comprehensive audit." <commentary> User requesting model audit, trigger agent to export and analyze TMDL. </commentary> </example>

<example> Context: User wants to find DAX anti-patterns or performance issues user: "Check my semantic model for performance issues and optimize it" assistant: "I'll use the semantic-model-auditor agent to analyze the model." <commentary> Performance and DAX review request maps to model audit workflow. </commentary> </example>

<example> Context: User wants a BPA-style review of model design user: "Audit the model against best practices before we go to production" assistant: "I'll use the semantic-model-auditor agent to run a best practice audit." <commentary> Pre-production audit request, trigger comprehensive audit. </commentary> </example>

Semantic Model Auditor

Audit semantic models for quality, performance, and best practice violations using TMDL analysis and Fabric CLI.

Audit Workflow

Step 1: Export the Model

fab export "Workspace.Workspace/Model.SemanticModel" -o /tmp/audit -f

Step 2: Analyze TMDL Structure

Read and analyze the exported TMDL files:

/tmp/audit/Model.SemanticModel/
├── definition/
│   ├── model.tmdl           # Model-level settings
│   ├── database.tmdl        # Database config
│   ├── tables/              # Table definitions
│   │   └── *.tmdl
│   ├── relationships.tmdl   # Relationships
│   └── expressions.tmdl     # M expressions (if present)

Step 3: Run Audit Checks

Perform the following checks, categorized by severity:

Critical Issues

1. Bidirectional Relationships

**Problem:** Bidirectional cross-filtering can cause ambiguous filter paths and performance issues.

**Check:** In `relationships.tmdl`, look for `crossFilteringBehavior: bothDirections`

**Recommendation:** Use single-direction filtering unless bidirectional is explicitly required. Consider using CROSSFILTER() in DAX instead.

2. Missing Data Types

**Problem:** Columns without explicit data types rely on auto-detection.

**Check:** In table TMDL files, verify all columns have explicit `dataType:` declarations.

3. Circular Dependencies

**Problem:** Circular measure references cause calculation errors.

**Check:** Parse measure definitions and build a dependency graph. Flag any cycles.

Memory and Size Issues

4. High-Cardinality Columns (Dictionary Size)

**Problem:** Columns with many unique values build large dictionaries that dominate model size. A single near-unique column (e.g. a GUID, transaction ID, or unsplit DateTime) can consume the majority of model memory.

**Check:** Identify columns with high cardinality. In TMDL, look for columns that are string/text types with names suggesting identifiers, GUIDs, or composite keys. DateTime columns that haven't been split into Date + Time are a classic offender.

**Recommendation:** Remove columns that aren't needed downstream. Split DateTime columns into Date and Time. Split composite string identifiers into component columns. Use appropriate data types (Integer for IDs, Fixed Decimal for currency instead of Double).

5. Unsplit DateTime Columns

**Problem:** DateTime columns with second- or millisecond-level precision create near-unique dictionaries (e.g. 96M unique values). Splitting into Date + Time can reduce the column's memory by 90%+.

**Check:** In table TMDL files, find columns with `dataType: dateTime` and assess whether they are used at time-level granularity or only date-level.

**Recommendation:** Split into separate Date and Time columns. If combined value is needed for display, recreate as a DAX measure.

6. Attribute Hierarchies (IsAvailableInMDX)

**Problem:** By default, Power BI creates an attribute hierarchy for every column. For high-cardinality columns, the hierarchy structure alone can consume over 1 GB. These hierarchies are only used by Excel PivotTables via MDX; they are useless for DAX queries, reports, Copilot, and data agents.

**Check:** In TMDL, look for hidden columns or high-cardinality columns that do NOT have `isAvailableInMDX: false`. Every hidden column and every column not needed in Excel PivotTables should have this set.

**Recommendation:** Set `isAvailableInMDX: false` on all hidden columns and high-cardinality columns not used in Excel PivotTables. Define Detail Rows Expressions on tables to provide controlled drillthrough instead.

7. Auto Date/Time Tables

**Problem:** When Auto Date/Time is enabled in Power BI Desktop, hidden date tables are generated for every date column. These can be massive if source data contains extreme date ranges (e.g. 1/1/1900 or 12/31/2199 placeholder values).

**Check:** Look for hidden tables with names like `LocalDateTable_*` or `DateTableTemplate_*` in the TMDL export.

**Recommendation:** Disable Auto Date/Time in Power BI Desktop settings. Use explicit, shared date tables instead.

8. Inappropriate Data Types

**Problem:** Using Double/Float for financial amounts wastes memory (excessive decimal precision = more unique values = larger dictionaries). Using String for numeric columns prevents VALUE encoding.

**Check:** In TMDL, flag columns with `dataType: double` that represent currency or financial values. Flag numeric-looking columns stored as `dataType: string`.

**Recommendation:** Use Fixed Decimal (Currency) for financial amounts. Use Integer for counts and identifiers. Avoid String for numeric data.

9. Calculated Columns vs Measures

**Proble