Install and qualify the Sales sampleLesson 3 of 6
Run the offline Sales demonstration
Inspect source analysis, fixture grain ratification and generated semantic metadata.
Run the documented demonstration
This exercise shows a dimensional model being built from AdventureWorks-shaped Sales inputs. It runs from the approved learning checkout with Node 24 or newer. It requires no Fabric request and no Hosted account. Keep it separate from a retained proof project: temporary demonstration artifacts are useful for learning, while a real project owns its catalogue, expectations and history.
Run the documented script from the library root:
node packages/powerbi/dimensional-model/tests/demo.mjsThe demonstration uses the Sales domain seed and a reference contract. It analyses the header/line relationship, validates the draft, performs fixture-only ratification, generates a semantic model and maps its metadata. Its final checks describe five tables, six relationships and no measures. Those are expectations for this particular demonstration, rather than a promise about every Sales model or a completed live pipeline.
Read the grain decision
Pause when the demonstration reaches ratification. What does one fact row represent? An order and an order line are different grains, even though both concern Sales. Source metadata helps identify relationships and ambiguity, but business meaning still needs a human decision. The fixture record teaches the protocol without providing customer approval.
Write a plain-language grain statement in your worksheet. Then identify who would be authorised to confirm it in a real engagement. Do not copy the demonstration's reviewer identity or its fixture approval into a client project. A generated contract and a human ratification record have different evidential roles, and the distinction must survive the handover.
Inspect what was produced
TMDL is a text representation of semantic-model definitions. Generated model metadata can expose tables and relationships for inspection. It does not establish that measures exist, that the model was deployed, that data was refreshed or that the serving model answered an independent comparison correctly. The demonstration reports no measures, so do not describe it as a validated measure library.
The temporary artifacts are cleaned up. Record the observed exercise output and your interpretation rather than relying on permanent files that the script does not retain. Keep the worksheet synthetic. The useful evidence here is that the documented offline protocol ran and exposed the intended modelling decisions, not that a customer-owned report has passed a qualification gate.
Distinguish the next observations
For live work, source expectations must be authored and captured independently. Fabric execution must be explicitly consented to and observed. Gold reconciliation, semantic probes, report queries and rendered states have separate requirements. Producers emit step results, and the ledger records the supporting receipts. A model-generation success cannot replace any of those missing observations.
| Demonstration observation | Safe interpretation |
|---|---|
| Source analysis | The fixture relationship was analysed |
| Draft validation | The proposed contract passed the demonstrated checks |
| Fixture ratification | The learning protocol recorded a fixture decision |
| Semantic generation | Definitions were produced and inspected |
| Five tables, six relationships, no measures | The documented fixture metadata matched its checks |
Completion check
Explain the demonstration's inputs, its fixture-only grain decision and its final metadata checks. Name three live observations it did not perform. Then explain why temporary cleanup is expected and why the absence of a retained live receipt is not a reason to invent one. The next lesson uses missing evidence deliberately: a gate should refuse a qualification claim when the supporting observations are absent.