Merge branch 'current' into hook-change

website/docs/docs/build/dimensions.md

@@ -12,7 +12,7 @@ Dimensions represent the non-aggregatable columns in your data set, which are th
 
 Groups are defined within semantic models, alongside entities and measures, and correspond to non-aggregatable columns in your dbt model that provides categorical or time-based context. In SQL, dimensions  is typically included in the GROUP BY clause.-->
 
-All dimensions require a `name`, `type`, and can optionally include an `expr` parameter. The `name` for your Dimension must be unique wihtin the same semantic model.
+All dimensions require a `name`, `type`, and can optionally include an `expr` parameter. The `name` for your Dimension must be unique within the same semantic model.
 
 | Parameter | Description | Type |
 | --------- | ----------- | ---- |

website/docs/docs/build/metricflow-time-spine.md

@@ -8,7 +8,8 @@ tags: [Metrics, Semantic Layer]
 
 It's common in analytics engineering to have a date dimension or "time-spine" table as a base table for different types of time-based joins and aggregations. The structure of this table is typically a base column of daily or hourly dates, with additional columns for other time grains, like fiscal quarters, defined based on the base column. You can join other tables to the time spine on the base column to calculate metrics like revenue at a point in time, or to aggregate to a specific time grain.
 
-MetricFlow requires you to define a time-spine table as a model-level configuration in the Semantic Layer for time-based joins and aggregations, such as cumulative metrics. This configuration informs dbt which model should be used for time range joins. It is especially useful for cumulative metrics or calculating time-based offsets. The time-spine model is joined to other tables when calculating certain types of metrics or dimensions. MetricFlow will join the time-spine model in the compiled SQL for the following types of metrics and dimensions:
+MetricFlow requires you to define at least one dbt model which provides a time-spine, and then specify (in YAML) the columns to be used for time-based joins. MetricFlow will join against the time-spine model for the following types of metrics and dimensions:
+
 - [Cumulative metrics](/docs/build/cumulative)
 - [Metric offsets](/docs/build/derived#derived-metric-offset)
 - [Conversion metrics](/docs/build/conversion)
@@ -19,20 +20,18 @@ To see the generated SQL for the metric and dimension types that use time-spine
 
 ## Configuring time-spine in YAML
 
-- The time spine is a special model that tells dbt and MetricFlow how to use specific columns by defining their properties.
-- The [`models` key](/reference/model-properties) for the time spine must be in your `models/` directory.
+- Each time spine is a normal dbt model with extra configurations that tell dbt and MetricFlow how to use specific columns by defining their properties.
+- You likely already have a calendar table in your project which you can use. If you don't, review the [example time-spine tables](#example-time-spine-tables) for sample code.
+- You add the configurations under the `time_spine` key for that [model's properties](/reference/model-properties), just as you would add a description or tests.
 - You only need to configure time-spine models that the Semantic Layer should recognize.
 - At a minimum, define a time-spine table for a daily grain.
-- You can optionally define a time-spine table for a different granularity, like hourly.
-- Note that if you don’t have a date or calendar model in your project, you'll need to create one.
+- You can optionally define additional time-spine tables for different granularities, like hourly. Review the [granularity considerations](#granularity-considerations) when deciding which tables to create.
 
 - If you're looking to specify the grain of a time dimension so that MetricFlow can transform the underlying column to the required granularity, refer to the [Time granularity documentation](/docs/build/dimensions?dimension=time_gran)
 
-If you already have a date dimension or time-spine table in your dbt project, you can point MetricFlow to this table by updating the `model` configuration to use this table in the Semantic Layer. This is a model-level configuration that tells dbt to use the model for time range joins in the Semantic Layer. 
-
 For example, given the following directory structure, you can create two time spine configurations, `time_spine_hourly` and `time_spine_daily`.  MetricFlow supports granularities ranging from milliseconds to years. Refer to the [Dimensions page](/docs/build/dimensions?dimension=time_gran#time) (time_granularity tab) to find the full list of supported granularities.
 
-:::tip 
+:::tip
 Previously, you had to create a model called `metricflow_time_spine` in your dbt project. Now, if your project already includes a date dimension or time spine table, you can simply configure MetricFlow to use that table by updating the `model` setting in the Semantic Layer.
 
 If you don’t have a date dimension table, you can still create one by using the code snippet below to build your time spine model.
@@ -46,34 +45,38 @@ If you don’t have a date dimension table, you can still create one by using th
 ```yaml
 [models:](/reference/model-properties)
   - name: time_spine_hourly
+    description: A date spine with one row per hour, ranging from 2020-01-01 to 2039-12-31.
     time_spine:
       standard_granularity_column: date_hour # column for the standard grain of your table
     columns:
       - name: date_hour
         granularity: hour # set granularity at column-level for standard_granularity_column
+
   - name: time_spine_daily
+    description: A date spine with one row per day, ranging from 2020-01-01 to 2039-12-31.
     time_spine:
       standard_granularity_column: date_day # column for the standard grain of your table
     columns:
       - name: date_day
         granularity: day # set granularity at column-level for standard_granularity_column
 ```
+
 </File>
 
-For an example project, refer to our [Jaffle shop](https://github.com/dbt-labs/jaffle-sl-template/blob/main/models/marts/_models.yml) example. Note that the [`models` key](/reference/model-properties) in the time spine configuration must be placed in your `models/` directory.
+For an example project, refer to our [Jaffle shop](https://github.com/dbt-labs/jaffle-sl-template/blob/main/models/marts/_models.yml) example.
 
-Now, break down the configuration above. It's pointing to a model called `time_spine_daily`. It sets the time spine configurations under the `time_spine` key. The `standard_granularity_column` is the lowest grain of the table, in this case, it's hourly. It needs to reference a column defined under the columns key, in this case, `date_hour`. Use the `standard_granularity_column` as the join key for the time spine table when joining tables in MetricFlow. Here, the granularity of the `standard_granularity_column` is set at the column level, in this case, `hour`.
+Now, break down the configuration above. It's pointing to a model called `time_spine_daily`, and all the configuration is colocated with the rest of the [model's properties](/reference/model-properties). It sets the time spine configurations under the `time_spine` key. The `standard_granularity_column` is the lowest grain of the table, in this case, it's hourly. It needs to reference a column defined under the columns key, in this case, `date_hour`. Use the `standard_granularity_column` as the join key for the time spine table when joining tables in MetricFlow. Here, the granularity of the `standard_granularity_column` is set at the column level, in this case, `hour`.
 
+### Considerations when choosing which granularities to create{#granularity-considerations}
 
-If you need to create a time spine table from scratch, you can do so by adding the following code to your dbt project. 
-The example creates a time spine at a daily grain and an hourly grain. A few things to note when creating time spine models:
-* MetricFlow will use the time spine with the largest compatible granularity for a given query to ensure the most efficient query possible. For example, if you have a time spine at a monthly grain, and query a dimension at a monthly grain, MetricFlow will use the monthly time spine. If you only have a daily time spine, MetricFlow will use the daily time spine and date_trunc to month.
-* You can add a time spine for each granularity you intend to use if query efficiency is more important to you than configuration time, or storage constraints. For most engines, the query performance difference should be minimal and transforming your time spine to a coarser grain at query time shouldn't add significant overhead to your queries.
-* We recommend having a time spine at the finest grain used in any of your dimensions to avoid unexpected errors. i.e., if you have dimensions at an hourly grain, you should have a time spine at an hourly grain.
+- MetricFlow will use the time spine with the largest compatible granularity for a given query to ensure the most efficient query possible. For example, if you have a time spine at a monthly grain, and query a dimension at a monthly grain, MetricFlow will use the monthly time spine. If you only have a daily time spine, MetricFlow will use the daily time spine and date_trunc to month.
+- You can add a time spine for each granularity you intend to use if query efficiency is more important to you than configuration time, or storage constraints. For most engines, the query performance difference should be minimal and transforming your time spine to a coarser grain at query time shouldn't add significant overhead to your queries.
+- We recommend having a time spine at the finest grain used in any of your dimensions to avoid unexpected errors. For example, if you have dimensions at an hourly grain, you should have a time spine at an hourly grain.
 
 ## Example time-spine tables
 
 ### Daily
+
 <File name="metricflow_time_spine.sql">
 
 <VersionBlock lastVersion="1.6">
@@ -140,9 +143,11 @@ select * from final
 where date_day > dateadd(year, -4, current_timestamp()) 
 and date_hour < dateadd(day, 30, current_timestamp())
 ```
+
 </VersionBlock>
 
 ### Daily (BigQuery)
+
 Use this model if you're using BigQuery. BigQuery supports `DATE()` instead of `TO_DATE()`:
 <VersionBlock lastVersion="1.6">
 
@@ -170,6 +175,7 @@ from final
 where date_day > dateadd(year, -4, current_timestamp()) 
 and date_hour < dateadd(day, 30, current_timestamp())
 ```
+
 </File>
 </VersionBlock>
 
@@ -200,12 +206,14 @@ from final
 where date_day > dateadd(year, -4, current_timestamp()) 
 and date_hour < dateadd(day, 30, current_timestamp())
 ```
+
 </File>
 </VersionBlock>
 
 </File>
 
-### Hourly 
+### Hourly
+
 <File name='time_spine_hourly.sql'>
 
 ```sql
@@ -237,4 +245,5 @@ select * from final
 where date_day > dateadd(year, -4, current_timestamp()) 
 and date_hour < dateadd(day, 30, current_timestamp())
 ```
+
 </File>

website/docs/docs/cloud-integrations/configure-auto-exposures.md

@@ -6,12 +6,10 @@ description: "Import and auto-generate exposures from dashboards and understand
 image: /img/docs/cloud-integrations/auto-exposures/explorer-lineage2.jpg
 ---
 
-# Configure auto-exposures <Lifecycle status='beta' />
+# Configure auto-exposures <Lifecycle status='preview' />
 
 As a data team, it’s critical that you have context into the downstream use cases and users of your data products. [Auto-exposures](/docs/collaborate/auto-exposures) integrates natively with Tableau and [auto-generates downstream lineage](/docs/collaborate/auto-exposures#view-auto-exposures-in-dbt-explorer) in dbt Explorer for a richer experience.
-:::info Available in beta
-Auto-exposures are currently available in beta to a limited group of users and are gradually being rolled out. If you're interested in gaining access or learning more, stay tuned for updates!
-:::
+
 Auto-exposures help data teams optimize their efficiency and ensure data quality by:
 
 - Helping users understand how their models are used in downstream analytics tools to inform investments and reduce incidents — ultimately building trust and confidence in data products.

website/docs/docs/collaborate/auto-exposures.md

@@ -7,12 +7,9 @@ pagination_next:  "docs/collaborate/data-tile"
 image: /img/docs/cloud-integrations/auto-exposures/explorer-lineage.jpg
 ---
 
-# Auto-exposures <Lifecycle status='beta' />
+# Auto-exposures <Lifecycle status='preview' />
 
 As a data team, it’s critical that you have context into the downstream use cases and users of your data products. Auto-exposures integrates natively with Tableau (Power BI coming soon) and auto-generates downstream lineage in dbt Explorer for a richer experience.
-:::info Available in beta
-Auto-exposures are currently available in beta to a limited group of users and are gradually being rolled out. If you're interested in gaining access or learning more, stay tuned for updates!
-:::
 
 Auto-exposures helps users understand how their models are used in downstream analytics tools to inform investments and reduce incidents — ultimately building trust and confidence in data products. It imports and auto-generates exposures based on Tableau dashboards, with user-defined curation.
 

website/docs/docs/collaborate/explore-projects.md

@@ -20,9 +20,9 @@ import ExplorerCourse from '/snippets/_explorer-course-link.md';
 - You have at least one successful job run in the deployment environment. Note that [CI jobs](/docs/deploy/ci-jobs) do not update dbt Explorer.
 - You are on the dbt Explorer page. To do this, select **Explore** from the navigation in dbt Cloud.
 
-## Overview page <Lifecycle status="beta" />
+## Overview page 
 
-Navigate the dbt Explorer overview page to access your project's resources and metadata, available in beta. The page includes the following sections:
+Navigate the dbt Explorer overview page to access your project's resources and metadata. The page includes the following sections:
 
 - **Search bar** &mdash; [Search](#search-resources) for resources in your project by keyword. You can also use filters to refine your search results.
 - **Sidebar** &mdash; Use the left sidebar to access model [performance](/docs/collaborate/model-performance), [project recommendations](/docs/collaborate/project-recommendations) in the **Project details** section. Browse your project's [resources, file tree, and database](#browse-with-the-sidebar) in the lower section of the sidebar.
@@ -96,7 +96,7 @@ To explore the lineage graphs of tests and macros, view [their resource details
 
 ### Example of full lineage graph
 
-Example of exploring the `order_items` model in the project's lineage graph:
+Example of exploring a model in the project's lineage graph:
 
 <Lightbox src="/img/docs/collaborate/dbt-explorer/example-project-lineage-graph.png" width="100%" title="Example of full lineage graph" />
 
@@ -162,12 +162,64 @@ Under the the **Models** option, you can filter on model properties (access or m
 
 </Expandable>
 
+<Expandable alt_header="Trust signals for resources" lifecycle="preview">
+
+Trust signal icons offer a quick, at-a-glance view of data health when browsing your models in dbt Explorer. These icons keep you informed on the status of your model's health using the indicators **Healthy**, **Caution**, **Degraded**, and **Unknown**. For accurate health data, ensure the resource is up-to-date and has had a recent job run.
+
+Each trust signal icon reflects key data health components, such as test success status, missing resource descriptions, absence of builds in 30-day windows, and more. 
+
+To access trust signals:
+- Use the search function or click on **Models** or **Sources** under the **Resource** tab. 
+- View the icons under the **Health** column. 
+- Hover over or click the trust signal to see detailed information. 
+- For sources, the trust signal also indicates the source freshness status.
+
+<Lightbox src="/img/docs/collaborate/dbt-explorer/trust-signal-health.jpg" width="60%" title="View trust signals for your models."/>
+
+<!-- commenting out until further iteration on the content
+
+<Tabs>
+<TabItem value="healthy" label="Healthy">
+A resource is considered Healthy if it meets the following criteria:
+- Ran all tests successfully
+- Successfully built in its last run
+- Has a description and tests configured
+- Has been built in the past 30 days 
+<Lightbox src="/img/docs/collaborate/dbt-explorer/trust-signal-healthy.png" title="Healthy trust signal icon"/>
+</TabItem>
+
+<TabItem value="caution" label="Caution">
+Any of the following conditions can trigger a caution status:
+- Successfully built in its last run
+- Is missing a description
+- Does not have any tests configured
+- Has not been built in the past 30 day
+<Lightbox src="/img/docs/collaborate/dbt-explorer/trust-signal-caution.png" title="Caution trust signal icon"/>
+</TabItem>
+
+<TabItem value="degraded" label="Degraded">
+A resource is considered Degraded if it meets any of the following criteria:
+- Last run failed or source freshness error
+<Lightbox src="/img/docs/collaborate/dbt-explorer/trust-signals-degraded.jpg" width="35%" title="Degraded trust signal icon"/>
+</TabItem>
+
+<TabItem value="unknown" label="Unknown">
+The Unknown trust signal icon indicates that:
+- Health information is unknown because the resource hasn't been run recently. 
+<Lightbox src="/img/docs/collaborate/dbt-explorer/trust-signal-unknown.png" title="Unknown trust signal icon"/>
+
+</TabItem>
+</Tabs>
+
+-->
+
+ </Expandable>
+
 ### Example of keyword search
-Example of results from searching on the keyword `item` and applying the filters models, description, and code:
+Example of results from searching on the keyword `customers` and applying the filters models, description, and code. Trust signals are visible to the right of the model name in the search results.
 
 <Lightbox src="/img/docs/collaborate/dbt-explorer/example-keyword-search.png" width="100%" title="Example of keyword search" />
 
-
 ## Browse with the sidebar
 
 From the sidebar, you can browse your project's resources, its file tree, and the database. 
@@ -201,6 +253,7 @@ In the upper right corner of the resource details page, you can:
 
 <Expandable alt_header="What details are available for a model?">
 
+- Trust signal icon &mdash; Icons offering a quick, at-a-glance view of data health. These icons indicate whether a model is Healthy, Caution, Degraded, or Unknown. Hover over an icon to view detailed information about the model's health.
 - **Status bar** (below the page title) &mdash; Information on the last time the model ran, whether the run was successful, how the data is materialized, number of rows, and the size of the model. 
 - **General** tab includes:
     - **Lineage** graph &mdash; The model’s lineage graph that you can interact with. The graph includes one upstream node and one downstream node from the model. Click the Expand icon in the graph's upper right corner to view the model in full lineage graph mode.