Generate and inspect TMDL

What you'll do

Inspect a generated semantic model and create a metadata-review worksheet. You will check tables, relationships, date roles and measure specifications without claiming deployment or refresh. Use a ratified synthetic snapshot contract and the approved installed runtime, or inspect the offline demonstration's described output.

Generate from the right contract

TMDL is the text representation of a semantic model. The dimensional-model generator creates a new deterministic Direct Lake model from a ratified Gold contract and project configuration. Generation does not contact a source or service, author DAX measures, deploy a model or refresh its data.

The installed snapshot example is:

❯node .agent-skills/powerbi/dimensional-model/runtime/semantic.mjs generate --contract contracts/gold.json --project project.json --name "Sales" --result evidence/generate-result.json

Use reviewed project inputs and a new output location. The command is an example for the documented basic route, not a replacement for publication-bound snapshot or history instructions. Those modes require their own complete manifests and explicit reporting choices. Missing history inputs must refuse rather than produce an apparently complete model.

Inspect structure before measures

Start with the model's table inventory. Find the fact, descriptive dimensions and intended date roles. Compare their names, columns, keys and types to the ratified contract. Follow each relationship from its fact column to the intended dimension key. A relationship count alone does not establish the correct filter path.

The offline Sales demonstration describes five tables, six relationships and no measures. "No measures" is a useful boundary: measure authoring and its independent probes belong to a later workflow. A complete-looking diagram should not encourage an assistant to invent DAX merely to populate report cards.

Review entry:
Question: monthly posted sales by territory
Path: agreed date -> sales fact -> territory context
Evidence: current model definitions and model-map review
Pending: DAX probe, deployed query and rendered value

Read the map as metadata evidence

The documented model-map workflow produces a schema-only bus matrix, inventory, relationship risks and a measure glossary from TMDL without changing the model. Use those outputs to explain which dimensions support which processes and where relationships deserve investigation. A bus matrix is a communication aid, not numerical reconciliation.

Compare the map with the current model definitions. If the model changes, an old map is a historical description. Do not treat a stale diagram as authority for new edits or a guarantee that a relationship still exists. Keep cited model revisions with your worksheet.

Plan the next evidence

Write three separate next steps: author and probe required measures against independent expectations; deploy through the reviewed execution boundary; observe the deployed model and report in named states. Each needs its own scope and consent. Generation grants none of those permissions automatically.

Finish with a plain statement: "The synthetic model definitions were generated and inspected; live data, measure correctness and report rendering remain unqualified." That is a useful completed modelling exercise. It says exactly what your evidence supports while leaving the next engineer a concrete plan.

Check your understanding

1. What does deterministic TMDL generation establish without a service request?
2. Why can six relationships still contain a wrong business filter path?
3. Which evidence is needed before a generated model supports a qualified report value?