Skip to content
Casabase CubeCasabase Cube Documentation

How Casabase Cube Works with Snowflake Intelligence

Casabase Cube integrates with Snowflake’s agent platform by exposing cube-aware capabilities that an agent can use to discover multidimensional metadata, construct queries, and return governed analytical results.

The key architectural principle is:

The agent interprets the question.
Casabase Cube evaluates the analytical result.

The agent does not need to recreate the cube’s hierarchy, aggregation, formula, time-balance, or row-level security logic. Those capabilities remain part of the Casabase Cube analytical model.

Request Flow

Section titled “Request Flow”

A typical analytical request follows this flow:

Natural-Language Question
          │
          ▼
Snowflake Intelligence
          │
          ▼
Cortex Agent
          │
          ├── Interpret Intent
          │
          ├── Select Casabase Cube Tool
          │
          └── Determine Required Context
          │
          ▼
Casabase Cube Discovery
          │
          ├── Identify Cube
          │
          ├── Identify Dimensions
          │
          ├── Resolve Members
          │
          └── Understand Hierarchies
          │
          ▼
Construct POV
          │
          ▼
Casabase Cube Query Engine
          │
          ├── Apply Security
          ├── Resolve Hierarchies
          ├── Aggregate Fact Data
          ├── Evaluate Formulas
          ├── Apply Solve Order
          └── Apply Time Behavior
          │
          ▼
Tabular Result
          │
          ▼
Agent Response

Snowflake provides the agent orchestration layer. Casabase Cube provides the multidimensional metadata and query capabilities used by the agent.

1. Interpret the User’s Request

Section titled “1. Interpret the User’s Request”

The process begins with a business question.

For example:

Show actual revenue by region for FY26.

The agent interprets the request and determines that it requires analytical data from Casabase Cube.

The request contains business concepts rather than SQL:

Actual
Revenue
Region
FY26

The agent must map those concepts to the cube structure before it can construct a query.

2. Discover the Cube Structure

Section titled “2. Discover the Cube Structure”

If the required cube context is not already known, the agent can use Casabase Cube discovery capabilities to understand the available model.

Discovery can include information such as:

  • Available cubes
  • Dimensions
  • Members
  • Hierarchy relationships
  • Member properties
  • Available calculated members

Conceptually:

User asks for "Revenue by Region"
              │
              ▼
Discover Cube Metadata
              │
              ├── ACCOUNT contains Revenue
              ├── ENTITY contains regional hierarchy
              ├── SCENARIO contains Actual
              └── YEARS contains FY26

This allows the agent to work with the model that actually exists rather than guessing the structure from relational column names.

3. Resolve Members and Hierarchy Intent

Section titled “3. Resolve Members and Hierarchy Intent”

Natural-language questions frequently imply hierarchy behavior.

For example:

Show revenue by region.

may require the agent to identify the appropriate regional parent and request its children.

A follow-up such as:

Break North America down to the next level.

requires the agent to preserve the existing analytical context while changing the hierarchy selection for the Entity dimension.

Conceptually:

North America
      │
      ▼
Hierarchy Selection
      │
      ▼
Children of North America

Casabase Cube provides the hierarchy model. The agent determines which supported member selection best represents the user’s request.

4. Construct the Point of View

Section titled “4. Construct the Point of View”

After resolving the required dimensions and members, the agent constructs a Casabase Cube Point of View (POV).

For example:

Show actual revenue for January FY26 in the United States.

might resolve conceptually to:

{
  "Account": ["Revenue"],
  "Scenario": ["Actual"],
  "Years": ["FY26"],
  "Period": ["Jan"],
  "Entity": ["United States"]
}

A request for a hierarchy expansion can use the supported POV selection operators.

For example:

{
  "Entity": [
    {
      "children": "North America"
    }
  ]
}

The exact POV depends on the dimensions, members, and hierarchy structure of the selected cube.

See Point of View (POV) for the Casabase Cube query-selection model.

5. Execute Through Casabase Cube

Section titled “5. Execute Through Casabase Cube”

