Meta:Context: a business context schema in dbt's semantic layer

At a dbt Summit 2026 breakout session titled "Meta:Context: a business context schema in dbt's semantic layer," Keith Binkly, director of analytics and insights at Green Dot, described a five-layer schema his team built to give AI agents the interpretive judgment that a semantic layer alone doesn't provide.

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

Binkly's starting point was a specific failure mode: a semantic layer will get the query and the math right, but it doesn't tell an agent what a number means. In one internal test, an agent found that 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 that gap as a context problem: understanding a metric's healthy range, what's driving a change, and what to do about it. Feeding an agent scattered docs, emails, and spreadsheets doesn't solve it either, because the model still has to work out which pieces are relevant to which metric.

The team's answer is called Meta:Context, a five-layer schema that lives directly in the meta block of dbt's semantic layer YAML, next to the metric it describes. The five categories are descriptions, expectations, investigation, relationships, and decisions, a set Binkly nicknamed "dried" as a memory aid.

Storing context in the same YAML as the metric has two effects, according to Binkly. 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, which makes 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. That structure also makes context coverage measurable across a project's metrics.

In a test case, Binkly compared how an AI 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 asked seven different models to write a context card from the same raw materials, with all 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 Binkly used to argue that 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, but 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 started building their own context cards using the same five-layer structure.

His advice for teams that want 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 if a team wants to move it later.

Watch the full session, plus every keynote and breakout from dbt Summit 2026, on demand. Watch dbt Summit 2026 on demand →