Findings JSON
Important
The Tabular Editor CLI is in Limited Public Preview. It is offered for evaluation with a Tabular Editor account; no license is required during preview. Commands, flags, and outputs may change before general availability. The preview build stops functioning after 2026-10-31. We recommend against using the CLI in production CI/CD pipelines during preview.
te validate, te bpa run, te test run, and te query report problems in one shared JSON shape, so a pipeline that gates on more than one of them needs one parser instead of four. Under --output-format json, each of these commands emits a single document - there is no way for one of them to leave nothing to parse.
Note
te query emits the findings envelope only when its pre-execution DAX validation produces at least one error. A successful query emits the query result instead: {columns, rows, rowCount, truncated, durationMs, trace?}.
The envelope
{
"command": "validate",
"durationMs": 412,
"summary": { "errors": 1, "warnings": 2, "info": 0, "total": 3 },
"findings": [
{
"severity": "error",
"source": "validate",
"code": "TE0001",
"message": "Unknown column 'Sales'[Amt]",
"object": "Revenue",
"objectType": "Measure",
"objectPath": "Sales/Revenue",
"expressionPosition": { "property": "Expression", "lineNumber": 3, "column": 9 },
"fixable": false
}
],
"valid": false
}
command- which command produced the document.durationMs- total run duration.summary- severity tally:errors,warnings,info,total.findings- one flat array, discriminated byseverity.
Per-finding keys
Present on every finding:
| Key | Values / meaning |
|---|---|
severity |
error, warning, or info. |
source |
validate, bpa, test, or query. |
code |
Stable finding code (a validation message ID, BPA rule ID, TEST_FAIL / TEST_ERROR / TEST_SUITE_INVALID, ...). |
message |
Human-readable description. |
object |
Bare name of the object the finding is about. |
objectType |
One of a closed vocabulary - see below. |
fixable |
true only for BPA violations whose rule defines a fix expression. |
Present only where the CLI knows them - these keys are absent rather than null when unset:
| Key | Populated by | Meaning |
|---|---|---|
objectPath |
validate and bpa violations only |
Canonical object path, resolvable as-is by te get or te set. Absent for test findings, query findings, and BPA rule errors. |
expressionPosition |
validate and query only |
{property, lineNumber, column} inside the named expression property. Optional on every source, including validate and query - absent whenever the analyzer reported no usable position, and all-or-nothing (never a partial position). |
ruleName, category |
bpa only |
The violated rule's name and category. |
objectType vocabulary
The closed set of objectType values (the singular forms of the path-grammar containers, not a TOM enum):
Measure, Column, Hierarchy, Level, Partition, CalculationItem, Table, Role, TablePermission, Perspective, Culture, DataSource, Expression, Function, Relationship, KPI, RefreshPolicy, Member, Calendar, Variation, Model, BpaRule, Test, TestSuite, Query.
Per-command extras
Each command keeps a few keys of its own at the top level of the envelope:
| Command | Extra keys |
|---|---|
te validate |
valid (boolean). |
te bpa run |
model, rulesEvaluated, violations, ruleErrors, ignoredRules. Rule-evaluation errors appear in findings at severity error with objectType: "BpaRule" - violations and ruleErrors split the two counts. |
te bpa run --fix |
A fix key inside the same single document: changes, fixed, fixErrors, skipped, fixedItems, fixErrorItems. If the fix pass itself fails, the envelope is still written with the reason in fix.error. Absent without --fix. |
te test run |
suites, invalidSuites, testSummary (per-status test tallies; summary remains the shared severity tally). |
te query |
None - and only on validation errors; see the note above. |
CI annotations
All four commands share one annotation writer for --ci vsts / --ci github (annotations go to stderr; stdout stays parseable):
- Annotations carry the finding's code:
code=on Azure DevOps,title=on GitHub. - Info-severity findings are not warnings: on GitHub they emit
::notice::, on Azure DevOps a plain log line. An Azure DevOps run whose only findings are informational reports Succeeded. - Multi-line messages are escaped into a single annotation line, so a rule description cannot break the log format.
Related pages
- Command Reference - exit codes are unaffected by the output format.
- CI/CD Integration - pipeline patterns that consume this shape.
- Automation and Scripting - parsing structured output from scripts.