For multidimensional analytical questions, the agent sends the resolved request through a supported Casabase Cube query path.

Conceptually:

Resolved POV
    │
    ▼
QUERY_CUBE
    │
    ▼
Casabase Cube Query Engine

This is an important part of the integration.

The agent should not attempt to reproduce the result by independently querying the underlying fact table when the question requires Casabase Cube semantics.

Why the Query Engine Matters

Section titled “Why the Query Engine Matters”

A Casabase Cube result can depend on more than stored fact rows.

For example:

Fact Data
    +
Hierarchy Structure
    +
Aggregation Operators
    +
Calculated Members
    +
Formula Dependencies
    +
Solve Order
    +
Time Balance
    +
Security
    │
    ▼
Final Cube Result

A direct relational query against the fact table does not necessarily reproduce these behaviors.

By executing the analytical request through Casabase Cube, the agent receives the same governed multidimensional result that supported Casabase Cube query interfaces use.

6. Apply Security

Section titled “6. Apply Security”

Agent-generated Casabase Cube queries do not bypass Casabase Cube row-level security.

Security is applied as part of the supported query path.

Conceptually:

Agent Query
     │
     ▼
Executing User Context
     │
     ▼
Casabase Cube Security Rules
     │
     ▼
Permitted Data
     │
     ▼
Aggregation and Calculation

This ordering matters.

Calculations are evaluated against the data the user is permitted to access. A user restricted to a particular Entity branch therefore receives results based on that permitted scope.

As elsewhere in Casabase Cube, row-level security is opt-in per user. A user with application access but no active Casabase Cube security rules for the cube is unrestricted by Casabase Cube row-level security.

Snowflake also applies its own role and privilege requirements to access the agent and the objects used by its tools.

See Governance and Security.

7. Evaluate Hierarchies and Aggregations

Section titled “7. Evaluate Hierarchies and Aggregations”

Casabase Cube performs hierarchy-aware aggregation dynamically.

If the POV requests a parent member such as:

North America

the query engine resolves the appropriate descendants and aggregation behavior according to the cube model.

The agent does not need to calculate the parent by retrieving leaf rows and adding them itself.

This preserves behaviors such as:

  • Hierarchical aggregation
  • Alternate hierarchies
  • Shared members
  • Member aggregation operators
  • Dynamic parent calculations

The multidimensional model remains authoritative.

8. Evaluate Formulas

Section titled “8. Evaluate Formulas”

Calculated members are also evaluated by the Casabase Cube query engine.

For example, if the cube defines:

Gross Margin %

the agent can request that member as part of the POV.

The calculation is not invented by the language model. Casabase Cube evaluates the formula defined for the member.

This preserves:

  • Formula syntax and semantics
  • Formula dependencies
  • Solve order
  • Hierarchy-aware functions
  • Cross-dimensional references
  • Supported time-navigation behavior

If a requested business metric is not defined in the cube, the agent should not silently invent a formula and present it as though it were governed Casabase Cube logic.

9. Return the Result to the Agent

Section titled “9. Return the Result to the Agent”

Casabase Cube returns the analytical result to the calling tool.

The agent can then use that result to answer the user’s question.

For example:

Casabase Cube Result
       │
       ▼
Agent
       │
       ├── Present Values
       ├── Summarize Result
       └── Respond to Follow-Up

How the result is ultimately presented is part of the Snowflake agent experience and can evolve independently of Casabase Cube.

The authoritative numerical result remains the result returned by the Casabase Cube query engine.

Follow-Up Questions

Section titled “Follow-Up Questions”

Conversational analysis becomes particularly useful when users refine a result incrementally.

For example:

User:
Show actual revenue by region for FY26.


Agent:
[Executes cube query]


User:
Break North America down to the next level.


Agent:
[Preserves relevant context and changes Entity selection]


User:
Now compare it with FY25.


Agent:
[Changes Years context and executes another cube query]

The conversational layer can maintain the analytical context while each data request is translated into a new governed cube query.

Discovery vs. Querying

Section titled “Discovery vs. Querying”

