A semantic layer can get a query and its math right, but it won't tell an AI agent what the resulting number actually means. That gap was the focus of a dbt Summit 2026 breakout session on Meta:Context, a business context schema presented by Keith Binkly, director of analytics and insights at Green Dot.

Green Dot runs an embedded-finance payments platform with a bank subsidiary, serving as program manager and issuing bank for more than a dozen enterprise partnerships, including Apple Cash, Intuit QuickBooks, Amazon Flex, and Crypto.com - all handling high-volume debit transactions in a heavily regulated business.

Binkly described a specific failure mode: in one internal test, an agent found Partner B's cost-efficiency ratio was roughly twelve times worse than Partner A's and recommended Green Dot help Partner B improve it. But the two partners run on entirely different payment rails, so the gap was expected and the recommendation was wrong. Binkly framed the issue as a context problem - knowing a metric's healthy range, what's driving a change, and what to do about it. Scattered docs, emails, and spreadsheets don't solve it, because the model still has to work out which pieces apply to which metric.

The team's answer, Meta:Context, is a five-layer schema stored directly in the meta block of dbt's semantic layer YAML, next to the metric it describes. The categories are descriptions, expectations, investigation, relationships, and decisions - a set Binkly nicknamed "dried" as a memory aid. Storing context alongside the metric means one semantic layer API call returns both the number and its context, and that context goes through the same review process as the metric: pull requests, CI, and the dbt manifest. Binkly said the fields are typed rather than freeform, making them checkable - whether a healthy range is populated or stale, whether an agent followed the documented investigation path, or whether it fabricated an escalation step - and context coverage becomes measurable across a project's metrics.

In a test case, Binkly compared how an agent handled the same question about a program's decline rate with and without a completed context card. Without the card, the agent correctly avoided a false conclusion but had no way to verify its hypothesis; with the card, it identified the actual cause, flagged what it couldn't prove, and named the query that would confirm it. Binkly also had seven different models write a context card from the same raw materials with analytical judgment stripped out. All seven flagged an untested claim appropriately, but none reconstructed the one rule that came from an analyst's actual investigation - a finding he used to argue the card is "the residue of an investigation," not a smarter model's writing.

Green Dot is piloting conversational BI on top of the schema and has no enterprise usage numbers yet. Binkly said two data leaders at regulated European organizations - a public-transport agency and an energy-grid operator - reached out independently after he shared the approach in the dbt community Slack and began building their own context cards using the same five-layer structure. His advice for teams wanting to try it: start with one KPI and three fields - purpose, healthy range, and business rules - then compare how an agent's answer changes before and after. Because the schema is plain YAML in a dbt project, Binkly said it's portable to other tools later.

Source: dbt Labs Blog