01 Concepts
The medallion build
Follow a consented source batch through Bronze, Silver, Gold and serving.
Agree the meaning before compiling the layers
The medallion build turns a declared source batch and ratified model contract into Bronze, Silver and Gold notebooks. It is one part of the engineering chain. Compilation produces artifacts and a plan; it does not establish that those artifacts executed in a tenant or reconciled to the source.
Start with source coverage and an independently reviewed oracle. Then state what one fact row means. Sales, AP, AR, GL and Inventory seeds are draft starting points, not client decisions. A human ratifies the grain before Gold compilation. Keep that decision distinct from a fixture-only ratification used in an offline exercise.
Give each layer a visible responsibility
| Layer | Responsibility and evidence |
|---|---|
| Bronze | Capture the declared source landing batch and bind it to its observation. |
| Silver | Type, deduplicate and prepare data. Retain accounting and quarantine observations. |
| Gold | Build ratified business-facing dimensional structures and reconcile them to independent expectations. |
Bronze needs a clear batch boundary. Silver should explain what happened to rows rather than silently dropping inconvenient records. Gold needs the agreed business grain and relationships. Layer names alone do not establish any of those properties; the required checks and recorded observations do.
Source profiling and extraction also remain separate. Profiling produces a value-free index of structure, keys, counts and coverage. Extracting a batch moves source data under its own read consent. An oracle capture has a different purpose again: it establishes the expectation used to judge downstream actuals.
Review the plan before Fabric executes
The build compiles notebooks and a batch-scoped execution plan. Fabric execution enforces the declared workspace scope, consent and definition digests. Review the exact target and artifact definitions before approving the external writes. A broad request to install the suite is not deployment consent.
Retain execution results, captured checks and reconciliation observations. Producers report what happened; the ledger records receipts that bind those results to their dependencies. A notebook that finishes without a runtime error may still have dropped rows or calculated the wrong amount. Independent comparisons address that difference.
Serve the qualified structures, then check the report
The semantic step generates deterministic Direct Lake TMDL from ratified Gold. Generation does not implicitly deploy or refresh it. A deployed, framed base model is needed before measure probes can check actual DAX behavior against independent expectations.
Report authoring resolves fields against the model and emits deterministic PBIR geometry. The deployment path retains its exact-plan approvals, definition readback, refresh or framing requirements and actual query observations. Capture the rendered report separately; layout, query results and visible labels establish different things.
You can follow the whole sequence in How it works. For your first learning run, use the offline Sales exercise rather than inventing a live tenant result.
Incremental and history paths remain preview
Incremental capture, Silver MERGE, Type 2 versions and point-in-time fact bindings have implemented contracts, with scope-specific proof still required. Treat these paths as preview. A compiled history notebook is not a live history qualification.
History proof binds source, run, coverage and expectation epochs, batch identity and selected receipts. AP and Import delivery also retain separate publication, refresh and qualification obligations. Inspect the installed contract and the current project's evidence before extending a demonstrated Sales claim to a different process or serving mode.