A live Cortex Analyst deployment makes metric type part of the guardrail
Evolv’s credit-card analytics build puts additive versus point-in-time behavior into the data model before natural-language questions reach SQL.
A new deployment note from evolv Consulting documents a Snowflake-native credit-card analytics agent that has moved beyond a chat demonstration. The implementation combines dbt models in Snowflake, a staged Cortex Analyst semantic model and a Streamlit in Snowflake interface; evolv says the same foundation is now live through Snowflake’s AI experience for portfolio, transaction, acquisition, payment, statement, authorization and daily-snapshot questions.
The most transferable design choice is not the interface. It is a long-format metric registry in which each row represents a metric, product, grain and date. Evolv says the registry is incrementally materialized with a merge on its business key, so refreshes update the recent slice instead of rebuilding the full model.
Additivity belongs in the contract
The registry carries a metric_type field that distinguishes additive measures, such as daily counts or spend, from non-additive values, such as point-in-time balances. That distinction matters for natural-language analytics because a syntactically valid query can still produce a false answer by summing snapshots across dates.
This is a useful operating lesson: do not leave aggregation behavior for the model to infer from a column name or prompt. Put it in the governed data contract where both generated SQL and human review can refer to it.
Evolv describes the semantic layer as more than physical schema mapping. Its YAML model adds descriptions, synonyms, instructions, measures and verified question-SQL pairs. The team also encoded domain traps that had previously lived in documents, dashboard notes, messages and analyst knowledge. Examples include ambiguous terms such as “active account,” point-in-time measures and incomplete recent periods caused by posting lags.
Validation is the production gate
The reported workflow sends a user question to Cortex Analyst with the staged semantic model, receives generated SQL and an explanation, executes the query through a Snowpark session, then renders a table or chart. Evolv says the data-science team tested the agent against known-good numbers and recurring business questions before treating it as a useful analytical tool.
That is stronger evidence than a screenshot, but the post does not publish a test-set size, accuracy rate, failure distribution, latency or adoption metric. Readers should therefore treat this as an inspectable architecture and deployment report, not a comparative benchmark.
The implementation also keeps curated dashboards and conversational analysis on the same definitions. Evolv says a planned monthly-business-review dashboard can reuse the semantic model and metric registry that ground the agent. That reduces one common source of trust failures: a dashboard and a chat answer applying different business logic to the same question.
For teams deploying Cortex Analyst, the practical sequence is clear: establish grain and canonical measures; label aggregation behavior; encode synonyms and known data traps; add verified queries from real stakeholder questions; then validate generated answers against known-good results. The model can generate SQL earlier than that. A production analytics surface should not be declared ready until the definitions underneath it hold up.
sources
comments · 0