Plenty of source systems never declared a foreign key. The tables arrive complete, the columns arrive complete, and yet nothing anywhere records which column points at which table. Flat file drops land the same way, and so does any database whose constraints came off for load performance years ago and never went back on.

So someone has to reconstruct the joins by hand, and that someone is you. You open the schema, read the column names, work out which identifier belongs to which parent, draw the line, and then start again on the next one. On a source of any real size that runs into hours, and none of those hours go into the modelling you were hired to do.

Watch this in action:

Run the pass you actually need

Open a project, workspace, or catalog canvas, open Ask AI, and choose Discover keys and relationships. The feature runs three passes: primary keys, business keys, and relationships. You can run them in any combination, and that combination matters.

If the import already carried the primary keys across from the source, untick primary keys and business keys and run relationships on their own. You ask one question and get one focused list back.

By default, the run covers every table on the canvas, and the launch form narrows it from there: all tables, a single functional layer, or a hand-picked set. If you selected nodes on the canvas before opening Ask AI, those selections carry straight into that scope.

It works before your keys do

Before the model sees anything, a deterministic pre-filter rules out table pairs that cannot be parent and child on structural grounds alone. What survives is the set worth reasoning about.

That pre-filter does not wait on key design. Point it at a freshly imported schema with nothing designated yet, and it falls back to key-shaped columns, matching on both name and type: a column named id, any name ending in id, and endings such as code, key, number, and reference. From there, the model works only the pairs that survived, weighing names and types alongside the profiling signals your catalog already holds: value distributions, cardinality, and how far sample data overlaps between two columns.

The one it gets wrong is the point

Every candidate comes back with a confidence score, the two columns behind it, and a short written reason. Proposals draw onto the canvas as dashed edges, and each arrowhead runs from the table that would hold the new foreign key toward the table it references, so you can read the direction before you decide anything.

Some candidates are wrong, and the interface is built on that assumption. In a run over an imported sample, a delivery address column was proposed against the wrong parent. The rationale said little more than “the column looks like a delivery address”, the score sitting next to it was low, and the true parent was the address table further down the diagram.

That is a suggestion you can judge in a single read: untick it, dismiss it, and the relationship is never created. Confidence measures how strongly the evidence agrees rather than promising a correct answer, so low scores appear in the list precisely because you are the one making the call, not because the tool expects you to accept them.

The candidates you do accept are recorded on the source tables and, by default, promoted forward to their staging and persistent staging counterparts, with each layer previewed before it lands. Accepting is the only write, and it lands on your current branch like every other change.

Where AI earns its keep

Will it find every relationship in a messy source? No, and it makes no claim otherwise. It proposes what the evidence supports and leaves the rest alone. And if it keeps missing the same way in your domain, the skill isn’t fixed in place: an organization administrator can customize it and hand the model sharper instructions.

What goes away is the grunt work of squinting at column names, guessing at parents, and dragging one key onto another. What stays is the judgment, and that was always the part worth your afternoon.