Data binding

You spent the morning defining Customer. It has a name. It has a region. Maybe a tier. On the canvas it looks finished, a clean little card with three neat property slots.

Ask it anything and nothing comes back. How many customers are in the Northeast? Silence. Name one. It cannot. The card is beautiful and completely empty, because right now "Customer" is a word. It describes a shape, and the shape points at nothing.

Somewhere in your lakehouse there are eight thousand real customers sitting in a table. The concept and the rows are both right there. They just have no wire between them.

A word until you point it at something

A concept is only a symbol. A symbol means something only when it points at a real thing. "Customer" the word and Acme Foods the real company are two different things. The binding is the arrow between them.

So a binding is small and specific. It does not say "connect Customer to the database" in some vague way. It says: the name property reads from the cust_name column, the region property reads from home_region. One property, one column, each wire drawn on purpose.

Notice the property you leave alone. An unbound property is not zero or blank. It is nothing at all, a slot with no source, and no amount of good data will fill it because nothing ever told it where to look. Binding is the difference between a slot that can hold a value and a slot that will.

Bind it, and the instances appear

Here is the payoff. It is less dramatic than people expect. You do not create instances. You do not type in Acme Foods, then Globex, then Initech, one card at a time. You draw the wires once, and the instances fall out of the rows.

Every matching row becomes one instance. The bound properties get their values from the bound columns, row by row, automatically. Add a row to the table tomorrow and a new instance appears already filled. Fix a value and the instance updates. The concept was a template with empty slots. Binding fills those slots with the live data.

Try it. Pick a property, pick the column that feeds it, and watch a single sample instance fill. Then leave one property unbound on purpose and see what "empty" really looks like.

Where the wire lands in Fabric

In Fabric IQ, this wire has a name and a home. A data binding maps an entity type, and each of its properties, to a source in your Fabric tenant: a lakehouse table or an eventhouse (KQL) table in OneLake, or a Power BI semantic model. The entity type stays exactly the same. The binding is what decides where its instances come from.

Binding is the step that turns an abstract type into concrete entity instances. Before it, the ontology is a vocabulary: Customer, Order, Shipment, the properties, the relationships, all declared and all empty. After it, the same ontology materializes into a knowledge graph over your real rows, without copying the data out of OneLake. That graph is what a data agent (Fabric's name for an AI agent grounded in your data) walks over when it answers a question. It does multi-hop reasoning over the bound instances. It does not guess. In the lab here we simulate the same wiring over uploaded CSVs, but the shape is identical. As of July 2026 Fabric IQ is in preview, so the exact details may change. Hold on to the idea that lasts: a type is empty until a binding points it at real data.

The one trap

Do not mistake a binding for a promise. The wire says where a value comes from. It says nothing about whether that value is any good. Bind region to a column full of blanks, a few wrong country codes, and three different spellings of "Northeast", and every instance copies that mess exactly. The binding did its job. It pointed at the column you named, and that column was full of bad data.

So binding answers where, and it opens the very next question: is the data in there good enough to become an instance? That is data quality, and it is where we go next.