A question about segments and quarters needs six answers before Cortex Analyst writes SQL

The example the post uses is one sentence: "Which customer segments had the highest order value last quarter, and how did that change from the previous quarter?" ^[4] Before any SQL runs, six things have to be resolved: what order value means, which field represents customer segment, how orders relate to customers, which calendar defines last quarter, whether the user is allowed to see the requested data, and whether the data product is trustworthy right now ^[5][22]. Snowflake privileges answer the access question, and the runtime contract check answers the fitness one ^[13]. The remaining four are modeling decisions ^[23].

The semantic view is where those four get made. Logical tables, row grain, primary keys and unique keys are declared there, so the meaning of one row is explicit ^[7]. Dimensions and time dimensions cover things like customer segment and fiscal quarter, and facts and governed metrics carry their aggregation and distinct-count behaviour ^[8]. Relationships are modeled explicitly, including bridge tables for many-to-many associations, so join paths do not have to be improvised ^[9]. Filters, synonyms and question-handling instructions sit in the same object ^[10], alongside verified queries that pair important question patterns with reviewed SQL ^[11]. Absent that, the post says, a language model looking only at table and column names may guess ^[6].

The post describes semantic views as schema-level objects integrated with Snowflake privileges and metadata, "not prompt text pretending to be governance" ^[12].

The trust half is a different artifact, and it is yours. "The contract check is application logic around the agent; it is not performed automatically by the semantic view itself," the post says ^[15]. So the gate that decides whether a domain is fresh enough to answer from is code your team writes, deploys and gets paged about. For a higher-risk domain, the same decision point can be implemented as a hard stop instead of a warning ^[17]. Whichever path the request takes, the response comes back with the SQL, the definitions, the scope and any required warning attached ^[19].

How much of this transfers depends on something the write-up is explicit about: all names, identifiers, queries and results are synthetic, and quantities are rounded to communicate scale ^[21]. The preview's outcome is reported as encouraging, qualified by the line that natural language is the interface and not the semantic layer ^[1]. There is no per-question accuracy figure. For the same experience on your own Customer 360, the questions your users actually ask would have to land inside the modeled coverage: the metrics they name defined as governed metrics with the aggregation behaviour they assume ^[8], the joins they imply present as modeled relationships ^[9], and their idea of last quarter matching the fiscal calendar in the time dimension ^[8]. Cortex Analyst attempts semantic SQL first, with metrics, dimensions and relationships supplied by the semantic view, and Cortex Agents can route across several of them ^[20]. The SQL then executes inside the governed platform, where Snowflake privileges and data-protection policies still apply ^[18].

That is a reasonable division of labour, and it prices the work honestly. The author put it this way: "Natural language does not remove the need for data modeling. It makes good data modeling visible to more people." ^[2]