AI can suggest DAX quickly, but a plausible formula is not proof that the measure matches the business rule. Model relationships, filter context, date logic, and total behavior all affect the result. This checklist helps analysts review generated DAX before using it in a report.
Give the assistant the right context
Describe the model tables, relationships, grain, intended measure, and expected behavior under filters. Use fictional sample column names or sanitized data. Do not paste customer records, confidential measures, credentials, or proprietary business information into a tool unless your organization's rules explicitly permit it.
Ask for an explanation of row context, filter context, relationship assumptions, and edge cases—not just code. If a response assumes an active relationship or a unique key that your model does not have, the measure may compile but still be wrong.
Check the metric definition first
Write the business definition in plain language. For net sales, does the rule subtract returns, discounts, and tax? Which date governs the sale: order, invoice, or shipment date? Are cancelled orders excluded? A DAX expression cannot decide these policy questions for you.
Confirm the data grain. If a sales table has one row per order line, multiplying each line's quantity by its unit price may be appropriate. If the amount already exists per line, multiplying it again would overstate revenue.
Test with tiny known data
Create or select a small test case where you can calculate the answer by hand: two products, a few lines, one return, and two dates. Include a case where the same order has multiple lines. Compare the measure result to your written rule at the total level and per group.
Then test the report under no filters, one category, one month, multiple slicers, and a blank or unmatched dimension key. Check whether totals are recalculated at the total context rather than being the sum of displayed rows. This is often expected for averages, ratios, and distinct counts.
Inspect the formula and model assumptions
- Are referenced tables and columns real, correctly typed, and spelled accurately?
- Does the expression sum row-level amounts or multiply independent totals?
- Does CALCULATE remove or retain the intended filters?
- Does an iterator scan a large table unnecessarily?
- Does a date calculation rely on a contiguous, marked date table and the intended relationship?
- Does the formula return sensible results for blank, zero, and negative values?
Use a temporary table visual with keys and the measure to inspect intermediate behavior. Ask a reviewer familiar with the model to compare it to the business definition.
Keep a regression example
Record the expected output for a few known cases and rerun them after changing the measure or model. Document the definition, assumptions, test cases, and any known limitations. If the measure influences finance, safety, compliance, or other high-impact decisions, follow formal review and approval procedures rather than relying on an informal AI check.
AI is useful as a coding assistant and a source of alternative explanations. The analyst remains responsible for validating that the calculation is correct, safe to share, and appropriate for the decision it supports.
