pbiplint 0.1.0

package/dist/pbiplint.mjs

@@ -0,0 +1,3377 @@
+#!/usr/bin/env node
+
+// src/main.ts
+import { mkdirSync, writeFileSync } from "node:fs";
+import { basename as basename2, dirname as dirname4, relative as relative2, resolve as resolve3 } from "node:path";
+
+// ../core/src/version.ts
+var VERSION = "0.1.0";
+
+// ../core/src/engine/config.ts
+var ConfigError = class extends Error {
+};
+function bindConfig(config, rules) {
+  const idByUpper = new Map(rules.map((r) => [r.id.toUpperCase(), r.id]));
+  const bound = { disabled: /* @__PURE__ */ new Set(), severity: /* @__PURE__ */ new Map(), failOn: config.failOn };
+  const unknownRules = [];
+  for (const id of config.disabled) {
+    const real = idByUpper.get(id.toUpperCase());
+    if (real === void 0) unknownRules.push(id);
+    else bound.disabled.add(real);
+  }
+  for (const [id, severity] of config.severity) {
+    const real = idByUpper.get(id.toUpperCase());
+    if (real === void 0) unknownRules.push(id);
+    else bound.severity.set(real, severity);
+  }
+  return { config: bound, unknownRules };
+}
+var SEVERITY_BY_NAME = { info: 1, warning: 2, error: 3 };
+var isRecord = (v) => typeof v === "object" && v !== null && !Array.isArray(v);
+function isResolvedConfig(v) {
+  return isRecord(v) && v.disabled instanceof Set && v.severity instanceof Map;
+}
+function resolveConfig(raw = {}) {
+  if (!isRecord(raw)) throw new ConfigError("pbiplint.config.json must be a JSON object");
+  for (const k of Object.keys(raw))
+    if (k !== "rules" && k !== "failOn" && k !== "$schema")
+      throw new ConfigError(`pbiplint.config.json: unknown key "${k}"`);
+  const out = { disabled: /* @__PURE__ */ new Set(), severity: /* @__PURE__ */ new Map(), failOn: 3 };
+  if (raw.rules !== void 0) {
+    if (!isRecord(raw.rules))
+      throw new ConfigError(
+        'pbiplint.config.json: "rules" must be an object of rule id to "off" | "info" | "warning" | "error"'
+      );
+    for (const [id, v] of Object.entries(raw.rules)) {
+      if (v === "off") out.disabled.add(id);
+      else if (v === "info" || v === "warning" || v === "error")
+        out.severity.set(id, SEVERITY_BY_NAME[v]);
+      else
+        throw new ConfigError(
+          `pbiplint.config.json: rules["${id}"] must be "off", "info", "warning", or "error"`
+        );
+    }
+  }
+  if (raw.failOn !== void 0) {
+    if (raw.failOn === "none") out.failOn = null;
+    else if (raw.failOn === "info" || raw.failOn === "warning" || raw.failOn === "error")
+      out.failOn = SEVERITY_BY_NAME[raw.failOn];
+    else
+      throw new ConfigError(
+        'pbiplint.config.json: "failOn" must be "info", "warning", "error", or "none"'
+      );
+  }
+  return out;
+}
+
+// ../core/src/tmdl/quote.ts
+function unquoteName(s) {
+  const t = s.trim();
+  if (t.length >= 2 && t.startsWith("'") && t.endsWith("'"))
+    return t.slice(1, -1).replace(/''/g, "'");
+  return t;
+}
+function unquoteValue(s) {
+  const t = s.trim();
+  if (t.length >= 2 && t.startsWith('"') && t.endsWith('"'))
+    return t.slice(1, -1).replace(/""/g, '"');
+  return t;
+}
+
+// ../core/src/engine/ignore.ts
+var IGNORE_ANNOTATION = "pbiplint.ignore";
+function isIgnored(object, ruleId) {
+  const raw = object?.annotations[IGNORE_ANNOTATION];
+  if (raw === void 0) return false;
+  const wanted = ruleId.toUpperCase();
+  return unquoteValue(raw).split(",").map((s) => s.trim()).some((s) => s === "*" || s.toUpperCase() === wanted);
+}
+
+// ../core/src/index/references.ts
+var QUALIFIED = /(?:'((?:[^']|'')+)'\s*|([\p{L}_][\p{L}\p{N}_]*))\[([^\]]+)\]/gu;
+var BARE = /\[([^\]]+)\]/g;
+function extractRefs(expression) {
+  const out = [];
+  const consumed = /* @__PURE__ */ new Set();
+  for (const m of expression.matchAll(QUALIFIED)) {
+    const table = m[1] !== void 0 ? m[1].replace(/''/g, "'") : m[2];
+    out.push({ table, name: m[3], qualified: true });
+    consumed.add(m.index + m[0].length - m[3].length - 2);
+  }
+  for (const m of expression.matchAll(BARE)) {
+    if (consumed.has(m.index)) continue;
+    out.push({ name: m[1], qualified: false });
+  }
+  return out;
+}
+var lower = (s) => s.toLowerCase();
+var key = (table, name) => `${lower(table)} ${lower(name)}`;
+function buildReferenceIndex(model) {
+  const tables = new Map(model.tables.map((t) => [lower(t.name), t]));
+  const columns2 = /* @__PURE__ */ new Map();
+  const measures = /* @__PURE__ */ new Map();
+  for (const t of model.tables) {
+    for (const c of t.columns) columns2.set(key(t.name, c.name), c);
+    for (const m of t.measures) measures.set(lower(m.name), m);
+  }
+  const columnOf = (t, name) => columns2.get(key(t.name, name));
+  const resolve4 = (raw, ownerTable, ownerKind) => {
+    if (raw.qualified) {
+      const t = tables.get(lower(raw.table));
+      if (!t) return { kind: "unresolved", table: raw.table, name: raw.name, qualified: true };
+      const col = columnOf(t, raw.name);
+      if (col) return { kind: "column", table: t.name, name: col.name, qualified: true };
+      const meas2 = t.measures.find((m) => lower(m.name) === lower(raw.name));
+      if (meas2) return { kind: "measure", table: t.name, name: meas2.name, qualified: true };
+      return { kind: "unresolved", table: raw.table, name: raw.name, qualified: true };
+    }
+    const meas = measures.get(lower(raw.name));
+    if (meas) return { kind: "measure", table: meas.table.name, name: meas.name, qualified: false };
+    if (ownerKind === "calculationItem")
+      return { kind: "unresolved", name: raw.name, qualified: false };
+    if (ownerTable) {
+      const col = columnOf(ownerTable, raw.name);
+      if (col) return { kind: "column", table: ownerTable.name, name: col.name, qualified: false };
+    }
+    for (const t of model.tables) {
+      const col = columnOf(t, raw.name);
+      if (col) return { kind: "column", table: t.name, name: col.name, qualified: false };
+    }
+    return { kind: "unresolved", name: raw.name, qualified: false };
+  };
+  const owners = [];
+  const byObject = /* @__PURE__ */ new Map();
+  const add = (kind, object, ownerTable, ...expressions) => {
+    const expression = expressions.filter((e) => e !== void 0).join("\n");
+    const owner = {
+      kind,
+      object,
+      ownerTable,
+      expression,
+      refs: extractRefs(expression).map((r) => resolve4(r, ownerTable, kind))
+    };
+    owners.push(owner);
+    byObject.set(object, owner);
+  };
+  for (const t of model.tables) {
+    for (const m of t.measures) add("measure", m, t, m.expression, m.formatStringDefinition);
+    for (const c of t.columns)
+      if (c.kind === "calculated") add("calculatedColumn", c, t, c.expression);
+    if (t.kind === "calculated")
+      add(
+        "calculatedTable",
+        t,
+        t,
+        ...t.partitions.filter((p) => p.sourceType === "calculated").map((p) => p.source)
+      );
+    for (const item of t.calculationGroup?.items ?? [])
+      add("calculationItem", item, t, item.expression, item.formatStringDefinition);
+  }
+  for (const role of model.roles) {
+    for (const tp of role.tablePermissions)
+      if (tp.filter !== void 0)
+        add("tablePermission", tp, tables.get(lower(tp.table)), tp.filter);
+  }
+  const columnRefs = /* @__PURE__ */ new Map();
+  const measureRefs = /* @__PURE__ */ new Map();
+  for (const o of owners) {
+    for (const r of o.refs) {
+      if (r.kind === "column") {
+        const k = key(r.table, r.name);
+        const arr = columnRefs.get(k) ?? [];
+        if (!arr.includes(o)) arr.push(o);
+        columnRefs.set(k, arr);
+      } else if (r.kind === "measure") {
+        const k = lower(r.name);
+        const arr = measureRefs.get(k) ?? [];
+        if (!arr.includes(o)) arr.push(o);
+        measureRefs.set(k, arr);
+      }
+    }
+  }
+  return {
+    owners,
+    refsOf: (object) => byObject.get(object)?.refs ?? [],
+    columnReferencedBy: (c) => columnRefs.get(key(c.table.name, c.name)) ?? [],
+    measureReferencedBy: (m) => measureRefs.get(lower(m.name)) ?? []
+  };
+}
+
+// ../core/src/index/relationships.ts
+var key2 = (table, column) => `${table} ${column}`;
+function push(map, k, r) {
+  const arr = map.get(k);
+  if (!arr) map.set(k, [r]);
+  else if (!arr.includes(r)) arr.push(r);
+}
+function buildRelationshipIndex(model) {
+  const byColumn = /* @__PURE__ */ new Map();
+  const byTable = /* @__PURE__ */ new Map();
+  for (const r of model.relationships) {
+    push(byColumn, key2(r.fromTable, r.fromColumn), r);
+    push(byColumn, key2(r.toTable, r.toColumn), r);
+    push(byTable, r.fromTable, r);
+    push(byTable, r.toTable, r);
+  }
+  return {
+    all: model.relationships,
+    forColumn: (table, column) => byColumn.get(key2(table, column)) ?? [],
+    forTable: (table) => byTable.get(table) ?? []
+  };
+}
+
+// ../core/src/index/usage.ts
+var key3 = (table, column) => `${table} ${column}`;
+function buildUsageIndex(model) {
+  const sortTargets = /* @__PURE__ */ new Set();
+  const levelColumns = /* @__PURE__ */ new Set();
+  const variationDefaults = /* @__PURE__ */ new Set();
+  for (const t of model.tables) {
+    for (const c of t.columns) {
+      if (c.sortByColumn !== void 0) sortTargets.add(key3(t.name, c.sortByColumn));
+      for (const v of c.variations)
+        if (v.defaultColumn)
+          variationDefaults.add(key3(v.defaultColumn.table, v.defaultColumn.column));
+    }
+    for (const h of t.hierarchies)
+      for (const l of h.levels) if (l.column !== void 0) levelColumns.add(key3(t.name, l.column));
+  }
+  return {
+    usedInSortBy: (c) => sortTargets.has(key3(c.table.name, c.name)),
+    usedInHierarchies: (c) => levelColumns.has(key3(c.table.name, c.name)),
+    usedInVariations: (c) => variationDefaults.has(key3(c.table.name, c.name))
+  };
+}
+
+// ../core/src/index/build.ts
+function buildIndexes(model) {
+  return {
+    relationships: buildRelationshipIndex(model),
+    usage: buildUsageIndex(model),
+    references: buildReferenceIndex(model)
+  };
+}
+
+// ../core/src/model/build.ts
+var str = (v) => typeof v === "string" ? v : void 0;
+var flag = (v) => v === true || typeof v === "string" && v.toLowerCase() === "true";
+var lower2 = (v) => str(v)?.toLowerCase();
+var loc = (n) => ({ file: n.file, line: n.line });
+var objects = (n, type) => n.children.filter((c) => c.kind === "object" && c.type === type);
+function annotationsOf(n) {
+  const out = {};
+  for (const c of objects(n, "annotation")) out[c.name] = c.value ?? "";
+  return out;
+}
+function named(n, name = n.name ?? "") {
+  return {
+    name,
+    description: n.description,
+    annotations: annotationsOf(n),
+    location: loc(n),
+    node: n
+  };
+}
+function splitQualifiedName(ref) {
+  const m = /^('(?:[^']|'')*'|[^.]+)\.('(?:[^']|'')*'|.+)$/.exec(ref.trim());
+  return m ? { table: unquoteName(m[1]), column: unquoteName(m[2]) } : { table: "", column: unquoteName(ref) };
+}
+function buildColumn(c, table) {
+  const p = c.props;
+  const variations = objects(c, "variation").map((v) => {
+    const dc = str(v.props.defaultcolumn);
+    return {
+      name: v.name,
+      relationship: str(v.props.relationship),
+      defaultHierarchy: str(v.props.defaulthierarchy),
+      defaultColumn: dc ? splitQualifiedName(dc) : void 0
+    };
+  });
+  const sortBy = str(p.sortbycolumn);
+  return {
+    ...named(c),
+    table,
+    kind: "data",
+    dataType: str(p.datatype),
+    isHidden: flag(p.ishidden),
+    isKey: flag(p.iskey),
+    isAvailableInMdx: p.isavailableinmdx === void 0 ? true : flag(p.isavailableinmdx),
+    formatString: str(p.formatstring),
+    summarizeBy: str(p.summarizeby),
+    sourceColumn: str(p.sourcecolumn),
+    sortByColumn: sortBy === void 0 ? void 0 : unquoteName(sortBy),
+    dataCategory: str(p.datacategory),
+    expression: c.value,
+    variations,
+    hasAlternateOf: c.children.some((ch) => ch.type === "alternateof")
+  };
+}
+function buildMeasure(x, table) {
+  const p = x.props;
+  return {
+    ...named(x),
+    table,
+    expression: x.value ?? "",
+    formatString: str(p.formatstring),
+    formatStringDefinition: str(p.formatstringdefinition),
+    isHidden: flag(p.ishidden),
+    displayFolder: str(p.displayfolder)
+  };
+}
+function buildPartition(pt, table) {
+  const sourceNode = pt.children.find((ch) => ch.type === "source" && ch.kind === "flag");
+  const ds = str(sourceNode?.props.datasource);
+  return {
+    ...named(pt),
+    table,
+    sourceType: (pt.value ?? "").trim().toLowerCase(),
+    mode: lower2(pt.props.mode),
+    source: str(pt.props.source) ?? str(sourceNode?.props.query),
+    dataSource: ds === void 0 ? void 0 : unquoteName(ds)
+  };
+}
+function buildHierarchy(h, table) {
+  const hierarchy = { ...named(h), table, isHidden: flag(h.props.ishidden), levels: [] };
+  for (const l of objects(h, "level")) {
+    const col = str(l.props.column);
+    const level = {
+      ...named(l),
+      hierarchy,
+      column: col === void 0 ? void 0 : unquoteName(col)
+    };
+    hierarchy.levels.push(level);
+  }
+  return hierarchy;
+}
+function buildCalculationGroup(cg, table) {
+  const precedence = str(cg.props.precedence);
+  const group = {
+    ...named(cg, table.name),
+    table,
+    precedence: precedence === void 0 ? void 0 : Number(precedence),
+    items: []
+  };
+  for (const ci of objects(cg, "calculationitem")) {
+    const item = {
+      ...named(ci),
+      table,
+      expression: ci.value ?? "",
+      formatStringDefinition: str(ci.props.formatstringdefinition)
+    };
+    group.items.push(item);
+  }
+  return group;
+}
+function buildTable(r, model) {
+  let t = model.tables.find((x) => x.name === r.name);
+  if (!t) {
+    t = {
+      ...named(r),
+      kind: "table",
+      isHidden: flag(r.props.ishidden),
+      dataCategory: str(r.props.datacategory),
+      columns: [],
+      measures: [],
+      partitions: [],
+      hierarchies: []
+    };
+    model.tables.push(t);
+  } else {
+    if (flag(r.props.ishidden)) t.isHidden = true;
+    t.dataCategory ??= str(r.props.datacategory);
+    t.description ??= r.description;
+    Object.assign(t.annotations, annotationsOf(r));
+  }
+  for (const c of r.children) {
+    if (c.kind === "object" && c.type === "column") t.columns.push(buildColumn(c, t));
+    else if (c.kind === "object" && c.type === "measure") t.measures.push(buildMeasure(c, t));
+    else if (c.kind === "object" && c.type === "partition") t.partitions.push(buildPartition(c, t));
+    else if (c.kind === "object" && c.type === "hierarchy")
+      t.hierarchies.push(buildHierarchy(c, t));
+    else if (c.type === "calculationgroup") t.calculationGroup = buildCalculationGroup(c, t);
+  }
+}
+function buildRelationship(r) {
+  const p = r.props;
+  const from = splitQualifiedName(str(p.fromcolumn) ?? "");
+  const to = splitQualifiedName(str(p.tocolumn) ?? "");
+  return {
+    ...named(r),
+    fromTable: from.table,
+    fromColumn: from.column,
+    toTable: to.table,
+    toColumn: to.column,
+    isActive: p.isactive === void 0 ? true : flag(p.isactive),
+    crossFilteringBehavior: lower2(p.crossfilteringbehavior) ?? "onedirection",
+    fromCardinality: lower2(p.fromcardinality) ?? "many",
+    toCardinality: lower2(p.tocardinality) ?? "one"
+  };
+}
+function buildRole(r) {
+  const role = {
+    ...named(r),
+    modelPermission: lower2(r.props.modelpermission),
+    members: r.children.filter((c) => c.kind === "object" && c.type.endsWith("member")).map((c) => ({ name: c.name })),
+    tablePermissions: []
+  };
+  for (const tp of objects(r, "tablepermission")) {
+    const permission = {
+      ...named(tp),
+      role,
+      table: tp.name,
+      filter: tp.value,
+      metadataPermission: lower2(tp.props.metadatapermission),
+      columnPermissions: objects(tp, "columnpermission").map((cp) => ({
+        column: cp.name,
+        permission: (cp.value ?? "").trim().toLowerCase()
+      }))
+    };
+    role.tablePermissions.push(permission);
+  }
+  return role;
+}
+function finalizeKinds(model) {
+  for (const t of model.tables) {
+    if (t.calculationGroup) t.kind = "calculationGroup";
+    else if (t.partitions.some((p) => p.sourceType === "calculated")) t.kind = "calculated";
+    else t.kind = "table";
+    for (const c of t.columns)
+      c.kind = c.expression !== void 0 ? "calculated" : t.kind === "calculated" ? "calculatedTable" : "data";
+  }
+}
+function buildModel(files) {
+  const model = {
+    name: "Model",
+    annotations: {},
+    location: { file: "", line: 0 },
+    props: {},
+    tables: [],
+    relationships: [],
+    roles: [],
+    perspectives: [],
+    cultures: [],
+    expressions: [],
+    functions: [],
+    dataSources: [],
+    files
+  };
+  for (const f of files) {
+    for (const r of f.roots) {
+      if (r.kind === "ref" || r.kind === "prop" || r.kind === "expr") continue;
+      switch (r.type) {
+        case "model":
+          Object.assign(model, named(r, r.name ?? "Model"), {
+            annotations: { ...model.annotations, ...annotationsOf(r) },
+            props: r.props
+          });
+          break;
+        case "annotation":
+          if (r.name) model.annotations[r.name] = r.value ?? "";
+          break;
+        case "table":
+          buildTable(r, model);
+          break;
+        case "relationship":
+          model.relationships.push(buildRelationship(r));
+          break;
+        case "role":
+          model.roles.push(buildRole(r));
+          break;
+        case "perspective": {
+          const p = {
+            ...named(r),
+            tables: objects(r, "perspectivetable").map((t) => t.name)
+          };
+          model.perspectives.push(p);
+          break;
+        }
+        case "cultureinfo":
+          model.cultures.push(named(r));
+          break;
+        case "expression":
+          model.expressions.push({ ...named(r), expression: r.value ?? "" });
+          break;
+        case "function":
+          model.functions.push({ ...named(r), expression: r.value ?? "" });
+          break;
+        case "datasource": {
+          const ds = {
+            ...named(r),
+            kind: (r.value ?? "").trim().toLowerCase() === "provider" ? "provider" : "structured"
+          };
+          model.dataSources.push(ds);
+          break;
+        }
+        default:
+          break;
+      }
+    }
+  }
+  finalizeKinds(model);
+  return model;
+}
+
+// ../core/src/rules/microsoft-bpa/bpa-rules.data.ts
+var BPA_RULES = [
+  {
+    id: "AVOID_FLOATING_POINT_DATA_TYPES",
+    name: "[Performance] Do not use floating point data types",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'DataType = "Double"',
+    fixExpression: "DataType = DataType.Decimal",
+    description: 'The "Double" floating point data type should be avoided, as it can result in unpredictable roundoff errors and decreased performance in certain scenarios. Use "Int64" or "Decimal" where appropriate (but note that "Decimal" is limited to 4 digits after the decimal sign).'
+  },
+  {
+    id: "ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS",
+    name: "[Performance] Set IsAvailableInMdx to false on non-attribute columns",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: "IsAvailableInMDX\nand\n\n(IsHidden or Table.IsHidden)\nand\n\nnot UsedInSortBy.Any() \nand\n\nnot UsedInHierarchies.Any()\nand\nnot UsedInVariations.Any()\nand\nSortByColumn = null",
+    fixExpression: "IsAvailableInMDX = false",
+    description: "To speed up processing time and conserve memory after processing, attribute hierarchies should not be built for columns that are never used for slicing by MDX clients. In other words, all hidden columns that are not used as a Sort By Column or referenced in user hierarchies should have their IsAvailableInMdx property set to false.\nReference: https://blog.crossjoin.co.uk/2018/07/02/isavailableinmdx-ssas-tabular/"
+  },
+  {
+    id: "AVOID_BI-DIRECTIONAL_RELATIONSHIPS_AGAINST_HIGH-CARDINALITY_COLUMNS",
+    name: "[Performance] Avoid bi-directional relationships against high-cardinality columns",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'UsedInRelationships.Any(CrossFilteringBehavior == CrossFilteringBehavior.BothDirections)\n\nand\n\nConvert.ToInt64(GetAnnotation("Vertipaq_Cardinality")) > 100000',
+    description: "For best performance, it is recommended to avoid using bi-directional relationships against high-cardinality columns. In order to run this rule, you must first run the script shown here: https://www.elegantbi.com/post/vertipaqintabulareditor"
+  },
+  {
+    id: "REDUCE_USAGE_OF_LONG-LENGTH_COLUMNS_WITH_HIGH_CARDINALITY",
+    name: "[Performance] Reduce usage of long-length columns with high cardinality",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'Convert.ToInt64(GetAnnotation("LongLengthRowCount")) > 500000',
+    description: "It is best to avoid lengthy text columns. This is especially true if the column has many unique values. These types of columns can cause longer processing times, bloated model sizes, as well as slower user queries. Long length is defined as more than 100 characters."
+  },
+  {
+    id: "SPLIT_DATE_AND_TIME",
+    name: "[Performance] Split date and time",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'Convert.ToInt32(GetAnnotation("DateTimeWithHourMinSec")) > 0',
+    description: "This rule finds datetime columns that have values not at midnight. To maximize performance, the time element should be split from date element (or the time component should be rounded to midnight as this will reduce column cardinality).\nReference: https://www.sqlbi.com/articles/separate-date-and-time-in-powerpivot-and-bism-tabular/"
+  },
+  {
+    id: "LARGE_TABLES_SHOULD_BE_PARTITIONED",
+    name: "[Performance] Large tables should be partitioned",
+    category: "Performance",
+    severity: 2,
+    scope: "Table",
+    expression: 'Convert.ToInt64(GetAnnotation("Vertipaq_RowCount")) > 25000000\nand\nPartitions.Count = 1',
+    description: "Large tables should be partitioned in order to optimize processing. In order for this rule to run properly, you must run the script shown here: https://www.elegantbi.com/post/vertipaqintabulareditor"
+  },
+  {
+    id: "REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION",
+    name: "[Performance] Reduce usage of calculated columns that use the RELATED function",
+    category: "Performance",
+    severity: 2,
+    scope: "CalculatedColumn",
+    expression: 'RegEx.IsMatch(Expression,"(?i)RELATED\\s*\\(")',
+    description: "Calculated columns do not compress as well as data columns and may cause longer processing times. As such, calculated columns should be avoided if possible. One scenario where they may be easier to avoid is if they use the RELATED function.\nReference: https://www.sqlbi.com/articles/storage-differences-between-calculated-columns-and-calculated-tables/"
+  },
+  {
+    id: "SNOWFLAKE_SCHEMA_ARCHITECTURE",
+    name: "[Performance] Consider a star-schema instead of a snowflake architecture",
+    category: "Performance",
+    severity: 2,
+    scope: "Table, CalculatedTable",
+    expression: "UsedInRelationships.Any(current.Name == FromTable.Name)\nand\nUsedInRelationships.Any(current.Name == ToTable.Name)",
+    description: "Generally speaking, a star-schema is the optimal architecture for tabular models. That being the case, there are valid cases to use a snowflake approach. Please check your model and consider moving to a star-schema architecture.\nReference: https://docs.microsoft.com/power-bi/guidance/star-schema"
+  },
+  {
+    id: "MODEL_SHOULD_HAVE_A_DATE_TABLE",
+    name: "[Performance] Model should have a date table",
+    category: "Performance",
+    severity: 2,
+    scope: "Model",
+    expression: 'Tables.Any(DataCategory == "Time" && Columns.Any(IsKey == true && DataType == "DateTime")) == false',
+    description: "Generally speaking, models should generally have a date table. Models that do not have a date table generally are not taking advantage of features such as time intelligence or may not have a properly structured architecture."
+  },
+  {
+    id: "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE",
+    name: "[Performance] Date/calendar tables should be marked as a date table",
+    category: "Performance",
+    severity: 2,
+    scope: "Table, CalculatedTable",
+    expression: '(Name.ToUpper().Contains("DATE") or Name.ToUpper().Contains("CALENDAR"))\n\nand\n\n(\nDataCategory <> "Time"\n\nor\n\nColumns.Any(IsKey == true && DataType == "DateTime") == false\n)',
+    description: "This rule looks for tables that contain the words 'date' or 'calendar' as they should likely be marked as a date table.\nReference: https://docs.microsoft.com/power-bi/transform-model/desktop-date-tables"
+  },
+  {
+    id: "REMOVE_AUTO-DATE_TABLE",
+    name: "[Performance] Remove auto-date table",
+    category: "Performance",
+    severity: 2,
+    scope: "Table, CalculatedTable",
+    expression: 'ObjectTypeName == "Calculated Table"\n\nand\n\n(\nName.StartsWith("DateTableTemplate_") \n\nor \n\nName.StartsWith("LocalDateTable_")\n)',
+    description: "Avoid using auto-date tables. Make sure to turn off auto-date table in the settings in Power BI Desktop. This will save memory resources. \nReference: https://www.youtube.com/watch?v=xu3uDEHtCrg"
+  },
+  {
+    id: "AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS",
+    name: "[Performance] Avoid excessive bi-directional or many-to-many relationships",
+    category: "Performance",
+    severity: 2,
+    scope: "Model",
+    expression: '(\n\nRelationships.Where(CrossFilteringBehavior == CrossFilteringBehavior.BothDirections).Count()\n\n+\n\nRelationships.Where(FromCardinality.ToString() == "Many" && ToCardinality.ToString() == "Many").Count()\n\n)\n\n\n/\n\n\nMath.Max(Convert.ToDecimal(Relationships.Count)\n\n,1)> 0.3',
+    description: "Limit use of b-di and many-to-many relationships. This rule flags the model if more than 30% of relationships are bi-di or many-to-many.\nReference: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/"
+  },
+  {
+    id: "LIMIT_ROW_LEVEL_SECURITY_(RLS)_LOGIC",
+    name: "[Performance] Limit row level security (RLS) logic",
+    category: "Performance",
+    severity: 2,
+    scope: "Table, CalculatedTable",
+    expression: 'RowLevelSecurity.Any(RegEx.IsMatch(it.Replace(" ",""),"(?i)RIGHT\\s*\\("))\nor\nRowLevelSecurity.Any(RegEx.IsMatch(it.Replace(" ",""),"(?i)LEFT\\s*\\("))\nor\nRowLevelSecurity.Any(RegEx.IsMatch(it.Replace(" ",""),"(?i)UPPER\\s*\\("))\nor\nRowLevelSecurity.Any(RegEx.IsMatch(it.Replace(" ",""),"(?i)LOWER\\s*\\("))\nor\nRowLevelSecurity.Any(RegEx.IsMatch(it.Replace(" ",""),"(?i)FIND\\s*\\("))\n',
+    description: "Try to simplify the DAX used for row level security. Usage of the functions within this rule can likely be offloaded to the upstream systems (data warehouse)."
+  },
+  {
+    id: "MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS",
+    name: "[Performance] Consider using aggregations if using Direct Query in Power BI",
+    category: "Performance",
+    severity: 1,
+    scope: "Model",
+    expression: 'Tables.Any(ObjectTypeName == "Table (DirectQuery)")\nand\n\n\nAllColumns.Any(AlternateOf != null) == false\nand \nDefaultPowerBIDataSourceVersion.ToString() == "PowerBI_V3"',
+    description: "If using Direct Query in Power BI Premium, you may want to consider using aggregations in order to boost performance.\nReference: https://docs.microsoft.com/power-bi/transform-model/desktop-aggregations"
+  },
+  {
+    id: "MINIMIZE_POWER_QUERY_TRANSFORMATIONS",
+    name: "[Performance] Minimize Power Query transformations",
+    category: "Performance",
+    severity: 2,
+    scope: "Partition",
+    expression: '\nSourceType.ToString() = "M"\nand\n(\nQuery.Contains("Table.Combine(")\nor\n\nQuery.Contains("Table.Join(")\nor\n\nQuery.Contains("Table.NestedJoin(")\nor\nQuery.Contains("Table.AddColumn(")\nor\nQuery.Contains("Table.Group(")\nor\nQuery.Contains("Table.Sort(")\nor\nQuery.Contains("Table.Pivot(")\nor\nQuery.Contains("Table.Unpivot(")\nor\nQuery.Contains("Table.UnpivotOtherColumns(")\nor\nQuery.Contains("Table.Distinct(")\nor\nQuery.Contains("[Query=""SELECT")\nor\nQuery.Contains("Value.NativeQuery")\nor\nQuery.Contains("OleDb.Query")\nor\nQuery.Contains("Odbc.Query")\n)',
+    description: "Minimize Power Query transformations in order to improve model processing performance. It is a best practice to offload these transformations to the data warehouse if possible. Also, please check whether query folding is occurring within your model. Please reference the article below for more information on query folding.\nReference: https://docs.microsoft.com/power-query/power-query-folding"
+  },
+  {
+    id: "AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY",
+    name: "[Performance] Avoid using many-to-many relationships on tables used for dynamic row level security",
+    category: "Performance",
+    severity: 3,
+    scope: "Table",
+    expression: 'UsedInRelationships.Any(FromCardinality == "Many" and ToCardinality== "Many")\nand\nRowLevelSecurity.Any(it.Length > 0)',
+    description: "Using many-to-many relationships on tables which use dynamic row level security can cause serious query performance degradation. This pattern's performance problems compound when snowflaking multiple many-to-many relationships against a table which contains row level security. Instead, use one of the patterns shown in the article below where a single dimension table relates many-to-one to a security table.\n\nReference: https://www.elegantbi.com/post/dynamicrlspatterns"
+  },
+  {
+    id: "UNPIVOT_PIVOTED_(MONTH)_DATA",
+    name: "[Performance] Unpivot pivoted (month) data",
+    category: "Performance",
+    severity: 2,
+    scope: "Table, CalculatedTable",
+    expression: 'Columns.Any(Name.ToUpper().Contains("JAN") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))\nand\nColumns.Any(Name.ToUpper().Contains("FEB") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))\nand\nColumns.Any(Name.ToUpper().Contains("MAR") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))\nand\nColumns.Any(Name.ToUpper().Contains("APR") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))\nand\nColumns.Any(Name.ToUpper().Contains("MAY") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))\nand\nColumns.Any(Name.ToUpper().Contains("JUN") && (DataType == DataType.Int64 || DataType == DataType.Decimal || DataType == DataType.Double))',
+    description: "Avoid using pivoted data in your tables. This rule checks specifically for pivoted data by month.\nReference: https://www.elegantbi.com/post/top10bestpractices"
+  },
+  {
+    id: "MANY-TO-MANY_RELATIONSHIPS_SHOULD_BE_SINGLE-DIRECTION",
+    name: "[Performance] Many-to-many relationships should be single-direction",
+    category: "Performance",
+    severity: 2,
+    scope: "Relationship",
+    expression: 'FromCardinality == "Many"\n\nand\n\nToCardinality == "Many"\n\nand\n\nCrossFilteringBehavior == "BothDirections"',
+    description: ""
+  },
+  {
+    id: "REDUCE_USAGE_OF_CALCULATED_TABLES",
+    name: "[Performance] Reduce usage of calculated tables",
+    category: "Performance",
+    severity: 2,
+    scope: "CalculatedTable",
+    expression: "1=1",
+    description: "Migrate calculated table logic to your data warehouse. Reliance on calculated tables will lead to technical debt and potential misalignments if you have multiple models on your platform."
+  },
+  {
+    id: "REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES",
+    name: "[Performance] Remove redundant columns in related tables",
+    category: "Performance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: "UsedInRelationships.Any() == false \nand\nModel.AllColumns.Any(Name == current.Name and Table.Name != current.Table.Name and Table.UsedInRelationships.Any(FromTable.Name == current.Table.Name))",
+    description: "Removing unnecessary columns reduces model size and speeds up data loading."
+  },
+  {
+    id: "MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY",
+    name: "[Performance] Measures using time intelligence and model is using Direct Query",
+    category: "Performance",
+    severity: 2,
+    scope: "Measure, CalculationItem",
+    expression: 'Model.Tables.Any(ObjectTypeName == "Table (DirectQuery)")\nand\n(\nRegEx.IsMatch(Expression,"CLOSINGBALANCEMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"CLOSINGBALANCEQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"CLOSINGBALANCEYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATEADD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATESBETWEEN\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATESINPERIOD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATESMTD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATESQTD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"DATESYTD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"ENDOFMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"ENDOFQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"ENDOFYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"FIRSTDATE\\s*\\(")\nor\nRegEx.IsMatch(Expression,"FIRSTNONBLANK\\s*\\(")\nor\nRegEx.IsMatch(Expression,"FIRSTNONBLANKVALUE\\s*\\(")\nor\nRegEx.IsMatch(Expression,"LASTDATE\\s*\\(")\nor\nRegEx.IsMatch(Expression,"LASTNONBLANK\\s*\\(")\nor\nRegEx.IsMatch(Expression,"LASTNONBLANKVALUE\\s*\\(")\nor\nRegEx.IsMatch(Expression,"NEXTDAY\\s*\\(")\nor\nRegEx.IsMatch(Expression,"NEXTMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"NEXTQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"NEXTYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"OPENINGBALANCEMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"OPENINGBALANCEQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"OPENINGBALANCEYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"PARALLELPERIOD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"PREVIOUSDAY\\s*\\(")\nor\nRegEx.IsMatch(Expression,"PREVIOUSMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"PREVIOUSQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"PREVIOUSYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"SAMEPERIODLASTYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"STARTOFMONTH\\s*\\(")\nor\nRegEx.IsMatch(Expression,"STARTOFQUARTER\\s*\\(")\nor\nRegEx.IsMatch(Expression,"STARTOFYEAR\\s*\\(")\nor\nRegEx.IsMatch(Expression,"TOTALMTD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"TOTALQTD\\s*\\(")\nor\nRegEx.IsMatch(Expression,"TOTALYTD\\s*\\(")\n)',
+    description: "At present, time intelligence functions are known to not perform as well when using Direct Query. If you are having performance issues, you may want to try alternative solutions such as adding columns in the fact table that show previous year or previous month data."
+  },
+  {
+    id: "REDUCE_NUMBER_OF_CALCULATED_COLUMNS",
+    name: "[Performance] Reduce number of calculated columns",
+    category: "Performance",
+    severity: 2,
+    scope: "Model",
+    expression: 'AllColumns.Where(Type.ToString() == "Calculated").Count() > 5',
+    description: "Calculated columns do not compress as well as data columns so they take up more memory. They also slow down processing times for both the table as well as process recalc. Offload calculated column logic to your data warehouse and turn these calculated columns into data columns.\nReference: https://www.elegantbi.com/post/top10bestpractices"
+  },
+  {
+    id: "CHECK_IF_BI-DIRECTIONAL_AND_MANY-TO-MANY_RELATIONSHIPS_ARE_VALID",
+    name: "[Performance] Check if bi-directional and many-to-many relationships are valid",
+    category: "Performance",
+    severity: 1,
+    scope: "Relationship",
+    expression: 'FromCardinality.ToString() = "Many" and ToCardinality.ToString() = "Many"\nor\nCrossFilteringBehavior == CrossFilteringBehavior.BothDirections',
+    description: "Bi-directional and many-to-many relationships may cause performance degradation or even have unintended consequences. Make sure to check these specific relationships to ensure they are working as designed and are actually necessary.\nReference: https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/"
+  },
+  {
+    id: "CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_(RLS)_IS_NECESSARY",
+    name: "[Performance] Check if dynamic row level security (RLS) is necessary",
+    category: "Performance",
+    severity: 1,
+    scope: "TablePermission",
+    expression: 'RegEx.IsMatch(Expression,"(?i)USERNAME\\(")\nor\nRegEx.IsMatch(Expression,"(?i)USERPRINCIPALNAME\\(")',
+    description: "Usage of dynamic row level security (RLS) can add memory and performance overhead. Please research the pros/cons of using it.\nReference: https://docs.microsoft.com/power-bi/admin/service-admin-rls"
+  },
+  {
+    id: "DAX_COLUMNS_FULLY_QUALIFIED",
+    name: "[DAX Expressions] Column references should be fully qualified",
+    category: "DAX Expressions",
+    severity: 3,
+    scope: "Measure, KPI, TablePermission, CalculationItem",
+    expression: 'DependsOn.Any(Key.ObjectType = "Column" and Value.Any(not FullyQualified))',
+    description: "Using fully qualified column references makes it easier to distinguish between column and measure references, and also helps avoid certain errors. When referencing a column in DAX, first specify the table name, then specify the column name in square brackets.\nReference: https://www.elegantbi.com/post/top10bestpractices"
+  },
+  {
+    id: "DAX_MEASURES_UNQUALIFIED",
+    name: "[DAX Expressions] Measure references should be unqualified",
+    category: "DAX Expressions",
+    severity: 3,
+    scope: "Measure, CalculatedColumn, CalculatedTable, KPI, CalculationItem",
+    expression: 'DependsOn.Any(Key.ObjectType = "Measure" and Value.Any(FullyQualified))',
+    description: "Using unqualified measure references makes it easier to distinguish between column and measure references, and also helps avoid certain errors. When referencing a measure using DAX, do not specify the table name. Use only the measure name in square brackets.\nReference: https://www.elegantbi.com/post/top10bestpractices"
+  },
+  {
+    id: "AVOID_DUPLICATE_MEASURES",
+    name: "[DAX Expressions] No two measures should have the same definition",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure",
+    expression: 'Model.AllMeasures.Any(Expression.Replace(" ","").Replace("\\n","").Replace("\\r","").Replace("\\t","") = outerIt.Expression.Replace(" ","").Replace("\\n","").Replace("\\r","").Replace("\\t","") and it <> outerIt)',
+    description: "Two measures with different names and defined by the same DAX expression should be avoided to reduce redundancy."
+  },
+  {
+    id: "USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT",
+    name: "[DAX Expressions] Use the TREATAS function instead of INTERSECT for virtual relationships",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculationItem",
+    expression: 'RegEx.IsMatch(Expression,"(?i)INTERSECT\\s*\\(")',
+    description: "The TREATAS function is more efficient and provides better performance than the INTERSECT function when used in virutal relationships.\nReference:  https://www.sqlbi.com/articles/propagate-filters-using-treatas-in-dax/"
+  },
+  {
+    id: "USE_THE_DIVIDE_FUNCTION_FOR_DIVISION",
+    name: "[DAX Expressions] Use the DIVIDE function for division",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculatedColumn, CalculationItem",
+    expression: 'RegEx.IsMatch(Expression,"\\]\\s*\\/(?!\\/)(?!\\*)")\nor\nRegEx.IsMatch(Expression,"\\)\\s*\\/(?!\\/)(?!\\*)")',
+    description: 'Use the DIVIDE  function instead of using "/". The DIVIDE function resolves divide-by-zero cases. As such, it is recommended to use to avoid errors.\n\nReference: https://docs.microsoft.com/power-bi/guidance/dax-divide-function-operator'
+  },
+  {
+    id: "AVOID_USING_THE_IFERROR_FUNCTION",
+    name: "[DAX Expressions] Avoid using the IFERROR function",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculatedColumn",
+    expression: 'RegEx.IsMatch(Expression,"(?i)IFERROR\\s*\\(")',
+    description: "Avoid using the IFERROR function as it may cause performance degradation. If you are concerned about a divide-by-zero error, use the DIVIDE function as it naturally resolves such errors as blank (or you can customize what should be shown in case of such an error).\nReference: https://www.elegantbi.com/post/top10bestpractices"
+  },
+  {
+    id: "MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES",
+    name: "[DAX Expressions] Measures should not be direct references of other measures",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure",
+    expression: "Model.AllMeasures.Any(DaxObjectName == current.Expression)",
+    description: "This rule identifies measures which are simply a reference to another measure. As an example, consider a model with two measures: [MeasureA] and [MeasureB]. This rule would be triggered for MeasureB if MeasureB's DAX was MeasureB:=[MeasureA]. Such duplicative measures should be removed."
+  },
+  {
+    id: "FILTER_COLUMN_VALUES",
+    name: "[DAX Expressions] Filter column values with proper syntax",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculatedColumn, CalculationItem",
+    expression: `RegEx.IsMatch(Expression,"(?i)CALCULATE\\s*\\(\\s*[^,]+,\\s*(?i)FILTER\\s*\\(\\s*\\'*[A-Za-z0-9 _]+'*\\s*,\\s*\\'*[A-Za-z0-9 _]+\\'*\\[[A-Za-z0-9 _]+\\]")
+or
+RegEx.IsMatch(Expression,"(?i)CALCULATETABLE\\s*\\([^,]*,\\s*(?i)FILTER\\s*\\(\\s*\\'*[A-Za-z0-9 _]+\\'*,\\s*\\'*[A-Za-z0-9 _]+\\'*\\[[A-Za-z0-9 _]+\\]")`,
+    description: `Instead of using this pattern FILTER('Table','Table'[Column]="Value") for the filter parameters of a CALCULATE or CALCULATETABLE function, use one of the options below. As far as whether to use the KEEPFILTERS function, see the second reference link below.
+
+Option 1: KEEPFILTERS('Table'[Column]="Value")
+Option 2: 'Table'[Column]="Value"
+
+Reference: https://docs.microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument
+Reference: https://www.sqlbi.com/articles/using-keepfilters-in-dax/`
+  },
+  {
+    id: "FILTER_MEASURE_VALUES_BY_COLUMNS",
+    name: "[DAX Expressions] Filter measure values by columns, not tables",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculatedColumn, CalculationItem",
+    expression: `RegEx.IsMatch(Expression,"(?i)CALCULATE\\s*\\(\\s*[^,]+,\\s*(?i)FILTER\\s*\\(\\s*\\'*[A-Za-z0-9 _]+\\'*\\s*,\\s*\\[[^\\]]+\\]")
+or
+RegEx.IsMatch(Expression,"(?i)CALCULATETABLE\\s*\\([^,]*,\\s*(?i)FILTER\\s*\\(\\s*\\'*[A-Za-z0-9 _]+\\'*,\\s*\\[")`,
+    description: "Instead of using this pattern FILTER('Table',[Measure]>Value) for the filter parameters of a CALCULATE or CALCULATETABLE function, use one of the options below (if possible). Filtering on a specific column will produce a smaller table for the engine to process, thereby enabling faster performance. Using the VALUES function or the ALL function depends on the desired measure result.\n\nOption 1: FILTER(VALUES('Table'[Column]),[Measure] > Value)\nOption 2: FILTER(ALL('Table'[Column]),[Measure] > Value)\n\nReference: https://docs.microsoft.com/power-bi/guidance/dax-avoid-avoid-filter-as-filter-argument"
+  },
+  {
+    id: "INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED",
+    name: "[DAX Expressions] Inactive relationships that are never activated",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Relationship",
+    expression: `IsActive == false
+and not
+(
+Model.AllMeasures.Any(RegEx.IsMatch(Expression,
+"(?i)USERELATIONSHIP\\s*\\(\\s*\\'*" +
+current.FromTable.Name + "\\'*\\[" + 
+current.FromColumn.Name + "\\]\\s*,\\s*\\'*" +
+current.ToTable.Name + "\\'*\\[" +
+current.ToColumn.Name + "\\]"))
+or
+Model.AllCalculationItems.Any(RegEx.IsMatch(Expression,
+"(?i)USERELATIONSHIP\\s*\\(\\s*\\'*" +
+current.FromTable.Name + "\\'*\\[" + 
+current.FromColumn.Name + "\\]\\s*,\\s*\\'*" +
+current.ToTable.Name + "\\'*\\[" +
+current.ToColumn.Name + "\\]"))
+)`,
+    description: "Inactive relationships are activated using the USERELATIONSHIP function. If an inactive relationship is not referenced in any measure via this function, the relationship will not be used. It should be determined whether the relationship is not necessary or to activate the relationship via this method.\n\nReference: https://docs.microsoft.com/power-bi/guidance/relationships-active-inactive\nReference: https://dax.guide/userelationship/"
+  },
+  {
+    id: "AVOID_USING_'1-(X/Y)'_SYNTAX",
+    name: "[DAX Expressions] Avoid using '1-(x/y)' syntax",
+    category: "DAX Expressions",
+    severity: 2,
+    scope: "Measure, CalculatedColumn, CalculationItem",
+    expression: `RegEx.IsMatch(Expression,"[0-9]+\\s*[-+]\\s*[\\(]*\\s*(?i)SUM\\s*\\(\\s*\\'*[A-Za-z0-9 _]+\\'*\\s*\\[[A-Za-z0-9 _]+\\]\\s*\\)\\s*\\/")
+or
+RegEx.IsMatch(Expression,"[0-9]+\\s*[-+]\\s*(?i)DIVIDE\\s*\\(")`,
+    description: "Instead of using the '1-(x/y)' or '1+(x/y)' syntax to achieve a percentage calculation, use the basic DAX functions (as shown below). Using the improved syntax will generally improve the performance. The '1+/-...' syntax always returns a value whereas the solution without the '1+/-...' does not (as the value may be 'blank'). Therefore the '1+/-...' syntax may return more rows/columns which may result in a slower query speed.\n\nLet's clarify with an example:\n\nAvoid this: 1 - SUM ( 'Sales'[CostAmount] ) / SUM( 'Sales'[SalesAmount] )\nBetter: DIVIDE ( SUM ( 'Sales'[SalesAmount] ) - SUM ( 'Sales'[CostAmount] ), SUM ( 'Sales'[SalesAmount] ) )\nBest: VAR x = SUM ( 'Sales'[SalesAmount] ) RETURN DIVIDE ( x - SUM ( 'Sales'[CostAmount] ), x )"
+  },
+  {
+    id: "EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS",
+    name: "[DAX Expressions] The EVALUATEANDLOG function should not be used in production models",
+    category: "DAX Expressions",
+    severity: 1,
+    scope: "Measure",
+    expression: 'RegEx.IsMatch(Expression,"(?i)EVALUATEANDLOG\\s*\\(")',
+    description: "The EVALUATEANDLOG function is meant to be used only in development/test environments and should not be used in production models.\n\nReference: https://pbidax.wordpress.com/2022/08/16/introduce-the-dax-evaluateandlog-function/"
+  },
+  {
+    id: "DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN",
+    name: "[Error Prevention] Data columns must have a source column",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "DataColumn",
+    expression: "string.IsNullOrWhitespace(SourceColumn)",
+    description: "Data columns must have a source column. A data column without a source column will cause an error when processing the model."
+  },
+  {
+    id: "EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION",
+    name: "[Error Prevention] Expression-reliant objects must have an expression",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "Measure, CalculatedColumn, CalculationItem",
+    expression: "string.IsNullOrWhiteSpace(Expression)",
+    description: "Calculated columns, calculation items and measures must have an expression. Without an expression, these objects will not show any values."
+  },
+  {
+    id: "AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS",
+    name: "[Error Prevention] Avoid structured data sources with provider partitions",
+    category: "Error Prevention",
+    severity: 2,
+    scope: "Partition",
+    expression: 'SourceType == "Query"\nand\nDataSource.Type == "Structured"',
+    description: "Power BI does not support provider (a.k.a. 'legacy') partitions which reference structured data sources. Partitions which reference structured data sources must use the M-language. Otherwise, 'provider' partitions must reference a 'provider' data source. This can be resolved by converting the structured data source into a provider data source (see 2nd reference link below).\n\nReference: https://docs.microsoft.com/power-bi/admin/service-premium-connect-tools#data-source-declaration\nReference: https://www.elegantbi.com/post/convertdatasources"
+  },
+  {
+    id: "AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE",
+    name: "[Error Prevention] Avoid the USERELATIONSHIP function and RLS against the same table",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "Table, CalculatedTable",
+    expression: `Model.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)USERELATIONSHIP\\s*\\(\\s*.+?(?=])\\]\\s*,\\s*'*" + current.Name + "'*\\["))
+and
+RowLevelSecurity.Any(it <> null)`,
+    description: "The USERELATIONSHIP function may not be used against a table which also leverages row-level security (RLS). This will generate an error when using the particular measure in a visual. This rule will highlight the table which is used in a measure's USERELATIONSHIP function as well as RLS.\n\nReference: https://blog.crossjoin.co.uk/2013/05/10/userelationship-and-tabular-row-security/"
+  },
+  {
+    id: "RELATIONSHIP_COLUMNS_SAME_DATA_TYPE",
+    name: "[Error Prevention] Relationship columns should be of the same data type",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "Relationship",
+    expression: "FromColumn.DataType != ToColumn.DataType",
+    description: "Columns used in a relationship should be of the same data type. Ideally, they will be of integer data type (see the related rule '[Formatting] Relationship columns should be of integer data type'). Having columns within a relationship which are of different data types may lead to various issues."
+  },
+  {
+    id: "AVOID_INVALID_NAME_CHARACTERS",
+    name: "[Error Prevention] Avoid invalid characters in names",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "Table, Measure, Hierarchy, Level, Perspective, Partition, DataColumn, CalculatedColumn, CalculatedTable, CalculatedTableColumn, KPI, ModelRole, CalculationGroup, CalculationItem",
+    expression: "Name.ToCharArray().Any(char.IsControl(it) and !char.IsWhiteSpace(it))",
+    fixExpression: "Name = string.Concat( it.Name.ToCharArray().Select( c => (char.IsControl(c) && !char.IsWhiteSpace(c)) ? ' ': c ))",
+    description: "This rule identifies if a name for a given object in your model (i.e. table/column/measure) which contains an invalid character. Invalid characters will cause an error when deploying the model (and failure to deploy). This rule has a fix expression which converts the invalid character into a space, resolving the issue."
+  },
+  {
+    id: "AVOID_INVALID_DESCRIPTION_CHARACTERS",
+    name: "[Error Prevention] Avoid invalid characters in descriptions",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "Table, Measure, Hierarchy, Level, Perspective, Partition, DataColumn, CalculatedColumn, CalculatedTable, CalculatedTableColumn, KPI, ModelRole, CalculationGroup, CalculationItem",
+    expression: "Description.ToCharArray().Any(char.IsControl(it) and !char.IsWhiteSpace(it))",
+    fixExpression: "Description = string.Concat( it.Description.ToCharArray().Select( c => (char.IsControl(c) && !char.IsWhiteSpace(c)) ? ' ': c ))",
+    description: "This rule identifies if a description for a given object in your model (i.e. table/column/measure) which contains an invalid character. Invalid characters will cause an error when deploying the model (and failure to deploy). This rule has a fix expression which converts the invalid character into a space, resolving the issue."
+  },
+  {
+    id: "SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS",
+    name: "[Error Prevention] Set IsAvailableInMdx to true on necessary columns",
+    category: "Error Prevention",
+    severity: 3,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: "IsAvailableInMDX = false\n\nand\n(\nUsedInSortBy.Any()\nor\nUsedInHierarchies.Any()\nor\nUsedInVariations.Any()\nor\nSortByColumn != null\n)",
+    fixExpression: "IsAvailableInMDX = true",
+    description: "In order to avoid errors, ensure that attribute hierarchies are enabled if a column is used for sorting another column, used in a hierarchy, used in variations, or is sorted by another column."
+  },
+  {
+    id: "UNNECESSARY_COLUMNS",
+    name: "[Maintenance] Remove unnecessary columns",
+    category: "Maintenance",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: `(IsHidden or Table.IsHidden)
+
+
+and ReferencedBy.Count = 0
+
+
+and (not UsedInRelationships.Any())
+
+
+and (not UsedInSortBy.Any())
+
+
+and (not UsedInHierarchies.Any())
+
+
+and (not Table.RowLevelSecurity.Any(
+it <> null and it.IndexOf("[" + current.Name + "]", "OrdinalIgnoreCase") >= 0
+))
+
+ and (not Model.Roles.Any(RowLevelSecurity.Any(
+it <> null and 
+(
+it.IndexOf(current.Table.Name + "[" + current.Name + "]", "OrdinalIgnoreCase") >= 0 or
+ it.IndexOf("'" + current.Table.Name + "'[" + current.Name + "]", "OrdinalIgnoreCase") >= 0
+ )
+)))
+and not (
+ObjectLevelSecurity.Any(it.ToString() == "None"))
+and not (
+Table.ObjectLevelSecurity.Any(it.ToString() == "None"))`,
+    fixExpression: "Delete()",
+    description: "Hidden columns that are not referenced by any DAX expressions, relationships, hierarchy levels or Sort By-properties should be removed."
+  },
+  {
+    id: "UNNECESSARY_MEASURES",
+    name: "[Maintenance] Remove unnecessary measures",
+    category: "Maintenance",
+    severity: 2,
+    scope: "Measure",
+    expression: "(Table.IsHidden or IsHidden) \nand ReferencedBy.Count = 0",
+    fixExpression: "Delete()",
+    description: "Hidden measures that are not referenced by any DAX expressions should be removed for maintainability"
+  },
+  {
+    id: "FIX_REFERENTIAL_INTEGRITY_VIOLATIONS",
+    name: "[Maintenance] Fix referential integrity violations",
+    category: "Maintenance",
+    severity: 2,
+    scope: "Relationship",
+    expression: 'Convert.ToInt64(GetAnnotation("Vertipaq_RIViolationInvalidRows")) > 0',
+    description: "This rule highlights relationships which have referential integrity violations. This indicates that there are values in the table on the 'from' side of the relationship which do not exist in the table on the 'to' side of the relationship. Referential integrity violations will also produce the 'blank' member value in slicers. It is recommended to fix these issues by ensuring that the 'to' table's primary key column has all the values in the 'from' table's foreign key column.\n\nReference: https://blog.enterprisedna.co/vertipaq-analyzer-tutorial-relationships-referential-integrity/"
+  },
+  {
+    id: "REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS",
+    name: "[Maintenance] Remove data sources not referenced by any partitions",
+    category: "Maintenance",
+    severity: 1,
+    scope: "ProviderDataSource, StructuredDataSource",
+    expression: "UsedByPartitions.Count() == 0\nand not Model.Tables.Any(SourceExpression.Contains(OuterIt.Name))\nand not Model.AllPartitions.Any(Query.Contains(OuterIt.Name))",
+    fixExpression: "Delete()",
+    description: "Data sources which are not referenced by any partitions may be removed."
+  },
+  {
+    id: "REMOVE_ROLES_WITH_NO_MEMBERS",
+    name: "[Maintenance] Remove roles with no members",
+    category: "Maintenance",
+    severity: 1,
+    scope: "ModelRole",
+    expression: "Members.Count() == 0",
+    fixExpression: "Delete()",
+    description: "May remove roles with no members."
+  },
+  {
+    id: "ENSURE_TABLES_HAVE_RELATIONSHIPS",
+    name: "[Maintenance] Ensure tables have relationships",
+    category: "Maintenance",
+    severity: 1,
+    scope: "Table, CalculatedTable",
+    expression: "UsedInRelationships.Count() == 0",
+    description: "This rule highlights tables which are not connected to any other table in the model with a relationship."
+  },
+  {
+    id: "OBJECTS_WITH_NO_DESCRIPTION",
+    name: "[Maintenance] Visible objects with no description",
+    category: "Maintenance",
+    severity: 1,
+    scope: "Table, Measure, DataColumn, CalculatedColumn, CalculatedTable, CalculatedTableColumn, CalculationGroup",
+    expression: "string.IsNullOrWhitespace(Description)\nand\nIsHidden == false",
+    description: "Add descriptions to objects. These descriptions are shown on hover within the Field List in Power BI Desktop. Additionally, you can leverage these descriptions to create an automated data dictionary (see link below).\nReference: https://www.elegantbi.com/post/datadictionary"
+  },
+  {
+    id: "PERSPECTIVES_WITH_NO_OBJECTS",
+    name: "[Maintenance] Perspectives with no objects",
+    category: "Maintenance",
+    severity: 1,
+    scope: "Perspective",
+    expression: "Model.Tables.Any(InPerspective[current.Name]) == false",
+    fixExpression: "Delete()",
+    description: "Perspectives that contain no objects (tables) are most likely not necessary. In this rule, it is only necessary to check tables as adding a column/measure/hierarchy to a perspective also adds the table to the perspective. Additionally, tables in general covers calculated tables and calculation groups as well."
+  },
+  {
+    id: "CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS",
+    name: "[Maintenance] Calculation groups with no calculation items",
+    category: "Maintenance",
+    severity: 2,
+    scope: "CalculationGroup",
+    expression: "CalculationItems.Count == 0",
+    description: "Calculation groups have no function unless they have calculation items."
+  },
+  {
+    id: "PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES",
+    name: "[Naming Conventions] Partition name should match table name for single partition tables",
+    category: "Naming Conventions",
+    severity: 1,
+    scope: "Table",
+    expression: "(Partitions.Count = 1 and Partitions[0].Name <> Name)",
+    fixExpression: "Partitions[0].Name = it.Name",
+    description: "Tables with just one partition should match their table and partition names.Tables with more than one partition should have each partition name starting with the table name."
+  },
+  {
+    id: "SPECIAL_CHARS_IN_OBJECT_NAMES",
+    name: "[Naming Conventions] Object names must not contain special characters",
+    category: "Naming Conventions",
+    severity: 2,
+    scope: "Model, Table, Measure, Hierarchy, Perspective, Partition, DataColumn, CalculatedColumn, CalculatedTable, CalculatedTableColumn, CalculationGroup, CalculationItem",
+    expression: "Name.IndexOf(char(9)) > -1\nor\n\nName.IndexOf(char(10)) > -1 \nor\n\nName.IndexOf(char(13)) > -1",
+    description: "Tabs, line breaks, etc."
+  },
+  {
+    id: "TRIM_OBJECT_NAMES",
+    name: "[Naming Conventions] Trim object names",
+    category: "Naming Conventions",
+    severity: 1,
+    scope: "Model, Table, Measure, Hierarchy, Level, Perspective, Partition, ProviderDataSource, DataColumn, CalculatedColumn, CalculatedTable, CalculatedTableColumn, StructuredDataSource, NamedExpression, ModelRole, CalculationGroup, CalculationItem",
+    expression: 'Name.StartsWith(" ") or Name.EndsWith(" ")',
+    description: "Unintentionally leaving a trailing space in an object name is a common occurrence when copying/duplicating objects in Tabular Editor."
+  },
+  {
+    id: "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS",
+    name: "[Formatting] Format flag columns as Yes/No value strings",
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: '(\nName.StartsWith("Is") and \nDataType = "Int64" and \nnot (IsHidden or Table.IsHidden)\n) \nor\n\n(\nName.EndsWith(" Flag") and \nDataType <> "String" and \nnot (IsHidden or Table.IsHidden)\n)',
+    description: "Flags must be properly formatted as Yes/No as this is easier to read than using 0/1 integer values."
+  },
+  {
+    id: "OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE",
+    name: "[Formatting] Objects should not start or end with a space",
+    category: "Formatting",
+    severity: 3,
+    scope: "Model, Table, Measure, Hierarchy, Perspective, Partition, DataColumn, CalculatedColumn",
+    expression: 'Name.StartsWith(" ") or Name.EndsWith(" ")',
+    description: "Objects should not start or end with a space"
+  },
+  {
+    id: "DATECOLUMN_FORMATSTRING",
+    name: '[Formatting] Provide format string for "Date" columns',
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'Name.IndexOf("Date", "OrdinalIgnoreCase") >= 0 \nand \nDataType = "DateTime" \nand \nFormatString <> "mm/dd/yyyy"',
+    fixExpression: 'FormatString = "mm/dd/yyyy"',
+    description: 'Columns of type "DateTime" that have "Month" in their names should be formatted as "mm/dd/yyyy".'
+  },
+  {
+    id: "MONTHCOLUMN_FORMATSTRING",
+    name: '[Formatting] Provide format string for "Month" columns',
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'Name.IndexOf("Month", "OrdinalIgnoreCase") >= 0 and DataType = "DateTime" and FormatString <> "MMMM yyyy"',
+    fixExpression: 'FormatString = "MMMM yyyy"',
+    description: 'Columns of type "DateTime" that have "Month" in their names should be formatted as "MMMM yyyy".'
+  },
+  {
+    id: "PROVIDE_FORMAT_STRING_FOR_MEASURES",
+    name: "[Formatting] Provide format string for measures",
+    category: "Formatting",
+    severity: 3,
+    scope: "Measure",
+    expression: "not IsHidden \nand not Table.IsHidden \nand string.IsNullOrWhitespace(FormatString) \nand string.IsNullOrWhitespace(FormatStringExpression)\n    ",
+    description: "Visible measures should have their format string property assigned"
+  },
+  {
+    id: "NUMERIC_COLUMN_SUMMARIZE_BY",
+    name: "[Formatting] Do not summarize numeric columns",
+    category: "Formatting",
+    severity: 3,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: '(\nDataType = "Int64"\nor \nDataType="Decimal" \nor \nDataType="Double"\n)\n\nand \nSummarizeBy <> "None"\n\nand not (IsHidden or Table.IsHidden)',
+    fixExpression: "SummarizeBy = AggregateFunction.None",
+    description: 'Numeric columns (integer, decimal, double) should have their SummarizeBy property set to "None" to avoid accidental summation in Power BI (create measures instead).'
+  },
+  {
+    id: "PERCENTAGE_FORMATTING",
+    name: "[Formatting] Percentages should be formatted with thousands separators and 1 decimal",
+    category: "Formatting",
+    severity: 2,
+    scope: "Measure",
+    expression: 'FormatString.Contains("%") and FormatString <> "#,0.0%;-#,0.0%;#,0.0%"',
+    fixExpression: 'FormatString = "#,0.0%\\u003B-#,0.0%\\u003B#,0.0%"',
+    description: ""
+  },
+  {
+    id: "INTEGER_FORMATTING",
+    name: "[Formatting] Whole numbers should be formatted with thousands separators and no decimals",
+    category: "Formatting",
+    severity: 2,
+    scope: "Measure",
+    expression: 'not FormatString.Contains("$") and not FormatString.Contains("%") and not (FormatString = "#,0" or FormatString = "#,0.0")',
+    fixExpression: 'FormatString = "#,0"',
+    description: ""
+  },
+  {
+    id: "RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE",
+    name: "[Formatting] Relationship columns should be of integer data type",
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: "UsedInRelationships.Any()\n\nand \n\nDataType != DataType.Int64",
+    description: "It is a best practice for relationship columns to be of integer data type. This applies not only to data warehousing but data modeling as well."
+  },
+  {
+    id: "ADD_DATA_CATEGORY_FOR_COLUMNS",
+    name: "[Formatting] Add data category for columns",
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'string.IsNullOrWhiteSpace(DataCategory)\n&&\n(\n    (\n        (\n            Name.ToLower().Contains("country")\n            || Name.ToLower().Contains("continent")\n            || Name.ToLower().Contains("city")\n        )\n        && DataType == DataType.String\n    )\n    ||\n    (\n        (\n            Name.ToLower() == "latitude"\n            || Name.ToLower() == "longitude"\n        )\n        &&\n        (\n            DataType == DataType.Decimal\n            || DataType == DataType.Double\n        )\n    )\n)\n',
+    description: "Add Data Category property for appropriate columns.\n\nReference: https://docs.microsoft.com/power-bi/transform-model/desktop-data-categorization"
+  },
+  {
+    id: "HIDE_FOREIGN_KEYS",
+    name: "[Formatting] Hide foreign keys",
+    category: "Formatting",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'UsedInRelationships.Any(FromColumn.Name == current.Name and FromCardinality == "Many")\n\nand\n\nIsHidden == false',
+    fixExpression: "IsHidden = true",
+    description: "Foreign keys should always be hidden."
+  },
+  {
+    id: "MARK_PRIMARY_KEYS",
+    name: "[Formatting] Mark primary keys",
+    category: "Formatting",
+    severity: 1,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'UsedInRelationships.Any(ToTable.Name == current.Table.Name and ToColumn.Name == current.Name and ToCardinality == "One")\n\nand\n\nIsKey == false\nand\ncurrent.Table.DataCategory != "Time"',
+    fixExpression: "IsKey = true",
+    description: "Set the 'Key' property to 'True' for primary key columns within the column properties."
+  },
+  {
+    id: "HIDE_FACT_TABLE_COLUMNS",
+    name: "[Formatting] Hide fact table columns",
+    category: "Formatting",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: `(
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)COUNT\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)COUNTBLANK\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)SUM\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)AVERAGE\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)VALUES\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)DISTINCT\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)DISTINCTCOUNT\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)MIN\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)MAX\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)COUNTA\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)AVERAGEA\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)MAXA\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+
+or
+ReferencedBy.AllMeasures.Any(RegEx.IsMatch(Expression,"(?i)MINA\\s*\\(\\s*\\'*" + outerit.Table.Name + "\\'*\\[" + outerit.Name + "\\]\\s*\\)"))
+)
+
+and IsHidden == false
+
+and (DataType == "Int64" || DataType == "Decimal" || DataType == "Double")`,
+    fixExpression: "IsHidden = true",
+    description: "It is a best practice to hide fact table columns that are used for aggregation in measures."
+  },
+  {
+    id: "FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED",
+    name: "[Formatting] First letter of objects must be capitalized",
+    category: "Formatting",
+    severity: 1,
+    scope: "Table, Measure, Hierarchy, CalculatedColumn, CalculatedTable, CalculatedTableColumn, CalculationGroup",
+    expression: "Name.Substring(0,1).ToUpper() != Name.Substring(0,1)",
+    description: ""
+  },
+  {
+    id: "MONTH_(AS_A_STRING)_MUST_BE_SORTED",
+    name: "[Formatting] Month (as a string) must be sorted",
+    category: "Formatting",
+    severity: 2,
+    scope: "DataColumn, CalculatedColumn, CalculatedTableColumn",
+    expression: 'Name.ToUpper().Contains("MONTH")\nand\n! Name.ToUpper().Contains("MONTHS") \nand \n\n\nDataType == DataType.String \nand \nSortByColumn == null',
+    description: "This rule highlights month columns which are strings and are not sorted. If left unsorted, they will sort alphabetically (i.e. April, August...). Make sure to sort such columns so that they sort properly (January, February, March...)."
+  }
+];
+
+// ../core/src/model/names.ts
+var tableRef = (name) => `'${name.replace(/'/g, "''")}'`;
+var bracket = (name) => `[${name.replace(/\]/g, "]]")}]`;
+var columnRef = (table, column) => `${tableRef(table)}${bracket(column)}`;
+var measureRef = (name) => bracket(name);
+var cardinalitySymbol = (c) => c === "many" ? "\u221E" : c === "one" ? "1" : "?";
+function relationshipName(r) {
+  const arrow = r.crossFilteringBehavior === "bothdirections" ? "\u2194" : "\u2190";
+  return `${columnRef(r.fromTable, r.fromColumn)} ${cardinalitySymbol(r.fromCardinality)}${arrow}${cardinalitySymbol(r.toCardinality)} ${columnRef(r.toTable, r.toColumn)}`;
+}
+function slug(id) {
+  return id.toLowerCase().replace(/[^a-z0-9]+/g, "-").replace(/^-+|-+$/g, "");
+}
+var RULE_URL_BASE = "https://pbiplint.com/rules/";
+var ruleUrl = (id) => RULE_URL_BASE + slug(id);
+
+// ../core/src/rules/helpers.ts
+var allColumns = (m) => m.tables.flatMap((t) => t.columns);
+var allMeasures = (m) => m.tables.flatMap((t) => t.measures);
+var allPartitions = (m) => m.tables.flatMap((t) => t.partitions);
+var allCalculationItems = (m) => m.tables.flatMap((t) => t.calculationGroup?.items ?? []);
+var allTablePermissions = (m) => m.roles.flatMap((r) => r.tablePermissions);
+var dataType = (c) => (c.dataType ?? "").toLowerCase();
+var isNumericType = (c) => ["int64", "decimal", "double"].includes(dataType(c));
+var hiddenOrTableHidden = (c) => c.isHidden || c.table.isHidden;
+var isBlank = (s) => s === void 0 || s.trim() === "";
+var escapeRegExp = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+var isDirectQueryTable = (t) => t.kind === "table" && t.partitions[0]?.mode === "directquery";
+var tablesInScope = (m) => m.tables.filter((t) => t.kind !== "calculationGroup");
+var tableObjectType = (t) => t.kind === "calculated" ? "CalculatedTable" : t.kind === "calculationGroup" ? "CalculationGroupTable" : "Table";
+var columnObjectType = (c) => c.kind === "calculated" ? "CalculatedColumn" : c.kind === "calculatedTable" ? "CalculatedTableColumn" : "Column";
+var finding = {
+  // A model synthesized because the folder has no model.tmdl has no real location, so Model
+  // findings carry none rather than pointing at line 0 of an empty file name.
+  model: (m) => ({
+    objectType: "Model",
+    objectName: "Model",
+    ...m.location.file === "" ? {} : { location: m.location },
+    object: m
+  }),
+  table: (t) => ({
+    objectType: tableObjectType(t),
+    objectName: tableRef(t.name),
+    location: t.location,
+    object: t
+  }),
+  column: (c) => ({
+    objectType: columnObjectType(c),
+    objectName: columnRef(c.table.name, c.name),
+    location: c.location,
+    object: c
+  }),
+  measure: (x) => ({
+    objectType: "Measure",
+    objectName: measureRef(x.name),
+    location: x.location,
+    object: x
+  }),
+  partition: (p) => ({
+    objectType: "Partition",
+    objectName: p.name,
+    location: p.location,
+    detail: `table ${tableRef(p.table.name)}`,
+    object: p
+  }),
+  relationship: (r) => ({
+    objectType: "Relationship",
+    objectName: relationshipName(r),
+    location: r.location,
+    object: r
+  }),
+  role: (r) => ({
+    objectType: "Role",
+    objectName: r.name,
+    location: r.location,
+    object: r
+  }),
+  tablePermission: (tp) => ({
+    objectType: "TablePermission",
+    objectName: tp.table,
+    location: tp.location,
+    detail: `role ${tp.role.name}`,
+    object: tp
+  }),
+  perspective: (p) => ({
+    objectType: "Perspective",
+    objectName: p.name,
+    location: p.location,
+    object: p
+  }),
+  hierarchy: (h) => ({
+    objectType: "Hierarchy",
+    objectName: h.name,
+    location: h.location,
+    detail: `table ${tableRef(h.table.name)}`,
+    object: h
+  }),
+  level: (l) => ({
+    objectType: "Level",
+    objectName: l.name,
+    location: l.location,
+    detail: `hierarchy ${l.hierarchy.name} in ${tableRef(l.hierarchy.table.name)}`,
+    object: l
+  }),
+  calculationItem: (i) => ({
+    objectType: "CalculationItem",
+    objectName: i.name,
+    location: i.location,
+    detail: `calculation group ${tableRef(i.table.name)}`,
+    object: i
+  }),
+  expression: (e) => ({
+    objectType: "NamedExpression",
+    objectName: e.name,
+    location: e.location,
+    object: e
+  }),
+  dataSource: (d) => ({
+    objectType: "DataSource",
+    objectName: d.name,
+    location: d.location,
+    object: d
+  })
+};
+function namedObjects(m, types) {
+  const want = new Set(types);
+  const out = [];
+  const push2 = (f, name, description) => {
+    if (want.has(f.objectType)) out.push({ finding: f, name, description });
+  };
+  push2(finding.model(m), m.name, m.description);
+  for (const t of m.tables) {
+    push2(finding.table(t), t.name, t.description);
+    for (const c of t.columns) push2(finding.column(c), c.name, c.description);
+    for (const x of t.measures) push2(finding.measure(x), x.name, x.description);
+    for (const h of t.hierarchies) {
+      push2(finding.hierarchy(h), h.name, h.description);
+      for (const l of h.levels) push2(finding.level(l), l.name, l.description);
+    }
+    for (const p of t.partitions) push2(finding.partition(p), p.name, p.description);
+    for (const i of t.calculationGroup?.items ?? [])
+      push2(finding.calculationItem(i), i.name, i.description);
+  }
+  for (const r of m.relationships) push2(finding.relationship(r), r.name, r.description);
+  for (const r of m.roles) {
+    push2(finding.role(r), r.name, r.description);
+    for (const tp of r.tablePermissions) push2(finding.tablePermission(tp), tp.name, tp.description);
+  }
+  for (const p of m.perspectives) push2(finding.perspective(p), p.name, p.description);
+  for (const e of m.expressions) push2(finding.expression(e), e.name, e.description);
+  for (const d of m.dataSources) push2(finding.dataSource(d), d.name, d.description);
+  return out;
+}
+function expressionObjects(m, kinds) {
+  const want = new Set(kinds);
+  const out = [];
+  for (const t of m.tables) {
+    if (want.has("measure"))
+      for (const x of t.measures)
+        out.push({ kind: "measure", finding: finding.measure(x), expression: x.expression });
+    if (want.has("calculatedColumn")) {
+      for (const c of t.columns)
+        if (c.kind === "calculated")
+          out.push({
+            kind: "calculatedColumn",
+            finding: finding.column(c),
+            expression: c.expression ?? ""
+          });
+    }
+    if (want.has("calculationItem"))
+      for (const i of t.calculationGroup?.items ?? [])
+        out.push({
+          kind: "calculationItem",
+          finding: finding.calculationItem(i),
+          expression: i.expression
+        });
+  }
+  return out;
+}
+
+// ../core/src/rules/rule-summaries.data.ts
+var RULE_SUMMARIES = {
+  ADD_DATA_CATEGORY_FOR_COLUMNS: "Columns with no data category whose name contains country, continent, or city and whose type is text, or whose name is exactly latitude or longitude and whose type is decimal or double.",
+  "AVOID_BI-DIRECTIONAL_RELATIONSHIPS_AGAINST_HIGH-CARDINALITY_COLUMNS": "Columns in a bi-directional relationship that have more than 100,000 distinct values. Cardinality is not stored in the model files, so pbiplint lists this rule but cannot run it.",
+  AVOID_DUPLICATE_MEASURES: "Two or more measures whose DAX is identical once spaces, tabs, and line breaks are removed. Every copy is reported.",
+  "AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS": "Models where bi-directional relationships plus many-to-many relationships make up more than 30 percent of all relationships. The finding is on the model, not on any one relationship.",
+  AVOID_FLOATING_POINT_DATA_TYPES: "Columns of any kind whose data type is Double, which Power BI Desktop calls Decimal Number.",
+  AVOID_INVALID_DESCRIPTION_CHARACTERS: "Descriptions containing a control character other than whitespace. Tabs and line breaks are allowed.",
+  AVOID_INVALID_NAME_CHARACTERS: "Object names containing a control character other than whitespace. Tabs and line breaks are allowed here and are covered by `SPECIAL_CHARS_IN_OBJECT_NAMES`.",
+  AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS: "Partitions whose source is a legacy query, a provider partition, that points at a structured data source.",
+  AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE: "Tables that have a row-level security filter in any role and are named as the second argument of USERELATIONSHIP in a measure.",
+  "AVOID_USING_'1-(X/Y)'_SYNTAX": "Expressions with a number, then plus or minus, then either `SUM('Table'[Column])` followed by a division operator, or a call to DIVIDE. The common shape is `1 - SUM(Sales[Cost]) / SUM(Sales[Amount])`.",
+  "AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY": "Regular tables that carry a row-level security filter in any role and take part in a many-to-many relationship.",
+  AVOID_USING_THE_IFERROR_FUNCTION: "Measures and calculated columns that call IFERROR.",
+  CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS: "Calculation groups that contain no calculation items.",
+  "CHECK_IF_BI-DIRECTIONAL_AND_MANY-TO-MANY_RELATIONSHIPS_ARE_VALID": "Every relationship that is bi-directional, many-to-many, or both. This is a review list at info severity, not a defect.",
+  "CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_(RLS)_IS_NECESSARY": "Row-level security filters that call USERNAME or USERPRINCIPALNAME. Reported per table permission, at info severity.",
+  DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN: "Data columns with no source column. Calculated columns are not checked.",
+  "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE": "Tables with date or calendar in the name that are not marked as a date table, meaning the data category is not Time or no DateTime column is marked as the key.",
+  DATECOLUMN_FORMATSTRING: "DateTime columns with date in the name whose format string is not exactly `mm/dd/yyyy`.",
+  DAX_COLUMNS_FULLY_QUALIFIED: "Measures and row-level security filters that refer to a column by its bare name, `[Column]`, instead of `'Table'[Column]`.",
+  DAX_MEASURES_UNQUALIFIED: "Measures, calculated columns, calculated tables, and calculation items that refer to a measure with a table prefix, `'Table'[Measure]`.",
+  ENSURE_TABLES_HAVE_RELATIONSHIPS: "Tables with no relationship to any other table. Calculation groups are not checked.",
+  EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS: "Measures that call EVALUATEANDLOG.",
+  EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION: "Measures, calculated columns, and calculation items whose expression is empty.",
+  FILTER_COLUMN_VALUES: "CALCULATE or CALCULATETABLE whose first filter argument is `FILTER('Table', 'Table'[Column] ...)`.",
+  FILTER_MEASURE_VALUES_BY_COLUMNS: "CALCULATE or CALCULATETABLE whose first filter argument is `FILTER('Table', [Measure] ...)`.",
+  FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED: "Tables, measures, hierarchies, calculated columns, calculated tables, and calculation groups whose first character has an upper case form and is not upper case.",
+  FIX_REFERENTIAL_INTEGRITY_VIOLATIONS: "Relationships where the many side holds key values that do not exist on the one side. Row data is not in the model files, so pbiplint lists this rule but cannot run it.",
+  "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS": "Visible columns whose name starts with Is and whose type is whole number, and visible columns whose name ends with Flag and whose type is not text.",
+  HIDE_FACT_TABLE_COLUMNS: "Visible numeric columns that a measure aggregates directly with a fully qualified reference, such as `SUM('Sales'[Amount])`. COUNT, SUM, AVERAGE, MIN, MAX, DISTINCTCOUNT, VALUES, DISTINCT, and their A-suffixed variants count as aggregations.",
+  HIDE_FOREIGN_KEYS: "Visible columns whose name matches the from column of a relationship whose from side is many. Only the from cardinality is tested, so a many-to-many relationship counts here too, not just many-to-one.",
+  INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED: "Inactive relationships that no measure or calculation item activates with USERELATIONSHIP.",
+  INTEGER_FORMATTING: 'Measures whose static format string is not a recognized whole-number, currency, or percentage format. The only format strings the rule accepts are `#,0`, `#,0.0`, and any string containing `$` or `%`. A measure with no format string at all fires too, and that is the common case: the rule reads only the format string, so it cannot tell an unformatted currency or ratio from an unformatted count. Each finding says what the rule saw: `no format string`, `format string "0.00"`, or `dynamic format string only`.',
+  ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS: "Hidden columns, or columns in hidden tables, that still have IsAvailableInMdx set to true and are not used to sort another column, in a hierarchy, or in a variation, and do not themselves sort by another column.",
+  LARGE_TABLES_SHOULD_BE_PARTITIONED: "Tables with more than 25 million rows and a single partition. Row counts are not in the model files, so pbiplint lists this rule but cannot run it.",
+  "LIMIT_ROW_LEVEL_SECURITY_(RLS)_LOGIC": "Tables whose row-level security filter, in any role, calls RIGHT, LEFT, UPPER, LOWER, or FIND.",
+  "MANY-TO-MANY_RELATIONSHIPS_SHOULD_BE_SINGLE-DIRECTION": "Many-to-many relationships with bi-directional cross filtering.",
+  MARK_PRIMARY_KEYS: "Columns on the one side of a relationship, outside date tables, that are not marked as the table's key.",
+  MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES: "Measures whose whole expression is a reference to another measure, such as `[Total Sales]`.",
+  MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY: "Measures and calculation items that call a time intelligence function, in a model where at least one table is in DirectQuery mode.",
+  MINIMIZE_POWER_QUERY_TRANSFORMATIONS: "Power Query partitions whose M text contains Table.Combine, Table.Join, Table.NestedJoin, Table.AddColumn, Table.Group, Table.Sort, Table.Pivot, Table.Unpivot, Table.UnpivotOtherColumns, Table.Distinct, a native SQL query, or an OLE DB or ODBC query.",
+  MODEL_SHOULD_HAVE_A_DATE_TABLE: "Models with no table that has the data category Time and a DateTime column marked as the key, which is what Mark as date table sets.",
+  MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS: "Models that have at least one DirectQuery table, no aggregation table (no column has an alternateOf mapping), and the PowerBI_V3 data source version, which is every project Desktop writes today.",
+  "MONTH_(AS_A_STRING)_MUST_BE_SORTED": "Text columns with month in the name, but not months, that have no sort-by column.",
+  MONTHCOLUMN_FORMATSTRING: "DateTime columns with month in the name whose format string is not exactly `MMMM yyyy`.",
+  NUMERIC_COLUMN_SUMMARIZE_BY: "Visible whole number, decimal, or double columns whose default summarization is anything other than None.",
+  OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE: "Names that start or end with a space, for the model, tables, measures, hierarchies, perspectives, partitions, data columns, and calculated columns.",
+  OBJECTS_WITH_NO_DESCRIPTION: "Visible tables, columns, measures, and calculation groups with no description. Visibility is the object's own flag.",
+  PARSE_ISSUE: "Lines the TMDL parser could not use: space indentation, an unterminated code fence, a line at an impossible indentation, a line in no form the parser recognizes, and a `///` description with a blank line between it and its declaration.",
+  PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES: "Regular tables with exactly one partition whose name differs from the table name. Calculated tables and calculation groups are not checked.",
+  PERCENTAGE_FORMATTING: "Measures with a percent format string other than `#,0.0%;-#,0.0%;#,0.0%`.",
+  PERSPECTIVES_WITH_NO_OBJECTS: "Perspectives that contain no tables. Adding any column, measure, or hierarchy to a perspective adds its table, so a perspective with no tables is empty.",
+  PROVIDE_FORMAT_STRING_FOR_MEASURES: "Visible measures with no format string and no dynamic format string.",
+  REDUCE_NUMBER_OF_CALCULATED_COLUMNS: "Models with more than five calculated columns across all tables. Columns of calculated tables do not count, and the finding is on the model.",
+  REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION: "Calculated columns whose DAX calls RELATED.",
+  REDUCE_USAGE_OF_CALCULATED_TABLES: "Every calculated table. Calculation groups are not included.",
+  "REDUCE_USAGE_OF_LONG-LENGTH_COLUMNS_WITH_HIGH_CARDINALITY": "Text columns where more than 500,000 rows hold values longer than 100 characters. Row data is not in the model files, so pbiplint lists this rule but cannot run it.",
+  RELATIONSHIP_COLUMNS_SAME_DATA_TYPE: "Relationships whose two columns have different data types.",
+  RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE: "Any column that takes part in a relationship and is not a whole number.",
+  "REMOVE_AUTO-DATE_TABLE": "Calculated tables generated by the Auto date/time option, whose names start with DateTableTemplate_ or LocalDateTable_.",
+  REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS: "Data sources that no partition names and that appear nowhere in any partition's query text.",
+  REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES: "Columns that take part in no relationship and share a name with a column on a table that this table relates to from the many side. In practice, a fact table column that duplicates a dimension attribute.",
+  REMOVE_ROLES_WITH_NO_MEMBERS: "Roles with no members.",
+  SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS: "Columns with IsAvailableInMdx set to false that are used to sort another column, appear in a hierarchy or a variation, or sort by another column.",
+  SNOWFLAKE_SCHEMA_ARCHITECTURE: "Tables that are on the from side of one relationship and the to side of another, which is what a dimension related to a sub-dimension looks like.",
+  SPECIAL_CHARS_IN_OBJECT_NAMES: "Names containing a tab, line feed, or carriage return.",
+  SPLIT_DATE_AND_TIME: "DateTime columns holding values that are not at midnight. Row data is not in the model files, so pbiplint lists this rule but cannot run it.",
+  TRIM_OBJECT_NAMES: "Names that start or end with a space, across every named object type in the model.",
+  UNNECESSARY_COLUMNS: "Hidden columns, or columns in hidden tables, that nothing references: no DAX expression, relationship, hierarchy, sort-by column, row-level security filter, or object-level security rule.",
+  UNNECESSARY_MEASURES: "Hidden measures, or measures on hidden tables, that no DAX expression references.",
+  "UNPIVOT_PIVOTED_(MONTH)_DATA": "Tables that have a numeric column for each of Jan, Feb, Mar, Apr, May, and Jun, matched as substrings of the column names.",
+  USE_THE_DIVIDE_FUNCTION_FOR_DIVISION: "Expressions that use the division operator right after a closing bracket or parenthesis, such as `[Sales] / [Cost]` or `SUM(...) / SUM(...)`. A slash that starts a comment is ignored.",
+  USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT: "Measures and calculation items that call INTERSECT."
+};
+
+// ../core/src/rules/microsoft-bpa/define.ts
+var byId = new Map(BPA_RULES.map((r) => [r.id, r]));
+var SCOPE_MAP = {
+  Model: "Model",
+  Table: "Table",
+  CalculatedTable: "CalculatedTable",
+  CalculationGroup: "CalculationGroupTable",
+  DataColumn: "Column",
+  CalculatedColumn: "CalculatedColumn",
+  CalculatedTableColumn: "CalculatedTableColumn",
+  Measure: "Measure",
+  Partition: "Partition",
+  Relationship: "Relationship",
+  ModelRole: "Role",
+  TablePermission: "TablePermission",
+  Perspective: "Perspective",
+  Hierarchy: "Hierarchy",
+  Level: "Level",
+  CalculationItem: "CalculationItem",
+  NamedExpression: "NamedExpression",
+  ProviderDataSource: "DataSource",
+  StructuredDataSource: "DataSource",
+  KPI: null
+};
+function mapScope(scope) {
+  const out = [];
+  for (const s of scope.split(",").map((x) => x.trim()).filter((x) => x.length > 0)) {
+    if (!(s in SCOPE_MAP)) throw new Error(`Unknown BPA scope: ${s}`);
+    const t = SCOPE_MAP[s];
+    if (t && !out.includes(t)) out.push(t);
+  }
+  return out;
+}
+var metaOf = (id) => {
+  const meta = byId.get(id);
+  if (!meta) throw new Error(`Unknown BPA rule id: ${id}`);
+  return meta;
+};
+var stripCategory = (name) => name.replace(/^\[[^\]]*\]\s*/, "");
+var extractUrls = (text) => [
+  ...new Set((text.match(/https?:\/\/[^\s)"]+/g) ?? []).map((u) => u.replace(/[.,]$/, "")))
+];
+function bpaRule(id, check) {
+  const meta = metaOf(id);
+  return {
+    id,
+    name: stripCategory(meta.name),
+    category: meta.category,
+    severity: meta.severity,
+    scope: mapScope(meta.scope),
+    description: RULE_SUMMARIES[id] ?? stripCategory(meta.name),
+    fixExpression: meta.fixExpression,
+    references: extractUrls(meta.description),
+    status: "ported",
+    check
+  };
+}
+function liveModelRule(id) {
+  return { ...bpaRule(id, () => []), status: "needsLiveModel" };
+}
+
+// ../core/src/rules/microsoft-bpa/columns.ts
+var columns = (m, pred) => allColumns(m).filter(pred).map(finding.column);
+var AVOID_FLOATING_POINT_DATA_TYPES = bpaRule(
+  "AVOID_FLOATING_POINT_DATA_TYPES",
+  (m) => columns(m, (c) => dataType(c) === "double")
+);
+var DATECOLUMN_FORMATSTRING = bpaRule(
+  "DATECOLUMN_FORMATSTRING",
+  (m) => columns(
+    m,
+    (c) => /date/i.test(c.name) && dataType(c) === "datetime" && (c.formatString ?? "") !== "mm/dd/yyyy"
+  )
+);
+var MONTHCOLUMN_FORMATSTRING = bpaRule(
+  "MONTHCOLUMN_FORMATSTRING",
+  (m) => columns(
+    m,
+    (c) => /month/i.test(c.name) && dataType(c) === "datetime" && (c.formatString ?? "") !== "MMMM yyyy"
+  )
+);
+var ADD_DATA_CATEGORY_FOR_COLUMNS = bpaRule(
+  "ADD_DATA_CATEGORY_FOR_COLUMNS",
+  (m) => columns(m, (c) => {
+    const n = c.name.toLowerCase();
+    const d = dataType(c);
+    return isBlank(c.dataCategory) && ((n.includes("country") || n.includes("continent") || n.includes("city")) && d === "string" || (n === "latitude" || n === "longitude") && (d === "decimal" || d === "double"));
+  })
+);
+var MONTH_AS_A_STRING_MUST_BE_SORTED = bpaRule(
+  "MONTH_(AS_A_STRING)_MUST_BE_SORTED",
+  (m) => columns(m, (c) => {
+    const u = c.name.toUpperCase();
+    return u.includes("MONTH") && !u.includes("MONTHS") && dataType(c) === "string" && c.sortByColumn === void 0;
+  })
+);
+var NUMERIC_COLUMN_SUMMARIZE_BY = bpaRule(
+  "NUMERIC_COLUMN_SUMMARIZE_BY",
+  (m) => columns(
+    m,
+    (c) => isNumericType(c) && (c.summarizeBy ?? "default").toLowerCase() !== "none" && !hiddenOrTableHidden(c)
+  )
+);
+var FORMAT_FLAG_COLUMNS_AS_YES_NO_VALUE_STRINGS = bpaRule(
+  "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS",
+  (m) => columns(
+    m,
+    (c) => !hiddenOrTableHidden(c) && (c.name.startsWith("Is") && dataType(c) === "int64" || c.name.endsWith(" Flag") && dataType(c) !== "string")
+  )
+);
+var DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN = bpaRule(
+  "DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN",
+  (m) => columns(m, (c) => c.kind === "data" && isBlank(c.sourceColumn))
+);
+var ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS = bpaRule(
+  "ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS",
+  (m, { indexes: { usage } }) => columns(
+    m,
+    (c) => c.isAvailableInMdx && hiddenOrTableHidden(c) && !usage.usedInSortBy(c) && !usage.usedInHierarchies(c) && !usage.usedInVariations(c) && c.sortByColumn === void 0
+  )
+);
+var SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS = bpaRule(
+  "SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS",
+  (m, { indexes: { usage } }) => columns(
+    m,
+    (c) => !c.isAvailableInMdx && (usage.usedInSortBy(c) || usage.usedInHierarchies(c) || usage.usedInVariations(c) || c.sortByColumn !== void 0)
+  )
+);
+var UNNECESSARY_COLUMNS = bpaRule("UNNECESSARY_COLUMNS", (m, { indexes }) => {
+  const permissions = allTablePermissions(m);
+  return columns(m, (c) => {
+    if (!hiddenOrTableHidden(c)) return false;
+    if (indexes.references.columnReferencedBy(c).length > 0) return false;
+    if (indexes.relationships.forColumn(c.table.name, c.name).length > 0) return false;
+    if (indexes.usage.usedInSortBy(c) || indexes.usage.usedInHierarchies(c)) return false;
+    const bare = `[${c.name}]`.toLowerCase();
+    const qualified = [
+      `${c.table.name}[${c.name}]`.toLowerCase(),
+      `'${c.table.name}'[${c.name}]`.toLowerCase()
+    ];
+    for (const tp of permissions) {
+      const f = tp.filter?.toLowerCase();
+      if (f === void 0) continue;
+      if (tp.table === c.table.name && f.includes(bare)) return false;
+      if (qualified.some((q) => f.includes(q))) return false;
+    }
+    for (const tp of permissions) {
+      if (tp.table !== c.table.name) continue;
+      if (tp.metadataPermission === "none") return false;
+      if (tp.columnPermissions.some((cp) => cp.column === c.name && cp.permission === "none"))
+        return false;
+    }
+    return true;
+  });
+});
+var AGGREGATIONS = [
+  "COUNT",
+  "COUNTBLANK",
+  "SUM",
+  "AVERAGE",
+  "VALUES",
+  "DISTINCT",
+  "DISTINCTCOUNT",
+  "MIN",
+  "MAX",
+  "COUNTA",
+  "AVERAGEA",
+  "MAXA",
+  "MINA"
+];
+var HIDE_FACT_TABLE_COLUMNS = bpaRule("HIDE_FACT_TABLE_COLUMNS", (m) => {
+  const measures = allMeasures(m);
+  return columns(m, (c) => {
+    if (c.isHidden || !isNumericType(c)) return false;
+    const re = new RegExp(
+      `(?:${AGGREGATIONS.join("|")})\\s*\\(\\s*'*${escapeRegExp(c.table.name)}'*\\[${escapeRegExp(c.name)}\\]\\s*\\)`,
+      "i"
+    );
+    return measures.some((x) => re.test(x.expression));
+  });
+});
+var columnRules = [
+  AVOID_FLOATING_POINT_DATA_TYPES,
+  DATECOLUMN_FORMATSTRING,
+  MONTHCOLUMN_FORMATSTRING,
+  ADD_DATA_CATEGORY_FOR_COLUMNS,
+  MONTH_AS_A_STRING_MUST_BE_SORTED,
+  NUMERIC_COLUMN_SUMMARIZE_BY,
+  FORMAT_FLAG_COLUMNS_AS_YES_NO_VALUE_STRINGS,
+  DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN,
+  ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS,
+  SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS,
+  UNNECESSARY_COLUMNS,
+  HIDE_FACT_TABLE_COLUMNS
+];
+
+// ../core/src/rules/microsoft-bpa/dependencies.ts
+function ownerFinding(o) {
+  switch (o.kind) {
+    case "measure":
+      return finding.measure(o.object);
+    case "calculatedColumn":
+      return finding.column(o.object);
+    case "calculatedTable":
+      return finding.table(o.object);
+    case "tablePermission":
+      return finding.tablePermission(o.object);
+    case "calculationItem":
+      return finding.calculationItem(o.object);
+  }
+}
+var DAX_COLUMNS_FULLY_QUALIFIED = bpaRule(
+  "DAX_COLUMNS_FULLY_QUALIFIED",
+  (_m, { indexes: { references } }) => references.owners.filter(
+    (o) => (o.kind === "measure" || o.kind === "tablePermission" || o.kind === "calculationItem") && o.refs.some((r) => r.kind === "column" && !r.qualified)
+  ).map(ownerFinding)
+);
+var DAX_MEASURES_UNQUALIFIED = bpaRule(
+  "DAX_MEASURES_UNQUALIFIED",
+  (_m, { indexes: { references } }) => references.owners.filter(
+    (o) => o.kind !== "tablePermission" && o.refs.some((r) => r.kind === "measure" && r.qualified)
+  ).map(ownerFinding)
+);
+var stripWhitespace = (s) => s.replace(/[ \n\r\t]/g, "");
+var AVOID_DUPLICATE_MEASURES = bpaRule("AVOID_DUPLICATE_MEASURES", (m) => {
+  const all = allMeasures(m);
+  const counts = /* @__PURE__ */ new Map();
+  for (const x of all) {
+    const k = stripWhitespace(x.expression);
+    counts.set(k, (counts.get(k) ?? 0) + 1);
+  }
+  return all.filter((x) => (counts.get(stripWhitespace(x.expression)) ?? 0) > 1).map(finding.measure);
+});
+var MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES = bpaRule(
+  "MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES",
+  (m) => {
+    const all = allMeasures(m);
+    const names = new Set(all.map((x) => measureRef(x.name)));
+    return all.filter((x) => names.has(x.expression)).map(finding.measure);
+  }
+);
+var UNNECESSARY_MEASURES = bpaRule(
+  "UNNECESSARY_MEASURES",
+  (m, { indexes: { references } }) => allMeasures(m).filter(
+    (x) => (x.table.isHidden || x.isHidden) && references.measureReferencedBy(x).length === 0
+  ).map(finding.measure)
+);
+var dependencyRules = [
+  DAX_COLUMNS_FULLY_QUALIFIED,
+  DAX_MEASURES_UNQUALIFIED,
+  AVOID_DUPLICATE_MEASURES,
+  MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES,
+  UNNECESSARY_MEASURES
+];
+
+// ../core/src/rules/microsoft-bpa/live-model.ts
+var liveModelRules = [
+  liveModelRule("AVOID_BI-DIRECTIONAL_RELATIONSHIPS_AGAINST_HIGH-CARDINALITY_COLUMNS"),
+  liveModelRule("REDUCE_USAGE_OF_LONG-LENGTH_COLUMNS_WITH_HIGH_CARDINALITY"),
+  liveModelRule("SPLIT_DATE_AND_TIME"),
+  liveModelRule("LARGE_TABLES_SHOULD_BE_PARTITIONED"),
+  liveModelRule("FIX_REFERENTIAL_INTEGRITY_VIOLATIONS")
+];
+
+// ../core/src/rules/microsoft-bpa/measures.ts
+var M = "measure";
+var CC = "calculatedColumn";
+var CI = "calculationItem";
+var patternRule = (id, kinds, patterns) => bpaRule(
+  id,
+  (m) => expressionObjects(m, kinds).filter((o) => patterns.some((p) => p.test(o.expression))).map((o) => o.finding)
+);
+var PROVIDE_FORMAT_STRING_FOR_MEASURES = bpaRule(
+  "PROVIDE_FORMAT_STRING_FOR_MEASURES",
+  (m) => allMeasures(m).filter(
+    (x) => !x.isHidden && !x.table.isHidden && isBlank(x.formatString) && isBlank(x.formatStringDefinition)
+  ).map(finding.measure)
+);
+var formatStringDetail = (x) => {
+  const fs = x.formatString ?? "";
+  if (fs.trim() !== "") return `format string "${fs}"`;
+  return isBlank(x.formatStringDefinition) ? "no format string" : "dynamic format string only";
+};
+var INTEGER_FORMATTING = bpaRule(
+  "INTEGER_FORMATTING",
+  (m) => allMeasures(m).filter((x) => {
+    const fs = x.formatString ?? "";
+    return !fs.includes("$") && !fs.includes("%") && !(fs === "#,0" || fs === "#,0.0");
+  }).map((x) => ({ ...finding.measure(x), detail: formatStringDetail(x) }))
+);
+var PERCENTAGE_FORMATTING = bpaRule(
+  "PERCENTAGE_FORMATTING",
+  (m) => allMeasures(m).filter(
+    (x) => (x.formatString ?? "").includes("%") && x.formatString !== "#,0.0%;-#,0.0%;#,0.0%"
+  ).map(finding.measure)
+);
+var USE_THE_DIVIDE_FUNCTION_FOR_DIVISION = patternRule(
+  "USE_THE_DIVIDE_FUNCTION_FOR_DIVISION",
+  [M, CC, CI],
+  [/\]\s*\/(?!\/)(?!\*)/, /\)\s*\/(?!\/)(?!\*)/]
+);
+var AVOID_USING_THE_IFERROR_FUNCTION = patternRule(
+  "AVOID_USING_THE_IFERROR_FUNCTION",
+  [M, CC],
+  [/IFERROR\s*\(/i]
+);
+var USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT = patternRule(
+  "USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT",
+  [M, CI],
+  [/INTERSECT\s*\(/i]
+);
+var FILTER_COLUMN_VALUES = patternRule(
+  "FILTER_COLUMN_VALUES",
+  [M, CC, CI],
+  [
+    /CALCULATE\s*\(\s*[^,]+,\s*FILTER\s*\(\s*'*[A-Za-z0-9 _]+'*\s*,\s*'*[A-Za-z0-9 _]+'*\[[A-Za-z0-9 _]+\]/i,
+    /CALCULATETABLE\s*\([^,]*,\s*FILTER\s*\(\s*'*[A-Za-z0-9 _]+'*,\s*'*[A-Za-z0-9 _]+'*\[[A-Za-z0-9 _]+\]/i
+  ]
+);
+var FILTER_MEASURE_VALUES_BY_COLUMNS = patternRule(
+  "FILTER_MEASURE_VALUES_BY_COLUMNS",
+  [M, CC, CI],
+  [
+    /CALCULATE\s*\(\s*[^,]+,\s*FILTER\s*\(\s*'*[A-Za-z0-9 _]+'*\s*,\s*\[[^\]]+\]/i,
+    /CALCULATETABLE\s*\([^,]*,\s*FILTER\s*\(\s*'*[A-Za-z0-9 _]+'*,\s*\[/i
+  ]
+);
+var AVOID_USING_1_X_Y_SYNTAX = patternRule(
+  "AVOID_USING_'1-(X/Y)'_SYNTAX",
+  [M, CC, CI],
+  [
+    /[0-9]+\s*[-+]\s*[(]*\s*SUM\s*\(\s*'*[A-Za-z0-9 _]+'*\s*\[[A-Za-z0-9 _]+\]\s*\)\s*\//i,
+    /[0-9]+\s*[-+]\s*DIVIDE\s*\(/i
+  ]
+);
+var EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS = patternRule(
+  "EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS",
+  [M],
+  [/EVALUATEANDLOG\s*\(/i]
+);
+var REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION = patternRule(
+  "REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION",
+  [CC],
+  [/RELATED\s*\(/i]
+);
+var EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION = bpaRule(
+  "EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION",
+  (m) => expressionObjects(m, [M, CC, CI]).filter((o) => isBlank(o.expression)).map((o) => o.finding)
+);
+var measureRules = [
+  PROVIDE_FORMAT_STRING_FOR_MEASURES,
+  INTEGER_FORMATTING,
+  PERCENTAGE_FORMATTING,
+  USE_THE_DIVIDE_FUNCTION_FOR_DIVISION,
+  AVOID_USING_THE_IFERROR_FUNCTION,
+  USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT,
+  FILTER_COLUMN_VALUES,
+  FILTER_MEASURE_VALUES_BY_COLUMNS,
+  AVOID_USING_1_X_Y_SYNTAX,
+  EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS,
+  REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION,
+  EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION
+];
+
+// ../core/src/rules/microsoft-bpa/naming.ts
+var namedObjectRule = (id, test) => bpaRule(
+  id,
+  (m) => namedObjects(m, mapScope(metaOf(id).scope)).filter((o) => test(o.name, o.description)).map((o) => o.finding)
+);
+var startsOrEndsWithSpace = (name) => name.startsWith(" ") || name.endsWith(" ");
+var TRIM_OBJECT_NAMES = namedObjectRule("TRIM_OBJECT_NAMES", startsOrEndsWithSpace);
+var OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE = namedObjectRule(
+  "OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE",
+  startsOrEndsWithSpace
+);
+var SPECIAL_CHARS_IN_OBJECT_NAMES = namedObjectRule(
+  "SPECIAL_CHARS_IN_OBJECT_NAMES",
+  (name) => /[\t\n\r]/.test(name)
+);
+var CONTROL_NOT_WHITESPACE = /[\x00-\x08\x0E-\x1F\x7F-\x84\x86-\x9F]/;
+var AVOID_INVALID_NAME_CHARACTERS = namedObjectRule(
+  "AVOID_INVALID_NAME_CHARACTERS",
+  (name) => CONTROL_NOT_WHITESPACE.test(name)
+);
+var AVOID_INVALID_DESCRIPTION_CHARACTERS = namedObjectRule(
+  "AVOID_INVALID_DESCRIPTION_CHARACTERS",
+  (_name, description) => CONTROL_NOT_WHITESPACE.test(description ?? "")
+);
+var FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED = namedObjectRule(
+  "FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED",
+  (name) => name.length > 0 && name.slice(0, 1).toUpperCase() !== name.slice(0, 1)
+);
+var PERSPECTIVES_WITH_NO_OBJECTS = bpaRule(
+  "PERSPECTIVES_WITH_NO_OBJECTS",
+  (m) => m.perspectives.filter((p) => p.tables.length === 0).map(finding.perspective)
+);
+var CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS = bpaRule(
+  "CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS",
+  (m) => m.tables.filter((t) => t.calculationGroup !== void 0 && t.calculationGroup.items.length === 0).map(finding.table)
+);
+var REMOVE_ROLES_WITH_NO_MEMBERS = bpaRule(
+  "REMOVE_ROLES_WITH_NO_MEMBERS",
+  (m) => m.roles.filter((r) => r.members.length === 0).map(finding.role)
+);
+var REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS = bpaRule(
+  "REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS",
+  (m) => {
+    const partitions = allPartitions(m);
+    return m.dataSources.filter(
+      (ds) => !partitions.some((p) => p.dataSource === ds.name) && !partitions.some((p) => (p.source ?? "").includes(ds.name))
+    ).map(finding.dataSource);
+  }
+);
+var AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS = bpaRule(
+  "AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS",
+  (m) => allPartitions(m).filter(
+    (p) => p.sourceType === "query" && m.dataSources.some((ds) => ds.name === p.dataSource && ds.kind === "structured")
+  ).map(finding.partition)
+);
+var namingRules = [
+  TRIM_OBJECT_NAMES,
+  OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE,
+  SPECIAL_CHARS_IN_OBJECT_NAMES,
+  AVOID_INVALID_NAME_CHARACTERS,
+  AVOID_INVALID_DESCRIPTION_CHARACTERS,
+  FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED,
+  PERSPECTIVES_WITH_NO_OBJECTS,
+  CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS,
+  REMOVE_ROLES_WITH_NO_MEMBERS,
+  REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS,
+  AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS
+];
+
+// ../core/src/rules/microsoft-bpa/relationships.ts
+var isManyToMany = (r) => r.fromCardinality === "many" && r.toCardinality === "many";
+var isBidirectional = (r) => r.crossFilteringBehavior === "bothdirections";
+var RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE = bpaRule(
+  "RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE",
+  (m, { indexes: { relationships } }) => allColumns(m).filter(
+    (c) => relationships.forColumn(c.table.name, c.name).length > 0 && dataType(c) !== "int64"
+  ).map(finding.column)
+);
+var HIDE_FOREIGN_KEYS = bpaRule(
+  "HIDE_FOREIGN_KEYS",
+  (m, { indexes: { relationships } }) => allColumns(m).filter(
+    (c) => !c.isHidden && relationships.forColumn(c.table.name, c.name).some((r) => r.fromColumn === c.name && r.fromCardinality === "many")
+  ).map(finding.column)
+);
+var MARK_PRIMARY_KEYS = bpaRule(
+  "MARK_PRIMARY_KEYS",
+  (m, { indexes: { relationships } }) => allColumns(m).filter(
+    (c) => !c.isKey && c.table.dataCategory !== "Time" && relationships.forColumn(c.table.name, c.name).some(
+      (r) => r.toTable === c.table.name && r.toColumn === c.name && r.toCardinality === "one"
+    )
+  ).map(finding.column)
+);
+var REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES = bpaRule(
+  "REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES",
+  (m, { indexes: { relationships } }) => {
+    const all = allColumns(m);
+    return all.filter(
+      (c) => relationships.forColumn(c.table.name, c.name).length === 0 && all.some(
+        (o) => o.name === c.name && o.table !== c.table && relationships.forTable(o.table.name).some((r) => r.fromTable === c.table.name)
+      )
+    ).map(finding.column);
+  }
+);
+var SNOWFLAKE_SCHEMA_ARCHITECTURE = bpaRule(
+  "SNOWFLAKE_SCHEMA_ARCHITECTURE",
+  (m, { indexes: { relationships } }) => tablesInScope(m).filter((t) => {
+    const rels = relationships.forTable(t.name);
+    return rels.some((r) => r.fromTable === t.name) && rels.some((r) => r.toTable === t.name);
+  }).map(finding.table)
+);
+var ENSURE_TABLES_HAVE_RELATIONSHIPS = bpaRule(
+  "ENSURE_TABLES_HAVE_RELATIONSHIPS",
+  (m, { indexes: { relationships } }) => tablesInScope(m).filter((t) => relationships.forTable(t.name).length === 0).map(finding.table)
+);
+var MANY_TO_MANY_RELATIONSHIPS_SHOULD_BE_SINGLE_DIRECTION = bpaRule(
+  "MANY-TO-MANY_RELATIONSHIPS_SHOULD_BE_SINGLE-DIRECTION",
+  (m) => m.relationships.filter((r) => isManyToMany(r) && isBidirectional(r)).map(finding.relationship)
+);
+var CHECK_IF_BIDIRECTIONAL_AND_MANY_TO_MANY_RELATIONSHIPS_ARE_VALID = bpaRule(
+  "CHECK_IF_BI-DIRECTIONAL_AND_MANY-TO-MANY_RELATIONSHIPS_ARE_VALID",
+  (m) => m.relationships.filter((r) => isManyToMany(r) || isBidirectional(r)).map(finding.relationship)
+);
+var RELATIONSHIP_COLUMNS_SAME_DATA_TYPE = bpaRule(
+  "RELATIONSHIP_COLUMNS_SAME_DATA_TYPE",
+  (m) => {
+    const column = (table, name) => m.tables.find((t) => t.name === table)?.columns.find((c) => c.name === name);
+    return m.relationships.filter((r) => {
+      const from = column(r.fromTable, r.fromColumn);
+      const to = column(r.toTable, r.toColumn);
+      return from !== void 0 && to !== void 0 && dataType(from) !== dataType(to);
+    }).map(finding.relationship);
+  }
+);
+var INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED = bpaRule(
+  "INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED",
+  (m) => {
+    const expressions = [
+      ...allMeasures(m).map((x) => x.expression),
+      ...allCalculationItems(m).map((i) => i.expression)
+    ];
+    return m.relationships.filter((r) => {
+      if (r.isActive) return false;
+      const re = new RegExp(
+        `USERELATIONSHIP\\s*\\(\\s*'*${escapeRegExp(r.fromTable)}'*\\[${escapeRegExp(r.fromColumn)}\\]\\s*,\\s*'*${escapeRegExp(r.toTable)}'*\\[${escapeRegExp(r.toColumn)}\\]`,
+        "i"
+      );
+      return !expressions.some((e) => re.test(e));
+    }).map(finding.relationship);
+  }
+);
+var AVOID_EXCESSIVE_BIDIRECTIONAL_OR_MANY_TO_MANY_RELATIONSHIPS = bpaRule(
+  "AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS",
+  (m) => {
+    const rels = m.relationships;
+    const count = rels.filter(isBidirectional).length + rels.filter(isManyToMany).length;
+    return count / Math.max(rels.length, 1) > 0.3 ? [finding.model(m)] : [];
+  }
+);
+var AVOID_USING_MANY_TO_MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY = bpaRule(
+  "AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY",
+  (m, { indexes: { relationships } }) => {
+    const permissions = allTablePermissions(m);
+    return m.tables.filter(
+      (t) => t.kind === "table" && relationships.forTable(t.name).some(isManyToMany) && permissions.some((tp) => tp.table === t.name && (tp.filter ?? "").length > 0)
+    ).map(finding.table);
+  }
+);
+var relationshipRules = [
+  RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE,
+  HIDE_FOREIGN_KEYS,
+  MARK_PRIMARY_KEYS,
+  REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES,
+  SNOWFLAKE_SCHEMA_ARCHITECTURE,
+  ENSURE_TABLES_HAVE_RELATIONSHIPS,
+  MANY_TO_MANY_RELATIONSHIPS_SHOULD_BE_SINGLE_DIRECTION,
+  CHECK_IF_BIDIRECTIONAL_AND_MANY_TO_MANY_RELATIONSHIPS_ARE_VALID,
+  RELATIONSHIP_COLUMNS_SAME_DATA_TYPE,
+  INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED,
+  AVOID_EXCESSIVE_BIDIRECTIONAL_OR_MANY_TO_MANY_RELATIONSHIPS,
+  AVOID_USING_MANY_TO_MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY
+];
+
+// ../core/src/rules/microsoft-bpa/tables.ts
+var hasDateTimeKey = (t) => t.columns.some((c) => c.isKey && dataType(c) === "datetime");
+var MODEL_SHOULD_HAVE_A_DATE_TABLE = bpaRule(
+  "MODEL_SHOULD_HAVE_A_DATE_TABLE",
+  (m) => m.tables.some((t) => t.dataCategory === "Time" && hasDateTimeKey(t)) ? [] : [finding.model(m)]
+);
+var DATE_CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE = bpaRule(
+  "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE",
+  (m) => tablesInScope(m).filter((t) => {
+    const u = t.name.toUpperCase();
+    return (u.includes("DATE") || u.includes("CALENDAR")) && (t.dataCategory !== "Time" || !hasDateTimeKey(t));
+  }).map(finding.table)
+);
+var REMOVE_AUTO_DATE_TABLE = bpaRule(
+  "REMOVE_AUTO-DATE_TABLE",
+  (m) => m.tables.filter(
+    (t) => t.kind === "calculated" && (t.name.startsWith("DateTableTemplate_") || t.name.startsWith("LocalDateTable_"))
+  ).map(finding.table)
+);
+var REDUCE_USAGE_OF_CALCULATED_TABLES = bpaRule(
+  "REDUCE_USAGE_OF_CALCULATED_TABLES",
+  (m) => m.tables.filter((t) => t.kind === "calculated").map(finding.table)
+);
+var REDUCE_NUMBER_OF_CALCULATED_COLUMNS = bpaRule(
+  "REDUCE_NUMBER_OF_CALCULATED_COLUMNS",
+  (m) => allColumns(m).filter((c) => c.kind === "calculated").length > 5 ? [finding.model(m)] : []
+);
+var MONTHS = ["JAN", "FEB", "MAR", "APR", "MAY", "JUN"];
+var UNPIVOT_PIVOTED_MONTH_DATA = bpaRule(
+  "UNPIVOT_PIVOTED_(MONTH)_DATA",
+  (m) => tablesInScope(m).filter(
+    (t) => MONTHS.every(
+      (mo) => t.columns.some((c) => c.name.toUpperCase().includes(mo) && isNumericType(c))
+    )
+  ).map(finding.table)
+);
+var PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES = bpaRule(
+  "PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES",
+  (m) => m.tables.filter(
+    (t) => t.kind === "table" && t.partitions.length === 1 && t.partitions[0].name !== t.name
+  ).map(finding.table)
+);
+var POWER_QUERY_PATTERNS = [
+  "Table.Combine(",
+  "Table.Join(",
+  "Table.NestedJoin(",
+  "Table.AddColumn(",
+  "Table.Group(",
+  "Table.Sort(",
+  "Table.Pivot(",
+  "Table.Unpivot(",
+  "Table.UnpivotOtherColumns(",
+  "Table.Distinct(",
+  '[Query="SELECT',
+  "Value.NativeQuery",
+  "OleDb.Query",
+  "Odbc.Query"
+];
+var MINIMIZE_POWER_QUERY_TRANSFORMATIONS = bpaRule(
+  "MINIMIZE_POWER_QUERY_TRANSFORMATIONS",
+  (m) => allPartitions(m).filter(
+    (p) => p.sourceType === "m" && POWER_QUERY_PATTERNS.some((s) => (p.source ?? "").includes(s))
+  ).map(finding.partition)
+);
+var MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS = bpaRule(
+  "MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS",
+  (m) => m.tables.some(isDirectQueryTable) && !allColumns(m).some((c) => c.hasAlternateOf) && String(m.props.defaultpowerbidatasourceversion ?? "").toLowerCase() === "powerbi_v3" ? [finding.model(m)] : []
+);
+var TIME_INTELLIGENCE_FUNCTIONS = [
+  "CLOSINGBALANCEMONTH",
+  "CLOSINGBALANCEQUARTER",
+  "CLOSINGBALANCEYEAR",
+  "DATEADD",
+  "DATESBETWEEN",
+  "DATESINPERIOD",
+  "DATESMTD",
+  "DATESQTD",
+  "DATESYTD",
+  "ENDOFMONTH",
+  "ENDOFQUARTER",
+  "ENDOFYEAR",
+  "FIRSTDATE",
+  "FIRSTNONBLANK",
+  "FIRSTNONBLANKVALUE",
+  "LASTDATE",
+  "LASTNONBLANK",
+  "LASTNONBLANKVALUE",
+  "NEXTDAY",
+  "NEXTMONTH",
+  "NEXTQUARTER",
+  "NEXTYEAR",
+  "OPENINGBALANCEMONTH",
+  "OPENINGBALANCEQUARTER",
+  "OPENINGBALANCEYEAR",
+  "PARALLELPERIOD",
+  "PREVIOUSDAY",
+  "PREVIOUSMONTH",
+  "PREVIOUSQUARTER",
+  "PREVIOUSYEAR",
+  "SAMEPERIODLASTYEAR",
+  "STARTOFMONTH",
+  "STARTOFQUARTER",
+  "STARTOFYEAR",
+  "TOTALMTD",
+  "TOTALQTD",
+  "TOTALYTD"
+];
+var TIME_INTELLIGENCE = new RegExp(`(?:${TIME_INTELLIGENCE_FUNCTIONS.join("|")})\\s*\\(`);
+var MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY = bpaRule(
+  "MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY",
+  (m) => m.tables.some(isDirectQueryTable) ? expressionObjects(m, ["measure", "calculationItem"]).filter((o) => TIME_INTELLIGENCE.test(o.expression)).map((o) => o.finding) : []
+);
+var RLS_FUNCTIONS = [/RIGHT\s*\(/i, /LEFT\s*\(/i, /UPPER\s*\(/i, /LOWER\s*\(/i, /FIND\s*\(/i];
+var LIMIT_ROW_LEVEL_SECURITY_LOGIC = bpaRule(
+  "LIMIT_ROW_LEVEL_SECURITY_(RLS)_LOGIC",
+  (m) => {
+    const permissions = allTablePermissions(m);
+    return tablesInScope(m).filter(
+      (t) => permissions.some(
+        (tp) => tp.table === t.name && tp.filter !== void 0 && RLS_FUNCTIONS.some((re) => re.test(tp.filter.replace(/ /g, "")))
+      )
+    ).map(finding.table);
+  }
+);
+var CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_IS_NECESSARY = bpaRule(
+  "CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_(RLS)_IS_NECESSARY",
+  (m) => allTablePermissions(m).filter(
+    (tp) => tp.filter !== void 0 && (/USERNAME\(/i.test(tp.filter) || /USERPRINCIPALNAME\(/i.test(tp.filter))
+  ).map(finding.tablePermission)
+);
+var AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE = bpaRule(
+  "AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE",
+  (m) => {
+    const permissions = allTablePermissions(m);
+    const measures = allMeasures(m);
+    return tablesInScope(m).filter((t) => {
+      if (!permissions.some((tp) => tp.table === t.name && tp.filter !== void 0)) return false;
+      const re = new RegExp(
+        `USERELATIONSHIP\\s*\\(\\s*.+?(?=\\])\\]\\s*,\\s*'*${escapeRegExp(t.name)}'*\\[`,
+        "i"
+      );
+      return measures.some((x) => re.test(x.expression));
+    }).map(finding.table);
+  }
+);
+var OBJECTS_WITH_NO_DESCRIPTION = bpaRule(
+  "OBJECTS_WITH_NO_DESCRIPTION",
+  (m) => m.tables.flatMap((t) => [
+    ...isBlank(t.description) && !t.isHidden ? [finding.table(t)] : [],
+    ...t.columns.filter((c) => isBlank(c.description) && !c.isHidden).map(finding.column),
+    ...t.measures.filter((x) => isBlank(x.description) && !x.isHidden).map(finding.measure)
+  ])
+);
+var tableRules = [
+  MODEL_SHOULD_HAVE_A_DATE_TABLE,
+  DATE_CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE,
+  REMOVE_AUTO_DATE_TABLE,
+  REDUCE_USAGE_OF_CALCULATED_TABLES,
+  REDUCE_NUMBER_OF_CALCULATED_COLUMNS,
+  UNPIVOT_PIVOTED_MONTH_DATA,
+  PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES,
+  MINIMIZE_POWER_QUERY_TRANSFORMATIONS,
+  MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS,
+  MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY,
+  LIMIT_ROW_LEVEL_SECURITY_LOGIC,
+  CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_IS_NECESSARY,
+  AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE,
+  OBJECTS_WITH_NO_DESCRIPTION
+];
+
+// ../core/src/rules/microsoft-bpa/index.ts
+var order = new Map(BPA_RULES.map((r, i) => [r.id, i]));
+var microsoftBpaRules = [
+  ...columnRules,
+  ...relationshipRules,
+  ...measureRules,
+  ...dependencyRules,
+  ...tableRules,
+  ...namingRules,
+  ...liveModelRules
+].sort((a, b) => order.get(a.id) - order.get(b.id));
+
+// ../core/src/rules/parse-issue.ts
+var PARSE_ISSUE = {
+  id: "PARSE_ISSUE",
+  name: "TMDL could not be fully parsed",
+  category: "Error Prevention",
+  severity: 3,
+  scope: ["File"],
+  description: RULE_SUMMARIES["PARSE_ISSUE"] ?? "TMDL could not be fully parsed",
+  references: ["https://learn.microsoft.com/analysis-services/tmdl/tmdl-overview"],
+  status: "builtin",
+  check: (model) => model.files.flatMap(
+    (f) => f.issues.map((issue) => ({
+      objectType: "File",
+      objectName: issue.file,
+      location: { file: issue.file, line: issue.line },
+      detail: `${issue.reason}: ${issue.text.trim()}`
+    }))
+  )
+};
+
+// ../core/src/rules/index.ts
+var defaultRules = [PARSE_ISSUE, ...microsoftBpaRules];
+
+// ../core/src/tmdl/parse.ts
+var HEADER = /^([A-Za-z_]\w*)(?:\s+(.+))?$/;
+var PROP = /^([A-Za-z_]\w*):(?:\s(.*))?$/;
+var REF = /^ref\s+([A-Za-z_]\w*)\s+(.+)$/;
+var tabIndent = (line) => {
+  let n = 0;
+  while (line[n] === "	") n++;
+  return n;
+};
+var leadingWs = (line) => line.length - line.trimStart().length;
+function splitHeader(content) {
+  let inQuote = false;
+  let eqAt = -1;
+  for (let i = 0; i < content.length; i++) {
+    const ch = content[i];
+    if (ch === "'") inQuote = !inQuote;
+    else if (ch === "=" && !inQuote) {
+      eqAt = i;
+      break;
+    }
+  }
+  const left = (eqAt >= 0 ? content.slice(0, eqAt) : content).trim();
+  const inline = eqAt >= 0 ? content.slice(eqAt + 1).trim() : "";
+  const m = HEADER.exec(left);
+  if (!m) return null;
+  return {
+    type: m[1],
+    name: m[2] === void 0 ? void 0 : unquoteName(m[2]),
+    hasEq: eqAt >= 0,
+    inline
+  };
+}
+function parseTmdl(file, text) {
+  const body = text.charCodeAt(0) === 65279 ? text.slice(1) : text;
+  const lines = body.replace(/\r\n?/g, "\n").split("\n");
+  const roots = [];
+  const issues = [];
+  const stack = [];
+  let pendingDescription = [];
+  let descriptionLine = 0;
+  let descriptionText = "";
+  let i = 0;
+  while (i < lines.length) {
+    const raw = lines[i];
+    const lineNo = i + 1;
+    if (raw.trim() === "") {
+      if (pendingDescription.length) {
+        issues.push({
+          file,
+          line: descriptionLine,
+          text: descriptionText,
+          reason: "description is not followed by a declaration"
+        });
+        pendingDescription = [];
+      }
+      i++;
+      continue;
+    }
+    const indent = tabIndent(raw);
+    const content = raw.slice(indent);
+    if (content.startsWith("///")) {
+      if (!pendingDescription.length) {
+        descriptionLine = lineNo;
+        descriptionText = raw;
+      }
+      pendingDescription.push(content.replace(/^\/\/\/ ?/, ""));
+      i++;
+      continue;
+    }
+    if (/^\s/.test(content)) {
+      issues.push({
+        file,
+        line: lineNo,
+        text: raw,
+        reason: "space indentation (TMDL requires tabs)"
+      });
+      i++;
+      continue;
+    }
+    const collectBlock = () => {
+      let j = i + 1;
+      while (j < lines.length && lines[j].trim() === "") j++;
+      if (j >= lines.length) return "";
+      const blockIndent = leadingWs(lines[j]);
+      if (blockIndent <= indent) return "";
+      const out = [];
+      let lastNonBlank = -1;
+      for (; j < lines.length; j++) {
+        const l = lines[j];
+        if (l.trim() === "") {
+          out.push("");
+          continue;
+        }
+        if (leadingWs(l) < blockIndent) break;
+        out.push(l.slice(blockIndent));
+        lastNonBlank = out.length - 1;
+      }
+      i = j - 1;
+      return out.slice(0, lastNonBlank + 1).join("\n");
+    };
+    const collectFenced = () => {
+      const out = [];
+      let j = i + 1;
+      while (j < lines.length && lines[j].trim() !== "```") {
+        out.push(lines[j]);
+        j++;
+      }
+      if (j >= lines.length)
+        issues.push({ file, line: lineNo, text: raw, reason: "unterminated ``` fence" });
+      const boundary = j < lines.length ? leadingWs(lines[j]) : 0;
+      i = j;
+      return out.map((l) => l.slice(Math.min(boundary, leadingWs(l)))).join("\n");
+    };
+    const base = {
+      props: {},
+      children: [],
+      file,
+      line: lineNo,
+      indent
+    };
+    let node;
+    let m;
+    if (m = REF.exec(content)) {
+      node = { ...base, kind: "ref", type: m[1].toLowerCase(), name: unquoteName(m[2]) };
+    } else if (m = PROP.exec(content)) {
+      node = { ...base, kind: "prop", type: m[1].toLowerCase(), value: unquoteValue(m[2] ?? "") };
+    } else {
+      const h = splitHeader(content);
+      if (!h) {
+        issues.push({ file, line: lineNo, text: raw, reason: "unrecognized line" });
+        i++;
+        continue;
+      }
+      if (h.hasEq) {
+        const value = h.inline === "```" ? collectFenced() : h.inline === "" ? collectBlock() : h.inline;
+        node = h.name === void 0 ? { ...base, kind: "expr", type: h.type.toLowerCase(), value } : { ...base, kind: "object", type: h.type.toLowerCase(), name: h.name, value };
+      } else if (h.name !== void 0) {
+        node = { ...base, kind: "object", type: h.type.toLowerCase(), name: h.name };
+      } else {
+        node = { ...base, kind: "flag", type: h.type.toLowerCase() };
+      }
+    }
+    if (pendingDescription.length) {
+      node.description = pendingDescription.join("\n");
+      pendingDescription = [];
+    }
+    stack.length = indent;
+    const parent = indent > 0 ? stack[indent - 1] : void 0;
+    if (indent > 0 && !parent) {
+      issues.push({ file, line: lineNo, text: raw, reason: "orphan indentation" });
+      i++;
+      continue;
+    }
+    if (parent) {
+      if (node.kind === "prop" || node.kind === "expr") parent.props[node.type] = node.value ?? "";
+      else if (node.kind === "flag") parent.props[node.type] = true;
+      parent.children.push(node);
+    } else {
+      roots.push(node);
+    }
+    stack[indent] = node;
+    i++;
+  }
+  return { file, roots, issues, lineCount: lines.length };
+}
+
+// ../core/src/rules/types.ts
+var CATEGORY_ORDER = [
+  "Performance",
+  "Error Prevention",
+  "DAX Expressions",
+  "Maintenance",
+  "Formatting",
+  "Naming Conventions"
+];
+var SEVERITY_LABEL = {
+  1: "info",
+  2: "warning",
+  3: "error"
+};
+
+// ../core/src/engine/rank.ts
+var effectiveSeverity = (rule, config) => config.severity.get(rule.id) ?? rule.severity;
+function summarizeRule(rule, config) {
+  return {
+    id: rule.id,
+    name: rule.name,
+    category: rule.category,
+    severity: effectiveSeverity(rule, config),
+    slug: slug(rule.id),
+    url: ruleUrl(rule.id),
+    status: rule.status
+  };
+}
+function rank(findings, rules, config) {
+  const byId2 = new Map(rules.map((r) => [r.id, r]));
+  const groups = /* @__PURE__ */ new Map();
+  for (const f of findings) {
+    let g = groups.get(f.ruleId);
+    if (!g) {
+      const rule = byId2.get(f.ruleId);
+      if (!rule) throw new Error(`Finding for unknown rule ${f.ruleId}`);
+      g = { rule: summarizeRule(rule, config), findings: [] };
+      groups.set(f.ruleId, g);
+    }
+    g.findings.push(f);
+  }
+  return [...groups.values()].sort(
+    (a, b) => b.rule.severity - a.rule.severity || CATEGORY_ORDER.indexOf(a.rule.category) - CATEGORY_ORDER.indexOf(b.rule.category) || b.findings.length - a.findings.length || a.rule.id.localeCompare(b.rule.id)
+  );
+}
+
+// ../core/src/engine/run.ts
+function runRules(model, indexes, rules, config) {
+  const result = {
+    findings: [],
+    rulesRun: [],
+    rulesSkipped: [],
+    ruleErrors: [],
+    ignored: 0
+  };
+  for (const rule of rules) {
+    if (config.disabled.has(rule.id)) {
+      result.rulesSkipped.push({ id: rule.id, reason: "disabled" });
+      continue;
+    }
+    if (rule.status === "needsLiveModel") {
+      result.rulesSkipped.push({ id: rule.id, reason: "needsLiveModel" });
+      continue;
+    }
+    result.rulesRun.push(rule.id);
+    let raw;
+    try {
+      raw = rule.check(model, { indexes });
+    } catch (e) {
+      result.ruleErrors.push({ id: rule.id, message: e instanceof Error ? e.message : String(e) });
+      continue;
+    }
+    for (const f of raw) {
+      if (isIgnored(f.object, rule.id)) {
+        result.ignored++;
+        continue;
+      }
+      const out = { ruleId: rule.id, objectType: f.objectType, objectName: f.objectName };
+      if (f.location) out.location = f.location;
+      if (f.detail !== void 0) out.detail = f.detail;
+      result.findings.push(out);
+    }
+  }
+  return result;
+}
+
+// ../core/src/engine/lint.ts
+function lint(files, options = {}) {
+  const rules = options.rules ?? defaultRules;
+  const { config, unknownRules } = bindConfig(
+    isResolvedConfig(options.config) ? options.config : resolveConfig(options.config),
+    rules
+  );
+  const parsed = files.map((f) => parseTmdl(f.path, f.text));
+  const model = buildModel(parsed);
+  const indexes = buildIndexes(model);
+  const run = runRules(model, indexes, rules, config);
+  const groups = rank(run.findings, rules, config);
+  const count = (severity) => groups.filter((g) => g.rule.severity === severity).reduce((n, g) => n + g.findings.length, 0);
+  const summary = {
+    files: files.length,
+    findings: run.findings.length,
+    errors: count(3),
+    warnings: count(2),
+    infos: count(1),
+    rulesRun: run.rulesRun.length,
+    rulesSkipped: run.rulesSkipped,
+    ruleErrors: run.ruleErrors,
+    ignored: run.ignored,
+    unknownRules
+  };
+  const failed = config.failOn !== null && groups.some((g) => g.rule.severity >= config.failOn);
+  return { model, findings: run.findings, groups, summary, failed };
+}
+
+// ../core/src/format/json.ts
+function formatJson(result, options = {}) {
+  const doc = {
+    version: 1,
+    tool: { name: "pbiplint", version: options.toolVersion ?? VERSION },
+    summary: result.summary,
+    groups: result.groups.map((g) => ({
+      rule: g.rule,
+      count: g.findings.length,
+      findings: g.findings.map((f) => ({
+        objectType: f.objectType,
+        objectName: f.objectName,
+        ...f.location ? { file: f.location.file, line: f.location.line } : {},
+        ...f.detail !== void 0 ? { detail: f.detail } : {}
+      }))
+    }))
+  };
+  return JSON.stringify(doc, null, 2) + "\n";
+}
+
+// ../core/src/format/text.ts
+var SEVERITY_TAG = { 3: "ERROR", 2: "WARN ", 1: "INFO " };
+var locationOf = (f) => f.location ? `${f.location.file}:${f.location.line}` : "";
+var plural = (n, noun) => `${n} ${noun}${n === 1 ? "" : "s"}`;
+function summaryLine(result) {
+  const s = result.summary;
+  return `${plural(s.findings, "finding")} (${plural(s.errors, "error")}, ${plural(s.warnings, "warning")}, ${s.infos} info) in ${plural(s.files, "file")}`;
+}
+function skippedLine(result) {
+  const s = result.summary;
+  const live = s.rulesSkipped.filter((r) => r.reason === "needsLiveModel").length;
+  const disabled = s.rulesSkipped.filter((r) => r.reason === "disabled").length;
+  const parts = [`${plural(s.rulesRun, "rule")} run`];
+  if (live) parts.push(`${plural(live, "rule")} skipped (need a live model)`);
+  if (disabled) parts.push(`${plural(disabled, "rule")} disabled by config`);
+  if (s.ignored) parts.push(`${plural(s.ignored, "finding")} ignored by annotation`);
+  return parts.join(", ");
+}
+var topGroups = (result, n = 5) => result.groups.slice(0, n);
+function formatText(result, _options = {}) {
+  const out = [`pbiplint: ${summaryLine(result)}`, skippedLine(result), ""];
+  if (result.groups.length === 0) {
+    out.push("No findings.", "");
+  } else {
+    out.push("Fix these first:");
+    topGroups(result).forEach(
+      (g, i) => out.push(
+        `  ${i + 1}. ${g.rule.name}  (${plural(g.findings.length, SEVERITY_LABEL[g.rule.severity])})`
+      )
+    );
+    out.push("");
+    for (const g of result.groups) {
+      out.push(
+        `${SEVERITY_TAG[g.rule.severity]}  ${g.rule.name}  ${g.rule.id}  (${g.findings.length})`
+      );
+      out.push(`       ${g.rule.url}`);
+      const width = Math.max(...g.findings.map((f) => f.objectName.length));
+      const locWidth = Math.max(...g.findings.map((f) => locationOf(f).length));
+      for (const f of g.findings) {
+        const cols = [f.objectName.padEnd(width), locationOf(f).padEnd(locWidth), f.detail ?? ""];
+        out.push(`       ${cols.join("  ")}`.trimEnd());
+      }
+      out.push("");
+    }
+  }
+  if (result.summary.ruleErrors.length) {
+    out.push("Rule errors (please report these):");
+    for (const e of result.summary.ruleErrors) out.push(`  ${e.id}: ${e.message}`);
+    out.push("");
+  }
+  return out.join("\n");
+}
+
+// ../core/src/format/markdown.ts
+var cell = (s) => s.replace(/\|/g, "\\|").replace(/\n/g, " ");
+function formatMarkdown(result, _options = {}) {
+  const out = [
+    "# pbiplint report",
+    "",
+    `${summaryLine(result)}. ${skippedLine(result)}.`,
+    ""
+  ];
+  if (result.groups.length === 0) {
+    out.push("No findings.", "");
+    return out.join("\n");
+  }
+  out.push("## Fix these first", "");
+  topGroups(result).forEach(
+    (g, i) => out.push(`${i + 1}. **${g.rule.name}** (${g.findings.length}) [${g.rule.id}](${g.rule.url})`)
+  );
+  out.push("");
+  for (const g of result.groups) {
+    out.push(
+      `## ${SEVERITY_LABEL[g.rule.severity].toUpperCase()}: ${g.rule.name} (${g.findings.length})`,
+      ""
+    );
+    out.push(`[${g.rule.id}](${g.rule.url}) \xB7 ${g.rule.category}`, "");
+    out.push("| Object | Type | Location | Detail |", "|---|---|---|---|");
+    for (const f of g.findings)
+      out.push(
+        `| \`${cell(f.objectName)}\` | ${f.objectType} | ${locationOf(f)} | ${cell(f.detail ?? "")} |`
+      );
+    out.push("");
+  }
+  return out.join("\n");
+}
+
+// ../core/src/format/sarif.ts
+var LEVEL = {
+  3: "error",
+  2: "warning",
+  1: "note"
+};
+var plain = (markdown) => markdown.replace(/`/g, "");
+function formatSarif(result, options = {}) {
+  const byId2 = new Map((options.rules ?? defaultRules).map((r) => [r.id, r]));
+  const prefix = options.pathPrefix ?? "";
+  const encodePath = (p) => p.split("/").map(encodeURIComponent).join("/");
+  const uri = (file) => encodePath(prefix ? `${prefix}/${file}` : file);
+  const helpFor = (id, description, url) => options.help?.[id] ?? {
+    text: `${plain(description)}
+
+Read more: ${url}`,
+    markdown: `${description}
+
+Read more: ${url}`
+  };
+  const rules = result.groups.map((g) => {
+    const full = byId2.get(g.rule.id);
+    return {
+      id: g.rule.id,
+      name: g.rule.name,
+      shortDescription: { text: g.rule.name },
+      fullDescription: full ? { text: plain(full.description), markdown: full.description } : { text: g.rule.name },
+      help: helpFor(g.rule.id, full?.description ?? g.rule.name, g.rule.url),
+      helpUri: g.rule.url,
+      defaultConfiguration: { level: LEVEL[g.rule.severity] },
+      properties: { category: g.rule.category }
+    };
+  });
+  const results = result.groups.flatMap(
+    (g, ruleIndex) => g.findings.map((f) => ({
+      ruleId: g.rule.id,
+      ruleIndex,
+      level: LEVEL[g.rule.severity],
+      message: { text: `${f.objectName}: ${g.rule.name}${f.detail ? ` (${f.detail})` : ""}` },
+      ...f.location ? {
+        locations: [
+          {
+            physicalLocation: {
+              artifactLocation: { uri: uri(f.location.file) },
+              region: { startLine: f.location.line }
+            }
+          }
+        ]
+      } : {}
+    }))
+  );
+  const doc = {
+    $schema: "https://json.schemastore.org/sarif-2.1.0.json",
+    version: "2.1.0",
+    runs: [
+      {
+        tool: {
+          driver: {
+            name: "pbiplint",
+            version: options.toolVersion ?? VERSION,
+            informationUri: "https://pbiplint.com",
+            rules
+          }
+        },
+        results
+      }
+    ]
+  };
+  return JSON.stringify(doc, null, 2) + "\n";
+}
+
+// ../core/src/format/index.ts
+var FORMATS = ["text", "json", "markdown", "sarif"];
+function formatResult(name, result, options = {}) {
+  switch (name) {
+    case "text":
+      return formatText(result, options);
+    case "json":
+      return formatJson(result, options);
+    case "markdown":
+      return formatMarkdown(result, options);
+    case "sarif":
+      return formatSarif(result, options);
+    default:
+      throw new Error(`Unknown format: ${String(name)}`);
+  }
+}
+
+// src/args.ts
+var UsageError = class extends Error {
+};
+var FAIL_ON = ["error", "warning", "info", "none"];
+function parseArgs(argv) {
+  const opts = { command: "lint", format: "text", sample: false };
+  const positional = [];
+  for (let i = 0; i < argv.length; i++) {
+    let arg = argv[i];
+    let inlineValue;
+    const eq = arg.indexOf("=");
+    if (arg.startsWith("--") && eq > 0) {
+      inlineValue = arg.slice(eq + 1);
+      arg = arg.slice(0, eq);
+    }
+    const value = () => {
+      if (inlineValue !== void 0) return inlineValue;
+      const v = argv[++i];
+      if (v === void 0) throw new UsageError(`${arg} needs a value`);
+      return v;
+    };
+    switch (arg) {
+      case "--help":
+      case "-h":
+        return { ...opts, command: "help" };
+      case "--version":
+      case "-v":
+        return { ...opts, command: "version" };
+      case "--sample":
+        opts.sample = true;
+        break;
+      case "--format": {
+        const f = value();
+        if (!FORMATS.includes(f))
+          throw new UsageError(`--format must be one of ${FORMATS.join(", ")}`);
+        opts.format = f;
+        break;
+      }
+      case "--fail-on": {
+        const f = value();
+        if (!FAIL_ON.includes(f))
+          throw new UsageError(`--fail-on must be one of ${FAIL_ON.join(", ")}`);
+        opts.failOn = f;
+        break;
+      }
+      case "--config":
+        opts.config = value();
+        break;
+      case "--output":
+      case "-o":
+        opts.output = value();
+        break;
+      default:
+        if (arg.startsWith("-")) throw new UsageError(`Unknown option ${arg}`);
+        positional.push(arg);
+    }
+  }
+  if (positional[0] === "rules") {
+    if (positional.length > 1) throw new UsageError("rules takes no arguments");
+    return { ...opts, command: "rules" };
+  }
+  if (positional.length > 1) throw new UsageError("Expected one path");
+  if (positional.length === 1 && opts.sample)
+    throw new UsageError("Give either a path or --sample, not both");
+  if (positional.length === 0 && !opts.sample) return { ...opts, command: "help" };
+  if (positional.length === 1) opts.path = positional[0];
+  return opts;
+}
+var HELP = `Usage: pbiplint <path> [options]
+       pbiplint --sample [options]
+       pbiplint rules
+
+Lint a Power BI semantic model (TMDL) for best-practice violations. Nothing is uploaded.
+
+<path>              a .SemanticModel folder, a PBIP folder, a definition folder, or one .tmdl file
+--sample            lint the bundled sample project instead of a path
+--format <name>     text (default), json, sarif, markdown
+--fail-on <level>   error (default), warning, info, none: lowest severity that exits 1
+--config <file>     pbiplint.config.json to use (default: nearest one above the model)
+--output <file>     write the report to a file instead of stdout (a one-line summary goes to stderr)
+--help, --version
+
+Exit codes: 0 no findings at or above --fail-on, 1 findings, 2 usage or input error.
+Rule pages: https://pbiplint.com/rules/
+`;
+
+// src/config.ts
+import { existsSync, readFileSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+var CONFIG_FILE = "pbiplint.config.json";
+function readConfig(path) {
+  let parsed;
+  try {
+    parsed = JSON.parse(readFileSync(path, "utf8"));
+  } catch (e) {
+    throw new UsageError(`Could not read ${path}: ${e instanceof Error ? e.message : String(e)}`);
+  }
+  if (typeof parsed !== "object" || parsed === null || Array.isArray(parsed))
+    throw new UsageError(`${path}: pbiplint.config.json must be a JSON object`);
+  return parsed;
+}
+function findConfig(startDir, explicit) {
+  if (explicit) {
+    const path = resolve(explicit);
+    if (!existsSync(path)) throw new UsageError(`${explicit} does not exist`);
+    return { path, config: readConfig(path) };
+  }
+  let dir = resolve(startDir);
+  for (; ; ) {
+    const candidate = join(dir, CONFIG_FILE);
+    if (existsSync(candidate)) return { path: candidate, config: readConfig(candidate) };
+    const parent = dirname(dir);
+    if (parent === dir) return { config: {} };
+    dir = parent;
+  }
+}
+
+// src/sample.ts
+import { existsSync as existsSync2 } from "node:fs";
+import { dirname as dirname2, join as join2 } from "node:path";
+import { fileURLToPath } from "node:url";
+function sampleDir() {
+  const here = dirname2(fileURLToPath(import.meta.url));
+  for (const candidate of [
+    join2(here, "..", "sample"),
+    join2(here, "..", "..", "sample"),
+    join2(here, "..", "..", "..", "examples", "messy-sales")
+  ]) {
+    if (existsSync2(join2(candidate, "definition"))) return candidate;
+  }
+  throw new Error("Bundled sample project not found");
+}
+
+// src/rule-help.data.ts
+var RULE_HELP = {
+  ADD_DATA_CATEGORY_FOR_COLUMNS: {
+    text: "Why it matters\n\nMap visuals bind a field by its data category, not by its name. Without one, a City column is geocoded by guesswork and can land in the wrong country when names repeat, and Latitude and Longitude are treated as ordinary numbers, so they are summed by default and the map draws a single point in the ocean. The category lives on the model, so every report inherits it once it is set, and it costs nothing at refresh or query time.\n\nHow to fix it\n\nIn Power BI Desktop, select the column, open Column tools, and choose the Data category. In the TMDL file, add dataCategory: City, dataCategory: Country, dataCategory: Continent, dataCategory: Latitude, or dataCategory: Longitude under the column.\n\nQuirks\n\n- The name test is a substring, so a text column called City Code or Country Manager fires too. Latitude and Longitude must match the whole name.\n\nRead more: https://pbiplint.com/rules/add-data-category-for-columns",
+    markdown: "### Why it matters\n\nMap visuals bind a field by its data category, not by its name. Without one, a City column is geocoded by guesswork and can land in the wrong country when names repeat, and Latitude and Longitude are treated as ordinary numbers, so they are summed by default and the map draws a single point in the ocean. The category lives on the model, so every report inherits it once it is set, and it costs nothing at refresh or query time.\n\n### How to fix it\n\nIn Power BI Desktop, select the column, open Column tools, and choose the Data category. In the TMDL file, add `dataCategory: City`, `dataCategory: Country`, `dataCategory: Continent`, `dataCategory: Latitude`, or `dataCategory: Longitude` under the column.\n\n### Quirks\n\n- The name test is a substring, so a text column called City Code or Country Manager fires too. Latitude and Longitude must match the whole name.\n\nRead more: https://pbiplint.com/rules/add-data-category-for-columns"
+  },
+  "AVOID_BI-DIRECTIONAL_RELATIONSHIPS_AGAINST_HIGH-CARDINALITY_COLUMNS": {
+    text: `Why it matters
+
+A bi-directional relationship makes the engine propagate filters both ways on every query that touches either table. On a key with a few hundred values that is cheap. On a key with hundreds of thousands of values, the expanded filter list is built and applied on every evaluation, and the cost shows up as slow visuals that look innocent in the model view.
+
+How to fix it
+
+Find the cardinality with DAX Studio's VertiPaq Analyzer, or with a query such as EVALUATE ROW("n", DISTINCTCOUNT('Sales'[Order ID])) in Power BI Desktop's DAX query view. Then set the relationship back to single direction and, where one report needs the reverse filter, get it from a measure with CROSSFILTER or TREATAS. If you already use Tabular Editor, the script in the links loads the same statistics into its Best Practice Analyzer, which can then run this rule directly.
+
+pbiplint cannot evaluate this rule from files; it appears in pbiplint rules as needing a live model.
+
+Read more: https://pbiplint.com/rules/avoid-bi-directional-relationships-against-high-cardinality-columns`,
+    markdown: "### Why it matters\n\nA bi-directional relationship makes the engine propagate filters both ways on every query that touches either table. On a key with a few hundred values that is cheap. On a key with hundreds of thousands of values, the expanded filter list is built and applied on every evaluation, and the cost shows up as slow visuals that look innocent in the model view.\n\n### How to fix it\n\nFind the cardinality with DAX Studio's VertiPaq Analyzer, or with a query such as `EVALUATE ROW(\"n\", DISTINCTCOUNT('Sales'[Order ID]))` in Power BI Desktop's DAX query view. Then set the relationship back to single direction and, where one report needs the reverse filter, get it from a measure with CROSSFILTER or TREATAS. If you already use Tabular Editor, the script in the links loads the same statistics into its Best Practice Analyzer, which can then run this rule directly.\n\npbiplint cannot evaluate this rule from files; it appears in `pbiplint rules` as needing a live model.\n\nRead more: https://pbiplint.com/rules/avoid-bi-directional-relationships-against-high-cardinality-columns"
+  },
+  AVOID_DUPLICATE_MEASURES: {
+    text: "Why it matters\n\nTwo names for one calculation split the reader's trust: nobody can tell which is the real one, reports end up using both, and the next change gets made to one copy only. When both appear in the same visual the engine also evaluates them separately, so the duplicate costs query time as well as confusion.\n\nHow to fix it\n\nKeep one measure and delete the other. If existing reports depend on both names, keep the second one for now as a plain reference to the first, Sales Amount = [Total Sales], and retire it once the reports are moved.\n\nQuirks\n\n- The comparison is exact apart from whitespace. Two measures that differ only in a comment or in letter case are not duplicates to this rule.\n\nRead more: https://pbiplint.com/rules/avoid-duplicate-measures",
+    markdown: "### Why it matters\n\nTwo names for one calculation split the reader's trust: nobody can tell which is the real one, reports end up using both, and the next change gets made to one copy only. When both appear in the same visual the engine also evaluates them separately, so the duplicate costs query time as well as confusion.\n\n### How to fix it\n\nKeep one measure and delete the other. If existing reports depend on both names, keep the second one for now as a plain reference to the first, `Sales Amount = [Total Sales]`, and retire it once the reports are moved.\n\n### Quirks\n\n- The comparison is exact apart from whitespace. Two measures that differ only in a comment or in letter case are not duplicates to this rule.\n\nRead more: https://pbiplint.com/rules/avoid-duplicate-measures"
+  },
+  "AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS": {
+    text: "Why it matters\n\nEach bi-directional or many-to-many relationship adds a filter path the engine has to consider on every query. A few in the right places are fine. When they are a third of the model, most queries pay for filter propagation they do not need, and the model starts to show ambiguity: two routes between the same tables, the engine picking one, and totals that stop adding up.\n\nHow to fix it\n\nIn the model view, set each bi-directional relationship back to single direction unless a report needs the reverse filter; where one does, get it from a measure with CROSSFILTER instead. Replace many-to-many relationships with a bridge table that relates many-to-one to both sides. In the relationships TMDL file the properties are crossFilteringBehavior: bothDirections and the two cardinality lines.\n\nQuirks\n\n- A relationship that is both bi-directional and many-to-many counts twice.\n\nRead more: https://pbiplint.com/rules/avoid-excessive-bi-directional-or-many-to-many-relationships",
+    markdown: "### Why it matters\n\nEach bi-directional or many-to-many relationship adds a filter path the engine has to consider on every query. A few in the right places are fine. When they are a third of the model, most queries pay for filter propagation they do not need, and the model starts to show ambiguity: two routes between the same tables, the engine picking one, and totals that stop adding up.\n\n### How to fix it\n\nIn the model view, set each bi-directional relationship back to single direction unless a report needs the reverse filter; where one does, get it from a measure with CROSSFILTER instead. Replace many-to-many relationships with a bridge table that relates many-to-one to both sides. In the relationships TMDL file the properties are `crossFilteringBehavior: bothDirections` and the two cardinality lines.\n\n### Quirks\n\n- A relationship that is both bi-directional and many-to-many counts twice.\n\nRead more: https://pbiplint.com/rules/avoid-excessive-bi-directional-or-many-to-many-relationships"
+  },
+  AVOID_FLOATING_POINT_DATA_TYPES: {
+    text: "Why it matters\n\nDouble is binary floating point, so values like 0.1 have no exact representation and sums drift in the last digits. Two totals that should match can differ by a fraction of a cent, and a money column stored as Double compresses worse than the same values as Fixed Decimal Number, so it costs memory as well. Fixed Decimal Number stores four decimal places exactly, and Whole Number compresses best of all.\n\nHow to fix it\n\nIn Power Query, change the column type to Fixed Decimal Number or Whole Number so the conversion happens before load. Changing it in the model view works too. In the TMDL file the property is dataType: decimal or dataType: int64. Keep Double only for values that need more than four decimal places, such as scientific measurements.\n\nRead more: https://pbiplint.com/rules/avoid-floating-point-data-types",
+    markdown: "### Why it matters\n\nDouble is binary floating point, so values like 0.1 have no exact representation and sums drift in the last digits. Two totals that should match can differ by a fraction of a cent, and a money column stored as Double compresses worse than the same values as Fixed Decimal Number, so it costs memory as well. Fixed Decimal Number stores four decimal places exactly, and Whole Number compresses best of all.\n\n### How to fix it\n\nIn Power Query, change the column type to Fixed Decimal Number or Whole Number so the conversion happens before load. Changing it in the model view works too. In the TMDL file the property is `dataType: decimal` or `dataType: int64`. Keep Double only for values that need more than four decimal places, such as scientific measurements.\n\nRead more: https://pbiplint.com/rules/avoid-floating-point-data-types"
+  },
+  AVOID_INVALID_DESCRIPTION_CHARACTERS: {
+    text: "Why it matters\n\nA control character in a description is invisible in Power BI Desktop and fails the deployment: the service rejects the metadata and the publish stops with an error that names no object. Finding the character by eye is close to impossible.\n\nHow to fix it\n\nRetype the description in Desktop, or remove the character from the /// comment lines above the object in the TMDL file. A text editor that shows invisible characters makes it easy to spot.\n\nQuirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/avoid-invalid-description-characters",
+    markdown: "### Why it matters\n\nA control character in a description is invisible in Power BI Desktop and fails the deployment: the service rejects the metadata and the publish stops with an error that names no object. Finding the character by eye is close to impossible.\n\n### How to fix it\n\nRetype the description in Desktop, or remove the character from the `///` comment lines above the object in the TMDL file. A text editor that shows invisible characters makes it easy to spot.\n\n### Quirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/avoid-invalid-description-characters"
+  },
+  AVOID_INVALID_NAME_CHARACTERS: {
+    text: "Why it matters\n\nA control character in a name is invisible in Power BI Desktop and fails the deployment: the service rejects the metadata and the publish stops with an error that names no object. Every DAX reference and report binding also has to reproduce the hidden character exactly, so the object is fragile even before it is deployed.\n\nHow to fix it\n\nRename the object in Desktop, or edit the name in the TMDL file. A text editor that shows invisible characters makes it easy to spot.\n\nQuirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/avoid-invalid-name-characters",
+    markdown: "### Why it matters\n\nA control character in a name is invisible in Power BI Desktop and fails the deployment: the service rejects the metadata and the publish stops with an error that names no object. Every DAX reference and report binding also has to reproduce the hidden character exactly, so the object is fragile even before it is deployed.\n\n### How to fix it\n\nRename the object in Desktop, or edit the name in the TMDL file. A text editor that shows invisible characters makes it easy to spot.\n\n### Quirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/avoid-invalid-name-characters"
+  },
+  AVOID_STRUCTURED_DATA_SOURCES_WITH_PROVIDER_PARTITIONS: {
+    text: 'Why it matters\n\nPower BI supports two combinations: a Power Query partition against any data source, or a legacy provider partition against a legacy provider data source. A provider partition against a structured data source is a mix the service refuses, so the model fails to deploy or refresh. Power BI Desktop never produces the combination; it appears in models migrated from Analysis Services or assembled by hand.\n\nHow to fix it\n\nRewrite the partition as Power Query, which is what Desktop would write: in the TMDL file, change partition Sales = query to partition Sales = m and replace the query text with an M expression such as let Source = Sql.Database("server", "db") in Source{[Schema="dbo",Item="Sales"]}[Data]. The other option is to change the data source itself to a provider data source so both halves are legacy; the elegantbi post in the links shows that conversion with Tabular Editor.\n\nRead more: https://pbiplint.com/rules/avoid-structured-data-sources-with-provider-partitions',
+    markdown: '### Why it matters\n\nPower BI supports two combinations: a Power Query partition against any data source, or a legacy provider partition against a legacy provider data source. A provider partition against a structured data source is a mix the service refuses, so the model fails to deploy or refresh. Power BI Desktop never produces the combination; it appears in models migrated from Analysis Services or assembled by hand.\n\n### How to fix it\n\nRewrite the partition as Power Query, which is what Desktop would write: in the TMDL file, change `partition Sales = query` to `partition Sales = m` and replace the query text with an M expression such as `let Source = Sql.Database("server", "db") in Source{[Schema="dbo",Item="Sales"]}[Data]`. The other option is to change the data source itself to a provider data source so both halves are legacy; the elegantbi post in the links shows that conversion with Tabular Editor.\n\nRead more: https://pbiplint.com/rules/avoid-structured-data-sources-with-provider-partitions'
+  },
+  AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE: {
+    text: "Why it matters\n\nWhen a role filters a table, the engine has to apply that filter through the active relationship, and USERELATIONSHIP asks it to swap in an inactive one. The two instructions conflict, so the measure fails for every user in the role while it works for the model owner, who tests without roles. That is a bug you find after publishing.\n\nHow to fix it\n\nKeep row-level security and USERELATIONSHIP on different tables. Either move the filter to another table in the same role, or replace USERELATIONSHIP with a second copy of the dimension that has an active relationship of its own, which is the usual answer for an order date and a ship date.\n\nQuirks\n\n- Only the second argument of USERELATIONSHIP is compared, and only measures are scanned. A calculation item that calls USERELATIONSHIP is not checked, and a measure that names the secured table as the first argument passes.\n\nRead more: https://pbiplint.com/rules/avoid-the-userelationship-function-and-rls-against-the-same-table",
+    markdown: "### Why it matters\n\nWhen a role filters a table, the engine has to apply that filter through the active relationship, and USERELATIONSHIP asks it to swap in an inactive one. The two instructions conflict, so the measure fails for every user in the role while it works for the model owner, who tests without roles. That is a bug you find after publishing.\n\n### How to fix it\n\nKeep row-level security and USERELATIONSHIP on different tables. Either move the filter to another table in the same role, or replace USERELATIONSHIP with a second copy of the dimension that has an active relationship of its own, which is the usual answer for an order date and a ship date.\n\n### Quirks\n\n- Only the second argument of USERELATIONSHIP is compared, and only measures are scanned. A calculation item that calls USERELATIONSHIP is not checked, and a measure that names the secured table as the first argument passes.\n\nRead more: https://pbiplint.com/rules/avoid-the-userelationship-function-and-rls-against-the-same-table"
+  },
+  "AVOID_USING_'1-(X/Y)'_SYNTAX": {
+    text: "Why it matters\n\nWritten that way the measure always returns a value. When there are no rows, the division is blank, one minus blank is one, and every empty cell in the matrix shows 100 percent. The visual fills with rows that should not be there, and the query does extra work to produce them. Written as a single DIVIDE over the difference, the measure is blank when the data is blank and the engine skips those rows.\n\nHow to fix it\n\nRewrite 1 - x / y as DIVIDE(y - x, y), and hold the shared denominator in a variable when it is used twice:\n\nMargin % =\nVAR Sales = SUM ( Sales[Amount] )\nRETURN DIVIDE ( Sales - SUM ( Sales[Cost] ), Sales )\n\nQuirks\n\n- The pattern needs SUM as the numerator, or DIVIDE right after the number. 1 - [Cost] / [Sales] and 1 - AVERAGE(...) / ... are not matched.\n- Table and column names must contain only letters, digits, spaces, and underscores for the SUM form to match.\n\nRead more: https://pbiplint.com/rules/avoid-using-1-x-y-syntax",
+    markdown: "### Why it matters\n\nWritten that way the measure always returns a value. When there are no rows, the division is blank, one minus blank is one, and every empty cell in the matrix shows 100 percent. The visual fills with rows that should not be there, and the query does extra work to produce them. Written as a single DIVIDE over the difference, the measure is blank when the data is blank and the engine skips those rows.\n\n### How to fix it\n\nRewrite `1 - x / y` as `DIVIDE(y - x, y)`, and hold the shared denominator in a variable when it is used twice:\n\n```\nMargin % =\nVAR Sales = SUM ( Sales[Amount] )\nRETURN DIVIDE ( Sales - SUM ( Sales[Cost] ), Sales )\n```\n\n### Quirks\n\n- The pattern needs SUM as the numerator, or DIVIDE right after the number. `1 - [Cost] / [Sales]` and `1 - AVERAGE(...) / ...` are not matched.\n- Table and column names must contain only letters, digits, spaces, and underscores for the SUM form to match.\n\nRead more: https://pbiplint.com/rules/avoid-using-1-x-y-syntax"
+  },
+  "AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY": {
+    text: "Why it matters\n\nA security filter is pushed through every relationship leading away from the secured table, on every query, for every user in the role. Through a many-to-many relationship that push is an expansion over the distinct values on both sides rather than a lookup, and it runs before the query proper. The slowdown grows with every such hop, and the model owner never sees it, because Desktop tests without roles.\n\nHow to fix it\n\nPut the security filter on a small security table that relates many-to-one to a single dimension, and let the dimension filter the facts through ordinary one-to-many relationships. The elegantbi post in the links walks through the patterns.\n\nQuirks\n\n- Any row-level security filter counts, not only dynamic filters that call USERNAME or USERPRINCIPALNAME.\n- Calculated tables are out of scope.\n\nRead more: https://pbiplint.com/rules/avoid-using-many-to-many-relationships-on-tables-used-for-dynamic-row-level-security",
+    markdown: "### Why it matters\n\nA security filter is pushed through every relationship leading away from the secured table, on every query, for every user in the role. Through a many-to-many relationship that push is an expansion over the distinct values on both sides rather than a lookup, and it runs before the query proper. The slowdown grows with every such hop, and the model owner never sees it, because Desktop tests without roles.\n\n### How to fix it\n\nPut the security filter on a small security table that relates many-to-one to a single dimension, and let the dimension filter the facts through ordinary one-to-many relationships. The elegantbi post in the links walks through the patterns.\n\n### Quirks\n\n- Any row-level security filter counts, not only dynamic filters that call USERNAME or USERPRINCIPALNAME.\n- Calculated tables are out of scope.\n\nRead more: https://pbiplint.com/rules/avoid-using-many-to-many-relationships-on-tables-used-for-dynamic-row-level-security"
+  },
+  AVOID_USING_THE_IFERROR_FUNCTION: {
+    text: "Why it matters\n\nIFERROR makes the engine evaluate the expression row by row so it can catch a failure, which switches off the bulk evaluation that makes DAX fast. Most uses guard a division, and DIVIDE handles that case without the penalty. The rest usually hide a data problem, such as text in a numeric column, that is better fixed in Power Query where the failure cannot happen.\n\nHow to fix it\n\nReplace IFERROR([A] / [B], 0) with DIVIDE([A], [B], 0). For type conversions, clean the column in Power Query so the conversion cannot fail. If a guard is unavoidable, test the condition with IF instead of catching the error.\n\nRead more: https://pbiplint.com/rules/avoid-using-the-iferror-function",
+    markdown: "### Why it matters\n\nIFERROR makes the engine evaluate the expression row by row so it can catch a failure, which switches off the bulk evaluation that makes DAX fast. Most uses guard a division, and DIVIDE handles that case without the penalty. The rest usually hide a data problem, such as text in a numeric column, that is better fixed in Power Query where the failure cannot happen.\n\n### How to fix it\n\nReplace `IFERROR([A] / [B], 0)` with `DIVIDE([A], [B], 0)`. For type conversions, clean the column in Power Query so the conversion cannot fail. If a guard is unavoidable, test the condition with IF instead of catching the error.\n\nRead more: https://pbiplint.com/rules/avoid-using-the-iferror-function"
+  },
+  CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS: {
+    text: "Why it matters\n\nA calculation group with no items still appears in the field list as a table with one column, and dropping that column on a visual does nothing. It is usually a group that was started and abandoned, and it puzzles whoever finds it later.\n\nHow to fix it\n\nAdd the calculation items, or delete the table. In the TMDL file a calculation group is a table with a calculationGroup block, and each item is a calculationItem inside it.\n\nRead more: https://pbiplint.com/rules/calculation-groups-with-no-calculation-items",
+    markdown: "### Why it matters\n\nA calculation group with no items still appears in the field list as a table with one column, and dropping that column on a visual does nothing. It is usually a group that was started and abandoned, and it puzzles whoever finds it later.\n\n### How to fix it\n\nAdd the calculation items, or delete the table. In the TMDL file a calculation group is a table with a `calculationGroup` block, and each item is a `calculationItem` inside it.\n\nRead more: https://pbiplint.com/rules/calculation-groups-with-no-calculation-items"
+  },
+  "CHECK_IF_BI-DIRECTIONAL_AND_MANY-TO-MANY_RELATIONSHIPS_ARE_VALID": {
+    text: "Why it matters\n\nBoth kinds have real uses, and both are easy to create by accident: Desktop offers bi-directional filtering as a dropdown, and it falls back to many-to-many when it finds duplicates on both sides of a key. An accidental one costs query time on every visual that touches the tables and can open a second filter path, which is where totals stop adding up without any error.\n\nHow to fix it\n\nConfirm each one is deliberate. If a bi-directional relationship exists only so one slicer narrows another, replace it with a measure-based visual filter or CROSSFILTER in the measures that need it. If a many-to-many relationship was created because a key column has duplicates, fix the duplicates in the source and go back to many-to-one.\n\nRead more: https://pbiplint.com/rules/check-if-bi-directional-and-many-to-many-relationships-are-valid",
+    markdown: "### Why it matters\n\nBoth kinds have real uses, and both are easy to create by accident: Desktop offers bi-directional filtering as a dropdown, and it falls back to many-to-many when it finds duplicates on both sides of a key. An accidental one costs query time on every visual that touches the tables and can open a second filter path, which is where totals stop adding up without any error.\n\n### How to fix it\n\nConfirm each one is deliberate. If a bi-directional relationship exists only so one slicer narrows another, replace it with a measure-based visual filter or CROSSFILTER in the measures that need it. If a many-to-many relationship was created because a key column has duplicates, fix the duplicates in the source and go back to many-to-one.\n\nRead more: https://pbiplint.com/rules/check-if-bi-directional-and-many-to-many-relationships-are-valid"
+  },
+  "CHECK_IF_DYNAMIC_ROW_LEVEL_SECURITY_(RLS)_IS_NECESSARY": {
+    text: 'Why it matters\n\nA dynamic filter is evaluated for each user separately, so the engine cannot share a cached result between two people with the same access, and every query carries the lookup that maps the user to their rows. That is the right trade when the audience is large or changes often. When a handful of fixed groups each see a fixed slice, static roles with a plain filter are faster and simpler to audit.\n\nHow to fix it\n\nKeep the dynamic filter when the user-to-data mapping lives in a table and changes without a redeploy. Otherwise create one role per audience with a static filter such as [Region] = "East" and assign members in the service.\n\nQuirks\n\n- A space before the parenthesis, as some DAX formatters write, is not matched: USERPRINCIPALNAME () passes.\n\nRead more: https://pbiplint.com/rules/check-if-dynamic-row-level-security-rls-is-necessary',
+    markdown: '### Why it matters\n\nA dynamic filter is evaluated for each user separately, so the engine cannot share a cached result between two people with the same access, and every query carries the lookup that maps the user to their rows. That is the right trade when the audience is large or changes often. When a handful of fixed groups each see a fixed slice, static roles with a plain filter are faster and simpler to audit.\n\n### How to fix it\n\nKeep the dynamic filter when the user-to-data mapping lives in a table and changes without a redeploy. Otherwise create one role per audience with a static filter such as `[Region] = "East"` and assign members in the service.\n\n### Quirks\n\n- A space before the parenthesis, as some DAX formatters write, is not matched: `USERPRINCIPALNAME ()` passes.\n\nRead more: https://pbiplint.com/rules/check-if-dynamic-row-level-security-rls-is-necessary'
+  },
+  DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN: {
+    text: "Why it matters\n\nA data column is filled from a column in the partition query, and the source column name is how the engine finds it. Without it, processing fails for the whole table, with an error that names the column but not the cause.\n\nHow to fix it\n\nSet sourceColumn on the column in the TMDL file to the name the query produces, or delete the column. Power BI Desktop always writes the property, so this appears only in hand-built or migrated files.\n\nRead more: https://pbiplint.com/rules/data-columns-must-have-a-source-column",
+    markdown: "### Why it matters\n\nA data column is filled from a column in the partition query, and the source column name is how the engine finds it. Without it, processing fails for the whole table, with an error that names the column but not the cause.\n\n### How to fix it\n\nSet `sourceColumn` on the column in the TMDL file to the name the query produces, or delete the column. Power BI Desktop always writes the property, so this appears only in hand-built or migrated files.\n\nRead more: https://pbiplint.com/rules/data-columns-must-have-a-source-column"
+  },
+  "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE": {
+    text: "Why it matters\n\nMarking the date table tells the engine which column is the calendar key, and every time intelligence function relies on it: DATESYTD, SAMEPERIODLASTYEAR, and the rest return wrong or blank results over an unmarked table without raising any error. Marking it also lets you turn off Auto date/time, which otherwise adds a hidden date table for every date column in the model.\n\nHow to fix it\n\nIn Power BI Desktop, select the table, open Table tools, choose Mark as date table, and pick the date column. In the TMDL file the result is dataCategory: Time on the table and isKey on the date column.\n\nQuirks\n\n- The name test is a substring, so a table called Updates or Candidates fires too.\n\nRead more: https://pbiplint.com/rules/date-calendar-tables-should-be-marked-as-a-date-table",
+    markdown: "### Why it matters\n\nMarking the date table tells the engine which column is the calendar key, and every time intelligence function relies on it: DATESYTD, SAMEPERIODLASTYEAR, and the rest return wrong or blank results over an unmarked table without raising any error. Marking it also lets you turn off Auto date/time, which otherwise adds a hidden date table for every date column in the model.\n\n### How to fix it\n\nIn Power BI Desktop, select the table, open Table tools, choose Mark as date table, and pick the date column. In the TMDL file the result is `dataCategory: Time` on the table and `isKey` on the date column.\n\n### Quirks\n\n- The name test is a substring, so a table called Updates or Candidates fires too.\n\nRead more: https://pbiplint.com/rules/date-calendar-tables-should-be-marked-as-a-date-table"
+  },
+  DATECOLUMN_FORMATSTRING: {
+    text: "Why it matters\n\nA date column with no format string is shown however the viewer's locale and the visual decide, so the same column can read 3/4/2026 in one visual and 4 March 2026 in another. A format string on the column fixes the presentation once for every report. The source ruleset picked the US short date as its convention.\n\nHow to fix it\n\nIn Power BI Desktop, select the column and set the Format under Column tools. In the TMDL file, add formatString: mm/dd/yyyy under the column. The expected format is US-centric; if your convention differs, set the format you want and turn this rule off in pbiplint.config.json, because only the exact string passes.\n\nQuirks\n\n- The name test is a substring, so any column containing the letters date, such as Update Time, is matched.\n- Any other format fires, including dd/mm/yyyy and yyyy-mm-dd.\n\nRead more: https://pbiplint.com/rules/datecolumn-formatstring",
+    markdown: "### Why it matters\n\nA date column with no format string is shown however the viewer's locale and the visual decide, so the same column can read 3/4/2026 in one visual and 4 March 2026 in another. A format string on the column fixes the presentation once for every report. The source ruleset picked the US short date as its convention.\n\n### How to fix it\n\nIn Power BI Desktop, select the column and set the Format under Column tools. In the TMDL file, add `formatString: mm/dd/yyyy` under the column. The expected format is US-centric; if your convention differs, set the format you want and turn this rule off in `pbiplint.config.json`, because only the exact string passes.\n\n### Quirks\n\n- The name test is a substring, so any column containing the letters date, such as Update Time, is matched.\n- Any other format fires, including `dd/mm/yyyy` and `yyyy-mm-dd`.\n\nRead more: https://pbiplint.com/rules/datecolumn-formatstring"
+  },
+  DAX_COLUMNS_FULLY_QUALIFIED: {
+    text: "Why it matters\n\nIn DAX a bare [Name] is the convention for a measure. A column written the same way reads as a measure to everyone who maintains the model, and the two behave differently in a row context, so the expression is misread before it is ever debugged. The bare form also breaks when the column moves to another table, or when a measure with the same name is added and the engine binds to that instead.\n\nHow to fix it\n\nWrite 'Table'[Column] for every column reference. The formula bar in Power BI Desktop completes the qualified form when you start typing the table name.\n\nQuirks\n\n- Calculation items are in the rule's scope but never fire, because Tabular Editor does not resolve bare column references inside calculation items and pbiplint matches that.\n- A bare name that matches any measure in the model is treated as a measure reference, so a column that shares its name with a measure is never flagged.\n- References are found by pattern matching, so a [Column] inside a string or a comment counts.\n\nRead more: https://pbiplint.com/rules/dax-columns-fully-qualified",
+    markdown: "### Why it matters\n\nIn DAX a bare `[Name]` is the convention for a measure. A column written the same way reads as a measure to everyone who maintains the model, and the two behave differently in a row context, so the expression is misread before it is ever debugged. The bare form also breaks when the column moves to another table, or when a measure with the same name is added and the engine binds to that instead.\n\n### How to fix it\n\nWrite `'Table'[Column]` for every column reference. The formula bar in Power BI Desktop completes the qualified form when you start typing the table name.\n\n### Quirks\n\n- Calculation items are in the rule's scope but never fire, because Tabular Editor does not resolve bare column references inside calculation items and pbiplint matches that.\n- A bare name that matches any measure in the model is treated as a measure reference, so a column that shares its name with a measure is never flagged.\n- References are found by pattern matching, so a `[Column]` inside a string or a comment counts.\n\nRead more: https://pbiplint.com/rules/dax-columns-fully-qualified"
+  },
+  DAX_MEASURES_UNQUALIFIED: {
+    text: "Why it matters\n\nA measure belongs to the model, not to the table it sits in; the table is only its home in the field list. Writing 'Sales'[Total Sales] makes it look like a column, which changes what the next reader expects it to do, and it breaks the moment someone moves the measure to a measure table, which is a routine tidy-up.\n\nHow to fix it\n\nWrite [Measure] with no table name.\n\nQuirks\n\n- Row-level security filters are not checked.\n- References are found by pattern matching, so a qualified measure reference inside a string or a comment counts.\n\nRead more: https://pbiplint.com/rules/dax-measures-unqualified",
+    markdown: "### Why it matters\n\nA measure belongs to the model, not to the table it sits in; the table is only its home in the field list. Writing `'Sales'[Total Sales]` makes it look like a column, which changes what the next reader expects it to do, and it breaks the moment someone moves the measure to a measure table, which is a routine tidy-up.\n\n### How to fix it\n\nWrite `[Measure]` with no table name.\n\n### Quirks\n\n- Row-level security filters are not checked.\n- References are found by pattern matching, so a qualified measure reference inside a string or a comment counts.\n\nRead more: https://pbiplint.com/rules/dax-measures-unqualified"
+  },
+  ENSURE_TABLES_HAVE_RELATIONSHIPS: {
+    text: "Why it matters\n\nA table that relates to nothing filters nothing and is filtered by nothing, so a visual that mixes its columns with another table's shows the same value repeated on every row. Sometimes that is the point: a parameter table, a measure table, or a security lookup that is read from DAX. More often it is a table that was loaded and never wired up, or a relationship that was deleted by accident.\n\nHow to fix it\n\nAdd the relationship in the model view, or confirm the table is disconnected on purpose and leave it. Hiding the table does not clear the finding, and a measure table with a single hidden column is reported like any other.\n\nRead more: https://pbiplint.com/rules/ensure-tables-have-relationships",
+    markdown: "### Why it matters\n\nA table that relates to nothing filters nothing and is filtered by nothing, so a visual that mixes its columns with another table's shows the same value repeated on every row. Sometimes that is the point: a parameter table, a measure table, or a security lookup that is read from DAX. More often it is a table that was loaded and never wired up, or a relationship that was deleted by accident.\n\n### How to fix it\n\nAdd the relationship in the model view, or confirm the table is disconnected on purpose and leave it. Hiding the table does not clear the finding, and a measure table with a single hidden column is reported like any other.\n\nRead more: https://pbiplint.com/rules/ensure-tables-have-relationships"
+  },
+  EVALUATEANDLOG_SHOULD_NOT_BE_USED_IN_PRODUCTION_MODELS: {
+    text: "Why it matters\n\nEVALUATEANDLOG is a debugging aid: in Power BI Desktop it emits a trace event with its argument on every evaluation so you can watch intermediate values. The service ignores it. Leaving it in a published model ships debug scaffolding that every reader has to look past, and anyone who opens the file in Desktop gets trace output they did not ask for.\n\nHow to fix it\n\nRemove the EVALUATEANDLOG wrapper and keep the expression inside it.\n\nRead more: https://pbiplint.com/rules/evaluateandlog-should-not-be-used-in-production-models",
+    markdown: "### Why it matters\n\nEVALUATEANDLOG is a debugging aid: in Power BI Desktop it emits a trace event with its argument on every evaluation so you can watch intermediate values. The service ignores it. Leaving it in a published model ships debug scaffolding that every reader has to look past, and anyone who opens the file in Desktop gets trace output they did not ask for.\n\n### How to fix it\n\nRemove the EVALUATEANDLOG wrapper and keep the expression inside it.\n\nRead more: https://pbiplint.com/rules/evaluateandlog-should-not-be-used-in-production-models"
+  },
+  EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION: {
+    text: "Why it matters\n\nWithout an expression the object cannot be evaluated: a measure returns nothing, a calculated column is empty, and a calculation item does nothing. Depending on the engine version the deployment fails outright, and the error points at the object without saying why.\n\nHow to fix it\n\nAdd the DAX, or delete the object.\n\nQuirks\n\n- Cannot fire on a TMDL file: the TMDL reader takes the next indented line as the expression, so an empty expression never survives loading.\n\nRead more: https://pbiplint.com/rules/expression-reliant-objects-must-have-an-expression",
+    markdown: "### Why it matters\n\nWithout an expression the object cannot be evaluated: a measure returns nothing, a calculated column is empty, and a calculation item does nothing. Depending on the engine version the deployment fails outright, and the error points at the object without saying why.\n\n### How to fix it\n\nAdd the DAX, or delete the object.\n\n### Quirks\n\n- Cannot fire on a TMDL file: the TMDL reader takes the next indented line as the expression, so an empty expression never survives loading.\n\nRead more: https://pbiplint.com/rules/expression-reliant-objects-must-have-an-expression"
+  },
+  FILTER_COLUMN_VALUES: {
+    text: `Why it matters
+
+FILTER over a whole table walks every row, keeps the ones that pass, and hands that row set to CALCULATE. A plain column predicate, 'Table'[Column] = "Value", is applied to the column's distinct values before any row is touched, which is far cheaper on a fact table and lets the storage engine do the work. The two forms also differ in meaning: FILTER over the table respects a filter already on the column, which the plain predicate replaces, so KEEPFILTERS is the exact equivalent.
+
+How to fix it
+
+Replace FILTER('Table', 'Table'[Column] = "Value") with KEEPFILTERS('Table'[Column] = "Value") to keep whatever filter is already on the column, or with 'Table'[Column] = "Value" to replace it. The SQLBI article in the links covers which one you want.
+
+Quirks
+
+- The pattern accepts a space as the table name, so FILTER('Table', [Measure] > 1) is also flagged by this rule and by FILTER_MEASURE_VALUES_BY_COLUMNS.
+- Only the first filter argument is checked, and only when the expression before it contains no comma. CALCULATE(DIVIDE([A], [B]), FILTER(...)) passes.
+- Table and column names must contain only letters, digits, spaces, and underscores.
+
+Read more: https://pbiplint.com/rules/filter-column-values`,
+    markdown: "### Why it matters\n\nFILTER over a whole table walks every row, keeps the ones that pass, and hands that row set to CALCULATE. A plain column predicate, `'Table'[Column] = \"Value\"`, is applied to the column's distinct values before any row is touched, which is far cheaper on a fact table and lets the storage engine do the work. The two forms also differ in meaning: FILTER over the table respects a filter already on the column, which the plain predicate replaces, so KEEPFILTERS is the exact equivalent.\n\n### How to fix it\n\nReplace `FILTER('Table', 'Table'[Column] = \"Value\")` with `KEEPFILTERS('Table'[Column] = \"Value\")` to keep whatever filter is already on the column, or with `'Table'[Column] = \"Value\"` to replace it. The SQLBI article in the links covers which one you want.\n\n### Quirks\n\n- The pattern accepts a space as the table name, so `FILTER('Table', [Measure] > 1)` is also flagged by this rule and by `FILTER_MEASURE_VALUES_BY_COLUMNS`.\n- Only the first filter argument is checked, and only when the expression before it contains no comma. `CALCULATE(DIVIDE([A], [B]), FILTER(...))` passes.\n- Table and column names must contain only letters, digits, spaces, and underscores.\n\nRead more: https://pbiplint.com/rules/filter-column-values"
+  },
+  FILTER_MEASURE_VALUES_BY_COLUMNS: {
+    text: "Why it matters\n\nFILTER over a whole table evaluates the measure once per row of the table. Over a fact table that is millions of measure evaluations to keep a few rows. Filtering the distinct values of one column instead evaluates the measure once per value, usually thousands of times fewer, and produces the same rows.\n\nHow to fix it\n\nReplace FILTER('Table', [Measure] > 0) with FILTER(VALUES('Table'[Column]), [Measure] > 0) to respect the current filter on the column, or FILTER(ALL('Table'[Column]), [Measure] > 0) to ignore it. Pick the column with the fewest distinct values that still gives the right answer.\n\nQuirks\n\n- Only the first filter argument is checked, and only when the expression before it contains no comma.\n- Table names must contain only letters, digits, spaces, and underscores.\n\nRead more: https://pbiplint.com/rules/filter-measure-values-by-columns",
+    markdown: "### Why it matters\n\nFILTER over a whole table evaluates the measure once per row of the table. Over a fact table that is millions of measure evaluations to keep a few rows. Filtering the distinct values of one column instead evaluates the measure once per value, usually thousands of times fewer, and produces the same rows.\n\n### How to fix it\n\nReplace `FILTER('Table', [Measure] > 0)` with `FILTER(VALUES('Table'[Column]), [Measure] > 0)` to respect the current filter on the column, or `FILTER(ALL('Table'[Column]), [Measure] > 0)` to ignore it. Pick the column with the fewest distinct values that still gives the right answer.\n\n### Quirks\n\n- Only the first filter argument is checked, and only when the expression before it contains no comma.\n- Table names must contain only letters, digits, spaces, and underscores.\n\nRead more: https://pbiplint.com/rules/filter-measure-values-by-columns"
+  },
+  FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED: {
+    text: `Why it matters
+
+Object names are the model's user interface: they appear in the field list, on axis labels, in tooltips, and in every export, and nothing capitalizes them for you. A field list that mixes "Sales Amount" with "total cost" reads as unfinished, and it tells a report author that the two fields came from different places and may not be equally trustworthy. Capitalizing the first letter costs nothing, survives every refresh, and is the convention nearly every published model follows. A name starting with a digit or a symbol is not flagged, because those characters have no upper case form.
+
+How to fix it
+
+Rename the object in Power BI Desktop, which updates the visuals and the DAX that reference it, or edit the name in the TMDL file.
+
+Quirks
+
+- Data columns are not in scope; only calculated and calculated-table columns are checked.
+
+Read more: https://pbiplint.com/rules/first-letter-of-objects-must-be-capitalized`,
+    markdown: `### Why it matters
+
+Object names are the model's user interface: they appear in the field list, on axis labels, in tooltips, and in every export, and nothing capitalizes them for you. A field list that mixes "Sales Amount" with "total cost" reads as unfinished, and it tells a report author that the two fields came from different places and may not be equally trustworthy. Capitalizing the first letter costs nothing, survives every refresh, and is the convention nearly every published model follows. A name starting with a digit or a symbol is not flagged, because those characters have no upper case form.
+
+### How to fix it
+
+Rename the object in Power BI Desktop, which updates the visuals and the DAX that reference it, or edit the name in the TMDL file.
+
+### Quirks
+
+- Data columns are not in scope; only calculated and calculated-table columns are checked.
+
+Read more: https://pbiplint.com/rules/first-letter-of-objects-must-be-capitalized`
+  },
+  FIX_REFERENTIAL_INTEGRITY_VIOLATIONS: {
+    text: "Why it matters\n\nEvery orphan key is grouped under a single blank row of the dimension, so slicers grow a blank entry, totals include amounts that no category explains, and a filter on any dimension attribute silently drops those rows. The blank row is also added to the dimension in memory on every refresh.\n\nHow to fix it\n\nFind the orphans with a query in Power BI Desktop's DAX query view, such as EVALUATE EXCEPT(VALUES(Sales[Product Key]), VALUES(Product[Product Key])), or read the violation count per relationship in DAX Studio's VertiPaq Analyzer. Then fix the source: add the missing dimension rows, or add an Unknown row and map the orphans to it.\n\npbiplint cannot evaluate this rule from files; it appears in pbiplint rules as needing a live model.\n\nRead more: https://pbiplint.com/rules/fix-referential-integrity-violations",
+    markdown: "### Why it matters\n\nEvery orphan key is grouped under a single blank row of the dimension, so slicers grow a blank entry, totals include amounts that no category explains, and a filter on any dimension attribute silently drops those rows. The blank row is also added to the dimension in memory on every refresh.\n\n### How to fix it\n\nFind the orphans with a query in Power BI Desktop's DAX query view, such as `EVALUATE EXCEPT(VALUES(Sales[Product Key]), VALUES(Product[Product Key]))`, or read the violation count per relationship in DAX Studio's VertiPaq Analyzer. Then fix the source: add the missing dimension rows, or add an Unknown row and map the orphans to it.\n\npbiplint cannot evaluate this rule from files; it appears in `pbiplint rules` as needing a live model.\n\nRead more: https://pbiplint.com/rules/fix-referential-integrity-violations"
+  },
+  "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS": {
+    text: "Why it matters\n\nA 0 or 1 in a slicer, a legend, or a table column tells the reader nothing without a lookup, and a whole-number flag is summed by default, so a card labeled Is Active shows a count of true rows that looks like something else. Yes and No read correctly everywhere and cannot be aggregated by accident.\n\nHow to fix it\n\nIn Power Query, add a conditional column or use Replace Values so the column holds Yes and No, and set its type to Text. Keep the numeric version hidden if a measure needs it for counting.\n\nQuirks\n\n- The name tests are case-sensitive prefix and suffix checks, so a whole-number column called Island or Issue Count fires, and the Flag suffix needs a space before it.\n\nRead more: https://pbiplint.com/rules/format-flag-columns-as-yes-no-value-strings",
+    markdown: "### Why it matters\n\nA 0 or 1 in a slicer, a legend, or a table column tells the reader nothing without a lookup, and a whole-number flag is summed by default, so a card labeled Is Active shows a count of true rows that looks like something else. Yes and No read correctly everywhere and cannot be aggregated by accident.\n\n### How to fix it\n\nIn Power Query, add a conditional column or use Replace Values so the column holds Yes and No, and set its type to Text. Keep the numeric version hidden if a measure needs it for counting.\n\n### Quirks\n\n- The name tests are case-sensitive prefix and suffix checks, so a whole-number column called Island or Issue Count fires, and the Flag suffix needs a space before it.\n\nRead more: https://pbiplint.com/rules/format-flag-columns-as-yes-no-value-strings"
+  },
+  HIDE_FACT_TABLE_COLUMNS: {
+    text: "Why it matters\n\nOnce a measure exists for a column, the column itself is the wrong thing to drag onto a visual: it produces an implicit sum that may not match the measure, ignores whatever logic the measure adds, and sits in the field list right next to the measure under a similar name. Hiding the column leaves one correct choice.\n\nHow to fix it\n\nHide the column in the model view, or add isHidden under the column in the TMDL file.\n\nQuirks\n\n- Only fully qualified references count. SUM([Amount]) inside a measure on the same table does not fire.\n- A visible column in a hidden table is still reported.\n\nRead more: https://pbiplint.com/rules/hide-fact-table-columns",
+    markdown: "### Why it matters\n\nOnce a measure exists for a column, the column itself is the wrong thing to drag onto a visual: it produces an implicit sum that may not match the measure, ignores whatever logic the measure adds, and sits in the field list right next to the measure under a similar name. Hiding the column leaves one correct choice.\n\n### How to fix it\n\nHide the column in the model view, or add `isHidden` under the column in the TMDL file.\n\n### Quirks\n\n- Only fully qualified references count. `SUM([Amount])` inside a measure on the same table does not fire.\n- A visible column in a hidden table is still reported.\n\nRead more: https://pbiplint.com/rules/hide-fact-table-columns"
+  },
+  HIDE_FOREIGN_KEYS: {
+    text: "Why it matters\n\nA key column on the many side of a relationship carries no meaning for a report author: the values are surrogate integers, and grouping by the fact table's key gives one row per key value labeled with a number nobody recognizes. Leaving it visible also puts two versions of the same field in the field list, one on the fact table and one on the dimension, and only the dimension's version filters the way people expect. Hiding the key removes the wrong choice from the field list without changing anything about how the model behaves.\n\nHow to fix it\n\nHide the column in the model view, or add isHidden under the column in the TMDL file.\n\nQuirks\n\n- The source rule compares from-column names only, not table plus column, so a dimension's key that shares a name with the fact table's foreign key is flagged too. pbiplint keeps this to match Tabular Editor.\n\nRead more: https://pbiplint.com/rules/hide-foreign-keys",
+    markdown: "### Why it matters\n\nA key column on the many side of a relationship carries no meaning for a report author: the values are surrogate integers, and grouping by the fact table's key gives one row per key value labeled with a number nobody recognizes. Leaving it visible also puts two versions of the same field in the field list, one on the fact table and one on the dimension, and only the dimension's version filters the way people expect. Hiding the key removes the wrong choice from the field list without changing anything about how the model behaves.\n\n### How to fix it\n\nHide the column in the model view, or add `isHidden` under the column in the TMDL file.\n\n### Quirks\n\n- The source rule compares from-column names only, not table plus column, so a dimension's key that shares a name with the fact table's foreign key is flagged too. pbiplint keeps this to match Tabular Editor.\n\nRead more: https://pbiplint.com/rules/hide-foreign-keys"
+  },
+  INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED: {
+    text: "Why it matters\n\nAn inactive relationship does nothing on its own. It exists so a measure can switch it on with USERELATIONSHIP, typically for a second date on a fact table. If no measure does, the relationship is either a leftover from a design that changed or a plan that was never finished, and a report author who sees the dotted line in the model view will assume the filter works.\n\nHow to fix it\n\nWrite the measure that uses it, CALCULATE([Total Sales], USERELATIONSHIP(Sales[Ship Date], 'Date'[Date])), or delete the relationship in the model view.\n\nQuirks\n\n- Only USERELATIONSHIP(from column, to column) counts as activation; the reversed argument order does not.\n- pbiplint escapes table and column names before building the pattern, which the source rule does not, so names with parentheses cannot break the check.\n\nRead more: https://pbiplint.com/rules/inactive-relationships-that-are-never-activated",
+    markdown: "### Why it matters\n\nAn inactive relationship does nothing on its own. It exists so a measure can switch it on with USERELATIONSHIP, typically for a second date on a fact table. If no measure does, the relationship is either a leftover from a design that changed or a plan that was never finished, and a report author who sees the dotted line in the model view will assume the filter works.\n\n### How to fix it\n\nWrite the measure that uses it, `CALCULATE([Total Sales], USERELATIONSHIP(Sales[Ship Date], 'Date'[Date]))`, or delete the relationship in the model view.\n\n### Quirks\n\n- Only `USERELATIONSHIP(from column, to column)` counts as activation; the reversed argument order does not.\n- pbiplint escapes table and column names before building the pattern, which the source rule does not, so names with parentheses cannot break the check.\n\nRead more: https://pbiplint.com/rules/inactive-relationships-that-are-never-activated"
+  },
+  INTEGER_FORMATTING: {
+    text: "Why it matters\n\nAn unformatted whole number is rendered with whatever default the client picks, so a measure that should read 1,234,567 can appear as 1234567 and leave the reader counting digits. Thousands separators are the single biggest readability win on a card or in a table column, and setting the format on the measure means every visual inherits it instead of each report author fixing it by hand and getting it slightly different. Currency and percentage measures follow their own conventions, which is why a format string containing $ or % is left alone by this rule.\n\nHow to fix it\n\nSet a format string that matches what the measure represents: #,0 for counts and other whole numbers, a currency format such as $#,0.00 for money, or #,0.0%;-#,0.0%;#,0.0% for percentages, which is the exact string PERCENTAGE_FORMATTING expects. In Power BI Desktop the Format box under Measure tools takes any of these. In the TMDL file the property is formatString: #,0 under the measure.\n\nQuirks\n\n- A measure with no format string at all is flagged by this rule as well as by PROVIDE_FORMAT_STRING_FOR_MEASURES. Setting the format string once clears both findings.\n- A measure with a dynamic format string but no static format string is flagged, because the source rule reads only the static format string.\n- Currency formats that do not use the $ character, for example \u20AC#,0.00, are flagged as though they were unformatted numbers, because the source rule looks for $ only.\n\nRead more: https://pbiplint.com/rules/integer-formatting",
+    markdown: "### Why it matters\n\nAn unformatted whole number is rendered with whatever default the client picks, so a measure that should read 1,234,567 can appear as 1234567 and leave the reader counting digits. Thousands separators are the single biggest readability win on a card or in a table column, and setting the format on the measure means every visual inherits it instead of each report author fixing it by hand and getting it slightly different. Currency and percentage measures follow their own conventions, which is why a format string containing $ or % is left alone by this rule.\n\n### How to fix it\n\nSet a format string that matches what the measure represents: `#,0` for counts and other whole numbers, a currency format such as `$#,0.00` for money, or `#,0.0%;-#,0.0%;#,0.0%` for percentages, which is the exact string `PERCENTAGE_FORMATTING` expects. In Power BI Desktop the Format box under Measure tools takes any of these. In the TMDL file the property is `formatString: #,0` under the measure.\n\n### Quirks\n\n- A measure with no format string at all is flagged by this rule as well as by `PROVIDE_FORMAT_STRING_FOR_MEASURES`. Setting the format string once clears both findings.\n- A measure with a dynamic format string but no static format string is flagged, because the source rule reads only the static format string.\n- Currency formats that do not use the `$` character, for example `\u20AC#,0.00`, are flagged as though they were unformatted numbers, because the source rule looks for `$` only.\n\nRead more: https://pbiplint.com/rules/integer-formatting"
+  },
+  ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS: {
+    text: "Why it matters\n\nWhen IsAvailableInMdx is true the engine builds an attribute hierarchy for the column at every refresh: a sorted structure that lets Excel and other MDX clients browse the column's values. A hidden column is never browsed, so the structure is built, stored, and rebuilt for nothing. On wide tables with many hidden keys and helper columns that is measurable refresh time and memory.\n\nHow to fix it\n\nAdd isAvailableInMdx: false under the column in the TMDL file. Power BI Desktop has no setting for this property but keeps the value once it is in the file. With many columns to change, Tabular Editor can set the property on every selected column in one edit; the TMDL edit needs no other tool.\n\nQuirks\n\n- Power BI Desktop never writes this property, so a Desktop-authored model gets one finding per hidden column until they are set.\n\nRead more: https://pbiplint.com/rules/isavailableinmdx-false-nonattribute-columns",
+    markdown: "### Why it matters\n\nWhen IsAvailableInMdx is true the engine builds an attribute hierarchy for the column at every refresh: a sorted structure that lets Excel and other MDX clients browse the column's values. A hidden column is never browsed, so the structure is built, stored, and rebuilt for nothing. On wide tables with many hidden keys and helper columns that is measurable refresh time and memory.\n\n### How to fix it\n\nAdd `isAvailableInMdx: false` under the column in the TMDL file. Power BI Desktop has no setting for this property but keeps the value once it is in the file. With many columns to change, Tabular Editor can set the property on every selected column in one edit; the TMDL edit needs no other tool.\n\n### Quirks\n\n- Power BI Desktop never writes this property, so a Desktop-authored model gets one finding per hidden column until they are set.\n\nRead more: https://pbiplint.com/rules/isavailableinmdx-false-nonattribute-columns"
+  },
+  LARGE_TABLES_SHOULD_BE_PARTITIONED: {
+    text: `Why it matters
+
+A single partition means every refresh reloads the whole table, and a 25-million-row table reloaded nightly is the usual reason a refresh runs for hours or times out. With partitions, only the ones whose data changed are processed. In Power BI that is what incremental refresh sets up for you.
+
+How to fix it
+
+Configure incremental refresh on the table in Power BI Desktop, which creates date-based partitions when the model is published. Check the row count with DAX Studio's VertiPaq Analyzer or with EVALUATE ROW("rows", COUNTROWS(Sales)) in DAX query view.
+
+pbiplint cannot evaluate this rule from files; it appears in pbiplint rules as needing a live model.
+
+Read more: https://pbiplint.com/rules/large-tables-should-be-partitioned`,
+    markdown: '### Why it matters\n\nA single partition means every refresh reloads the whole table, and a 25-million-row table reloaded nightly is the usual reason a refresh runs for hours or times out. With partitions, only the ones whose data changed are processed. In Power BI that is what incremental refresh sets up for you.\n\n### How to fix it\n\nConfigure incremental refresh on the table in Power BI Desktop, which creates date-based partitions when the model is published. Check the row count with DAX Studio\'s VertiPaq Analyzer or with `EVALUATE ROW("rows", COUNTROWS(Sales))` in DAX query view.\n\npbiplint cannot evaluate this rule from files; it appears in `pbiplint rules` as needing a live model.\n\nRead more: https://pbiplint.com/rules/large-tables-should-be-partitioned'
+  },
+  "LIMIT_ROW_LEVEL_SECURITY_(RLS)_LOGIC": {
+    text: "Why it matters\n\nA security filter runs on every query from every user in the role, and string functions in it are evaluated row by row on the secured table. A filter that compares a precomputed key column with equals is applied as a lookup instead. The string logic usually exists to derive a key from an email address or a code, which the source can produce once at load.\n\nHow to fix it\n\nAdd the derived key as a column in Power Query or in the source, and write the filter as a plain comparison such as [Email] = USERPRINCIPALNAME() or [Region Key] = LOOKUPVALUE(...).\n\nQuirks\n\n- Spaces are removed before matching and the match is a substring, so BRIGHT( or L E F T( also match.\n\nRead more: https://pbiplint.com/rules/limit-row-level-security-rls-logic",
+    markdown: "### Why it matters\n\nA security filter runs on every query from every user in the role, and string functions in it are evaluated row by row on the secured table. A filter that compares a precomputed key column with equals is applied as a lookup instead. The string logic usually exists to derive a key from an email address or a code, which the source can produce once at load.\n\n### How to fix it\n\nAdd the derived key as a column in Power Query or in the source, and write the filter as a plain comparison such as `[Email] = USERPRINCIPALNAME()` or `[Region Key] = LOOKUPVALUE(...)`.\n\n### Quirks\n\n- Spaces are removed before matching and the match is a substring, so `BRIGHT(` or `L E F T(` also match.\n\nRead more: https://pbiplint.com/rules/limit-row-level-security-rls-logic"
+  },
+  "MANY-TO-MANY_RELATIONSHIPS_SHOULD_BE_SINGLE-DIRECTION": {
+    text: "Why it matters\n\nA many-to-many relationship has no unique key on either side, so the engine resolves it through a set of distinct values rather than a direct lookup. Making that relationship bi-directional as well lets filters travel back through the same expansion, and that is where filter ambiguity begins: as soon as two paths reach the same table, the result depends on which path the engine chooses, and totals stop agreeing with the sum of their parts. The extra direction also costs at query time, because every filter has to be expanded across the distinct values on both sides instead of one. Single direction keeps one predictable filter path and is the accepted default; add the reverse direction only where a specific report needs it and you have confirmed the model has no second path.\n\nHow to fix it\n\nSet the cross filter direction to Single in the relationship dialog, or remove the crossFilteringBehavior: bothDirections line from the relationship in the relationships TMDL file.\n\nRead more: https://pbiplint.com/rules/many-to-many-relationships-should-be-single-direction",
+    markdown: "### Why it matters\n\nA many-to-many relationship has no unique key on either side, so the engine resolves it through a set of distinct values rather than a direct lookup. Making that relationship bi-directional as well lets filters travel back through the same expansion, and that is where filter ambiguity begins: as soon as two paths reach the same table, the result depends on which path the engine chooses, and totals stop agreeing with the sum of their parts. The extra direction also costs at query time, because every filter has to be expanded across the distinct values on both sides instead of one. Single direction keeps one predictable filter path and is the accepted default; add the reverse direction only where a specific report needs it and you have confirmed the model has no second path.\n\n### How to fix it\n\nSet the cross filter direction to Single in the relationship dialog, or remove the `crossFilteringBehavior: bothDirections` line from the relationship in the relationships TMDL file.\n\nRead more: https://pbiplint.com/rules/many-to-many-relationships-should-be-single-direction"
+  },
+  MARK_PRIMARY_KEYS: {
+    text: "Why it matters\n\nThe key flag declares that the column is unique, which lets the engine and client tools treat it as the identifier of the row rather than one more attribute to aggregate, and the engine enforces the uniqueness at refresh, so a duplicate key fails loudly instead of quietly doubling a total. It also documents intent: the next person reading the model can see at a glance which column defines the grain of the dimension, without tracing every relationship to work it out. Tables marked as date tables are skipped, because marking a table as a date table already sets the key on its date column.\n\nHow to fix it\n\nAdd isKey under the column in the TMDL file. Power BI Desktop has no setting for it on ordinary tables but keeps the value once it is in the file. Make sure the column really is unique first, because refresh fails if it is not.\n\nRead more: https://pbiplint.com/rules/mark-primary-keys",
+    markdown: "### Why it matters\n\nThe key flag declares that the column is unique, which lets the engine and client tools treat it as the identifier of the row rather than one more attribute to aggregate, and the engine enforces the uniqueness at refresh, so a duplicate key fails loudly instead of quietly doubling a total. It also documents intent: the next person reading the model can see at a glance which column defines the grain of the dimension, without tracing every relationship to work it out. Tables marked as date tables are skipped, because marking a table as a date table already sets the key on its date column.\n\n### How to fix it\n\nAdd `isKey` under the column in the TMDL file. Power BI Desktop has no setting for it on ordinary tables but keeps the value once it is in the file. Make sure the column really is unique first, because refresh fails if it is not.\n\nRead more: https://pbiplint.com/rules/mark-primary-keys"
+  },
+  MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES: {
+    text: "Why it matters\n\nAn alias measure is a second name for the same number. Reports pick one or the other, the two drift apart the first time someone edits the alias instead of the original, and anyone reading the model has to follow the reference to learn what it means.\n\nHow to fix it\n\nPoint the reports at the original and delete the alias. If the alias exists only for a friendlier name, rename the original instead; Power BI Desktop updates the visuals that use it.\n\nQuirks\n\n- Only the exact form matches: [Measure] and nothing else. A table prefix, a comment, or a surrounding function passes.\n\nRead more: https://pbiplint.com/rules/measures-should-not-be-direct-references-of-other-measures",
+    markdown: "### Why it matters\n\nAn alias measure is a second name for the same number. Reports pick one or the other, the two drift apart the first time someone edits the alias instead of the original, and anyone reading the model has to follow the reference to learn what it means.\n\n### How to fix it\n\nPoint the reports at the original and delete the alias. If the alias exists only for a friendlier name, rename the original instead; Power BI Desktop updates the visuals that use it.\n\n### Quirks\n\n- Only the exact form matches: `[Measure]` and nothing else. A table prefix, a comment, or a surrounding function passes.\n\nRead more: https://pbiplint.com/rules/measures-should-not-be-direct-references-of-other-measures"
+  },
+  MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY: {
+    text: "Why it matters\n\nTime intelligence functions build sets of dates and evaluate the measure over each set. In Import mode that is in-memory work. In DirectQuery each set becomes a query, or a long list of dates inside one, sent to the source on every visual refresh, and sources are rarely fast at it. The functions work, but a page of year-to-date and prior-year cards can take many seconds to render.\n\nHow to fix it\n\nIf the fact table can be imported, import it and keep DirectQuery for the tables that need it. If it cannot, add prior-period columns to the fact table in the source, such as the same day's amount one year earlier on each row, so the measure becomes a plain SUM.\n\nQuirks\n\n- Function names are matched case-sensitively, in upper case only, as in the source rule.\n\nRead more: https://pbiplint.com/rules/measures-using-time-intelligence-and-model-is-using-direct-query",
+    markdown: "### Why it matters\n\nTime intelligence functions build sets of dates and evaluate the measure over each set. In Import mode that is in-memory work. In DirectQuery each set becomes a query, or a long list of dates inside one, sent to the source on every visual refresh, and sources are rarely fast at it. The functions work, but a page of year-to-date and prior-year cards can take many seconds to render.\n\n### How to fix it\n\nIf the fact table can be imported, import it and keep DirectQuery for the tables that need it. If it cannot, add prior-period columns to the fact table in the source, such as the same day's amount one year earlier on each row, so the measure becomes a plain SUM.\n\n### Quirks\n\n- Function names are matched case-sensitively, in upper case only, as in the source rule.\n\nRead more: https://pbiplint.com/rules/measures-using-time-intelligence-and-model-is-using-direct-query"
+  },
+  MINIMIZE_POWER_QUERY_TRANSFORMATIONS: {
+    text: "Why it matters\n\nThese are the steps most likely to stop query folding. When folding stops, Power Query pulls the raw rows and does the work itself on the refresh machine, on every refresh, instead of asking the source for the finished result. On a large table that is the difference between a five-minute refresh and an hour, and the same logic in a view or the warehouse runs once, with indexes.\n\nHow to fix it\n\nMove the join, grouping, or pivot into the source as a view or a table and point the query at that. Where a step has to stay in Power Query, check that the steps before it still fold by right-clicking the step and looking for View Native Query. A native query folds nothing after it, so put it first or replace it with a view.\n\nQuirks\n\n- The check is a case-sensitive substring match on the M text, so a function name inside a comment counts too.\n\nRead more: https://pbiplint.com/rules/minimize-power-query-transformations",
+    markdown: "### Why it matters\n\nThese are the steps most likely to stop query folding. When folding stops, Power Query pulls the raw rows and does the work itself on the refresh machine, on every refresh, instead of asking the source for the finished result. On a large table that is the difference between a five-minute refresh and an hour, and the same logic in a view or the warehouse runs once, with indexes.\n\n### How to fix it\n\nMove the join, grouping, or pivot into the source as a view or a table and point the query at that. Where a step has to stay in Power Query, check that the steps before it still fold by right-clicking the step and looking for View Native Query. A native query folds nothing after it, so put it first or replace it with a view.\n\n### Quirks\n\n- The check is a case-sensitive substring match on the M text, so a function name inside a comment counts too.\n\nRead more: https://pbiplint.com/rules/minimize-power-query-transformations"
+  },
+  MODEL_SHOULD_HAVE_A_DATE_TABLE: {
+    text: "Why it matters\n\nEvery time intelligence function needs a contiguous date column to work over, and the marked date table is where it finds one. Without it, the model either leans on Auto date/time, which adds a hidden date table per date column and cannot be extended with fiscal periods or holidays, or does no time intelligence at all. A single shared date table also gives every fact table the same month, quarter, and year attributes, so visuals from different tables line up.\n\nHow to fix it\n\nAdd a date table with one row per day covering every date in the model, from the source, from Power Query, or with CALENDAR in DAX. Mark it as a date table under Table tools and relate each fact table's date column to it. A date table built in DAX satisfies this rule, though REDUCE_USAGE_OF_CALCULATED_TABLES will list it.\n\nRead more: https://pbiplint.com/rules/model-should-have-a-date-table",
+    markdown: "### Why it matters\n\nEvery time intelligence function needs a contiguous date column to work over, and the marked date table is where it finds one. Without it, the model either leans on Auto date/time, which adds a hidden date table per date column and cannot be extended with fiscal periods or holidays, or does no time intelligence at all. A single shared date table also gives every fact table the same month, quarter, and year attributes, so visuals from different tables line up.\n\n### How to fix it\n\nAdd a date table with one row per day covering every date in the model, from the source, from Power Query, or with CALENDAR in DAX. Mark it as a date table under Table tools and relate each fact table's date column to it. A date table built in DAX satisfies this rule, though `REDUCE_USAGE_OF_CALCULATED_TABLES` will list it.\n\nRead more: https://pbiplint.com/rules/model-should-have-a-date-table"
+  },
+  MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS: {
+    text: "Why it matters\n\nIn DirectQuery every visual sends a query to the source. Aggregation tables let the engine answer the common high-level questions, totals by month or by region, from a small imported table and send only the detail queries through. Without them, the summary page of a dashboard pays the full round trip to the source on every interaction. This is an info-level prompt to consider the feature, not a defect.\n\nHow to fix it\n\nCreate a summary table at the grain the reports use most, import it, and set it up under Manage aggregations in Power BI Desktop. The guide in the links covers the setup and the rules the engine uses to match queries to the aggregation.\n\nRead more: https://pbiplint.com/rules/model-using-direct-query-and-no-aggregations",
+    markdown: "### Why it matters\n\nIn DirectQuery every visual sends a query to the source. Aggregation tables let the engine answer the common high-level questions, totals by month or by region, from a small imported table and send only the detail queries through. Without them, the summary page of a dashboard pays the full round trip to the source on every interaction. This is an info-level prompt to consider the feature, not a defect.\n\n### How to fix it\n\nCreate a summary table at the grain the reports use most, import it, and set it up under Manage aggregations in Power BI Desktop. The guide in the links covers the setup and the rules the engine uses to match queries to the aggregation.\n\nRead more: https://pbiplint.com/rules/model-using-direct-query-and-no-aggregations"
+  },
+  "MONTH_(AS_A_STRING)_MUST_BE_SORTED": {
+    text: "Why it matters\n\nA text month sorts alphabetically: April, August, December. Every axis and slicer that uses the column shows that order until someone notices, and the fix has to be repeated in each visual unless it is made once on the column.\n\nHow to fix it\n\nAdd a month number column, then in Power BI Desktop select the month name column and set Sort by column under Column tools to the number. In the TMDL file the property is sortByColumn: 'Month Number' under the column.\n\nQuirks\n\n- The name test is a substring, so Month Name fires and so does a text column called Monthly Target. Months is excluded, so Months Elapsed passes.\n\nRead more: https://pbiplint.com/rules/month-as-a-string-must-be-sorted",
+    markdown: "### Why it matters\n\nA text month sorts alphabetically: April, August, December. Every axis and slicer that uses the column shows that order until someone notices, and the fix has to be repeated in each visual unless it is made once on the column.\n\n### How to fix it\n\nAdd a month number column, then in Power BI Desktop select the month name column and set Sort by column under Column tools to the number. In the TMDL file the property is `sortByColumn: 'Month Number'` under the column.\n\n### Quirks\n\n- The name test is a substring, so Month Name fires and so does a text column called Monthly Target. Months is excluded, so Months Elapsed passes.\n\nRead more: https://pbiplint.com/rules/month-as-a-string-must-be-sorted"
+  },
+  MONTHCOLUMN_FORMATSTRING: {
+    text: "Why it matters\n\nA DateTime column named Month usually holds the first day of each month, and with a default date format it reads as March 1, 2026 rather than March 2026. The MMMM yyyy format shows the month and year, and setting it on the column fixes every visual at once.\n\nHow to fix it\n\nSet the Format under Column tools in Power BI Desktop, or add formatString: MMMM yyyy under the column in the TMDL file. If you prefer a shorter form such as MMM yyyy, set it and turn this rule off in pbiplint.config.json, because only the exact string passes.\n\nQuirks\n\n- The name test is a substring, so any DateTime column with month in its name is checked.\n\nRead more: https://pbiplint.com/rules/monthcolumn-formatstring",
+    markdown: "### Why it matters\n\nA DateTime column named Month usually holds the first day of each month, and with a default date format it reads as March 1, 2026 rather than March 2026. The `MMMM yyyy` format shows the month and year, and setting it on the column fixes every visual at once.\n\n### How to fix it\n\nSet the Format under Column tools in Power BI Desktop, or add `formatString: MMMM yyyy` under the column in the TMDL file. If you prefer a shorter form such as `MMM yyyy`, set it and turn this rule off in `pbiplint.config.json`, because only the exact string passes.\n\n### Quirks\n\n- The name test is a substring, so any DateTime column with month in its name is checked.\n\nRead more: https://pbiplint.com/rules/monthcolumn-formatstring"
+  },
+  NUMERIC_COLUMN_SUMMARIZE_BY: {
+    text: "Why it matters\n\nWith a default summarization, dragging the column onto a visual produces an implicit sum, and it is easy to sum something that should never be summed: a year, a unit price, a percentage, a key. The implicit measure also bypasses the format string and the logic of the real measures, so two visuals of the same thing disagree. With summarization off, the column lands on a visual as a category and the author reaches for a measure.\n\nHow to fix it\n\nIn Power BI Desktop, select the column and set Summarization to Don't summarize under Column tools. In the TMDL file the property is summarizeBy: none. Create explicit measures for the aggregations reports need.\n\nQuirks\n\n- A column with no summarizeBy property is treated as Default, which is not None, so it is flagged.\n\nRead more: https://pbiplint.com/rules/numeric-column-summarize-by",
+    markdown: "### Why it matters\n\nWith a default summarization, dragging the column onto a visual produces an implicit sum, and it is easy to sum something that should never be summed: a year, a unit price, a percentage, a key. The implicit measure also bypasses the format string and the logic of the real measures, so two visuals of the same thing disagree. With summarization off, the column lands on a visual as a category and the author reaches for a measure.\n\n### How to fix it\n\nIn Power BI Desktop, select the column and set Summarization to Don't summarize under Column tools. In the TMDL file the property is `summarizeBy: none`. Create explicit measures for the aggregations reports need.\n\n### Quirks\n\n- A column with no summarizeBy property is treated as Default, which is not None, so it is flagged.\n\nRead more: https://pbiplint.com/rules/numeric-column-summarize-by"
+  },
+  OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE: {
+    text: 'Why it matters\n\nA leading or trailing space is invisible on screen but is part of the name, so "Sales " and "Sales" are two different objects to the engine. That is enough to break a DAX reference, a report visual binding, or a deployment that expects the trimmed name, and the error you get back will name an object that looks perfectly correct. Stray spaces almost always arrive by accident, pasted in or inherited from a source column name, so trimming them is safe and rarely breaks anything downstream. TRIM_OBJECT_NAMES makes the same check across more object types at a lower severity, so every finding here appears there as well.\n\nHow to fix it\n\nRename the object without the space in Power BI Desktop, which updates the visuals and DAX that reference it, or edit the name in the TMDL file.\n\nQuirks\n\n- Narrower scope than TRIM_OBJECT_NAMES: levels, roles, expressions, calculation items, calculated tables, and calculated table columns are not checked here.\n\nRead more: https://pbiplint.com/rules/objects-should-not-start-or-end-with-a-space',
+    markdown: '### Why it matters\n\nA leading or trailing space is invisible on screen but is part of the name, so "Sales " and "Sales" are two different objects to the engine. That is enough to break a DAX reference, a report visual binding, or a deployment that expects the trimmed name, and the error you get back will name an object that looks perfectly correct. Stray spaces almost always arrive by accident, pasted in or inherited from a source column name, so trimming them is safe and rarely breaks anything downstream. `TRIM_OBJECT_NAMES` makes the same check across more object types at a lower severity, so every finding here appears there as well.\n\n### How to fix it\n\nRename the object without the space in Power BI Desktop, which updates the visuals and DAX that reference it, or edit the name in the TMDL file.\n\n### Quirks\n\n- Narrower scope than `TRIM_OBJECT_NAMES`: levels, roles, expressions, calculation items, calculated tables, and calculated table columns are not checked here.\n\nRead more: https://pbiplint.com/rules/objects-should-not-start-or-end-with-a-space'
+  },
+  OBJECTS_WITH_NO_DESCRIPTION: {
+    text: "Why it matters\n\nThe description is the tooltip a report author sees when hovering a field in the field list, and it is the only place in the model to say what a measure counts, which currency a column is in, or which of two similar fields to use. Without it, every author works that out from the name, and gets it wrong at about the same rate. Descriptions also feed documentation tools, so the same sentence pays off twice.\n\nHow to fix it\n\nIn Power BI Desktop, open Model view, select the object, and type the Description in the Properties pane. In the TMDL file a description is one or more /// lines directly above the object. With hundreds of objects, Tabular Editor can paste descriptions into many objects at once; the TMDL comment lines need no other tool.\n\nQuirks\n\n- Visibility is the object's own isHidden flag: a visible column inside a hidden table is still reported.\n- A calculation group table is reported once, as a calculation group.\n\nRead more: https://pbiplint.com/rules/objects-with-no-description",
+    markdown: "### Why it matters\n\nThe description is the tooltip a report author sees when hovering a field in the field list, and it is the only place in the model to say what a measure counts, which currency a column is in, or which of two similar fields to use. Without it, every author works that out from the name, and gets it wrong at about the same rate. Descriptions also feed documentation tools, so the same sentence pays off twice.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view, select the object, and type the Description in the Properties pane. In the TMDL file a description is one or more `///` lines directly above the object. With hundreds of objects, Tabular Editor can paste descriptions into many objects at once; the TMDL comment lines need no other tool.\n\n### Quirks\n\n- Visibility is the object's own isHidden flag: a visible column inside a hidden table is still reported.\n- A calculation group table is reported once, as a calculation group.\n\nRead more: https://pbiplint.com/rules/objects-with-no-description"
+  },
+  PARSE_ISSUE: {
+    text: "Why it matters\n\nThe parser skipped the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor's TMDL reader is stricter and refuses to open a file that puts a blank line after a /// line at all.\n\nHow to fix it\n\nOpen the file at the reported line. TMDL is indented with tabs, and expression blocks open and close with  on their own lines. A /// description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker.\n\nRead more: https://pbiplint.com/rules/parse-issue",
+    markdown: "### Why it matters\n\nThe parser skipped the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor's TMDL reader is stricter and refuses to open a file that puts a blank line after a `///` line at all.\n\n### How to fix it\n\nOpen the file at the reported line. TMDL is indented with tabs, and expression blocks open and close with ``` on their own lines. A `///` description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker.\n\nRead more: https://pbiplint.com/rules/parse-issue"
+  },
+  PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES: {
+    text: "Why it matters\n\nA single-partition table has no reason for its partition to carry a different name, and when it does it is usually the table's old name from before a rename. Refresh logs, error messages, and the TMDL file all name the partition, so a mismatch sends the reader looking for a table that no longer exists.\n\nHow to fix it\n\nRename the partition in the TMDL file: the line partition 'Old Name' = m becomes partition 'Table Name' = m. Power BI Desktop names the partition after the table when it creates it, so on a Desktop project this usually points at a hand edit or a migrated model.\n\nRead more: https://pbiplint.com/rules/partition-name-should-match-table-name-for-single-partition-tables",
+    markdown: "### Why it matters\n\nA single-partition table has no reason for its partition to carry a different name, and when it does it is usually the table's old name from before a rename. Refresh logs, error messages, and the TMDL file all name the partition, so a mismatch sends the reader looking for a table that no longer exists.\n\n### How to fix it\n\nRename the partition in the TMDL file: the line `partition 'Old Name' = m` becomes `partition 'Table Name' = m`. Power BI Desktop names the partition after the table when it creates it, so on a Desktop project this usually points at a hand edit or a migrated model.\n\nRead more: https://pbiplint.com/rules/partition-name-should-match-table-name-for-single-partition-tables"
+  },
+  PERCENTAGE_FORMATTING: {
+    text: "Why it matters\n\nPercentages formatted inconsistently end up side by side in the same report, so one card reads 12.3% while the next reads 12.34% or 12%, and the reader is left wondering whether the numbers disagree or only the formatting does. The three-part string this rule expects sets the positive, negative, and zero cases together, so a negative percentage keeps its sign and a thousands separator appears once values pass 1000%. Setting it on the measure fixes the presentation for every report that uses the model, rather than leaving each report author to format the visual by hand. This is house style rather than correctness: if your standard uses a different number of decimals, disable the rule in pbiplint.config.json instead of working around it.\n\nHow to fix it\n\nUse the format string #,0.0%;-#,0.0%;#,0.0%. In Power BI Desktop, paste it into the Format box under Measure tools. In the TMDL file, set formatString: #,0.0%;-#,0.0%;#,0.0% under the measure.\n\nRead more: https://pbiplint.com/rules/percentage-formatting",
+    markdown: "### Why it matters\n\nPercentages formatted inconsistently end up side by side in the same report, so one card reads 12.3% while the next reads 12.34% or 12%, and the reader is left wondering whether the numbers disagree or only the formatting does. The three-part string this rule expects sets the positive, negative, and zero cases together, so a negative percentage keeps its sign and a thousands separator appears once values pass 1000%. Setting it on the measure fixes the presentation for every report that uses the model, rather than leaving each report author to format the visual by hand. This is house style rather than correctness: if your standard uses a different number of decimals, disable the rule in `pbiplint.config.json` instead of working around it.\n\n### How to fix it\n\nUse the format string `#,0.0%;-#,0.0%;#,0.0%`. In Power BI Desktop, paste it into the Format box under Measure tools. In the TMDL file, set `formatString: #,0.0%;-#,0.0%;#,0.0%` under the measure.\n\nRead more: https://pbiplint.com/rules/percentage-formatting"
+  },
+  PERSPECTIVES_WITH_NO_OBJECTS: {
+    text: "Why it matters\n\nAn empty perspective still shows up in clients that offer perspectives, such as Excel, as a named view of the model that contains nothing. It is either an abandoned start or the remains of objects that were removed, and it leaves the next person asking what it was for.\n\nHow to fix it\n\nAdd the objects the perspective should show, or delete its file from the perspectives folder. Power BI Desktop does not manage perspectives, so they appear only in models built or edited with other tools.\n\nRead more: https://pbiplint.com/rules/perspectives-with-no-objects",
+    markdown: "### Why it matters\n\nAn empty perspective still shows up in clients that offer perspectives, such as Excel, as a named view of the model that contains nothing. It is either an abandoned start or the remains of objects that were removed, and it leaves the next person asking what it was for.\n\n### How to fix it\n\nAdd the objects the perspective should show, or delete its file from the `perspectives` folder. Power BI Desktop does not manage perspectives, so they appear only in models built or edited with other tools.\n\nRead more: https://pbiplint.com/rules/perspectives-with-no-objects"
+  },
+  PROVIDE_FORMAT_STRING_FOR_MEASURES: {
+    text: "Why it matters\n\nA measure with no format string is rendered with the client's default, which usually means no thousands separator and a decimal count that varies with the data, so the same measure can look different in two visuals on the same page. Setting the format on the measure fixes the presentation once for every report that will ever use the model, instead of leaving each report author to set it per visual and get it slightly wrong. Hidden measures and measures on hidden tables are not checked, because nothing displays them directly; a measure that has only a dynamic format string is also left alone.\n\nHow to fix it\n\nSet the Format under Measure tools in Power BI Desktop, or add formatString under the measure in the TMDL file: #,0 for whole numbers, #,0.00 for decimals, a currency format such as $#,0.00, or #,0.0%;-#,0.0%;#,0.0% for percentages.\n\nQuirks\n\n- A measure with only a dynamic format string passes here but fires INTEGER_FORMATTING, which reads the static format string alone.\n\nRead more: https://pbiplint.com/rules/provide-format-string-for-measures",
+    markdown: "### Why it matters\n\nA measure with no format string is rendered with the client's default, which usually means no thousands separator and a decimal count that varies with the data, so the same measure can look different in two visuals on the same page. Setting the format on the measure fixes the presentation once for every report that will ever use the model, instead of leaving each report author to set it per visual and get it slightly wrong. Hidden measures and measures on hidden tables are not checked, because nothing displays them directly; a measure that has only a dynamic format string is also left alone.\n\n### How to fix it\n\nSet the Format under Measure tools in Power BI Desktop, or add `formatString` under the measure in the TMDL file: `#,0` for whole numbers, `#,0.00` for decimals, a currency format such as `$#,0.00`, or `#,0.0%;-#,0.0%;#,0.0%` for percentages.\n\n### Quirks\n\n- A measure with only a dynamic format string passes here but fires `INTEGER_FORMATTING`, which reads the static format string alone.\n\nRead more: https://pbiplint.com/rules/provide-format-string-for-measures"
+  },
+  REDUCE_NUMBER_OF_CALCULATED_COLUMNS: {
+    text: "Why it matters\n\nA calculated column is computed after load, one row at a time, and stored without the compression the engine gets for a column it loaded from the source, so each one costs refresh time and memory out of proportion to its size. Five is a budget rather than a limit: past it, the model is usually doing in DAX what Power Query or the source would do once and better.\n\nHow to fix it\n\nMove the logic into Power Query as a custom column, or into the source as a view. Keep DAX calculated columns for the few cases that need the model, such as a value that depends on a measure.\n\nRead more: https://pbiplint.com/rules/reduce-number-of-calculated-columns",
+    markdown: "### Why it matters\n\nA calculated column is computed after load, one row at a time, and stored without the compression the engine gets for a column it loaded from the source, so each one costs refresh time and memory out of proportion to its size. Five is a budget rather than a limit: past it, the model is usually doing in DAX what Power Query or the source would do once and better.\n\n### How to fix it\n\nMove the logic into Power Query as a custom column, or into the source as a view. Keep DAX calculated columns for the few cases that need the model, such as a value that depends on a measure.\n\nRead more: https://pbiplint.com/rules/reduce-number-of-calculated-columns"
+  },
+  REDUCE_USAGE_OF_CALCULATED_COLUMNS_THAT_USE_THE_RELATED_FUNCTION: {
+    text: "Why it matters\n\nRELATED in a calculated column copies a value from the one side of a relationship onto every row of the many side. That is a lookup the source can do with a join, or Power Query with a merge, at load time and often folded to the source. Done in DAX it is computed row by row after load and stored without full compression, and the copied column then duplicates a dimension attribute, which REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES also flags.\n\nHow to fix it\n\nAdd the column in Power Query with Merge Queries, or join it in the source view. If the value is only needed inside a measure, use RELATED in the measure instead of storing a column.\n\nQuirks\n\n- RELATEDTABLE( does not match; the pattern requires a parenthesis right after RELATED.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-calculated-columns-that-use-the-related-function",
+    markdown: "### Why it matters\n\nRELATED in a calculated column copies a value from the one side of a relationship onto every row of the many side. That is a lookup the source can do with a join, or Power Query with a merge, at load time and often folded to the source. Done in DAX it is computed row by row after load and stored without full compression, and the copied column then duplicates a dimension attribute, which `REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES` also flags.\n\n### How to fix it\n\nAdd the column in Power Query with Merge Queries, or join it in the source view. If the value is only needed inside a measure, use RELATED in the measure instead of storing a column.\n\n### Quirks\n\n- RELATEDTABLE( does not match; the pattern requires a parenthesis right after RELATED.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-calculated-columns-that-use-the-related-function"
+  },
+  REDUCE_USAGE_OF_CALCULATED_TABLES: {
+    text: "Why it matters\n\nA calculated table is rebuilt from DAX after every refresh, holds a copy of data that exists somewhere else, and is invisible to the source's lineage and to every other model. When two models need the same table, each rebuilds it its own way and they drift. A date table is the usual exception, and even there a shared table in the source or in a dataflow serves every model the same way.\n\nHow to fix it\n\nBuild the table in the source or in Power Query so it loads as data. Where a calculated table stays, keep it small and give it a description that says why.\n\nQuirks\n\n- With Auto date/time on, each hidden LocalDateTable is a calculated table and fires here as well as REMOVE_AUTO-DATE_TABLE. Turning the option off clears both.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-calculated-tables",
+    markdown: "### Why it matters\n\nA calculated table is rebuilt from DAX after every refresh, holds a copy of data that exists somewhere else, and is invisible to the source's lineage and to every other model. When two models need the same table, each rebuilds it its own way and they drift. A date table is the usual exception, and even there a shared table in the source or in a dataflow serves every model the same way.\n\n### How to fix it\n\nBuild the table in the source or in Power Query so it loads as data. Where a calculated table stays, keep it small and give it a description that says why.\n\n### Quirks\n\n- With Auto date/time on, each hidden LocalDateTable is a calculated table and fires here as well as `REMOVE_AUTO-DATE_TABLE`. Turning the option off clears both.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-calculated-tables"
+  },
+  "REDUCE_USAGE_OF_LONG-LENGTH_COLUMNS_WITH_HIGH_CARDINALITY": {
+    text: "Why it matters\n\nThe engine stores each distinct text value once in a dictionary and encodes the rows against it. Long unique strings, such as comments, descriptions, or URLs with query strings, defeat that: the dictionary grows as large as the data, memory and refresh time follow, and every visual that touches the column pays to decode it. Such a column is usually never shown in a visual anyway.\n\nHow to fix it\n\nLeave the column out of the model unless a report shows it. If it is needed, shorten it in Power Query, keep only the rows that matter, or move it to a detail table reached by drillthrough. Check column sizes with DAX Studio's VertiPaq Analyzer.\n\npbiplint cannot evaluate this rule from files; it appears in pbiplint rules as needing a live model.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-long-length-columns-with-high-cardinality",
+    markdown: "### Why it matters\n\nThe engine stores each distinct text value once in a dictionary and encodes the rows against it. Long unique strings, such as comments, descriptions, or URLs with query strings, defeat that: the dictionary grows as large as the data, memory and refresh time follow, and every visual that touches the column pays to decode it. Such a column is usually never shown in a visual anyway.\n\n### How to fix it\n\nLeave the column out of the model unless a report shows it. If it is needed, shorten it in Power Query, keep only the rows that matter, or move it to a detail table reached by drillthrough. Check column sizes with DAX Studio's VertiPaq Analyzer.\n\npbiplint cannot evaluate this rule from files; it appears in `pbiplint rules` as needing a live model.\n\nRead more: https://pbiplint.com/rules/reduce-usage-of-long-length-columns-with-high-cardinality"
+  },
+  RELATIONSHIP_COLUMNS_SAME_DATA_TYPE: {
+    text: "Why it matters\n\nThe engine relates columns by value, and when the types differ it converts one side for every query. A text key on one side and a whole number on the other works until a value like 007 meets 7, at which point rows quietly fall into the blank member. Matching types remove both the conversion cost and the surprise.\n\nHow to fix it\n\nChange both columns to the same type in Power Query, and prefer whole numbers for keys. In the TMDL file the property is dataType on each column.\n\nRead more: https://pbiplint.com/rules/relationship-columns-same-data-type",
+    markdown: "### Why it matters\n\nThe engine relates columns by value, and when the types differ it converts one side for every query. A text key on one side and a whole number on the other works until a value like 007 meets 7, at which point rows quietly fall into the blank member. Matching types remove both the conversion cost and the surprise.\n\n### How to fix it\n\nChange both columns to the same type in Power Query, and prefer whole numbers for keys. In the TMDL file the property is `dataType` on each column.\n\nRead more: https://pbiplint.com/rules/relationship-columns-same-data-type"
+  },
+  RELATIONSHIP_COLUMNS_SHOULD_BE_OF_INTEGER_DATA_TYPE: {
+    text: "Why it matters\n\nA relationship is evaluated by matching values, and whole numbers match fastest and compress smallest. Text keys carry their dictionary into every join, and DateTime keys work but store more than an integer date key would. On the largest fact tables the key columns are often the biggest, so the choice shows up in memory as much as in query time.\n\nHow to fix it\n\nUse integer surrogate keys from the source where they exist. Where the natural key is text, add a numeric key in the source or with a merge in Power Query. Date relationships on a DateTime column are common and work; an integer date key such as 20260904 is the stricter option.\n\nQuirks\n\n- Every date relationship on a DateTime column fires this rule. That is what the source rule does; disable it in pbiplint.config.json if date keys are your standard.\n\nRead more: https://pbiplint.com/rules/relationship-columns-should-be-of-integer-data-type",
+    markdown: "### Why it matters\n\nA relationship is evaluated by matching values, and whole numbers match fastest and compress smallest. Text keys carry their dictionary into every join, and DateTime keys work but store more than an integer date key would. On the largest fact tables the key columns are often the biggest, so the choice shows up in memory as much as in query time.\n\n### How to fix it\n\nUse integer surrogate keys from the source where they exist. Where the natural key is text, add a numeric key in the source or with a merge in Power Query. Date relationships on a DateTime column are common and work; an integer date key such as 20260904 is the stricter option.\n\n### Quirks\n\n- Every date relationship on a DateTime column fires this rule. That is what the source rule does; disable it in `pbiplint.config.json` if date keys are your standard.\n\nRead more: https://pbiplint.com/rules/relationship-columns-should-be-of-integer-data-type"
+  },
+  "REMOVE_AUTO-DATE_TABLE": {
+    text: "Why it matters\n\nWith Auto date/time on, Power BI Desktop creates a hidden calculated date table for every date column in the model, each with its own year, quarter, month, and day hierarchy. A model with a dozen date columns carries a dozen hidden tables, all rebuilt on every refresh, and none of them can be extended with fiscal periods or holidays or shared between fact tables. One real date table does everything they do, once.\n\nHow to fix it\n\nIn Power BI Desktop, open Options, then Current file, then Data Load, and clear Auto date/time. The hidden tables disappear on the next save. Then add a date table and mark it as a date table so the date hierarchies come from it.\n\nQuirks\n\n- With the option on, each hidden table also fires REDUCE_USAGE_OF_CALCULATED_TABLES.\n\nRead more: https://pbiplint.com/rules/remove-auto-date-table",
+    markdown: "### Why it matters\n\nWith Auto date/time on, Power BI Desktop creates a hidden calculated date table for every date column in the model, each with its own year, quarter, month, and day hierarchy. A model with a dozen date columns carries a dozen hidden tables, all rebuilt on every refresh, and none of them can be extended with fiscal periods or holidays or shared between fact tables. One real date table does everything they do, once.\n\n### How to fix it\n\nIn Power BI Desktop, open Options, then Current file, then Data Load, and clear Auto date/time. The hidden tables disappear on the next save. Then add a date table and mark it as a date table so the date hierarchies come from it.\n\n### Quirks\n\n- With the option on, each hidden table also fires `REDUCE_USAGE_OF_CALCULATED_TABLES`.\n\nRead more: https://pbiplint.com/rules/remove-auto-date-table"
+  },
+  REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS: {
+    text: "Why it matters\n\nAn unused data source is a connection string, and usually a credential, that the model still asks to have configured on every deployment, so the service keeps prompting for credentials to a source nothing reads. It is a leftover from a migration or a source that was replaced.\n\nHow to fix it\n\nDelete the data source's file from the dataSources folder of the project.\n\nQuirks\n\n- Tabular Editor 3 CLI 0.5.2 did not report this rule when loading from TMDL, although it did from .bim; pbiplint follows the rule text.\n- Power BI Desktop never writes data sources, so this rule matters only for hand-built or migrated models.\n\nRead more: https://pbiplint.com/rules/remove-data-sources-not-referenced-by-any-partitions",
+    markdown: "### Why it matters\n\nAn unused data source is a connection string, and usually a credential, that the model still asks to have configured on every deployment, so the service keeps prompting for credentials to a source nothing reads. It is a leftover from a migration or a source that was replaced.\n\n### How to fix it\n\nDelete the data source's file from the `dataSources` folder of the project.\n\n### Quirks\n\n- Tabular Editor 3 CLI 0.5.2 did not report this rule when loading from TMDL, although it did from .bim; pbiplint follows the rule text.\n- Power BI Desktop never writes data sources, so this rule matters only for hand-built or migrated models.\n\nRead more: https://pbiplint.com/rules/remove-data-sources-not-referenced-by-any-partitions"
+  },
+  REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES: {
+    text: "Why it matters\n\nA fact table row that carries the product name as well as the product key stores the name once per sale instead of once per product, and offers the report author two Product Name fields that behave differently: the fact table's version cannot filter other fact tables and shows only the names that have sales. The dimension's copy is the one that should exist.\n\nHow to fix it\n\nRemove the column from the fact table's query in Power Query and use the dimension's column in reports. If a measure needs the value, RELATED reaches it through the relationship.\n\nQuirks\n\n- Matching is by column name only, so two unrelated columns that happen to share a name fire too.\n\nRead more: https://pbiplint.com/rules/remove-redundant-columns-in-related-tables",
+    markdown: "### Why it matters\n\nA fact table row that carries the product name as well as the product key stores the name once per sale instead of once per product, and offers the report author two Product Name fields that behave differently: the fact table's version cannot filter other fact tables and shows only the names that have sales. The dimension's copy is the one that should exist.\n\n### How to fix it\n\nRemove the column from the fact table's query in Power Query and use the dimension's column in reports. If a measure needs the value, RELATED reaches it through the relationship.\n\n### Quirks\n\n- Matching is by column name only, so two unrelated columns that happen to share a name fire too.\n\nRead more: https://pbiplint.com/rules/remove-redundant-columns-in-related-tables"
+  },
+  REMOVE_ROLES_WITH_NO_MEMBERS: {
+    text: 'Why it matters\n\nIn a Power BI project the role definitions live in the files and the membership lives in the service, so a role in the files never has members and this rule fires for every role. pbiplint keeps that behavior to match the source ruleset. On models where membership is in the file, such as ones built for Analysis Services, a role with no members grants nothing and leaves the next reviewer guessing whether membership was never assigned, was removed on purpose, or was dropped by a failed deployment, which is exactly the question a security review needs answered.\n\nHow to fix it\n\nOn a Power BI project, turn the rule off with "REMOVE_ROLES_WITH_NO_MEMBERS": "off" in pbiplint.config.json, or annotate the roles that are meant to be empty. Elsewhere, assign the members or delete the role.\n\nQuirks\n\n- Power BI Desktop never writes role members, so every role in a Desktop-authored project is flagged.\n\nRead more: https://pbiplint.com/rules/remove-roles-with-no-members',
+    markdown: '### Why it matters\n\nIn a Power BI project the role definitions live in the files and the membership lives in the service, so a role in the files never has members and this rule fires for every role. pbiplint keeps that behavior to match the source ruleset. On models where membership is in the file, such as ones built for Analysis Services, a role with no members grants nothing and leaves the next reviewer guessing whether membership was never assigned, was removed on purpose, or was dropped by a failed deployment, which is exactly the question a security review needs answered.\n\n### How to fix it\n\nOn a Power BI project, turn the rule off with `"REMOVE_ROLES_WITH_NO_MEMBERS": "off"` in `pbiplint.config.json`, or annotate the roles that are meant to be empty. Elsewhere, assign the members or delete the role.\n\n### Quirks\n\n- Power BI Desktop never writes role members, so every role in a Desktop-authored project is flagged.\n\nRead more: https://pbiplint.com/rules/remove-roles-with-no-members'
+  },
+  SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS: {
+    text: "Why it matters\n\nA column that sorts another column, or sits in a hierarchy, is used through its attribute hierarchy, and that is exactly what setting IsAvailableInMdx to false removes. The result is a processing error, or a hierarchy that fails in Excel and other MDX clients, usually after someone set the property to false in bulk to save memory.\n\nHow to fix it\n\nRemove the isAvailableInMdx: false line from the column in the TMDL file, so the property returns to its default of true.\n\nRead more: https://pbiplint.com/rules/set-isavailableinmdx-to-true-on-necessary-columns",
+    markdown: "### Why it matters\n\nA column that sorts another column, or sits in a hierarchy, is used through its attribute hierarchy, and that is exactly what setting IsAvailableInMdx to false removes. The result is a processing error, or a hierarchy that fails in Excel and other MDX clients, usually after someone set the property to false in bulk to save memory.\n\n### How to fix it\n\nRemove the `isAvailableInMdx: false` line from the column in the TMDL file, so the property returns to its default of true.\n\nRead more: https://pbiplint.com/rules/set-isavailableinmdx-to-true-on-necessary-columns"
+  },
+  SNOWFLAKE_SCHEMA_ARCHITECTURE: {
+    text: "Why it matters\n\nIn a star schema every dimension relates directly to the fact table, so a filter on Category reaches Sales in one hop. When Category hangs off Product, which hangs off Sales, the filter travels two hops, the model view is harder to read, and any bi-directional relationship along the chain doubles the chance of ambiguity. The engine handles a snowflake, but it handles a star faster, and a report author understands a star at a glance.\n\nHow to fix it\n\nFlatten the sub-dimension into its parent with a merge in Power Query, so Product carries Category Name and the Category table goes away. Keep a snowflake only where the sub-dimension is shared by several dimensions or is very large.\n\nQuirks\n\n- The test is the from side and the to side of a relationship, not the many side and the one side, so a table with a one-to-one relationship can count.\n\nRead more: https://pbiplint.com/rules/snowflake-schema-architecture",
+    markdown: "### Why it matters\n\nIn a star schema every dimension relates directly to the fact table, so a filter on Category reaches Sales in one hop. When Category hangs off Product, which hangs off Sales, the filter travels two hops, the model view is harder to read, and any bi-directional relationship along the chain doubles the chance of ambiguity. The engine handles a snowflake, but it handles a star faster, and a report author understands a star at a glance.\n\n### How to fix it\n\nFlatten the sub-dimension into its parent with a merge in Power Query, so Product carries Category Name and the Category table goes away. Keep a snowflake only where the sub-dimension is shared by several dimensions or is very large.\n\n### Quirks\n\n- The test is the from side and the to side of a relationship, not the many side and the one side, so a table with a one-to-one relationship can count.\n\nRead more: https://pbiplint.com/rules/snowflake-schema-architecture"
+  },
+  SPECIAL_CHARS_IN_OBJECT_NAMES: {
+    text: "Why it matters\n\nTabs and line breaks inside a name are invisible in most of the interface, so the object looks correct in the field list while every DAX reference, report binding, and deployment script has to reproduce the hidden character exactly. When one of them does not, you get a broken reference between two names that look identical on screen, which is one of the slowest kinds of model bug to track down. The same characters break CSV and Excel exports, where a line feed inside a column header splits the header across rows. Names should contain printable characters and ordinary spaces only.\n\nHow to fix it\n\nRename the object without the character in Power BI Desktop, or edit the name in the TMDL file.\n\nQuirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/special-chars-in-object-names",
+    markdown: "### Why it matters\n\nTabs and line breaks inside a name are invisible in most of the interface, so the object looks correct in the field list while every DAX reference, report binding, and deployment script has to reproduce the hidden character exactly. When one of them does not, you get a broken reference between two names that look identical on screen, which is one of the slowest kinds of model bug to track down. The same characters break CSV and Excel exports, where a line feed inside a column header splits the header across rows. Names should contain printable characters and ordinary spaces only.\n\n### How to fix it\n\nRename the object without the character in Power BI Desktop, or edit the name in the TMDL file.\n\n### Quirks\n\n- In practice this rule cannot fire on a project loaded from TMDL files, because the format does not carry these characters. It is kept so that models built by other means are covered.\n\nRead more: https://pbiplint.com/rules/special-chars-in-object-names"
+  },
+  SPLIT_DATE_AND_TIME: {
+    text: "Why it matters\n\nA timestamp column has nearly as many distinct values as rows, so it does not compress and it cannot relate to a date table. Split into a date and a time, each column has a few thousand distinct values, compresses well, relates to a date table and a time table, and supports the questions people actually ask, which are by day and by hour rather than by second.\n\nHow to fix it\n\nIn Power Query, add a Date column and a Time column from the timestamp and remove the original, or round the timestamp to midnight if the time is never used. Check cardinality with DAX Studio's VertiPaq Analyzer or with DISTINCTCOUNT in DAX query view.\n\npbiplint cannot evaluate this rule from files; it appears in pbiplint rules as needing a live model.\n\nRead more: https://pbiplint.com/rules/split-date-and-time",
+    markdown: "### Why it matters\n\nA timestamp column has nearly as many distinct values as rows, so it does not compress and it cannot relate to a date table. Split into a date and a time, each column has a few thousand distinct values, compresses well, relates to a date table and a time table, and supports the questions people actually ask, which are by day and by hour rather than by second.\n\n### How to fix it\n\nIn Power Query, add a Date column and a Time column from the timestamp and remove the original, or round the timestamp to midnight if the time is never used. Check cardinality with DAX Studio's VertiPaq Analyzer or with DISTINCTCOUNT in DAX query view.\n\npbiplint cannot evaluate this rule from files; it appears in `pbiplint rules` as needing a live model.\n\nRead more: https://pbiplint.com/rules/split-date-and-time"
+  },
+  TRIM_OBJECT_NAMES: {
+    text: 'Why it matters\n\nA leading or trailing space is invisible in the field list but part of the name, so "Sales " and "Sales" are two objects to the engine, and a DAX reference, a visual binding, or a deployment script that uses the trimmed name fails against something that looks correct. The space usually arrives with a source column name or a paste. OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE reports the same names at error severity for a narrower set of object types.\n\nHow to fix it\n\nRename the object without the space in Power BI Desktop, or edit the name in the TMDL file. Trim column names in Power Query so they arrive clean.\n\nRead more: https://pbiplint.com/rules/trim-object-names',
+    markdown: '### Why it matters\n\nA leading or trailing space is invisible in the field list but part of the name, so "Sales " and "Sales" are two objects to the engine, and a DAX reference, a visual binding, or a deployment script that uses the trimmed name fails against something that looks correct. The space usually arrives with a source column name or a paste. `OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE` reports the same names at error severity for a narrower set of object types.\n\n### How to fix it\n\nRename the object without the space in Power BI Desktop, or edit the name in the TMDL file. Trim column names in Power Query so they arrive clean.\n\nRead more: https://pbiplint.com/rules/trim-object-names'
+  },
+  UNNECESSARY_COLUMNS: {
+    text: "Why it matters\n\nA hidden column that nothing uses is loaded, compressed, and refreshed for no reader. Key columns and helper columns pile up this way as a model evolves, and each one costs memory and refresh time in proportion to its cardinality. Removing them is the cheapest model diet there is.\n\nHow to fix it\n\nRemove the column in Power Query with Choose Columns or Remove Columns, so it is never loaded.\n\nQuirks\n\n- DAX references are approximated by pattern matching: references inside strings or comments count, and a bare [Column] reference resolves measure-first, then the expression's own table, then the first table with that column.\n- Report usage is not visible to this rule. A hidden column used only by a visual, a slicer, or a report-level filter is still flagged.\n\nRead more: https://pbiplint.com/rules/unnecessary-columns",
+    markdown: "### Why it matters\n\nA hidden column that nothing uses is loaded, compressed, and refreshed for no reader. Key columns and helper columns pile up this way as a model evolves, and each one costs memory and refresh time in proportion to its cardinality. Removing them is the cheapest model diet there is.\n\n### How to fix it\n\nRemove the column in Power Query with Choose Columns or Remove Columns, so it is never loaded.\n\n### Quirks\n\n- DAX references are approximated by pattern matching: references inside strings or comments count, and a bare [Column] reference resolves measure-first, then the expression's own table, then the first table with that column.\n- Report usage is not visible to this rule. A hidden column used only by a visual, a slicer, or a report-level filter is still flagged.\n\nRead more: https://pbiplint.com/rules/unnecessary-columns"
+  },
+  UNNECESSARY_MEASURES: {
+    text: "Why it matters\n\nA hidden measure that no other measure uses can only be reached by a report that already had it, so it is either dead or a hidden dependency that breaks the day someone deletes it as dead. Either way it belongs in the open or in the bin.\n\nHow to fix it\n\nDelete the measure, or unhide it if reports still use it.\n\nQuirks\n\n- References from calculation items and from other hidden measures count as usage.\n- Report usage is not visible to this rule. A hidden measure used only by a visual is still flagged.\n\nRead more: https://pbiplint.com/rules/unnecessary-measures",
+    markdown: "### Why it matters\n\nA hidden measure that no other measure uses can only be reached by a report that already had it, so it is either dead or a hidden dependency that breaks the day someone deletes it as dead. Either way it belongs in the open or in the bin.\n\n### How to fix it\n\nDelete the measure, or unhide it if reports still use it.\n\n### Quirks\n\n- References from calculation items and from other hidden measures count as usage.\n- Report usage is not visible to this rule. A hidden measure used only by a visual is still flagged.\n\nRead more: https://pbiplint.com/rules/unnecessary-measures"
+  },
+  "UNPIVOT_PIVOTED_(MONTH)_DATA": {
+    text: "Why it matters\n\nA column per month is a spreadsheet layout. In a model it means a measure per month, no way to filter by date, no relationship to the date table, and a schema change every year. Unpivoted into one Month column and one Value column, the same data relates to the date table and every measure and time intelligence function works over it.\n\nHow to fix it\n\nIn Power Query, select the month columns, choose Unpivot Columns, and rename the Attribute and Value columns. Then relate the month to the date table.\n\nQuirks\n\n- Only the first six months are tested, and full names count, so a table with January through June fires and one with only Jul through Dec does not.\n\nRead more: https://pbiplint.com/rules/unpivot-pivoted-month-data",
+    markdown: "### Why it matters\n\nA column per month is a spreadsheet layout. In a model it means a measure per month, no way to filter by date, no relationship to the date table, and a schema change every year. Unpivoted into one Month column and one Value column, the same data relates to the date table and every measure and time intelligence function works over it.\n\n### How to fix it\n\nIn Power Query, select the month columns, choose Unpivot Columns, and rename the Attribute and Value columns. Then relate the month to the date table.\n\n### Quirks\n\n- Only the first six months are tested, and full names count, so a table with January through June fires and one with only Jul through Dec does not.\n\nRead more: https://pbiplint.com/rules/unpivot-pivoted-month-data"
+  },
+  USE_THE_DIVIDE_FUNCTION_FOR_DIVISION: {
+    text: "Why it matters\n\nDividing by a zero or blank denominator with / produces an error, and an error in one cell takes down the whole visual with a generic message. DIVIDE returns blank in that case, or an alternate result you choose, so the visual shows a gap where the data has one instead of failing.\n\nHow to fix it\n\nWrite DIVIDE([Sales], [Cost]), with a third argument when you want something other than blank for a zero denominator.\n\nQuirks\n\n- A slash after a number or a variable name is not matched: 1 / [Sales] and total / count pass.\n- Division by a constant, [Sales] / 100, is flagged even though it cannot fail.\n\nRead more: https://pbiplint.com/rules/use-the-divide-function-for-division",
+    markdown: "### Why it matters\n\nDividing by a zero or blank denominator with `/` produces an error, and an error in one cell takes down the whole visual with a generic message. DIVIDE returns blank in that case, or an alternate result you choose, so the visual shows a gap where the data has one instead of failing.\n\n### How to fix it\n\nWrite `DIVIDE([Sales], [Cost])`, with a third argument when you want something other than blank for a zero denominator.\n\n### Quirks\n\n- A slash after a number or a variable name is not matched: `1 / [Sales]` and `total / count` pass.\n- Division by a constant, `[Sales] / 100`, is flagged even though it cannot fail.\n\nRead more: https://pbiplint.com/rules/use-the-divide-function-for-division"
+  },
+  USE_THE_TREATAS_FUNCTION_INSTEAD_OF_INTERSECT: {
+    text: "Why it matters\n\nINTERSECT is used to push a filter from one table to another when no relationship exists: take the values on one side and intersect them with the other. TREATAS does the same job by treating the first table's values as a filter on the second table's columns, and the engine applies it as a filter, which is much cheaper than materializing both sets and intersecting them.\n\nHow to fix it\n\nReplace CALCULATE([Measure], INTERSECT(VALUES(Table2[Key]), VALUES(Table1[Key]))) with CALCULATE([Measure], TREATAS(VALUES(Table1[Key]), Table2[Key])). The SQLBI article in the links covers the pattern.\n\nQuirks\n\n- INTERSECT used for anything other than a virtual relationship, such as set logic inside a measure, is flagged too.\n\nRead more: https://pbiplint.com/rules/use-the-treatas-function-instead-of-intersect",
+    markdown: "### Why it matters\n\nINTERSECT is used to push a filter from one table to another when no relationship exists: take the values on one side and intersect them with the other. TREATAS does the same job by treating the first table's values as a filter on the second table's columns, and the engine applies it as a filter, which is much cheaper than materializing both sets and intersecting them.\n\n### How to fix it\n\nReplace `CALCULATE([Measure], INTERSECT(VALUES(Table2[Key]), VALUES(Table1[Key])))` with `CALCULATE([Measure], TREATAS(VALUES(Table1[Key]), Table2[Key]))`. The SQLBI article in the links covers the pattern.\n\n### Quirks\n\n- INTERSECT used for anything other than a virtual relationship, such as set logic inside a measure, is flagged too.\n\nRead more: https://pbiplint.com/rules/use-the-treatas-function-instead-of-intersect"
+  }
+};
+
+// src/walk.ts
+import { existsSync as existsSync3, readdirSync, readFileSync as readFileSync2, statSync } from "node:fs";
+import { basename, dirname as dirname3, join as join3, relative, resolve as resolve2 } from "node:path";
+var toPosix = (p) => p.split("\\").join("/");
+function readTmdlFiles(root, dir, out) {
+  for (const entry of readdirSync(dir, { withFileTypes: true }).sort(
+    (a, b) => a.name.localeCompare(b.name)
+  )) {
+    const p = join3(dir, entry.name);
+    if (entry.isDirectory()) readTmdlFiles(root, p, out);
+    else if (entry.name.endsWith(".tmdl"))
+      out.push({ path: toPosix(relative(root, p)), text: readFileSync2(p, "utf8") });
+  }
+}
+function resolveModel(input) {
+  const path = resolve2(input);
+  if (!existsSync3(path)) throw new UsageError(`${input} does not exist`);
+  const stat = statSync(path);
+  if (stat.isFile()) {
+    if (!path.endsWith(".tmdl")) throw new UsageError(`${input} is not a .tmdl file or a folder`);
+    return {
+      root: dirname3(path),
+      files: [{ path: basename(path), text: readFileSync2(path, "utf8") }]
+    };
+  }
+  if (existsSync3(join3(path, "definition")) && statSync(join3(path, "definition")).isDirectory()) {
+    const files = [];
+    readTmdlFiles(path, join3(path, "definition"), files);
+    if (files.length) return { root: path, files };
+  }
+  const models = readdirSync(path, { withFileTypes: true }).filter(
+    (e) => e.isDirectory() && e.name.endsWith(".SemanticModel")
+  );
+  if (models.length === 1) return resolveModel(join3(path, models[0].name));
+  if (models.length > 1)
+    throw new UsageError(
+      `${input} contains ${models.length} semantic models; point at one of them: ${models.map((m) => m.name).join(", ")}`
+    );
+  const direct = [];
+  readTmdlFiles(path, path, direct);
+  if (direct.length) return { root: path, files: direct };
+  throw new UsageError(
+    `No semantic model found at ${input} (expected a .SemanticModel folder, a PBIP folder, a definition folder, or .tmdl files)`
+  );
+}
+
+// src/main.ts
+var VERSION2 = true ? "0.1.0" : "0.0.0-dev";
+function listRules() {
+  const width = Math.max(...defaultRules.map((r) => r.id.length));
+  return defaultRules.map(
+    (r) => `${r.id.padEnd(width)}  ${(r.status === "needsLiveModel" ? "needs live model" : r.status).padEnd(16)}  ${SEVERITY_LABEL[r.severity].padEnd(7)}  ${r.category.padEnd(18)}  ${r.name}`
+  ).join("\n");
+}
+async function main(argv, io) {
+  try {
+    const opts = parseArgs(argv);
+    if (opts.command === "help") {
+      io.stdout(HELP);
+      return 0;
+    }
+    if (opts.command === "version") {
+      io.stdout(`pbiplint ${VERSION2}
+`);
+      return 0;
+    }
+    if (opts.command === "rules") {
+      io.stdout(listRules() + "\n");
+      return 0;
+    }
+    const target = opts.sample ? sampleDir() : resolve3(io.cwd(), opts.path);
+    const model = resolveModel(target);
+    const found = findConfig(model.root, opts.config ? resolve3(io.cwd(), opts.config) : void 0);
+    const config = resolveConfig({
+      ...found.config,
+      ...opts.failOn ? { failOn: opts.failOn } : {}
+    });
+    const result = lint(model.files, { config });
+    const pathPrefix = relative2(io.cwd(), model.root).split("\\").join("/");
+    const report = formatResult(opts.format, result, {
+      toolVersion: VERSION2,
+      pathPrefix,
+      help: RULE_HELP
+    });
+    if (opts.output) {
+      const out = resolve3(io.cwd(), opts.output);
+      mkdirSync(dirname4(out), { recursive: true });
+      writeFileSync(out, report);
+      io.stderr(`pbiplint: ${summaryLine(result)}, wrote ${opts.output}
+`);
+    } else {
+      io.stdout(report);
+    }
+    for (const e of result.summary.ruleErrors) io.stderr(`rule ${e.id} failed: ${e.message}
+`);
+    const configName = basename2(found.path ?? CONFIG_FILE);
+    for (const id of result.summary.unknownRules)
+      io.stderr(
+        `pbiplint: ${configName}: no rule named "${id}" (run pbiplint rules for the list)
+`
+      );
+    return result.failed ? 1 : 0;
+  } catch (e) {
+    if (e instanceof UsageError || e instanceof ConfigError) {
+      io.stderr(`pbiplint: ${e.message}
+`);
+      if (e instanceof UsageError) io.stderr(`Run pbiplint --help for usage.
+`);
+      return 2;
+    }
+    io.stderr(
+      `pbiplint: unexpected error: ${e instanceof Error ? e.stack ?? e.message : String(e)}
+`
+    );
+    return 2;
+  }
+}
+
+// src/bin.ts
+process.stdout.on("error", (e) => {
+  if (e.code === "EPIPE") process.exit(0);
+  throw e;
+});
+main(process.argv.slice(2), {
+  stdout: (s) => process.stdout.write(s),
+  stderr: (s) => process.stderr.write(s),
+  cwd: () => process.cwd()
+}).then((code) => {
+  process.exitCode = code;
+}).catch((e) => {
+  process.stderr.write(`pbiplint: ${e instanceof Error ? e.message : String(e)}
+`);
+  process.exitCode = 2;
+});