Proposals, evidence and trust

Two numbers matter in Keel, and they mean different things:

• Confidence (0–1) — how sure Keel is about something it inferred: a join, a table role, a semantic type, a suggested rule, term or policy.
• Trust score (0–100) — how much a consumer should rely on a metric's numbers right now, from data quality, coverage, governance and freshness.

Proposals

Every inference is stored as a proposal with origin (Discovered, Inferred, LlmSuggested, UserDefined, Imported), confidence and evidence, and status Proposed until a person — or an explicit auto-accept threshold — accepts it. Proposals appear in the Review queue (joins, table classifications, sensitive columns), in Data quality (suggested rules), in the Glossary (term and synonym suggestions) and in Policies (the default mask suggestion).

Evidence

Relationship scoring (ADR-0007) is a logistic combination of signals, each shown with its weight:

Signal	Effect
Declared foreign key	Strong positive; schema fact, exempt from the low-cardinality cap
Value inclusion (probe over up to 1,000 sampled distinct values)	Positive by overlap %
Name match (normalization, abbreviations, singularization, Jaro-Winkler)	Positive
Type compatibility, index on the column, composite-key membership	Positive
Low cardinality, date or amount types, ambiguity between targets	Negative
Query-log co-usage	Designed in, but always 0 today: query-log ingestion is not built yet
LLM review	Adjusts uncertain candidates (0.3–0.9) by at most ±0.25, with its rationale

Table and column classification combine name, type, value-pattern and distribution rules; sensitivity and PII come from names and value signatures (email, phone, IP, US SSN, UK NINO, IBAN, Luhn-checked card numbers).

What the LLM sees

The LLM is optional; every stage falls back to heuristics. When it is on:

• Prompts carry metadata and statistics — names, types, nullability, comments, null ratio, distinct count, lengths.
• Min/max and top values are included only when the tenant enables Allow samples in prompts, and never for columns classified Confidential or Restricted. Relationship-review prompts never carry values.
• Customer metadata is fenced as data (prompt-injection defence); output is structured JSON validated against a schema, retried once, then dropped.
• Everything the LLM suggests is a proposal with origin LlmSuggested and capped confidence (0.7 for metrics and terms).
• A per-tenant daily token budget applies (default 500,000 tokens; counted per worker process today).

Trust score

Each metric's trust score is recomputed in the same transaction as the data-quality run that affects it:

trust = 0.60 × upstream data  +  0.15 × coverage × 100  +  0.15 × governance  +  0.10 × freshness

Part	Where it comes from
Upstream data (0–100)	The lowest score of the tables the metric reads (through lineage); unmeasured parts count as 50. A rule scores Pass 100, Warn 60, Fail 0, weighted by severity.
Coverage (0–1)	Share of the recommended rules that are active
Governance (0–100)	25 points each: owner, description, approved glossary term, certified
Freshness (0–100)	Mean of the upstream freshness rules

While any upstream Critical rule fails, trust is capped at 40. Bands: Trusted ≥ 85, Caution 60–84, Low trust < 60. Trust appears in the Metrics catalog, the workspace inspector, serving responses (trust.metrics, with warnings for Caution and LowTrust), MCP tool results and assistant answers, and in exports as metadata. See Data quality.

Certification is separate

A metric's certification level (Draft → Reviewed → Certified → Deprecated) is a governance decision with criteria — see Policies and certification. A Certified metric whose trust is capped by a failing Critical rule is flagged At risk.