Verification

In a company of any size, several tables end up with almost the same name. Verification is how you say which one the organization actually stands behind.

Any table can be verified — Foundation, Integration, Derived, and Dynamic alike — and so can a metric, which is a special kind of table. The whole trust axis belongs to admins.

The trust states

State	What it means
Unvetted	Nobody has endorsed it yet. This is where everything starts.
Verified	An admin has endorsed its definition. You can rely on it.
Verified · review pending	It was verified, but its definition has changed since. The endorsement is paused, not withdrawn.
Retired	Deliberately no longer the right thing to use. Still live and still queryable, but pushed down in search.
Verifying fingerprint…	Transient, and rare. The table is verified, but the fingerprint Ronja watches for changes has not been worked out yet — so she cannot yet say whether the definition has moved. Shown as Rehashing where space is tight.

Trust is a separate question from whether a table is finished building. A table can be fully built and live and still Unvetted — nobody has looked at it yet. The two never mean the same thing.

Verifying fingerprint… is the only state you should not see for long. It normally clears on the table’s next successful build. If it stays, an admin can click Verify again on the table’s page, which works the fingerprint out afresh and re-stamps the endorsement — for a metric, rebuild it first and then verify.

A metric always shows its trust badge, including Unvetted: a number the company is asked to trust should say so either way. An ordinary table shows a badge only once it has one worth showing — Verified, Verified · review pending, Retired, or the transient Verifying fingerprint… — so an unvetted table simply carries no badge.

Search (⌘K) is the one exception, for both: a search result shows a badge only when the table is Verified or Retired, never Unvetted, Verified · review pending, or Verifying fingerprint…. A results list is deliberately terse, and “review pending” is worked out from the table itself. Open the table to see the full picture.

Verifying a table

Open the table and find the Governance · admin only panel on its page.

Click Verify. The table’s definition is fingerprinted at that moment, and the badge turns green.
To step back from an endorsement, click Retire. The table keeps working; it is flagged historical and demoted in search.
A retired table is brought back with Re-open, which returns it to Unvetted.

Verification is never automatic — that is what makes the badge mean something.

An admin can do the same thing by asking Ronja in a chat: “mark the Orders table as verified”, “retire the old revenue table”, or “that change is fine — acknowledge it”. She shows you the action for approval before it runs, then reports the table’s new state back. She never verifies anything on her own initiative, and she has no way to do it on behalf of someone who is not an admin.

When Verify is not available

Some tables cannot be endorsed at all. On those, Verify is greyed out and the panel says why:

“This table has to build successfully before it can be verified.” — the table has never finished a build, so there is nothing built to stand behind.
“Move this table into a feature before verifying it.” — the table belongs to no feature, so there is no shared place where the endorsement would be seen.
“Unarchive this table before verifying it.” — an archived table is out of circulation.
“This table is not published to any discovery surface, so there is nothing to endorse yet.” — nobody would ever be offered the table, so a badge on it would endorse nothing.

A table in the trash cannot be verified either; restore it first. In every one of these cases Retire and Re-open still work — taking an endorsement back must always stay possible, even on a table you could not endorse today.

What “the definition changed” means

Once a table is verified, Ronja watches its definition and tells you when it moves. What counts as the definition depends on the kind of table:

For a Derived table or a metric, it is the calculation, followed all the way down through the tables it is built from. A change to an upstream table’s own SQL drifts everything downstream of it.
For a Foundation, Integration, or Dynamic table, there is no calculation to read, so it is the source the table is bound to plus the shape it produces — which columns exist and what type they are. Re-pointing a connection, or the upstream system adding, dropping, renaming, or re-typing a column, all count.

Extra rows alone never count. A daily refresh that brings in a million more rows changes nothing about the definition, and a verified table stays cleanly verified through it. What does count is the shape of the columns: one being added, dropped, renamed, or changing type moves the definition — including when the change comes from the data itself, as when a column that had only been empty finally receives real values and settles on a type. Ronja would rather ask than assume, so treat that as a prompt to look, not as an error.

When the definition does move, the badge changes to amber Verified · review pending and admins are notified — plus the owner, for a metric. Ordinary tables have no owner, so there it is the admins. The table keeps working. An admin then either clicks Acknowledge — “I have looked at the change and it is still correct” — which re-stamps the fingerprint and restores the clean badge, or has the change reworked.

Ronja errs towards flagging. If she tells you something drifted and the change turns out to be harmless, one Acknowledge clears it.

Verification and search

A verified table earns its place ahead of its rivals, and a retired one steps behind them. Both places you search do that, but they do it with different force — and the difference is worth knowing.

In Search (⌘K)

How well a result matches what you typed always comes first: an exact name match wins even if it is retired. Verification decides the order among results that match equally well — which is exactly the case that matters when eight tables have almost the same name. The verified one is offered first and the retired one last, and a result that is Verified or Retired shows that badge next to its name, so you can see why it sits where it does.

This is a re-ranking, not a filter: nothing is hidden because it is unvetted, and a retired table you search for by name still comes back.

When Ronja searches during a chat

When Ronja looks for a table herself during a chat, verification is not a tiebreak. It adjusts how relevant she judges each result to be — alongside how recently the table’s data was refreshed. A verified table is scored up, a retired one is scored down, and a verified metric is scored up furthest of all: the official definition of a number beats a curated dataset.

That is a stronger effect than the ⌘K ordering, deliberately. A verified table can be offered ahead of one whose name matches your words more closely, and a retired table can be pushed down far enough to fall off the end of the list Ronja looks at — in which case she will not consider it at all.

So if you want a specific retired table in a chat, name it directly, or open it from Search (⌘K), which never drops it. And when Ronja does use a verified table or a verified metric, she says so, so you can see which definition an answer rests on.

Two things verification does not do

It does not restrict access. Verification says whether a table is trusted, not who may read it. Access is decided by scopes and sharing.
It does not survive a move. Moving a table into another feature returns it to Unvetted. An endorsement given in one feature carries no endorsement into another, and a move changes who can see and edit the table.

Verification is also separate from drafts and approvals: a draft is a change waiting to land, while verification is a statement about what has already landed.