Data Contracts in Microsoft Fabric

A supplier file lands at 6am, as it does every morning. The pipeline runs, the refresh completes and the dashboard looks normal. Overnight the supplier renamed one column, so the field your margin calculation relies on is now empty. Nothing has failed, so nothing raises an alert.

This is schema drift: the structure of incoming data changes and nothing downstream is told. A data contract is the practical way to catch it as the data arrives, before it reaches your Silver and Gold layers and the people reading your reports. If you are after the business case rather than the build, our companion article covers the cost to trust and decision making.

Think of the contract check as the goods-in bay at a warehouse. A delivery is checked against the order before anything goes on the shelves, and whatever does not match goes into a quarantine cage while someone phones the supplier.

Why a successful pipeline can still load the wrong data

Your platform depends on systems it does not control: CRMs, finance packages, supplier feeds and third-party APIs. Four kinds of change are common:

A field is renamed or removed, so reports that rely on it show blanks or zeros.
A field changes format. A date arrives as text, or a number arrives with a currency symbol.
A new region, product or status code appears with no mapping, so it drops out of totals.
A file arrives empty, late or twice, leaving figures understated, stale or double-counted.

Many pipelines load what they receive and carry on. A failed job gets noticed straight away, whereas a job that succeeds with the wrong data can go unnoticed for weeks.

What a data contract covers

A data contract is an agreed definition of what a source should deliver. It records the structure (which fields to expect and the type of each), the rules (which fields must be filled in and which values are allowed), the timeliness (when the data should arrive and roughly how much of it) and the ownership (who is responsible for the source and who to contact when something changes).

Ordinary documentation can say all of that. What makes a contract different is that it is checked automatically: each time new data arrives it is compared against the contract, and a mismatch is flagged immediately. The Open Data Contract Standard gives you a formal YAML format if you want one, though a simple in-house version works just as well.

Where a contract check fits in a medallion design

Many Fabric platforms use a medallion design with Bronze, Silver and Gold layers, as we did in our Fabric case study, where scheduled ELT pipelines load raw data into the Bronze lakehouse layer. The design keeps a raw copy and separates cleaning from reporting, so recovery is possible. It does not notice that incoming data has changed. The contract check closes that gap, and we would normally place it at the handover from Bronze to Silver.

In practice the check does four things. It leaves the raw copy untouched, validates each load against the contract, holds anything that fails in a quarantine area and alerts the data owner with a clear description of what changed. The quarantine area is the cage in the goods-in bay: the delivery is not refused, only kept off the shelves until someone decides.

A worked example with a supplier file

Take the 6am file again. Without a contract, it loads as normal and the renamed field arrives empty. Reports show an unexpected drop in a key figure, and a few days later a manager or a client asks why. Someone spends hours tracing the cause, the reports are corrected and the wrong figures are explained to people who have already seen them.

With a contract, the sequence looks like this (the timings are illustrative):

Within minutes of arrival, the check spots the missing field.
The file is held in quarantine, and reports continue to show the last correct data.
The data owner receives an alert naming the missing field and the supplier.
They contact the supplier, or approve the change if it was expected.
Once it is resolved, the file is reprocessed from the raw copy.

Not every change needs to stop the process. A new optional field can usually be accepted automatically, while a missing or renamed field should be held for review. Agree in advance which is which, and write it into the contract. The point is that every change is noticed and someone decides what happens to it.

What Microsoft Fabric offers for data contracts

At the time of writing, Fabric has no single data contract feature for tables, files and databases. For streaming events there is a close equivalent: Event Schema Registry became generally available in September 2026, and Microsoft describes it as defining and validating contracts between event producers and consumers. For everything else, Fabric provides building blocks, plus a few features that make the problem more pressing.

Features that help

Pipelines and notebooks can run validation checks as data arrives, and they are a natural place to build a custom contract check. Materialized lake views, also generally available since September 2026, let you attach constraints to a view. Each constraint either fails the refresh or drops the offending rows, and fail is the default. Currently, a dropped row shows up only as a count in the lineage view, so a quarantine area still has to be built.

Dataflow Gen2 destinations can be set to a fixed schema, which stops a change in the query output from silently reshaping the destination table. Event Schema Registry validates events against Avro schemas, but it drops events that do not conform instead of routing them to a quarantine, logs the error in the eventstream runtime logs and does not enforce compatibility between schema versions. Schema-aware eventstreams are still in preview.

Features that can let changes through

Some Fabric features are designed to keep data flowing by adapting when a source changes. Mirroring of Azure SQL Database passes through schema changes such as renamed columns and changed data types, and shortcut tables in Eventhouse sync column additions, deletions, renames and type changes automatically unless you switch that off. That is convenient, but it means a renamed or removed field can travel straight through to your reports. Separately, primary key, unique and foreign key constraints in a Fabric warehouse are declared but not enforced, so uniqueness has to be checked elsewhere.

Ownership and monitoring with Microsoft Purview

Microsoft Purview lets you record an owner and terms of use for each data product in the Unified Catalog, and its data quality features can score the health of your data. Check what is available for Fabric in your tenant, as parts are still in preview. Our article One platform - one governance covers how Purview and Fabric work together, and our Microsoft Purview services cover the build.

AI-assisted data engineering in Fabric

Microsoft acquired Osmos in January 2026, and the Fabric data engineering agent built on it (Project Osmos) is in preview. You give it a task and it plans and carries out the work within guardrails you set, then validates the result against the lakehouse resources you authorise. An agent can only check data against the rules it has been given, so you still need a clear definition of what correct data looks like. We make the same point in Data fundamentals - why good data is the essential precursor to effective AI.

Getting started with data contracts

Automated checks catch problems, and agreements between teams prevent them. The biggest difference usually comes from naming an owner for each data source on both the supplying and receiving side, and agreeing a simple change process so that system owners and suppliers give notice before they change what they send. You cannot control every external source, so detection is needed alongside prevention.

Start with external feeds and the sources behind your most important reports, then extend from there. If you are also planning a move from Power BI to Fabric, our guide to the risks leaders need to plan for is worth reading alongside this.

Four questions to ask about your own platform:

If a source system changed its format tomorrow, would we know before our reports were affected?
Who would be alerted, and how quickly?
Can we recover and reprocess data if something incorrect gets through?
Do we know who owns each of our data sources?

How PTR can help

We specialise in building data solutions in the Microsoft ecosystem, including Fabric, and we work in a collaborative, mentoring style so your team understands and owns what we build. A typical route looks like this:

Free Discovery Workshop. A one-hour call with one of our solution architects about your data sources and where the biggest risks sit.

Data Discovery Project. Typically three to five days spent reviewing your systems, pipelines and skills, ending with a technical strategy and implementation plan. See our data discovery service.

Implementation. Contract checks, quarantine and alerting built into your platform through our Microsoft Fabric consultancy and data integration work.

Training. Hands-on Fabric courses, including a one-day course on data ingestion with Data Factory and Dataflows, so your team can maintain and extend the checks.

Book a free discovery workshop or call us on 0118 979 4000.

Microsoft Fabric

Data Contracts in Microsoft Fabric

Why a successful pipeline can still load the wrong data

What a data contract covers