Canvas AI skills for tables

Discover keys and relationships works across the tables on a canvas: launch it once, choose which of its three passes to run, and it proposes primary keys, business keys, and foreign-key relationships together, all from one review. Two more skills work on a single table instead: the one you have selected on the canvas or in the schema explorer. Enrich table metadata drafts descriptions and a business name; Classify sensitive columns proposes governance classifications. All three return a preview, and none of them writes to your catalog until you review that preview and accept it.

Discover keys and relationships

Launch this skill from a project or workspace canvas, or from the catalog Canvas tab. Choose which of its three passes to run, in any combination: Primary keys, Business keys, and Relationships. The run covers every table visible on the canvas by default, or narrow it first: the scope selector offers all tables, a single functional layer, or a hand-picked set, and any nodes you already selected on the canvas carry straight into the launch form. Landing-layer tables are listed but never scanned, since Landing mirrors raw arrivals before any keys or relationships exist to find.

The review opens in the docked Ask AI pane beside the canvas, so the diagram stays visible while you work through the proposals. Run only one of the three passes and the review is a single list; run keys and relationships together and the review opens as two tabs, Keys and Relationships, so you can check one without losing your place in the other.

Primary and business keys

The primary keys pass proposes a primary key candidate for each table in scope. The business keys pass proposes a business (natural) key, but only for tables where a business key makes sense: staging tables, or tables already in the data vault or data mart layer (hubs, links, satellites, dimensions, and facts). A source or landing table is never a valid home for a business key on its own.

That is why scanning a source table for a business key does not stop there: the proposal redirects to the staging table that source feeds, matched through the source’s recorded lineage where it exists, and by column name otherwise. If a scanned source table has no staging table downstream, its business-key proposal is skipped, and the review’s notice line tells you how many tables that happened to, so nothing goes missing silently.

Where a business key resolves, the review’s chip shows a composed integration key: the business key’s columns joined into one value, the same way an integration key is composed elsewhere in your Data Vault. Whether that composition includes the record source depends on your organization’s Data Vault settings. The launch form tells you which way it is set before you run discovery: Integration keys include the record source (Data Vault settings) or Integration keys do not include the record source (Data Vault settings).

Accepting a suggested key replaces the table’s current key. That is why the proposal goes through review rather than writing directly: swapping a table’s key is a consequential change, so you see exactly what is being proposed before it takes effect. See Define table keys for how a primary key and a business key work once one is set.

Relationships

The relationships pass proposes foreign-key-style relationships between the tables in scope: a candidate list, each with a confidence score and a short reason drawn from the tables’ columns, names, types, and profiling signals (value distributions, cardinality, and sample overlap). A deterministic pre-filter rules out table pairs that cannot be a parent and child relationship on structural grounds alone, so the model spends its reasoning only on pairs worth considering, and it works before any keys exist: on a freshly imported schema, it falls back to key-shaped columns (a column named id, a name ending in id, or endings such as code, key, number, and reference) matched by name and type.

Read confidence as how strongly the evidence points to a real relationship, not as a guarantee: a high score means the naming, types, and profiling signals agree, a low one means the evidence was thinner or mixed. Low-confidence candidates are included so you can make the call, not because the skill is asking you to accept everything it finds.

Accept a single candidate, or select a set and bulk accept them together. Accepting records the relationship on the source-layer tables the candidate names, and, by choice at apply time (on by default), promotes it forward to the same tables’ Staging and Persistent Staging counterparts, so the join you confirmed once follows the data through the pipeline. Next to the apply button, Apply to Staging and Apply to Persistent Staging are separate toggles, each ticked by default; untick either to skip that layer, or both to record the accepted relationships on the source layer only.

Each layer gets its own preview showing exactly what will be created there: a layer with no matching table simply does not appear, and a layer whose columns cannot be carried forward shows a notice naming what it skipped. The Landing layer is never a promotion target, though a relationship promoted to Staging still traces through the Landing tables that connect Staging back to the source.

Proposed relationships render on the canvas as dashed preview edges between the two tables, restyling the moment you decide: a dashed edge solidifies when accepted and disappears when rejected. Proposed keys render the same way, as ghost chips on their tables’ key columns.

Each pending edge points: an arrowhead runs from the table that would hold the new foreign key to the table it references, so you can read the direction before you decide. On the catalog Canvas tab, the two columns behind a proposal also surface as ghost rows on their tables, muted and dashed until you decide: the referencing column carries a foreign key marker, and the edge anchors column to column instead of table to table. Click a proposal card in the review pane, or its dashed edge on the canvas, and the two highlight together: the canvas pans to frame both tables while the matching card scrolls into view in the pane. Click an empty part of the canvas to clear the highlight.

You can also reach relationship discovery for one table at a time without opening the full launcher: right-click a table on the project canvas to edit its relationships, and choose Suggest relationships in that dialog.

Discover keys and relationships works at the physical table layer throughout. For business relationships and business keys between the entities on a business model, use Discover relationships and keys from the business modeling surface instead. See AI skills catalog.

Enrich table metadata

For a selected table, this skill proposes a clearer table description, a description for each column, a business name, and the matching business entity where one is evident from the table’s shape and content. It never changes structure: no column, type, or key changes come out of this skill, only descriptive metadata.

Review the proposal, then apply it. Nothing is written until you do.

Classify sensitive columns

For a selected table, this skill proposes governance classifications for the table’s columns from their names and types, across three schemes: sensitivity, personal data, and regulatory. It uses your organization’s platform taxonomy for these schemes, the same schemes governance uses everywhere else classifications appear (see Classification settings).

The skill returns one proposal per column, and only where it is confident. A column with no confident classification is left alone rather than guessed at. Review the proposed classifications, then apply them.

Troubleshooting

Nothing was proposed for a column, key, or relationship. This is by design, not a failure: each of these skills only proposes something when it is confident. A column with an ambiguous name or type, a table without a plausible key, or a table pair without a plausible relationship is left alone rather than guessed at. For relationships, check the run’s scope first (Landing-layer tables are never scanned); if the scope was right, either the pre-filter ruled out every pair or nothing met the model’s confidence bar, so try widening the scope or check that the columns you expected to match have comparable names and types.

Some tables had no staging target for a business key. The business keys pass can only land on a staging table, a data vault table, or a data mart table. Scanning a source table redirects its business-key proposal to the staging table that source feeds; a source table with no staging table downstream is skipped, and the review’s notice line counts how many tables that happened to. Build out the staging table first, then run the business keys pass again.

You do not want a proposed key. Reject it in the review step before applying. Because accepting a key replaces the table’s current key, review is exactly where you catch a suggestion that does not fit before it changes anything.

A layer shows a skipped notice for a relationship. That layer has a matching table, but one of the relationship’s columns could not be carried forward to it: the counterpart column it should map to was not found in that layer. Check that the counterpart column exists and is mapped in that layer, then run discovery again. A layer with no matching table at all is left out of the preview entirely rather than shown with a notice.

You applied or accepted on the wrong branch. All three skills write to whichever branch is active when you act on a proposal. Check the branch picker before you apply or accept; if you already acted on the wrong branch, switch to that branch to review what changed, or discard the branch if it was only created for this run.