# Semantic model AST
The normalized shape every source format parses into. Power BI facts that the type
definitions cannot state on their own; read this before changing the AST or adding an
ingestion format.
## What is modeled, and what is not
Modeled: tables, columns, measures, partitions, relationships, hierarchies, RLS roles,
calculation groups, KPIs, and model-level shared M expressions. Columns also carry their
variations (TOM `variation`) — the declaration a report's date-hierarchy binding resolves
through — and tables carry the engine's auto date/time identity flags (`is_private`,
`is_local_date_table`, `is_template_date_table`).
Deliberately absent: data sources, perspectives, cultures and translations, role
memberships, annotations, linguistic metadata. None of them *consume* model objects, so
none can keep an object alive, so none affect reachability. Adding them later is additive
and breaks nothing — but do not add them speculatively. The single exception proves the
rule: the two engine annotations `__PBI_LocalDateTable` and `__PBI_TemplateDateTable` are
consumed, because they *describe* an object (which tables are auto date/time machinery)
and that description is load-bearing for the linter's verdict — not because they
reference anything.
Also absent for the same reason: data types, display folders, source column names,
calculation-item precedence. They describe objects; they never reference them.
## Power BI semantics the types don't show
**A calculated table is not a flag.** It is a table whose partition source is DAX rather
than M. `Table::is_calculated()` derives it from the partition; there is no boolean to
set, and an ingestion format that invents one is wrong.
**A calculation group is a property of a table**, not a top-level object. A calculation
group table also carries synthetic columns — the group's field column and an ordinal
column — in `columns` like any other table. Nothing distinguishes them structurally, and
DAX can reference them (`'Time Intelligence'[Period] = "YTD"`), so ingestion must map
them or those references will not resolve.
**Measure names are unique across the whole model**, not per table. A measure's home
table is provenance for display, not part of its identity for lookup. See
[name-resolution.md](name-resolution.md).
**Relationships default to active.** TMDL omits the flag for active relationships, so
`Relationship::default()` sets `is_active: true`. An inactive relationship still keeps its
key columns alive — `USERELATIONSHIP` can switch it on at query time — so the flag is for
reporting and linting, never for liveness.
**A column's sort-by column is a liveness edge.** A used column keeps the column it sorts
by alive, even when nothing else references it.
**Auto date/time is identity, not liveness.** The engine generates a hidden
`LocalDateTable_*` per date column (plus one `DateTableTemplate_*`), and the model says
which tables those are: the `__PBI_*DateTable` annotations, `isPrivate`, and — for formats
that carry neither — the `LocalDateTable_`/`DateTableTemplate_` name prefixes. The flags
are display-only metadata; they never confer or remove liveness. Two things read them:
the graph's hierarchy-binding resolution (a visual's date hierarchy over a varied column
lands on the related `LocalDateTable_*` through `Column::variations`), and
`DependencyGraph::auto_date_time_tables` — the provenance-based verdict (in use /
unused by reports / dead) that scan renders in its own section. That verdict is
deliberately *not* reachability: the engine's own relationship keeps the machinery alive
for as long as the user's date column is used, so "alive" says nothing about whether a
report binds it.
**Partition sources are four, not two.** M (Power Query), DAX (calculated table), a legacy
native query in the data source's own dialect, and `Other` for DirectLake entity
partitions, inferred partitions, and kinds Microsoft has not shipped yet. `Other` and
`Query` yield no DAX and no M, and must never be guessed at — an unrecognized source
lands in `Other`, which is why its `Default` is not derived.
## Expressions hide in unobvious places
Missing one expression site means the objects it references get no edges and are reported
unused. That is a false positive, and the scan design forbids them. Beyond the obvious
measure and calculated-column expressions, DAX also lives in:
- dynamic format strings, on measures and on calculation items
- KPI target, status, and trend expressions
- detail-rows (drillthrough) definitions, on measures and on tables
- RLS filters, one per role per table
- calculation item expressions
`TabularDatabase::dax_expressions()` and `m_expressions()` are the only enumeration of
these sites. The graph layer consumes those two functions instead of walking the AST, so
a new expression-bearing field cannot be silently omitted from reachability analysis.
**Adding an expression field to the AST means adding it to the enumeration** — the tests
assert every kind is produced exactly once from a fixture that exercises all of them.
Enumerated expressions borrow their owner's names rather than carrying an owned
`ObjectId`, so walking every expression in a model allocates nothing. The graph layer
calls `to_object_id()` once per node it actually creates, instead of once per
expression — a measure with a format string, detail rows, and a KPI would otherwise
pay for six identical owner keys. A test pins both views as `Copy` to keep it that way.
Each enumerated expression carries a home table: the row-context table used to resolve
unqualified references inside it. For an RLS filter that is the permission's target table,
not anything belonging to the role. For a calculated table's partition it is the
calculated table itself, which is deliberately conservative — unqualified columns in such
an expression usually belong to the *source* table, so this can only add candidate edges,
never drop them.