> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Semantic-layer reference

> The stored YAML and query behavior implemented by the current warehouse connectors.

Deepline stores semantic-layer documents as workspace files.
Connector update tools accept `yaml` or its `content` alias. They also accept optional `dryRun`.
Read tools return configuration state, content hash, update time, table names, and optional YAML.
See [Build and validate a layer](/docs/semantic-layer) for the procedure.

## Snowflake YAML

The current renderer reads an object with a `tables` array. Each table needs a
`name` and a physical table reference. Model-level `name` and `description` are
not required by its validator.

| Field | Implemented behavior |
| - | - |
| `tables[].name` | Logical table name selected by the semantic query. |
| `tables[].base_table` | Physical `table`, with optional `database` and `schema`. |
| `tables[].table` | Alternative physical table string when `base_table.table` is absent. |
| `dimensions`, `time_dimensions`, `facts` | Named fields available as dimension/fact selections. |
| `metrics` | Named aggregate expressions. |
| `filters` | Named predicates applied when selected in the query. |
| Field `name` | Field identifier and default SQL expression. |
| Field `expr`, `sql` | These fields define the SQL expression. The renderer uses `expr` first, then `sql`, then `name`. |
| Field `synonyms` | Alternative names for selecting the field. |

`data_type`, `description`, `main_id`, and `unique` may be useful annotations,
but the current Snowflake renderer does not enforce them. It does not apply
`base_filter`, compile `relationships`, or use model-level `funnel_events`.
A successful update is not validation of those annotations or of warehouse
objects and expressions.

## Snowflake query behavior

`snowflake_run_semantic_query` selects one logical `table_name` and named
`metrics`, `dimensions`, `facts`, and `filters`, either in `params` or through
the retained top-level fields. The renderer adds `GROUP BY` when a query selects metrics with dimensions or facts. It combines selected filters with `AND`. The response includes rendered `sql`
alongside query rows and metadata.

Although the input schema accepts `custom_dimensions` and
`custom_filter_expressions`, the current renderer does not apply them. It does
not generate joins from relationship annotations.

A `type: "funnel"` query uses supplied `params.steps`, not YAML funnel definitions.
Each step must resolve a known time dimension in the selected table. The
implementation unions step rows and returns `event_count` per step. The renderer does not currently enforce cohort identity, event order, or a time window.
It accepts `cohort_by`, `enforce_order`, and `time_window_days`, but these fields do not implement those behaviors. Do not interpret those counts as an ordered user-conversion funnel.

See the [generated Snowflake query contract](/docs/providers/snowflake/actions/run-semantic-query)
for accepted input fields. Schema acceptance alone does not establish renderer
behavior.

## Validation boundaries

Snowflake update validation checks YAML parsing, the `tables` array, table names,
and physical references. It does not reject every unknown annotation or compile
every metric, filter, and physical column.

Redshift update validation requires a nonempty `tables` array, nonempty table
names, and `base_table.table`. Its storage/validation contract does not establish
support for the Snowflake semantic-query renderer. Check each connector's own
[setup and action reference](/docs/integrations) before transferring a model.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.