It is useful to distinguish two broad categories of agent operations.

Discovery

Section titled “Discovery”

Discovery helps the agent understand the cube model.

Examples:

What cubes are available?
What dimensions are in the Finance cube?
What members are below North America?
Does the cube contain a Gross Margin calculation?

Querying

Section titled “Querying”

Querying asks Casabase Cube to evaluate analytical data.

Examples:

Show revenue for FY26.
Compare Actual and Budget by region.
Show Gross Margin % by product category.

Discovery establishes the model context. Querying uses that context to produce analytical results.

Analysis vs. Administration

Section titled “Analysis vs. Administration”

Agent tools can also be separated by privilege level.

Conceptually:

CUBE_PUBLIC
     │
     ├── Discover
     └── Query


CUBE_ADMIN
     │
     └── Administrative Operations

The exact tools available depend on how the agent is configured, but administrative capabilities should remain restricted to users who are authorized to perform those operations.

An AI interface does not change the underlying Casabase Cube role model.

See Roles and Privileges.

Tool Selection

Section titled “Tool Selection”

A Cortex Agent can have multiple tools available.

Snowflake’s orchestration layer determines which configured tool or tools to use for a request.

For Casabase Cube analytical questions, the intended pattern is:

Question About Cube Structure
          │
          ▼
Casabase Cube Discovery Tool


Question About Cube Data
          │
          ▼
Casabase Cube Query Tool


Question About Product Usage
          │
          ▼
Configured Documentation / Search Tool


Administrative Request
          │
          ▼
Authorized Administrative Tool

Agent instructions and tool descriptions should make these boundaries clear so that requests are routed to the appropriate governed capability.

Structured Data Should Remain Cube-Aware

Section titled “Structured Data Should Remain Cube-Aware”

Snowflake agents can work with structured data through several types of tools.

For Casabase Cube analytical results, however, the relevant question is not simply:

Can the agent query this table?

It is:

Does this query need Casabase Cube semantics?

If the answer depends on cube hierarchies, formulas, aggregation behavior, time behavior, or Casabase Cube security, the request should use the Casabase Cube query path.

This prevents a parallel analytical definition from developing outside the cube.

Documentation and Product Questions

Section titled “Documentation and Product Questions”

The agent can also be configured with a documentation or search capability for questions such as:

How do I add a dimension?
What does solve order do?
How do I troubleshoot a dimension build?

These are different from data questions.

Conceptually:

"How do I calculate Gross Margin?"
          │
          ▼
Documentation / Product Guidance


"What was Gross Margin in FY26?"
          │
          ▼
Casabase Cube Query

Keeping these tool responsibilities distinct helps the agent select the appropriate source for each request.

Errors and Refusals

Section titled “Errors and Refusals”

If Casabase Cube returns an error or refuses a query, the agent should preserve the meaning of that response rather than inventing an approximate result.

For example, a query may be refused because:

  • The requested calculation is outside supported semantics
  • The calculation exceeds supported scale
  • Required cube context cannot be resolved
  • The executing user lacks required access

The appropriate response is to explain the issue or refine the request.

Conceptually:

Casabase Cube Refuses Query
           │
           ▼
Agent Receives Error
           │
           ▼
Explain or Refine
           │
           X
Do Not Invent Approximate Result

This is consistent with Casabase Cube’s general refuse rather than approximate approach.

Responsibility Model

Section titled “Responsibility Model”

The complete integration can be summarized as:

Component Primary Responsibility
User Express the business question
Snowflake Intelligence Conversational user experience
Cortex Agent Interpret the request, orchestrate tools, and maintain conversation context
Casabase Cube discovery capabilities Expose the multidimensional model to the agent
Casabase Cube query capabilities Execute governed multidimensional requests
Casabase Cube query engine Apply hierarchy, aggregation, formulas, time behavior, and application security
Snowflake Provide data platform, compute, identity, roles, privileges, and agent infrastructure

This separation keeps natural-language interaction flexible while preserving Casabase Cube as the authoritative analytical layer.

Section titled “Related Topics”