Asserted vs. derived edges

Your graph has an edge on it that says a customer is at risk.

Try to find where it came from. Open the customers table. There is no "at risk" column. Open the orders table, the shipments, the freezer telemetry. No row says "at risk" about anyone. You did not type it. No upload brought it in. No key match made it. But there it sits on the graph, an edge, just like any other.

So who put it there?

Nobody did. A rule did. Somewhere a freezer breached. That breach sits three hops away from the customer, along edges you did store. A rule walked those hops and worked out something the data never stated directly: this customer is about to get a bad shipment. It wrote that conclusion onto the graph as an edge.

Two kinds of edge, one graph

Look at a single graph and you cannot always tell which edges you stored and which ones a rule concluded. They look the same. They traverse the same. But they were made in different ways, and that difference decides one thing: can you trust an edge as a fact, or must you treat it as an opinion that can change.

The three solid edges are asserted. Each one is a key you recorded. This order's customer_id really does point at Acme, so "Acme places O-101" is a stored fact. Nothing computed it. It is already in the data, and the edge just makes the match easy to see.

The dashed edge across the top is derived. No row holds it. A rule took the whole three-hop chain and turned it into one conclusion, "at risk", then drew it as an edge. It is true right now, for exactly as long as the breach and the chain behind it stay true.

A derived edge is an output, not a record

Here is the part people get wrong. A derived edge sits on the graph and looks like every other edge, so it is tempting to treat it as a solid fact. It is not. It is the current output of a small calculation, and every calculation has inputs.

The inputs are the asserted graph and the rule. Change either one and the output changes. Add a breach, and new at-risk edges appear. Fix a wrong foreign key so a shipment no longer reaches a customer, and an at-risk edge quietly goes away. Rewrite the rule to also require a same-day delivery window, and the whole derived layer redraws. Nothing in that right-hand column was ever saved. It is worked out again from whatever the data and the rule say at the moment you ask.

That is a strength, not a weakness. An asserted edge can go stale, meaning out of date, because a fact you recorded last Tuesday stays on the graph until someone updates the row. A derived edge cannot go stale, because there is nothing to update. It is only ever as fresh as its inputs.

Flip the inputs yourself and watch which edges move.

Notice what never moved. The five solid edges stayed perfectly still through every toggle, because they are facts you stored. Only the dashed ones came and went, because they were conclusions the graph kept working out again. That is the whole difference, and once you see it you can read any graph correctly: solid means recorded, dashed means concluded.

Why this matters for an AI agent

An AI agent grounded in the graph will answer using both kinds of edge, and it will not tell you which is which. Ask "which customers are at risk" and it walks derived edges. Ask "which customer placed order O-101" and it walks an asserted one. Same walk, but you should trust the two answers differently, and an honest agent can tell you why: this edge is a stored fact, that one is a conclusion a rule drew from these three facts.

That is what makes derived edges powerful instead of dangerous. The conclusion is not a random guess. It has a derivation: a specific path of asserted edges plus a named rule, and the agent can show it. "At risk because F-02 breached, cooled shipment SH-9, which carried order O-101, which Acme placed." Every step of that is a stored fact. The at-risk edge is just the sum of them.

How the two kinds materialize

When Fabric IQ materializes the ontology into a knowledge graph, it builds both kinds of edge, in layers. The asserted edges come from your data bindings. You bound a relationship to a foreign key, so a stored key match over your OneLake tables becomes an asserted edge in the graph Fabric IQ builds. The derived edges come from rules and inference (rules that draw new conclusions) running over that asserted graph, and they produce new edges the raw data never held.

The difference stays honest because the model keeps it clear. A derived edge is worked out again from the data and rules as of the materialized graph's refresh, not stored as ground truth. So it reflects that last refresh, not the instant you ask. And the two kinds keep separate origins. An asserted edge traces back to its binding and the row behind it. A derived edge traces back to the rule and the asserted edges it fired on. That separation is what lets a data agent pointed at this graph tell "you stored this" apart from "a rule concluded this" in its own answer.

Fabric IQ is in preview as of July 2026. The exact way you write these rules and trace an edge back to its origin will keep changing, so do not rely on the exact steps yet. The idea underneath is the part that lasts: your graph carries facts you asserted and conclusions it derives, and the derived layer is a recomputation, never a saved truth.

The one trap

Do not treat a derived edge as a fact you can file away. The moment you copy an at-risk edge into a report and act on it a week later, you have frozen a conclusion whose inputs have changed since. The breach cleared, the order shipped, the rule got stricter, and your frozen edge is now wrong, even though it still looks sure. Asserted edges you can snapshot, because they were facts when you stored them. Derived edges you re-ask, every time, because their whole value is that they reflect the graph as it is right now.

You have seen how the graph gets its edges, and that the derived ones get worked out again every time the data under them changes. Recomputing is not free. Neither is keeping the whole graph in storage, ready for a question that may never come. Next: what the graph actually costs.