Where should each order be delivered?

Demo · synthetic data

One order, its customer and its delivery address, in four steps: the question, what the engine suggests and the data shows, your decision, and what you can explain afterwards.

An order view needs each order’s delivery address

Order 100 has customer 8 and a ship_to_id of 13. The customer is clear: customer_id is named after the customers table, so the plan links it. ship_to_id names no table, so no naming rule links it, and the delivery address is not confirmed.

Illustrative preview · synthetic data The order view today: Delivery address not confirmed

Order	Customer	`ship_to_id`	Delivery address
100	8	13	not confirmed
101	3	5	not confirmed
102	6	10	not confirmed

The engine suggests a table and counts the values

Suggestion: orders.ship_to_id → addresses.address_id, from suggest_relationships
Why: The name reads as an address role (ship-to); its type matches the key of addresses; and orders and addresses already both point at customers.
Data check: All 60 orders in this sample have a ship_to_id that exists in addresses (15 different addresses). The next candidate, customers, holds for only 35 of 60: matching numbers alone would not have picked the right table.
What it does not say: A check counts values; it does not say what the column means. Only someone who knows the business can say that ship_to_id is where an order is delivered.

Technical details

suggest_relationships ranks the columns no rule links by name, type and triangles in the graph (score 3.94), then counts how many of their values exist in the target key, on the synthetic rows of this demo. In the tools: {"source": "orders", "source_cols": ["ship_to_id"], "target": "addresses", "target_cols": ["address_id"]} as a confirmed entry.

Does `ship_to_id` mean the address each order is delivered to?

This is your decision, not the engine’s. Your answer applies to this demo only. Nothing changes in Fabric.

With the tools you pass the relationship as confirmed, and the next plan, data dictionary or API carries it.

What you can explain now

Demo with synthetic dataYour example, in short

You reviewed: orders.ship_to_id → addresses.address_id, suggested by suggest_relationships
The data shows: All 60 orders in this sample have a ship_to_id that exists in addresses (15 different addresses).
Your decision: You left it open. Delivery address not confirmed
Still open: What ship_to_id means. The check shows the values match; the meaning still needs someone who knows the business.
Next: Document it: data_dictionary with the relationship in confirmed. Status: tested end to end (a draft; creates nothing).
Prepare a report: semantic_model_draft, a Power BI model in TMDL. Status: tested end to end (a draft; creates nothing).
Prepare an app: create_backend with the same entry. Creating a new API is experimental; updating one in place was tested end to end on 27 October 2026 (test status).

Illustrative preview · synthetic data The order view today: Delivery address not confirmed

Order	Customer	`ship_to_id`	Delivery address
100	8	13	not confirmed
101	3	5	not confirmed
102	6	10	not confirmed

Krusgraph demo with synthetic data (schema shop).
Reviewed: orders.ship_to_id → addresses.address_id, suggested by suggest_relationships.
Data check: All 60 orders in this sample have a ship_to_id that exists in addresses (15 different addresses).
Decision: left open.
Still open: what ship_to_id means.
Nothing was changed in Fabric.

Demo with synthetic dataYour example, in short

You reviewed: orders.ship_to_id → addresses.address_id, suggested by suggest_relationships
The data shows: All 60 orders in this sample have a ship_to_id that exists in addresses (15 different addresses).
Your decision: You accepted, in this demo, that ship_to_id is each order’s delivery address.
Still open: The check counts values in this sample at one moment; new rows can change it, and it does not ask whether the address belongs to the order’s customer.
Next: Document it: data_dictionary with the relationship in confirmed. Status: tested end to end (a draft; creates nothing).
Prepare a report: semantic_model_draft, a Power BI model in TMDL. Status: tested end to end (a draft; creates nothing).
Prepare an app: create_backend with the same entry. Creating a new API is experimental; updating one in place was tested end to end on 27 October 2026 (test status).

Illustrative preview · synthetic data The order view with your decision

Order	Customer	`ship_to_id`	Delivery address
100	8	13	address 13
101	3	5	address 5
102	6	10	address 10

Krusgraph demo with synthetic data (schema shop).
Reviewed: orders.ship_to_id → addresses.address_id, suggested by suggest_relationships.
Data check: All 60 orders in this sample have a ship_to_id that exists in addresses (15 different addresses).
Decision: accepted in the demo as the delivery address.
Still open: the check is a count in this sample; the address's customer was not compared.
Nothing was changed in Fabric.

The whole sample

Every table and relationship of the example. Select one to see why it was suggested and what the data check found.

suggested relationship1 — many cardinality needs your decision no key: query only

Suggested by the engineorders → customers

Suggestion: orders.customer_id → customers.customer_id
Why: The column name matches the customers table and its key.
Data check: All 60 orders in this sample reference an existing customer.
Your review: Does customer_id mean the customer that each order refers to?

Technical details

Rule R1: column named <B>_id / <B>id / <singular B>_id / <singular B>id (also _key, _code, _nr, _no, _sk, _bk) where B has a single key. In the API for GraphQL the link becomes orders.customer and customers.orders. The check is the counting query validate_plan runs.

Explore on your own, or try your own tables.

The demo graph lets you select any table or relationship of this sample. To review a plan for your own lakehouse, connect Krusgraph to Claude.

Explore the demo graph Connect to Claude