Most Microsoft Fabric projects start with the same diagram. Three layers: bronze, silver, gold. Raw data lands in bronze, gets cleaned in silver, and gets shaped for reporting in gold. It is a sound pattern, and drawing it takes about five minutes.
The diagram is the quick part. You can stand up a working version in an afternoon, demo it, and it will look finished. It stays finished until one of two things happens: a second source system arrives with messier data than the first, or someone with authority asks a question you cannot answer quickly.
What “survives audit” actually means
Audit here is not only the formal kind. It is any moment when someone needs to trust a number enough to act on it and asks the obvious follow-ups. Where did this figure come from? Who is allowed to see it? When did it last refresh? If we ran it again, would we get the same answer? A medallion lakehouse that cannot answer those in a minute is a demo, not a platform.
The layers do not give you those answers on their own. They organise the data. The answers come from the parts teams tend to add last, or skip: lineage, quality gates, access control, and the documentation that ties them together.
Lineage you can actually follow
Lineage is the ability to take a number in a gold table and trace it back through silver to the exact bronze record and the load that brought it in. In practice that means a few habits, held consistently. Stamp every bronze row with its source and the timestamp of the load that wrote it, so no record is anonymous. Keep transformations as code in version control, whether that is dbt models or notebooks in a git repo, so the logic behind silver and gold is readable and reviewable. Fabric shows a lineage view across items, which helps, but treat it as a map rather than the whole record. The git history and the source stamps are what let you reconstruct a figure when someone challenges it.
Quality gates, so bad data stops early
The failure that erodes trust fastest is a wrong number that looks right. It usually comes from a bad batch that loaded quietly and flowed through to a report. The fix is to check data as it moves and to fail loudly when a check does not pass.
- Reconciliation. Compare row counts and control totals in silver against the source, so a partial load is caught before anyone sees it.
- Constraints. Enforce the rules you rely on, like a key being unique or an amount never being null, at the point data enters silver.
- Schema checks. Fail the run when a source quietly adds, drops, or renames a column, rather than loading whatever turns up.
When a check fails, the batch should stop and someone should be told, not have the run carry on and overwrite good data with bad. Quarantining a failed batch and alerting on it is far less work than explaining a wrong board number after the fact.
Security applied in one place
Access has to be designed in, not added once the data is already open inside the organisation. Row-level and object-level security belong in the model or warehouse, driven by Entra ID groups rather than named individuals, so access changes when someone’s role changes. Keep separate workspaces for development, test, and production, with least-privilege roles and no shared admin login. Where lower environments hold real personal data, mask or exclude the sensitive columns so a developer never needs production access to do their job.
Freshness you can see
“Is this current?” is one of the first questions anyone asks of a number, so the platform should answer it without a person checking by hand. Orchestrate the loads as pipelines with alerting, so a failed refresh raises a signal instead of leaving yesterday’s data looking like today’s. A visible freshness timestamp on the gold layer turns an anxious question into a glance.
How we build it, and what you are left with
When we build a Fabric lakehouse for a client, the layers are the fast part. The work that takes the time is the lineage, the quality gates, the security model, and the documentation: a data dictionary, a named owner for each dataset, and a runbook for the loads. We hand it over so your own engineers can operate it, add a new source without breaking the pattern, and answer the auditor’s questions themselves.
A medallion architecture is worth building. It is only worth trusting once it can tell you where a number came from, who can see it, and whether it is current. That is the half that takes the real work, and it is the half that decides whether anyone relies on the platform a year from now.