06-reference/research

snowflake semantic views cortex gateway agent identity audit

2026-10-02·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)

Two of the draft's three Snowflake pillars are generally available (GA), the Cortex AI Gateway is the one in preview, and the readmission rate is the citable healthcare example

The question

"For the pinned draft 'Agents don't need your data warehouse': what do current Snowflake docs support on semantic views / Cortex AI Gateway / agent identity-audit, and what's one concrete citable example of a healthcare metric definition that provably differs across systems?"

Context: this brief closes the two items marked ## Open in [[2026-09-29-agents-need-your-definitions]] — the hook example, and the Snowflake specifics that "need a current-docs check before publishing." The draft is a founder-pinned publish target feeding the Nov-30 credibility push.

Headline: The draft is publishable and its evidence is stronger than expected, but the status map is the opposite of what a reasonable guess would produce. Semantic views are generally available and have been since mid-2025. Agent identity is also GA, and the agent audit trail is already queryable in GA views, with dated release notes and a specific, checkable fact behind them: ACCESS_HISTORY records the base columns an agent actually read through a view, and now carries an agents_info column naming the invoking agent chain. The one pillar in preview is the Cortex AI Gateway, which shipped 2026-09-15 as an open preview limited to Amazon Web Services commercial regions. So the draft's governance claim stands on GA ground; its model-routing claim does not.

What we already know (from the vault)

What the web says

Status source rank used throughout: dated release note > product doc with no preview admonition > Snowflake blog or press release > third party. Snowflake labels previews explicitly with a "Preview Feature — Open" admonition, so absence of that banner is meaningful but is recorded below as "not marked preview" rather than as a GA citation.

Pillar 1 — semantic views: GA, and GA three separate times

The schema-level SEMANTIC VIEW object went GA at Summit, June 2025: "The ability to define semantic views ... is now generally available" (Summit announcements). Querying via the SEMANTIC_VIEW clause went GA in the 9.25 release notes (Aug 25-28, 2025) — 2025-08-25 is the start of that release window, not a single-day GA date (9.25 release notes). Putting the view name directly in a FROM clause went GA 2026-03-02 (release note). The overview, querying and SEMANTIC_VIEW construct pages carry no preview admonition.

A ring of sub-features is still in open preview, two of them inside the CREATE SEMANTIC VIEW page itself. Snowflake's live preview table lists semantic view materializations, the Open Semantic Interchange YAML format, Tableau .tds export, and verified-query optimization as Open preview (preview features). The range-join constraint and the metric USING parameter carry in-page "Preview Feature — Open" admonitions (CREATE SEMANTIC VIEW). The core object is safe to publish as GA; "semantic views are GA" as an unqualified sentence is not.

Semantic views are the documented recommended path for Cortex Analyst; the legacy stage YAML is supported, not deprecated. Docs: "Semantic Views are the recommended approach for working with Cortex Analyst," and legacy stage YAML files "are still supported for backward compatibility" but "don't support the direct SQL query interface, native sharing, or other features" (Cortex Analyst; migration page). Do not write "deprecated." Separately, YAML authoring of a semantic view is co-equal with DDL: "Both formats produce the same semantic view object" (YAML vs DDL).

The one-definition claim is supported in doc language, but not as a named three-product guarantee. Citable verbatim: a semantic view "provides consistent business definitions across enterprise applications"; the worked net-revenue example "ensures a single authoritative definition with proper aggregation behavior"; without one, "dozens of inconsistent calculations might exist throughout different reports and applications" (overview). No page asserts "one metric reused across business intelligence and Cortex Analyst and Snowflake CoWork." A cleaner supporting fact than the slogan: querying a semantic view requires SELECT on the view only, not on the underlying tables (querying).

Pillar 2 — Cortex AI Gateway: real, open preview, AWS-only

The gateway exists as a documented product with its own release note: "Sep 15, 2026: Cortex AI Gateway (Preview)" (release note). The guide page and all three sub-pages carry the "Preview Feature — Open" admonition, and the region limit is explicit: "Available to accounts in Amazon Web Services (AWS) commercial regions only," with three regions excluded (Cortex AI Gateway). Docs describe it as "the control plane where you govern how AI applications and third-party agents in your organization reach models." One gateway is auto-provisioned per account, named SNOWFLAKE, and "USAGE is granted to PUBLIC by default, so the gateway is reachable out of the box."

