Axi checks a key on your data before declaring it
Axi could already put a key in your draft. It now reads your data first, and shows you the count it read.
The numbers come from the query
Ask "which columns of orders are keys?" and Axi samples the column before it proposes anything.
For a primary key, it reads up to 50,000 rows and counts how many values were different and how many were empty — a column whose values repeat, or that is sometimes blank, is not a key. For a foreign key, it takes up to 10,000 distinct values and counts how many of them actually exist in the table it would point at; anything short of all of them means the join would quietly drop rows.
The result sits under the change on the card: 4,812 of 4,812 sampled rows distinct, 9,998 of 10,000 sampled values found in customers.id. Those figures are measured, not written by Axi — it reads them to make up its mind, and cannot round them or invent them. They are samples rather than proofs, so the judgement stays yours.
A key it has not checked says so
A key proposed without a check comes back greyed, marked Not checked on your data yet. If you already know the column and want it declared anyway, say so and Axi will — noting in its answer that it did not look.
A column that looks like a key but points at a table that is not on this connection is reported rather than proposed. Axi tells you what it appears to point at and stops, because that reference could never resolve into a join.
Also new
Axi can now mark a bridge table's key as joining in both directions, and hiding a whole column is a single change on the card rather than one row per field bound to it.
Checks are read-only and capped, but they are real queries. On BigQuery a foreign-key check reads one column of each table, so ask for a table at a time rather than a whole connection when the bill matters.