Review a workbook as code.

What is the direct answer to this workbook question?

Packaged .twbx archives and large .twb XML files are hard to review in Git or edit with AI coding agents. xmetric opens .twbx and .twb workbooks in your browser, and every shelf placement, mark, filter and Level of Detail formula in it is a command. A declarative text workbook format for Git workflows is in development.

Why are packaged BI workbooks difficult to review in Git?

Software engineering teams version-control their application code, infrastructure (Terraform), and SQL transformations (dbt), yet their BI layer often remains trapped in binary archives or auto-generated XML:

1. Opaque binary containers: A .twbx or .pbix file is a binary ZIP archive that cannot be reviewed line by line in a GitHub pull request (though Power BI Desktop also supports saving a Power BI Project .pbip folder of text files for Git).
2. Fragile XML bloat: Even if you unpack a .twb XML file, a three-sheet workbook routinely spans 20,000 to 60,000 lines of base64 thumbnails, window coordinates, and internal [Calculation_938472938] IDs. If an AI coding agent like Claude Code or Cursor tries to edit a .twb file directly, a single mismatched tag corrupts the workbook.
3. Click-only authoring vs code-only markdown: Existing "BI-as-code" tools force a tradeoff: either everyone writes raw SQL + Markdown in an IDE (leaving non-technical analysts unable to drag a pill to explore data), or everyone clicks around a GUI that cannot be cleanly diffed in Git.

How does xmetric connect visual shelves and commands?

xmetric is built on one principle: every action in the visual UI is a command.

Whether you drag Order Date to the Columns shelf with your mouse, filter Region, or define a { FIXED [Customer ID] : MIN([Order Date]) } calculation, the workspace runs the same structured command:

What could a future text workbook format look like?

Instead of 1,500 lines of XML for a single cohort retention chart, the text format in development aims to express only the data source, the named calculations, and the shelf encodings. A sketch (the final format may differ):

version: 1
datasource:
  file: orders.parquet

calculations:
  cohort_month: "DATETRUNC('month', { FIXED [customer_id] : MIN([order_date]) })"
  months_active: "DATEDIFF('month', [cohort_month], DATETRUNC('month', [order_date]))"
  retention_rate: "COUNTD([customer_id]) / ATTR({ FIXED [cohort_month] : COUNTD([customer_id]) })"

worksheets:
  - name: Cohort Retention Matrix
    mark: square
    rows: [cohort_month]
    columns: [months_active]
    color: retention_rate
    label: retention_rate
    filters:
      - field: status
        equals: "paid"
        context: true

In 22 lines of plain text, both a human code reviewer and an AI coding agent can see:

• Which calculation is a FIXED Level of Detail expression;
• That status = "paid" is a Context Filter (context: true), so it applies before the FIXED cohort calculation;
• Which fields sit on Rows, Columns, Color, and Label.

How do dashboards-as-code approaches compare?

Code-first tools store authored reports as source files; xmetric currently opens existing workbooks and exposes specific commands. Its declarative text format remains in development.

When are Evidence or Lightdash a better fit?

Use Evidence for a Markdown-and-SQL reporting workflow, or Lightdash for its governed metric definitions and explorer.

• Reports as Markdown and SQL. Choose Evidence if your team wants to write narrative data reports in Markdown and SQL inside VS Code or Cursor and deploy them as a static website through CI/CD.
• Governed YAML metrics. Choose Lightdash if your company wants every chart governed through YAML metric definitions (inside an existing dbt project or as standalone Lightdash YAML, since dbt is optional).
• Text files in Git today. Both already store their definitions as text you can diff; xmetric's text format is still in development.

When should I use xmetric?

Use xmetric when the starting point is an existing local workbook or a supported data file, rather than a new code-first report.

• Existing Tableau workbooks. Open .twbx and .twb files in your browser, inspect their calculated fields, and save packaged data files.
• Tableau's calculation grammar. Build views on shelves with FIXED, INCLUDE, EXCLUDE LODs and table calculations, for free.
• Humans and agents on one model. The public xmetric MCP server is live at https://getxmetric.com/mcp with no authentication or API key. Anonymous initialize, tool discovery and widget-resource checks passed on 2026-10-29. ChatGPT and Claude host rendering and tool selection remain unverified; their directory listings remain coming. The declarative text workbook format remains in development.

What is live, and what remains planned?

The public xmetric MCP server is live at https://getxmetric.com/mcp with no authentication or API key. Anonymous initialize, tool discovery and widget-resource checks passed on 2026-10-29. ChatGPT and Claude host rendering and tool selection remain unverified; their directory listings remain coming. See the dated public protocol receipt and setup and evidence limits.

The public server is available; host operation and directory approval are separate checks.

The file board parses supported .pbix, .twbx/.twb, CSV, Excel and Parquet files in your browser. Choosing a file shares supported schema, source names and calculation definitions with xmetric and the chat host; requested result cells, filters and SQL or DAX evidence are shared when answering. The original file is not uploaded by this flow. Small aggregates and labels can still be sensitive. Privacy details.

What data does this worked example use?

The initial view uses authored synthetic data, not customer data or a captured agent session.

The example record lists its file, calculation or SQL and expected values. The live browser result is computed by xmetric’s existing engine or workbook inspector. Samples are excluded from own-data activation reporting.