An important limit on what the gateway actually governs, which cuts against an over-strong claim. It routes, it does not entitle. The guide page: "USAGE on the gateway doesn't widen what a user can reach. A request still needs whatever access the underlying model requires." The release note, separately: the gateway "governs the path traffic takes, not the set of models a user is entitled to, so it doesn't expand your security perimeter." Model entitlement lives in a separate and go-forward mechanism, model role-based access control over objects in the SNOWFLAKE.MODELS schema; the older CORTEX_MODELS_ALLOWLIST parameter is being retired, with docs stating that from August 2026 "the only permitted change will be to set it to 'None'" and that "later in 2026, the parameter will be removed entirely" (AISQL privileges and access).

Gateway metering and tracing are documented. SNOWFLAKE.ACCOUNT_USAGE.AI_GATEWAY_USAGE_HISTORY holds one row per gateway request with credits and user attribution, 365-day retention (view docs). Traces are metadata-only by default; capturing prompts and responses requires explicitly enabling payload capture (observability). Dynamic model routing is a later announcement still: "Snowflake said dynamic model routing will be entering private preview shortly" (Constellation Research, 2026-08-18).

Note a status discrepancy worth knowing about if the post cites the Snowflake blog. The Black Hat launch post dated 2026-07-28 labels nearly every gateway capability "private preview," including agent-action auditability and intelligent model routing (Snowflake blog). The September release note supersedes it: the gateway is now an open preview. Cite the release note, not the blog.

Pillar 3 — agent identity and audit: GA identity, shipped audit columns, and the strongest citable material in the draft

This is the finding that reverses the expected ordering. The agent-identity framework page carries no preview admonition and states: "Agent identity lets Snowflake recognize when an AI agent is active in a session, so you can govern agent-driven access separately from ordinary human or service access" (agent identity). Two modes are documented, delegated and autonomous, and a context function IS_AGENT_ACTIVATED returns TRUE for an agent-active session and can be used inside masking and row-access policy bodies. Four dated release notes sit behind the mechanics. Two carry an explicit general-availability label; the other two are release-noted column additions with no status label either way, which under the evidence rule above is recorded as "not marked preview" rather than as a GA citation:

The practical read does not change: all four are usable today, and the two audit columns are gated on Enterprise Edition because ACCESS_HISTORY is. What changes is how they can be cited — two as GA, two as shipped-and-unlabelled.

The specific fact that makes the draft's governance claim provable rather than rhetorical: ACCESS_HISTORY resolves reads through a view down to base objects and columns. base_objects_accessed is "a JSON array of all base data objects to execute a query, including columns," and for secure views "the log record contains the underlying base table ... to generate the view" (ACCESS_HISTORY). Combined with agents_info, that answers "which columns did this agent actually read, through which view." Snowflake's own framing, on the agent-identity page rather than the ACCESS_HISTORY reference: these columns "help you reconstruct the causal chain that compliance teams often need" (agent identity). One stability note for anyone writing a query against this view: the column scheduled for removal in the 2026_07 behaviour-change bundle is invoker_identity (VARIANT, "A JSON object that identifies the Snowflake service that directly accessed the object"), which sits immediately above agents_info on the same page. agents_info itself is not slated for removal, so a query built on agents_info and base_objects_accessed is safe; one built on invoker_identity is not. Two caveats the post must carry: "Access History requires Enterprise Edition (or higher)," and a programmatic access token on its own does not make a session agentic — docs state Snowflake does not treat such sessions as agentic "unless you also use a supported agent identity path."

Product-name drift the draft will trip over: "Snowflake Intelligence" is retired. The product went GA on 2025-11-04 under its former name, Snowflake Intelligence; the rename to Snowflake CoWork came later and the release-note page was retitled with it, which is why that page now reads "Snowflake CoWork (General availability) ... previously available as a preview feature" at a November 2025 date and why its URL slug is still 2025-11-04-snowflake-intelligence. The November date is the GA event, not the rename. The rename is not fully flushed through the docs either: release notes dated February 2026 still reference SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY, so treat SNOWFLAKE_COWORK_USAGE_HISTORY as the current name rather than the only name in circulation. The old doc path 404s (release note; press release). Cortex Agents also went GA 2025-11-04 (release note), though the Cortex Agent code-execution tool is still Preview.

The healthcare hook: two published stewards, two specifications, one name

