Certifications and relationships

Metrics govern your answers. Certifications and relationships govern the tables the answers come from: which sources to trust, which to avoid, and how tables join – so agents stop guessing.

Table certifications

A certification is a human-vouched trust mark on a warehouse table or view:

The classic case: your warehouse has both a synced stripe_charges table and a hand-rolled payments_backup someone loaded last year. Certify stripe_charges with a note like "canonical payments source, synced daily" and deprecate payments_backup with "superseded by stripe_charges, stale since March". The notes matter – agents read them when choosing between sources.

The flow mirrors the rest of the semantic layer: anyone proposes with data-catalog-certification-propose (targets can be addressed by ID or by name – an ambiguous name returns candidates to pick from), and a human resolves it with data-catalog-certification-certify-prepare / -execute or data-catalog-certification-deprecate-prepare / -execute, both of which require typing "confirm". Revoking a certification deletes it outright, with the change activity-logged.

Certifications surface wherever schemas do: system.information_schema.tables rows carry each table's trust mark in the certification column, so anything exploring your schema sees them inline:

SELECT table_name, table_type, description, certification
FROM system.information_schema.tables
WHERE table_name IN ('stripe_charges', 'payments_backup')

Relationship proposals

A relationship proposal is a reviewed join fact between two warehouse tables. Instead of every session rediscovering that orders.customer_id matches stripe_customers.id, an agent proposes the join once – with evidence – and a human accepts it.

A proposal records the two tables, the join keys, a confidence score, reasoning, and sampling evidence: the agent shows its work, like "98% of orders.customer_id values match stripe_customers.id in a sample". Proposals are deduped regardless of direction, so orders → stripe_customers and stripe_customers → orders count as the same pair.

You can also create, edit, and delete joins manually from the Relationships tab without going through the proposal flow. Click New join to open the join editor, or use the more menu on any active join row to edit or delete it. Manually created joins go straight to the active joins list – they don't require proposal review since the human is already making the decision.

Acceptance and rejection both go through a human with a typed "confirm" (data-catalog-relationship-accept-prepare / -execute and data-catalog-relationship-reject-prepare / -execute).

Accepted joins become real lazy joins and surface in system.information_schema.relationships, carrying the proposal's confidence and reasoning:

SELECT source_table, source_column, target_table, target_column, confidence, reasoning
FROM system.information_schema.relationships
WHERE confidence IS NOT NULL

How agents use trust marks

When the semantic layer is enabled, agents exploring your schema:

• Prefer certified tables and mention when they're using one
• Avoid deprecated tables, citing the deprecation note if they must touch one
• Join along accepted relationships instead of inferring keys from column names

The effect compounds: each certification and accepted join is a decision made once, by a human, that every future session inherits.