Time-series binding

A freezer is not one temperature.

It is a temperature at 09:00:00, and another at 09:00:30, and another thirty seconds after that, and it keeps sending one for as long as it runs. The whole story of that freezer is in the stream: the night it drifted warm, the four minutes a door stood open, the exact moment food stopped being safe.

Now try to hold that in one cell. You bind the freezer's temperature to a single value, the way you would bind its serial number. The first reading lands: −18.2. The next one lands and overwrites it. The next overwrites that. By the time anyone looks, the cell shows one number, and every reading before it is gone. The breach happened, but the record of it was gone the moment it arrived.

A single value throws the history away

The problem with binding telemetry, the readings a sensor keeps sending, to one cell is not that the number is wrong. Each reading is fine on its own. The problem is that a cell has room for exactly one reading, and the sensor keeps sending more.

Overwrite, overwrite, overwrite. You are left with the latest reading and no way to ask the question that really matters: not "how warm is it now" but "was it ever too warm, and for how long". That question needs the whole series, and a single-value binding never kept one.

One concept, two bindings

So the fix is not to choose between identity and history. You hold both on the same concept, through two different bindings.

The static binding answers "which freezer is this": its id, its bay, the safe-max it was built to hold. Those facts do not change. You would be surprised if the bay changed between readings. The time-series binding answers "what has it been doing": one temperature per tick, the whole run kept, nothing overwritten. Same Freezer, two kinds of fact, and one never replaces the other.

Scrub across the history and you can see the difference. One value stays fixed. One value moves.

Watch what happens in the middle of the run. The safe-max never changes, because it is a fixed fact, bound once. The reading climbs, crosses the fixed line, and the freezer switches to breach, because it is state over time, and state moves. A single-value binding would have shown you one number and hidden the climb that made it dangerous.

Dual binding: a lakehouse and an eventhouse, side by side

In Fabric IQ an entity type is not limited to one source. A single concept can carry more than one binding, and they can point at very different places.

The Freezer's fixed facts bind the same way you saw before: to a table in a lakehouse or semantic model, one row per freezer, holding its id and bay and safe-max. Its temperature binds to a place built for fast-moving data. Streaming readings land in an eventhouse, the store Fabric uses for high-volume time-series data, usually fed by Eventstream from the live sensor feed and queried with KQL. So the same ontology concept reads from a static table to know who the freezer is, and from a live telemetry store to know what it is doing. This is the cold-chain pattern in one shape: identity is static, temperature is a series.

A data agent, Fabric's name for an AI agent grounded in your data, gets both, and it does not need to know they came from two different engines. It can say which freezer this is and whether that freezer breached last night, because the concept it reasons over is bound to both. In the lab, the time-series step runs real series math over a bundled telemetry CSV instead of a live eventhouse stream, so you can watch a breach get computed without setting up Eventstream. The ontology item is in preview as of July 2026, so treat the details as likely to change, but the core design will last: one concept, a binding for identity and a binding for state over time.

The one trap

Do not reduce a stream to just its latest value because that is easier to store. The moment you bind telemetry to a single cell, you have decided that history does not matter, and you will find out you were wrong only when someone asks how long the freezer was warm and the answer is gone. A moving fact needs a binding that keeps every tick. Give the concept two bindings, one fixed and one moving, and it can be a thing and remember its whole history at the same time.

You have now bound identity, fixed facts, and state over time onto your concepts. Every row is wired to something real. Next you get to see the point of all that binding, when the entities and edges stop being a schema and join into one connected thing you can walk through: the knowledge graph.