The same table can be trusted, mistrusted, and actively avoided — depending on who you ask.

revenue_attribution. Same table. Three teams. Three answers. Analytics built it and trusts it: source for all their dashboards, refreshes daily, good enough for weekly reporting. Finance uses revenue_reconciled for anything board-facing because the attribution logic doesn't match how they recognize revenue. Operations had an incident in Q2 where the data was wrong for three weeks. Nobody removed it from the catalog. They just stopped using it.
The catalog shows one entry, and the entry doesn't reflect the divergence in trust. There's no field for 'trusted by Analytics but not Finance.' There's no field for 'do not use, Q2 incident, unresolved.' The table looks the same to any system reading the metadata.
Trust is a relationship between a dataset and a use case, not a binary property. revenue_attribution is trusted for weekly operational dashboards. For board-facing revenue figures, Finance uses something else. Operations stopped using it after the Q2 incident. All three are true simultaneously.
When an AI system selects a table for a revenue query, it needs to know which version of trust applies. Trusted by whom, for what purpose, under what conditions. A single trusted: true field doesn't carry this information.
The context that makes data trustworthy is specific, conditional, and constantly changing. It needs to travel with the data rather than living in the team that built it.