Snowflake and Databricks Can Carry Business Meaning. Who Owns the Definition?

Snowflake and Databricks provide capabilities for expressing context, governing access, and answering business questions. The implementation still needs someone to decide what the business question means, which result is acceptable, and how a definition changes. A platform can carry an agreed definition; a successful query cannot establish that the organization agreed the right one.

The hard question is often hidden in a familiar word

An executive asks, "How many active customers did we have this quarter?" The data team has customer, invoice, payment, and contract records. The question looks simple enough for a conversational interface. Yet "active" could mean an invoice issued, a payment received, a contract in force, or activity recorded in a product.

Each interpretation may be useful. The problem is presenting one as the answer without making the choice visible. A model can select a plausible interpretation, generate valid SQL, and return an internally consistent number that does not answer the sponsor's intended question.

Adding another paragraph to a prompt may help communicate a settled definition. It does not resolve a disagreement between Finance, Sales, and Operations. That disagreement needs a business decision and a named owner before it becomes implementation logic.

What native capabilities contribute

Snowflake's semantic views documentation describes database objects for business concepts, metrics, and relationships. Those capabilities give an implementation a place to express agreed meaning rather than repeatedly reconstruct it from raw column names. Snowflake's Cortex Analyst documentation currently recommends transitioning to Cortex Agents. An implementation should assess the current supported route rather than assume an older standalone integration is the default.

Databricks documents Unity Catalog capabilities for access control, lineage, and auditing. Its Genie Agent setup guidance describes adding context such as instructions and example SQL queries before sharing an agent. Its testing and monitoring guidance describes reviewing responses and using feedback to identify improvements; user feedback alone does not change the agent's behavior.

These are different platform capabilities, not interchangeable boxes in a generic architecture. The useful design question is how the customer's selected capabilities implement the required meaning and controls. The existence of a semantic object, governance catalog, or conversational answer does not remove the need to test the business result.

Write a contract for the question

A practical metric contract states the purpose, entity being counted, source population, qualifying event, period boundary, exclusions, and expected treatment of duplicates or corrections. It names the business owner and provides examples that make the definition falsifiable.

For active customers, the contract might specify distinct customer identifiers with at least one qualifying invoice dated within the fiscal quarter. It should then address credits, cancelled invoices, merged accounts, and the calendar used to determine the quarter. Those are decisions to agree for the actual business, not defaults supplied by this article.

The contract should also describe what to do when the user asks an ambiguous variation. If "active" has two valid meanings, the experience may need to ask a clarifying question or expose the chosen definition in the answer. It should not hide a switch between definitions because one query was easier to generate.

A synthetic example where the totals match

Consider four invented accounts and two possible definitions. The first counts accounts with an invoice issued during the quarter. The second counts accounts with a payment received during the quarter. For this small example, assume the records and dates are accepted, there are no cancellations, and customer identities are already resolved.

Both definitions return two customers. They do not identify the same customers: the invoice-based set is A and C; the payment-based set is A and B. Comparing only the aggregate total would miss the difference.

This is why acceptance examples should include expected membership as well as totals where the question requires it. An apparently correct number can conceal a wrong population. The same issue can affect downstream breakdowns, exception lists, or follow-up questions even when the first answer looks convincing.

Separate the responsibilities

The business owner decides the intended meaning and accepts the examples. The platform owner establishes permitted data access, supported execution paths, and the relevant operational controls. The implementation team translates the agreement into data mappings, calculations, context, and tests. An accountable business reviewer decides how the answer informs the actual business decision.

These roles can overlap in a small team, but their responsibilities should remain distinguishable. A platform administrator should not become the unintentional owner of a revenue definition merely because they configured the agent. A sponsor should not be asked to certify SQL behavior they cannot inspect without technical support.

The diagram represents responsibilities, not mandatory physical hosting. A reviewer can use an experience hosted within a platform. A source can already reside there. Neither the answer nor the data must leave a platform boundary simply because the diagram gives human review its own node.

Test four different forms of correctness

First, test the business definition: do the agreed examples include and exclude the intended records? Second, test the calculation and query: are the grain, joins, filters, aggregation, and parameter handling correct? Third, test the narrative: does the answer describe the returned result without changing its meaning? Fourth, test authorization: is this user allowed to see the result and its supporting detail?

These checks can fail independently. A query can run successfully and duplicate customers through a join. A calculation can be correct while the summary describes invoices as cash receipts. An accurate answer can reveal a breakdown the user's role should not receive.

A useful acceptance set contains normal questions, ambiguous terms, empty results, missing context, prohibited access, and counterexamples. For the active-customer example, test the actual account membership, not only the count of two. Include a follow-up asking which customers changed and check that the same definition remains in force.

Treat generated SQL as an execution path to inspect

Generated SQL should be assessed against the agreed contract and configured controls. The fact that a query uses familiar tables does not establish that it used the intended join or time boundary. Equally, querying a physical table is not automatically a governance failure if the approved architecture permits and controls that path.

Snowflake's semantic-view documentation explicitly describes Cortex Agents using semantic-view information to generate SQL against physical tables. The design therefore should not rely on a simplistic claim that every valid answer must query only one named view. It should identify the supported execution behavior and the controls that make that behavior acceptable for the customer's use case.

Record the effective configuration and test it. Avoid promising that all answers follow one constrained tool path unless the implementation actually enforces that path. A reference architecture is a design statement; deployment evidence must establish what the configured system does.

A definition change is a controlled revision

Suppose the business changes active customers from invoice-based to payment-based. In the synthetic example, the count remains two, but the population changes. A superficial regression check could report no difference while the business interpretation has changed substantially.

The revision should identify the owner, reason, effective date, impacted outputs, and whether historical reporting will be restated. Update the relevant semantic configuration, logic, examples, and explanations, then rerun the acceptance cases. Preserve the older definition where it is needed to interpret prior decisions.

Feedback from a reviewer is an input to that process, not automatic permission to rewrite the definition. A request to correct an answer might reveal a data defect, a query problem, or a genuine policy change. Routing all three through silent prompt edits makes maintenance harder to understand.

How Orisdale would contribute

Orisdale's proposed role is to connect the business agreement with a bounded implementation on the customer's platform. That starts by choosing one decision, identifying the definitions it depends on, and establishing acceptance cases with the people who own them.

Potential deliverables include a decision contract, source-to-definition mapping, a platform-specific responsibility design, a tested question set, and a handover record for operation and revision. Native platform capabilities should be used where they fit; the objective is not to build a competing semantic layer simply to give the engagement another component.

The customer still needs named owners for meaning, access, and business decisions. Where those owners or usable source evidence are missing, the initial work should expose the dependency rather than promise an immediate agent rollout. Orisdale's delivery journey describes how agreement, implementation, verification, and revision connect.

Bring one disputed question to the architecture discussion

Before commissioning a wider assistant, take one question that different teams answer differently. Write the competing definitions, identify the records each includes, and ask who can accept the result. That exercise reveals more about readiness than a broad demonstration that answers only agreeable questions.

Use the Snowflake and Databricks reference pages to discuss platform responsibilities, then scope a working session around the specific decision. A durable business-answer experience needs both capable technology and an agreement about what its answers are supposed to mean.