Centers for Medicare & Medicaid Services (CMS) side. The Hospital-Wide All-Cause Unplanned Readmission measure (consensus-based entity / National Quality Forum identifier CBE/NQF #1789, developed for CMS by Yale New Haven Health Services Corporation's Center for Outcomes Research and Evaluation) counts "admissions for Medicare beneficiaries who are 65 years and older ... with a complete claims history for the 12 months prior to admission," and defines a readmission as "an inpatient admission for any cause, except for certain planned readmissions, within 30 days" of discharge (measure specification). It is attributed to the facility, risk-adjusted with hierarchical generalized linear models across five specialty cohorts, and reported as a risk-standardized readmission rate, which the methodology report derives by multiplying a predicted-to-expected ratio by "the overall national readmission rate" (CMS-hosted CORE methodology report).

One lineage point to state plainly rather than skate past, because it is where a healthcare reader will test the post. #1789 is the claims-only specification, and the Hospital Inpatient Quality Reporting (IQR) Program no longer collects that version. The IQR required-measure list for the FY 2026 payment update names "Hybrid Hospital-Wide All-Cause Readmission Measure (HWR)" with a data source of "EHR and Claims" — the hybrid successor, reportedly CBE #2879e (identifier UNVERIFIED — it appears in none of the primary sources captured for this brief; confirm it at a steward page before putting it in the post), mandatory from the FY 2026 payment determination (CMS, Hospital Inpatient Quality Reporting (IQR) Program Measures for the FY 2026 Payment Update, December 2023; no stable public URL captured, document retained in the verification extract). #1789's removed endorsement status is consistent with that: the claims-only version was superseded inside IQR, and it survives in the accountable-care variant (the Accountable Care Organization / all-condition readmission measure) rather than in hospital inpatient reporting. For the comparison below, #1789 is the right thing to cite as the CMS-side specification lineage — it is the published, fully-specified claims measure, and the hybrid is its successor under the same measure name. Nothing in the CMS-versus-NCQA divergence depends on which of the two IQR collects, because both are facility-attributed Medicare measures and neither resembles the plan-attributed HEDIS one.

National Committee for Quality Assurance (NCQA) side. The Healthcare Effectiveness Data and Information Set (HEDIS) Plan All-Cause Readmissions (PCR) measure covers "persons 18 years of age and older," counts "unplanned acute readmissions (inpatient and observation stays)" within 30 days, is attributed to the health plan, is risk-adjusted by penalized logistic regression, and reports an observed-to-expected ratio centred on 1.0 — "O/E ratio = 1.0 means that the number of readmissions was the same as expected given the case mix." The index-stay window is specified: index hospital stays are acute inpatient discharges "on or between January 1 and December 1 of the measurement year," and the readmission side scans admissions "on or between January 3 and December 31 of the measurement year," which is what gives every index stay a full 30 days of look-forward inside the measurement year (NCQA PCR; NCQA risk-adjusted utilization FAQ; Medicaid.gov PCR calculation guidance).

CMS Hospital-Wide All-Cause Unplanned Readmission (#1789) NCQA HEDIS Plan All-Cause Readmissions (PCR)
Steward CMS (developed by Yale CORE) NCQA
Program Hospital Inpatient Quality Reporting (IQR) — which now collects the Hybrid HWR successor (EHR and claims; CBE #2879e unverified); #1789 is the claims-only lineage HEDIS; feeds plan ratings
Attributed to the facility the health plan; the unit of count is the stay, not the person ("The Count of IHS is based on discharges, not beneficiaries")
Age / payer Medicare beneficiaries 65 and older, 12-month prior claims history 18 and older; commercial and Medicaid product lines report 18-64
Stay types counted inpatient admissions only inpatient and observation stays
Window 30 days from discharge 30 days from discharge; index stays are discharges on or between January 1 and December 1 of the measurement year
"Planned" removed from the numerator, via the CORE planned-readmission algorithm (published planned-procedure list plus discharge-diagnosis logic) the numerator too, but via a different definition: maintenance chemotherapy, rehabilitation, organ transplant, or a potentially planned procedure without an acute principal diagnosis
Risk model hierarchical generalized linear models, five specialty cohorts penalized logistic regression, no cohort split
Unique exclusions against medical advice, primary psychiatric diagnosis, cancer treatment, Prospective Payment System (PPS)-exempt cancer hospitals pregnancy, perinatal conditions, death during the index stay, any hospice use, 4+ stays in the year
What the number IS a risk-standardized rate — a percentage of discharges an observed-to-expected ratio — unitless, centred on 1.0 by construction

Three details that make this sharper than "definitions differ." First, the one element everyone assumes is the hard part is the only one that agrees: both are 30 days anchored on the discharge date. Second, "planned readmission" exists in both specifications and both stewards subtract it from the same side of the fraction, the numerator, but under different definitions of what counts as planned. CMS uses the CORE planned-readmission algorithm. NCQA's numerator step excludes "planned admissions with a principal diagnosis of maintenance chemotherapy, a principal diagnosis of rehabilitation, an organ transplant, or a potentially planned procedure without a principal acute diagnosis." Its denominator step excludes something else entirely — death during the stay, a principal diagnosis of pregnancy, or a condition originating in the perinatal period — and contains no planned-admission exclusion at all (Medicaid.gov PCR calculation guidance, Column 1 Step 4 and Column 2 Step 4). So the same word names two different sets of stays being removed from the same place, which is harder to spot in a specification review than a structural difference would be. Third, for a commercial plan the two populations do not overlap at all, because CMS starts at 65 and the commercial PCR product line stops at 64.

And the divergence exists inside a single steward, too. NCQA's own required-measures list publishes PCR as two separate measures, "Plan All-Cause Readmissions—Observed-to-Expected Ratio—18-64 years" and the same measure "—65+" (NCQA 2026 Health Plan Ratings required measures). One acronym, two incomparable numbers, one steward.

A governance point that argues the draft's thesis on its own. The CMS specification is a moving target under an unchanged measure name. Attribute the drift carefully, though: the page documenting it is the hybrid measures methodology page, so the change belongs to the Hybrid HWR measure now in IQR, not to claims-only #1789. For 2026, "a key change to the measures includes the addition of Medicare Advantage patients," which shifts the denominator's payer scope between reporting years (QualityNet hybrid measures methodology). A definition that drifts year over year, under a measure name that does not, is exactly the thing that has to live somewhere versioned.

Two corrections to avoid, both of which a healthcare reader would catch. The hospital-wide measure is not part of the Hospital Readmissions Reduction Program: CMS states that program "doesn't include the Hospital-Wide All-Cause Readmission (HWR) measure, which is included in the Hospital Inpatient Quality Reporting (IQR) Program," and uses six condition-specific measures instead (CMS hospital readmissions). So the 3-percent payment penalty belongs to those six measures, not to the hospital-wide one. Separately, do not write "NQF-endorsed" for #1789: its endorsement status is listed as removed, with the steward no longer seeking maintenance, while the measure name remains in use. Write "CBE/NQF #1789." And when naming the program, say that IQR today collects the hybrid successor rather than implying #1789 is the measure hospitals currently submit.

One element worth stating outright, because the source already cited above resolves it. The PCR index-stay window first read as unresolvable behind the HEDIS Volume 2 paywall. It is not: the Medicaid.gov calculation guidance specifies it directly. Index hospital stays are acute inpatient discharges "on or between January 1 and December 1 of the measurement year," with the readmission scan running over admissions "on or between January 3 and December 31" (Medicaid.gov PCR calculation guidance). The December 1 cut is what reserves a full 30-day look-forward window inside the measurement year. Volume 2 remains paywalled, and the product-line exclusions above still rest on licensed restatements rather than the primary specification, which is a narrower caveat than the one this brief originally carried.

Convergences and contradictions

Synthesis for RDCO

The draft is publishable, and the single edit that matters is swapping which pillar gets hedged. A writer working from the draft's current ## Open note would most likely hedge agent identity (newest-sounding, least familiar) and assert the gateway (named in a Summit recap, sounds like shipped infrastructure). Both instincts are backwards. Agent identity has dated general-availability release notes behind it, a documented context function, a dedicated user type, and two new audit columns. The gateway has a Preview admonition and an Amazon-Web-Services-only region limit, which also means a meaningful share of a buyer-facing audience cannot run it at all. Concretely: cite semantic views as GA with the three release-note dates and the sub-feature caveat; cite SERVICE_AGENT and Restricted Session Scope as GA with their release-note dates, and agent_type and agents_info as release-noted, not preview-marked, columns in GA views — the governance spine is usable today, with ACCESS_HISTORY gated on Enterprise Edition; and describe Cortex AI Gateway as announced and in open preview, AWS commercial regions only, as of September 2026. Two mechanical fixes before publish: "Snowflake Intelligence" is now "Snowflake CoWork" (renamed after, not at, its 2025-11-04 GA, and the old name still surfaces in 2026 release notes), and the gateway routes traffic rather than granting model entitlement, so it should not be described as the thing that decides which models an agent may call.

Rewrite the draft's claim 4 into its lead technical paragraph, because it is the part no competitor post will have. The draft currently asserts governance matters "with protected health information" and leaves it there. The verified version is specific and checkable: a Snowflake agent can hold its own identity as a SERVICE_AGENT user, every session it opens is automatically agent-active, policies can branch on IS_AGENT_ACTIVATED, and ACCESS_HISTORY records the base columns that agent read through whatever view it queried, with the invoking agent chain in agents_info. Requires Enterprise Edition. That paragraph is the difference between a thesis post and a post a data leader forwards to their platform team, and it directly serves the stated credibility domain of agents in production.

Lead with the readmission example rather than listing it as a hook option. The draft hedged between "readmission rate or gross retention." Gross retention is the weaker choice: a reader grants that definitions vary and moves on. Readmission rate is unarguable, because two national stewards publish two specifications that produce different kinds of number, and the gap is not a rounding difference. CMS reports a risk-standardized rate for facility-attributed Medicare patients 65 and older counting inpatient admissions only. NCQA reports an observed-to-expected ratio for plan-attributed members 18 and older counting observation stays too, and for commercial lines stops at 64, so the populations do not overlap at all. Both are 30 days from discharge, which is the detail that makes the example land: the part everyone assumes is hard is the only part that agrees. The sharpest line for a non-healthcare executive is that the two measures do not even return the same kind of number: one answers with a percentage of discharges, the other with a unitless ratio whose neutral value is 1.0 by construction ("O/E ratio = 1.0 means that the number of readmissions was the same as expected given the case mix"). They cannot go in the same column of the same table, let alone be compared. Do not put illustrative values on them in the post unless a published figure is cited for each; the unit mismatch carries the point without inventing numbers. No connector resolves that, and no frontier model resolves it either, because the disagreement is upstream of the data in a published specification.

One positioning mismatch worth naming rather than quietly absorbing. The Nov-30 targets were revised on 2026-09-30 so the six pieces are specifically "what I built on Snowflake, what broke, what I'd do next" ([[2026-09-29-nov30-credibility-targets]]). This draft is a thesis essay with no artifact behind it. The cheapest way to make it count against that target rather than beside it: define the two readmission specifications as two named metrics in one GA semantic view, ask the same natural-language question over each, publish the two different correct answers, and show the ACCESS_HISTORY row proving which columns the agent read. That uses only GA primitives, converts the central claim from assertion into reproducible demonstration, produces the "what broke" material the target asks for, and sits squarely on the healthcare-and-life-sciences space the founder named ([[01-projects/hcls/index|Healthcare / Life Sciences: the moonshot space]]).

The transferable rule, which is the part phData work reuses. Every vendor-feature claim in a buyer-facing artifact needs a status label attached at the moment of writing, and the evidence standard is a dated release note, not the vendor's own launch blog. Inside one four-line ## Open block in a note three days old, this brief found a retired product name, a feature whose status the vendor's blog and release note disagree about, a region restriction that excludes two of three clouds, a deprecating account parameter, and two GA release notes nobody had connected to the argument they support. That hit rate argues for making the status check a standing pre-publish gate rather than a per-draft research request.

Why this is in the vault

This closes both ## Open items blocking the founder-pinned draft [[2026-09-29-agents-need-your-definitions]], a publish target under [[2026-09-29-nov30-credibility-targets]], and it changes the draft rather than merely supplying it: the hedge moves from agent identity to the gateway, the draft's vaguest claim becomes its strongest, and the hook example is upgraded from a two-way hedge to a named dual-steward specification. It also extends the vault's GA-versus-preview matrix to three features that matrix did not cover.

Open follow-ups

Related

Sources

Vault:

Snowflake release notes (highest evidence rank):

Snowflake product docs:

Snowflake blog / secondary (lower rank; superseded where a release note exists, and labelled as such in-text):

Healthcare measure stewards: