diff --git a/docs.json b/docs.json
index eff49d1a..799ade12 100644
--- a/docs.json
+++ b/docs.json
@@ -51,7 +51,15 @@
"group": "BI feature guides",
"icon": "person-chalkboard",
"pages": [
- "guides/metrics-catalog",
+ {
+ "group": "Spotlight",
+ "icon": "stars",
+ "pages": [
+ "guides/metrics-catalog",
+ "guides/metrics-catalog/catalog",
+ "guides/metrics-catalog/canvas"
+ ]
+ },
{
"group": "Chart types",
"pages": [
diff --git a/guides/metrics-catalog.mdx b/guides/metrics-catalog.mdx
index 291dacd0..d92f7f51 100644
--- a/guides/metrics-catalog.mdx
+++ b/guides/metrics-catalog.mdx
@@ -1,5 +1,6 @@
---
title: "Spotlight"
+sidebarTitle: "Overview"
description: Spotlight is a suite of features designed to put Metrics front and center. It simplifies data exploration, making it easy for business users to focus on metrics without dealing with complex tables or time dimensions.
---
@@ -11,947 +12,19 @@ description: Spotlight is a suite of features designed to put Metrics front and
## Getting Started
-Lightdash users don't need to do anything to get started! Spotlight features use your existing [Lightdash semantic layer](/guides/lightdash-semantic-layer) and metrics definitions, so you can get started today.
+Spotlight features use your existing [Lightdash semantic layer](/guides/lightdash-semantic-layer) and metrics definitions, so you can get started today. Head to **Metrics** in the navigation bar to start exploring.
-Head to the Metrics Catalog under the Browse menu in the navigation bar.
+Spotlight is organized into two main views:
-## Browsing the catalog
+- **Catalog** — A searchable, filterable table of all your project metrics. Browse metrics by category, owner, or popularity, explore any metric over time in the Metrics Explorer, and curate what your business users see through `.yml` configuration.
-Browse all the project metrics you have access to (based on permissions and user-attributes) in the **Metrics Catalog**.
+- **Canvas** — A freeform workspace where you can drag metrics onto a canvas and draw connections between them to visualize metric trees, hierarchies, and dependencies.
-
- 
-
-
-1. **Search**: Easily find metrics by their names or .yml descriptions using the searchbar.
-
-2. **View .yml descriptions**: Click on any description to expand and view the full content, including rendered Markdown.
-
-3. **Categories**: Use categories to streamline your metrics and KPIs. Filter metrics by category and add new ones directly in the UI. ***Users with editor permissions and above*** can click on any category cell to edit, rename, change its color, or delete it.
-
-4. **View popularity**: Discover a metric’s popularity and see where it’s being used. Click to explore a complete list of charts which use the metric. Metrics are sorted by default to highlight the most used ones first.
-
-5. **Explore**: ***Interactive viewers and above*** can dive deeper by clicking *Explore* to visualize the metric in a chart format.
-
-## Exploring a metric
-
-Visualize your metrics in the **Metrics Explorer**.
-
-
- 
-
-
-1. **Plot over time**: View your selected metric plotted over a time dimension as a line chart. You can adjust this dimension or set a default time dimension in your `.yml` to simplify the process for users. [See how](#configuring-default-time-settings-in-yml)
-
-2. **Filter by date**: Use the date picker with convenient presets for quick selection. [See how default presets work based on the granularity](#faq)
-
-3. **Adjust the time granularity**: Refine your view by choosing the desired level of date granularity.
-
-4. **Filter by a dimension:** Filter your metric by any string or boolean dimension from the same table.
-
-5. **Segment-by**: Break down the metric by any non-time dimension in your dataset.
-
-6. **Compare to:**
-
- * **'This time last year'**: Compare the selected time period to the same period last year
-
- * **'Another metric':** Compare to any other metric in the project **that has a default time dimension specified in the `.yml`**. This includes joins [See how](#configuring-default-time-settings-in-yml)
-
-7. **Drag to zoom:** Click and drag across the chart to highlight the desired time range or data points, then release to zoom in on that segment. Hit ‘Reset Zoom’ to reset chart.
-
-## Curating Spotlight for your business users
-
-Spotlight is designed to be a tool for your business users to explore and understand your data.
-
-To make Spotlight more useful for your business users, you can curate the metrics they can see and explore.
-
-To do this, you can:
-
-* Control the visibility of metrics in the catalog
-
-* Add categories to your metrics
-
-* Add default time settings to your metrics
-
-All through your Lightdash `.yml` files.
-
-### Configuring global visibility of metrics
-
-You can control the visibility of metrics in the catalog by creating a new file called `lightdash.config.yml` in the root of your dbt project.
-
-
- If you're new to lightdash.config.yml, check out our [getting started guide](/references/lightdash-config-yml#getting-started-with-lightdashconfigyml) to learn how to create and set up this file.
-
-
-See this video for an example on how to set this up:
-
-
-
-
-
-**Step-by-step guide**
-
-1. Add the following to your `lightdash.config.yml` file:
-
-```yml
-spotlight:
- default_visibility: show
-```
-
-
- **The default visibility can be set to `show` or `hide`.**
-
- If you don't set this, the default visibility will be `show`, so all metrics will be visible in the catalog by default (but other settings like user attributes will still apply).
-
-
-This will set the default visibility of metrics in the catalog to `show` for all metrics in your project. You can also set this to `hide` if you prefer to hide metrics by default and then override this on a per-model/metric basis.
-
-2. Now that you've set the default visibility, you can override this on a per-model/metric basis.
-
-
-
- ```yml
- models:
- - name: events
- meta:
- spotlight:
- visibility: hide
- ```
-
-
- ```yml
- models:
- - name: events
- config:
- meta:
- spotlight:
- visibility: hide
- ```
-
-
- ```yml
- type: model
- name: events
-
- spotlight:
- visibility: hide
- ```
-
-
-
-This will hide the events model from the catalog.
-
-3. If there are metrics in the events model that you want to make visible, you can override the default visibility for those metrics.
-
-
-
- ```yml
- models:
- - name: events
- meta:
- spotlight:
- visibility: hide
- metrics:
- event_count:
- type: count
- spotlight:
- visibility: show
- ```
-
-
- ```yml
- models:
- - name: events
- config:
- meta:
- spotlight:
- visibility: hide
- metrics:
- event_count:
- type: count
- spotlight:
- visibility: show
- ```
-
-
- ```yml
- type: model
- name: events
-
- spotlight:
- visibility: hide
-
- metrics:
- event_count:
- type: count
- spotlight:
- visibility: show
- ```
-
-
-
-4. Once you compile your project, you'll see the `event_count` metric in the catalog, even though the events model is hidden.
-
-### Assigning categories to metrics
-
-Categories are a great way to organize your metrics in the catalog. You can create a new category by adding a new `categories` field to your `lightdash.config.yml` file.
-
-Here's a video showing how to set this up:
-
-
-
-
-
-**Step-by-step guide**
-
-1. Add the following to your `lightdash.config.yml` file:
-
-```yml
-spotlight:
- categories:
- revenue: # Required, this is the name of the category, and how it will be referenced in the catalog. It must be unique.
- label: Revenue # Required, this is what will be displayed in the catalog
- color: "orange" # Optional, defaults to "gray", with the option to choose from a range of colors: "gray", "violet", "red", "orange", "green", "blue", "indigo", "pink", "yellow"
-```
-
-2. Now that you've added a category, you can assign metrics to it by adding a `categories` field to your models `.yml` file.
-
-
-
- ```yml
- models:
- - name: events
- meta:
- spotlight:
- visibility: show
- categories:
- - revenue
- ```
-
-
- ```yml
- models:
- - name: events
- config:
- meta:
- spotlight:
- visibility: show
- categories:
- - revenue
- ```
-
-
- ```yml
- type: model
- name: events
-
- spotlight:
- visibility: show
- categories:
- - revenue
- ```
-
-
-
-This will add the `revenue` category to all metrics in the events model.
-
-If you want to add another category to a specific metric, you can do so by adding the `categories` field to the metric's `.yml` file. And remember, you can only add categories that have been defined in the `lightdash.config.yml` file.
-
-3. Now you can add the `marketing` category to the `event_count` metric:
- So in your `lightdash.config.yml` file, you need to have another category. Let's call it `marketing` and add it to the `event_count` metric, like so:
-
-```yml
-spotlight:
- categories:
- marketing:
- label: Marketing
- color: "blue"
- revenue:
- label: Revenue
- color: "orange"
-```
-
-Now you can add the `marketing` category to the `event_count` metric:
-
-
-
- ```yml
- models:
- - name: events
- meta:
- spotlight:
- visibility: show
- categories:
- - revenue
- metrics:
- event_count:
- type: count
- spotlight:
- categories:
- - marketing
- ```
-
-
- ```yml
- models:
- - name: events
- config:
- meta:
- spotlight:
- visibility: show
- categories:
- - revenue
- metrics:
- event_count:
- type: count
- spotlight:
- categories:
- - marketing
- ```
-
-
- ```yml
- type: model
- name: events
-
- spotlight:
- visibility: show
- categories:
- - revenue
-
- metrics:
- event_count:
- type: count
- spotlight:
- categories:
- - marketing
- ```
-
-
-
-In this example, the `event_count` metric will have both the `marketing` and `revenue` categories, it's cumulative.
-
-4. Once you compile your project, you'll see the `event_count` metric in the catalog with both the `marketing` and `revenue` categories and you can use this to filter your metrics in the catalog.
-
-
- **The categories you define need to be unique, so you can't have two categories with the same name.**
-
- If you try to add a category with the same name as an existing category, you'll get an error. This error will be displayed in the UI and in the terminal (if you use the Lightdash CLI) when you compile your project.
-
-
-## Assigning owners to metrics
-
-You can assign owners to metrics using the `spotlight.owner` property. The owner displays in the metrics catalog with their name and avatar.
-
-### Set an owner at the metric level
-
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: amount
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- owner: alice@yourcompany.com
- ```
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: amount
- config:
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- owner: alice@yourcompany.com
- ```
-
-
- ```yaml
- type: model
- name: orders
-
- dimensions:
- - name: amount
-
- metrics:
- total_revenue:
- type: sum
- sql: ${TABLE}.amount
- spotlight:
- owner: alice@yourcompany.com
- ```
-
-
-
-### Set a default owner at the model level
-
-You can set a default owner for all metrics in a model. Metric-level owners override the model-level default.
-
-
-
- ```yaml
- models:
- - name: orders
- meta:
- spotlight:
- owner: bob@yourcompany.com # default for all metrics in this model
- columns:
- - name: amount
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- owner: alice@yourcompany.com # overrides model owner
- avg_revenue:
- type: average
- # inherits bob@yourcompany.com from model
- ```
-
-
- ```yaml
- models:
- - name: orders
- config:
- meta:
- spotlight:
- owner: bob@yourcompany.com # default for all metrics in this model
- columns:
- - name: amount
- config:
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- owner: alice@yourcompany.com # overrides model owner
- avg_revenue:
- type: average
- # inherits bob@yourcompany.com from model
- ```
-
-
- ```yaml
- type: model
- name: orders
-
- spotlight:
- owner: bob@yourcompany.com # default for all metrics in this model
-
- dimensions:
- - name: amount
-
- metrics:
- total_revenue:
- type: sum
- sql: ${TABLE}.amount
- spotlight:
- owner: alice@yourcompany.com # overrides model owner
- avg_revenue:
- type: average
- sql: ${TABLE}.amount
- # inherits bob@yourcompany.com from model
- ```
-
-
-
-
- - Use the email address of a Lightdash user in your organization.
- - Metric-level owner takes precedence over model-level.
- - You can filter by owner in the Spotlight UI.
- - If the email doesn't match a Lightdash user, the metric shows as "Unassigned".
-
-
-## Controlling filtering and segmentation options
-
-You can control which dimensions appear in the filter and segment-by dropdowns when exploring metrics. This helps users focus on relevant dimensions.
-
-### Hide a dimension from all metrics
-
-Use boolean values at the dimension level to hide a dimension from filter or segment-by dropdowns for all metrics in that model:
-
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: internal_tracking_id
- meta:
- dimension:
- spotlight:
- filter_by: false # hide from filter dropdown
- segment_by: false # hide from segment-by dropdown
- ```
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: internal_tracking_id
- config:
- meta:
- dimension:
- spotlight:
- filter_by: false # hide from filter dropdown
- segment_by: false # hide from segment-by dropdown
- ```
-
-
- ```yaml
- type: model
- name: orders
-
- dimensions:
- - name: internal_tracking_id
- spotlight:
- filter_by: false # hide from filter dropdown
- segment_by: false # hide from segment-by dropdown
- ```
-
-
-
-### Allowlist specific dimensions for a metric
-
-Use an array of dimension names at the metric level to create an allowlist of dimensions for that specific metric:
-
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: amount
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- filter_by:
- - status
- - region
- - order_date
- segment_by:
- - status
- - customer_segment
- ```
-
-
- ```yaml
- models:
- - name: orders
- columns:
- - name: amount
- config:
- meta:
- metrics:
- total_revenue:
- type: sum
- spotlight:
- filter_by:
- - status
- - region
- - order_date
- segment_by:
- - status
- - customer_segment
- ```
-
-
- ```yaml
- type: model
- name: orders
-
- dimensions:
- - name: amount
-
- metrics:
- total_revenue:
- type: sum
- sql: ${TABLE}.amount
- spotlight:
- filter_by:
- - status
- - region
- - order_date
- segment_by:
- - status
- - customer_segment
- ```
-
-
-
-### How it works
-
-- **Dimension-level (boolean, default `true`)**: Controls whether a dimension appears in dropdowns for all metrics in that model.
-- **Metric-level (array of dimension names)**: Creates an allowlist of dimensions for that specific metric.
-- **Metric-level allowlists override dimension-level settings**: If a dimension has `filter_by: false` but a metric includes it in its `filter_by` array, it will still be available for that metric.
-
-### Use cases
-
-- Hide internal/technical dimensions that aren't useful for analysis.
-- Curate the exploration experience per metric (e.g., revenue metrics only filterable by business dimensions).
-- Reduce clutter in models with many dimensions.
-
-## Configuring default time settings in .yml
-
-We recommend setting up default time fields to make it easier for your business users and save them time.
-
-To pre-select a time field in the explore view, simply define the default settings in your Lightdash `.yml` files.
-
-### Set a table-level default time dimension
-
-1. Create or modify your table configuration in the .yml file. For example, to set a default time dimension on the events table:
-
-
-
- ```yml
- models:
- - name: events
- columns:
- - name: event_date
- description: "Event date"
- meta:
- dimension:
- label: "Event date"
- type: date
- time_intervals:
- - DAY
- - name: event
- description: "Event"
- meta:
- dimension:
- type: string
- metrics:
- count:
- type: count
- ```
-
-
- ```yml
- models:
- - name: events
- columns:
- - name: event_date
- description: "Event date"
- config:
- meta:
- dimension:
- label: "Event date"
- type: date
- time_intervals:
- - DAY
- - name: event
- description: "Event"
- config:
- meta:
- dimension:
- type: string
- metrics:
- count:
- type: count
- ```
-
-
- ```yml
- type: model
- name: events
-
- dimensions:
- - name: event_date
- description: "Event date"
- label: "Event date"
- type: date
- time_intervals:
- - DAY
- - name: event
- description: "Event"
- type: string
-
- metrics:
- count:
- type: count
- sql: ${TABLE}.event
- ```
-
-
-
-2. Add the default time dimension at the table level:
-
-
-
- ```yaml
- models:
- - name: events
- meta:
- default_time_dimension:
- field: event_date
- interval: DAY
- columns:
- # ... your column definitions here
- ```
-
-
- ```yaml
- models:
- - name: events
- config:
- meta:
- default_time_dimension:
- field: event_date
- interval: DAY
- columns:
- # ... your column definitions here
- ```
-
-
- ```yaml
- type: model
- name: events
-
- default_time_dimension:
- field: event_date
- interval: DAY
-
- dimensions:
- # ... your dimension definitions here
- ```
-
-
-
-3. [Compile your project](/references/integrations/dbt-projects)
-
-4. Navigate to the metrics catalog
-
-5. Open any metrics from the events table
-
-6. All metrics with that default time set will be plotted against the `event date` with day granularity `in the last 30 days`
-
-### Set a metric-level default time dimension
-
-This will override the time dimension defined on the table level.
-
-1. Modify your existing table configuration to add a metric-level default time dimension:
-
-
-
- ```yaml
- models:
- - name: events
- meta:
- default_time_dimension:
- field: event_date
- interval: DAY
- columns:
- - name: event
- description: "Event"
- meta:
- metrics:
- count:
- type: count
- # This will override the table level default time dimension
- default_time_dimension:
- field: event_date
- interval: MONTH
- ```
-
-
- ```yaml
- models:
- - name: events
- config:
- meta:
- default_time_dimension:
- field: event_date
- interval: DAY
- columns:
- - name: event
- description: "Event"
- config:
- meta:
- metrics:
- count:
- type: count
- # This will override the table level default time dimension
- default_time_dimension:
- field: event_date
- interval: MONTH
- ```
-
-
- ```yaml
- type: model
- name: events
-
- default_time_dimension:
- field: event_date
- interval: DAY
-
- dimensions:
- - name: event
- description: "Event"
-
- metrics:
- count:
- type: count
- sql: ${TABLE}.event
- # This will override the table level default time dimension
- default_time_dimension:
- field: event_date
- interval: MONTH
- ```
-
-
-
-2. [Compile your project](/references/integrations/dbt-projects)
-
-3. Navigate to the metrics catalog
-
-4. Explore the Events' count metric
-
-5. The metric will be plotted against the `event date` with **month** granularity, instead of the default **day** granularity applied to the table
-
-## Canvas view (alpha)
-
-The **Canvas View** is a powerful, flexible workspace designed for visualizing and organizing metrics in creative ways. A key use case is creating **Metric Trees** to visualize metric relationships, hierarchies, and dependencies. This visualization enables you to see how metrics impact your KPIs and compare performance over the previous month.
-
-### How to use the ‘Canvas view’ for Metric trees:
-
-1. **Filter your metrics**: Use the 'categories' or 'search' functions to narrow your list of metrics. Canvas view currently works best with fewer than 30 metrics to ensure smooth performance. Need help creating categories? [Learn more here](#browsing-the-catalog).
-
-2. **Enable Canvas view**: Select **Canvas view** to activate the workspace.
-
-3. **Add metrics**: Drag your desired metrics from the grey sidebar into the canvas workspace.
-
-4. **Create connections**: Link metrics by dragging between nodes to build relationships and dependencies. Connected nodes will be saved and visible the next time you filter your metrics down by category.
-
-5. **Remove nodes**: Select a node and press **Backspace** to delete it.
-
-6. **Permissions**: Viewers can see trees created in the Canvas View but cannot make edits.
-
-Canvas view is currently in alpha.
-
-Your metric connections are saved, so the next time you filter by a category and switch to canvas view, you'll see your saved connections. However, the placement of any unconnected tiles will not be retained.
-
-## FAQs
-
-**a. What time intervals are supported?**
-
-Currently, we only support: DAY, WEEK, MONTH, YEAR
-
-**b. What pre-filled filters are applied?**
-
-* Time grain Year -> past 3 years
-
-* Time grain Month -> past 12 months
-
-* Time grain Week -> past 12 weeks
-
-* Time grain Day -> past 30 days
-
-So if one of your business users explores a metric with a default time grain of DAY, metrics will be shown for the past 30 days with granularity of days with the default time dimension prefilled.
-
-**c. Can I pull through other metadata from my .yml files?**
-
-Not yet, but soon you'll be able to manage metadata directly in the UI and sync it back to dbt.
-
-**d. Which other metrics can I compare my selected metric by?**
-
-1. **Metrics with defaults in `.yml`:** Metrics with a default time dimension specified in the `.yml` file will always appear.
-
-2. **Metrics with a single time dimension:** Metrics from tables with only one time dimension will appear as it's assumed to be the most relevant.
-
-3. **Metrics from joined tables:** Metrics from joined tables that meet the criteria in points 1 and 2 will also appear.
-
-**e. How can I be sure that my yml changes are correct?**
-
-If you use VSCode, you can use our Lightdash schema validation to check your yml files are correct.
-
-1. Install this YAML extension for VSCode: [https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml)
-
-2. Open your user settings in JSON format and add the following:
-
-```json
-"[yaml]": {
- "editor.defaultFormatter": "redhat.vscode-yaml"
-},
-"yaml.schemas": {
- "https://raw.githubusercontent.com/lightdash/lightdash/refs/heads/main/packages/common/src/schemas/json/lightdash-dbt-2.0.json": [
- "*.yml",
- "/**/models/**/*.yml",
- "/**/models/**/*.yaml",
- "!lightdash.config.yml",
- "!dbt_project.yml"
- ],
- "https://raw.githubusercontent.com/lightdash/lightdash/refs/heads/main/packages/common/src/schemas/json/lightdash-project-config-1.0.json": [
- "lightdash.config.yml"
- ]
-}
-```
-
-This will add schema validation to your model yml files and your lightdash.config.yml file.
-
-3. Reload VSCode
-
-4. You'll see a red squiggly line under any errors in your yml files as well as suggestions for how to fix them and what is allowed.
-
-
-
-## Roles and permissions
-
-| **Action** | **Project Admin** | **Project Developer** | **Project Editor** | **Project Interactive Viewer** | **Project Viewer** |
-| :---------------------------- | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: |
-| Browse the ‘Metrics catalog’ | | | | | |
-| Add/edit /delete ‘Categories’ | | | | | |
-| Open the ‘Metrics Explorer’ | | | | | |
\ No newline at end of file
+
+
+ Browse, explore, and curate your metrics in the Metrics Catalog.
+
+
+ Visualize metric relationships and dependencies in the Canvas view.
+
+
diff --git a/guides/metrics-catalog/canvas.mdx b/guides/metrics-catalog/canvas.mdx
new file mode 100644
index 00000000..4e94e59a
--- /dev/null
+++ b/guides/metrics-catalog/canvas.mdx
@@ -0,0 +1,175 @@
+---
+title: "Canvas"
+description: "Use the Canvas view to visualize metric relationships, hierarchies, and dependencies in a flexible workspace."
+---
+
+The **Canvas View** is a flexible workspace for visualizing and organizing metrics. You can use it to build **Metric Trees** that show how metrics relate to each other, visualize hierarchies, and understand dependencies across your data model.
+
+### How to use the Canvas view
+
+1. **Filter your metrics**: Use the search bar, categories, or table filters to narrow down the list. Canvas view works best with fewer than 30 metrics for smooth performance. Need help creating categories? [Learn more here](/guides/metrics-catalog/catalog#browsing-the-catalog).
+
+2. **Enable Canvas view**: Switch to the Canvas view toggle in the metrics catalog.
+
+3. **Add metrics**: Drag metrics from the sidebar into the canvas workspace.
+
+4. **Create connections**: Drag between node handles to draw edges representing relationships and dependencies.
+
+5. **Remove nodes**: Select a node and press **Backspace** to delete it.
+
+
+ Viewers can see trees and connections but cannot make edits.
+
+
+## Saved Trees
+
+
+ **Experimental:** Saved Trees is behind a feature flag. Reach out to support to enable it for your organization. Learn more about [Feature Maturity Levels](/references/workspace/feature-maturity-levels).
+
+
+Saved Trees are named, persistent canvas layouts that preserve your metric arrangements and connections. Unlike the ad-hoc canvas — where unconnected node positions reset between sessions — Saved Trees store the full layout including every node position and edge.
+
+Saved Trees are shared across your team: anyone with access to the project can view them, and users with the right permissions can create, edit, and delete them.
+
+### Creating a Saved Tree
+
+
+ 
+ 
+
+
+1. In the Canvas View, click **New Tree** to enter edit mode.
+2. Type a name in the text input at the top of the canvas.
+3. Drag metrics from the sidebar into the canvas and draw connections between them.
+4. Click **Save**. The button is disabled until you provide a name and add at least one node.
+
+When you save, the tree name, node positions, edges, and metric references are all persisted.
+
+Click **Cancel** to discard your work. If you have unsaved changes, a confirmation dialog will appear.
+
+
+ [Driver edges](#drivers) are not stored with the tree — they are injected automatically whenever matching nodes are present.
+
+
+### Collaborative locking
+
+Only one user can edit a Saved Tree at a time. When you start editing, the tree is locked to you. The lock stays active while you work — if you stop editing for more than 2 minutes, the lock is automatically released so others can make changes.
+
+When a tree is locked by another user, you'll see an **"Editing by {name}"** badge in the header, and the Edit and Delete options are disabled until the lock is released.
+
+Your changes are automatically saved as a draft while you edit, so if you accidentally close the tab or refresh the page, your work-in-progress can be recovered when you return.
+
+### Permissions
+
+| Action | Admin | Developer | Editor | Interactive Viewer | Viewer |
+| :--- | :---: | :---: | :---: | :---: | :---: |
+| View a Saved Tree | | | | | |
+| Create a Saved Tree | | | | | |
+| Edit a Saved Tree | | | | | |
+| Delete a Saved Tree | | | | | |
+
+## Drivers
+
+Drivers are metrics that directly influence or feed into another metric. By defining drivers in your `.yml` files, you can automatically visualize how metrics relate to each other in the Canvas view — no manual drawing needed.
+
+For example, `total_order_amount` is a driver of `total_revenue`, `average_order_size`, and `total_completed_order_amount` — because each of those metrics is influenced by the total order amount. On the canvas, this creates a tree where `total_order_amount` fans out to the metrics it drives.
+
+### Defining drivers
+
+Add a `drivers` property to any metric listing the metrics that flow into it. You can reference metrics from the same table or across tables using the `table.metric` syntax:
+
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: order_amount
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ drivers:
+ - total_order_amount
+ average_order_size:
+ type: average
+ drivers:
+ - total_order_amount
+ total_completed_order_amount:
+ type: sum
+ drivers:
+ - total_order_amount
+ ```
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: order_amount
+ config:
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ drivers:
+ - total_order_amount
+ average_order_size:
+ type: average
+ drivers:
+ - total_order_amount
+ total_completed_order_amount:
+ type: sum
+ drivers:
+ - total_order_amount
+ ```
+
+
+ ```yaml
+ type: model
+ name: orders
+
+ dimensions:
+ - name: order_amount
+
+ metrics:
+ total_revenue:
+ type: sum
+ sql: ${TABLE}.order_amount
+ drivers:
+ - total_order_amount
+ average_order_size:
+ type: average
+ sql: ${TABLE}.order_amount
+ drivers:
+ - total_order_amount
+ total_completed_order_amount:
+ type: sum
+ sql: ${TABLE}.order_amount
+ drivers:
+ - total_order_amount
+ ```
+
+
+
+This creates edges on the canvas pointing from each driver to the current metric (e.g., `total_order_amount` → `total_revenue`, `total_order_amount` → `average_order_size`, etc.).
+
+### How drivers appear on the canvas
+
+- **Automatic**: Driver edges appear as soon as both the driver and target metrics are on the canvas.
+- **Read-only**: You cannot delete or modify driver edges from the UI — they are managed through your `.yml` configuration.
+- **Visually distinct**: Driver edges use a different style to distinguish them from manually-created connections.
+
+In Saved Trees, driver edges are displayed alongside manually-created edges, giving you a complete picture of both the relationships you've drawn and the ones defined in your data model.
+
+
+ Driver edges cannot be removed from a Saved Tree. If you don't want a driver edge to appear, remove one of its endpoint nodes from the canvas.
+
diff --git a/guides/metrics-catalog/catalog.mdx b/guides/metrics-catalog/catalog.mdx
new file mode 100644
index 00000000..984e3a21
--- /dev/null
+++ b/guides/metrics-catalog/catalog.mdx
@@ -0,0 +1,923 @@
+---
+title: "Catalog"
+description: "Browse, explore, and curate your metrics in the Spotlight Metrics Catalog."
+---
+
+## Browsing the catalog
+
+Browse all the project metrics you have access to (based on permissions and user-attributes) in the **Metrics Catalog**.
+
+
+ 
+
+
+1. **Search**: Easily find metrics by their names or .yml descriptions using the searchbar.
+
+2. **View .yml descriptions**: Click on any description to expand and view the full content, including rendered Markdown.
+
+3. **Categories**: Use categories to streamline your metrics and KPIs. Filter metrics by category and add new ones directly in the UI. ***Users with editor permissions and above*** can click on any category cell to edit, rename, change its color, or delete it.
+
+4. **View popularity**: Discover a metric's popularity and see where it's being used. Click to explore a complete list of charts which use the metric. Metrics are sorted by default to highlight the most used ones first.
+
+5. **Explore**: ***Interactive viewers and above*** can dive deeper by clicking *Explore* to visualize the metric in a chart format.
+
+## Exploring a metric
+
+Visualize your metrics in the **Metrics Explorer**.
+
+
+ 
+
+
+1. **Plot over time**: View your selected metric plotted over a time dimension as a line chart. You can adjust this dimension or set a default time dimension in your `.yml` to simplify the process for users. [See how](#configuring-default-time-settings-in-yml)
+
+2. **Filter by date**: Use the date picker with convenient presets for quick selection. [See how default presets work based on the granularity](#faqs)
+
+3. **Adjust the time granularity**: Refine your view by choosing the desired level of date granularity.
+
+4. **Filter by a dimension:** Filter your metric by any string or boolean dimension from the same table.
+
+5. **Segment-by**: Break down the metric by any non-time dimension in your dataset.
+
+6. **Compare to:**
+
+ * **'This time last year'**: Compare the selected time period to the same period last year
+
+ * **'Another metric':** Compare to any other metric in the project **that has a default time dimension specified in the `.yml`**. This includes joins [See how](#configuring-default-time-settings-in-yml)
+
+7. **Drag to zoom:** Click and drag across the chart to highlight the desired time range or data points, then release to zoom in on that segment. Hit 'Reset Zoom' to reset chart.
+
+## Curating Spotlight for your business users
+
+Spotlight is designed to be a tool for your business users to explore and understand your data.
+
+To make Spotlight more useful for your business users, you can curate the metrics they can see and explore.
+
+To do this, you can:
+
+* Control the visibility of metrics in the catalog
+
+* Add categories to your metrics
+
+* Add default time settings to your metrics
+
+All through your Lightdash `.yml` files.
+
+### Configuring global visibility of metrics
+
+You can control the visibility of metrics in the catalog by creating a new file called `lightdash.config.yml` in the root of your dbt project.
+
+
+ If you're new to lightdash.config.yml, check out our [getting started guide](/references/lightdash-config-yml#getting-started-with-lightdashconfigyml) to learn how to create and set up this file.
+
+
+See this video for an example on how to set this up:
+
+
+
+
+
+**Step-by-step guide**
+
+1. Add the following to your `lightdash.config.yml` file:
+
+```yml
+spotlight:
+ default_visibility: show
+```
+
+
+ **The default visibility can be set to `show` or `hide`.**
+
+ If you don't set this, the default visibility will be `show`, so all metrics will be visible in the catalog by default (but other settings like user attributes will still apply).
+
+
+This will set the default visibility of metrics in the catalog to `show` for all metrics in your project. You can also set this to `hide` if you prefer to hide metrics by default and then override this on a per-model/metric basis.
+
+2. Now that you've set the default visibility, you can override this on a per-model/metric basis.
+
+
+
+ ```yml
+ models:
+ - name: events
+ meta:
+ spotlight:
+ visibility: hide
+ ```
+
+
+ ```yml
+ models:
+ - name: events
+ config:
+ meta:
+ spotlight:
+ visibility: hide
+ ```
+
+
+ ```yml
+ type: model
+ name: events
+
+ spotlight:
+ visibility: hide
+ ```
+
+
+
+This will hide the events model from the catalog.
+
+3. If there are metrics in the events model that you want to make visible, you can override the default visibility for those metrics.
+
+
+
+ ```yml
+ models:
+ - name: events
+ meta:
+ spotlight:
+ visibility: hide
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ visibility: show
+ ```
+
+
+ ```yml
+ models:
+ - name: events
+ config:
+ meta:
+ spotlight:
+ visibility: hide
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ visibility: show
+ ```
+
+
+ ```yml
+ type: model
+ name: events
+
+ spotlight:
+ visibility: hide
+
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ visibility: show
+ ```
+
+
+
+4. Once you compile your project, you'll see the `event_count` metric in the catalog, even though the events model is hidden.
+
+### Assigning categories to metrics
+
+Categories are a great way to organize your metrics in the catalog. You can create a new category by adding a new `categories` field to your `lightdash.config.yml` file.
+
+Here's a video showing how to set this up:
+
+
+
+
+
+**Step-by-step guide**
+
+1. Add the following to your `lightdash.config.yml` file:
+
+```yml
+spotlight:
+ categories:
+ revenue: # Required, this is the name of the category, and how it will be referenced in the catalog. It must be unique.
+ label: Revenue # Required, this is what will be displayed in the catalog
+ color: "orange" # Optional, defaults to "gray", with the option to choose from a range of colors: "gray", "violet", "red", "orange", "green", "blue", "indigo", "pink", "yellow"
+```
+
+2. Now that you've added a category, you can assign metrics to it by adding a `categories` field to your models `.yml` file.
+
+
+
+ ```yml
+ models:
+ - name: events
+ meta:
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+ ```
+
+
+ ```yml
+ models:
+ - name: events
+ config:
+ meta:
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+ ```
+
+
+ ```yml
+ type: model
+ name: events
+
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+ ```
+
+
+
+This will add the `revenue` category to all metrics in the events model.
+
+If you want to add another category to a specific metric, you can do so by adding the `categories` field to the metric's `.yml` file. And remember, you can only add categories that have been defined in the `lightdash.config.yml` file.
+
+3. Now you can add the `marketing` category to the `event_count` metric:
+ So in your `lightdash.config.yml` file, you need to have another category. Let's call it `marketing` and add it to the `event_count` metric, like so:
+
+```yml
+spotlight:
+ categories:
+ marketing:
+ label: Marketing
+ color: "blue"
+ revenue:
+ label: Revenue
+ color: "orange"
+```
+
+Now you can add the `marketing` category to the `event_count` metric:
+
+
+
+ ```yml
+ models:
+ - name: events
+ meta:
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ categories:
+ - marketing
+ ```
+
+
+ ```yml
+ models:
+ - name: events
+ config:
+ meta:
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ categories:
+ - marketing
+ ```
+
+
+ ```yml
+ type: model
+ name: events
+
+ spotlight:
+ visibility: show
+ categories:
+ - revenue
+
+ metrics:
+ event_count:
+ type: count
+ spotlight:
+ categories:
+ - marketing
+ ```
+
+
+
+In this example, the `event_count` metric will have both the `marketing` and `revenue` categories, it's cumulative.
+
+4. Once you compile your project, you'll see the `event_count` metric in the catalog with both the `marketing` and `revenue` categories and you can use this to filter your metrics in the catalog.
+
+
+ **The categories you define need to be unique, so you can't have two categories with the same name.**
+
+ If you try to add a category with the same name as an existing category, you'll get an error. This error will be displayed in the UI and in the terminal (if you use the Lightdash CLI) when you compile your project.
+
+
+## Assigning owners to metrics
+
+You can assign owners to metrics using the `spotlight.owner` property. The owner displays in the metrics catalog with their name and avatar.
+
+### Set an owner at the metric level
+
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: amount
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ owner: alice@yourcompany.com
+ ```
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: amount
+ config:
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ owner: alice@yourcompany.com
+ ```
+
+
+ ```yaml
+ type: model
+ name: orders
+
+ dimensions:
+ - name: amount
+
+ metrics:
+ total_revenue:
+ type: sum
+ sql: ${TABLE}.amount
+ spotlight:
+ owner: alice@yourcompany.com
+ ```
+
+
+
+### Set a default owner at the model level
+
+You can set a default owner for all metrics in a model. Metric-level owners override the model-level default.
+
+
+
+ ```yaml
+ models:
+ - name: orders
+ meta:
+ spotlight:
+ owner: bob@yourcompany.com # default for all metrics in this model
+ columns:
+ - name: amount
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ owner: alice@yourcompany.com # overrides model owner
+ avg_revenue:
+ type: average
+ # inherits bob@yourcompany.com from model
+ ```
+
+
+ ```yaml
+ models:
+ - name: orders
+ config:
+ meta:
+ spotlight:
+ owner: bob@yourcompany.com # default for all metrics in this model
+ columns:
+ - name: amount
+ config:
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ owner: alice@yourcompany.com # overrides model owner
+ avg_revenue:
+ type: average
+ # inherits bob@yourcompany.com from model
+ ```
+
+
+ ```yaml
+ type: model
+ name: orders
+
+ spotlight:
+ owner: bob@yourcompany.com # default for all metrics in this model
+
+ dimensions:
+ - name: amount
+
+ metrics:
+ total_revenue:
+ type: sum
+ sql: ${TABLE}.amount
+ spotlight:
+ owner: alice@yourcompany.com # overrides model owner
+ avg_revenue:
+ type: average
+ sql: ${TABLE}.amount
+ # inherits bob@yourcompany.com from model
+ ```
+
+
+
+
+ - Use the email address of a Lightdash user in your organization.
+ - Metric-level owner takes precedence over model-level.
+ - You can filter by owner in the Spotlight UI.
+ - If the email doesn't match a Lightdash user, the metric shows as "Unassigned".
+
+
+## Controlling filtering and segmentation options
+
+You can control which dimensions appear in the filter and segment-by dropdowns when exploring metrics. This helps users focus on relevant dimensions.
+
+### Hide a dimension from all metrics
+
+Use boolean values at the dimension level to hide a dimension from filter or segment-by dropdowns for all metrics in that model:
+
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: internal_tracking_id
+ meta:
+ dimension:
+ spotlight:
+ filter_by: false # hide from filter dropdown
+ segment_by: false # hide from segment-by dropdown
+ ```
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: internal_tracking_id
+ config:
+ meta:
+ dimension:
+ spotlight:
+ filter_by: false # hide from filter dropdown
+ segment_by: false # hide from segment-by dropdown
+ ```
+
+
+ ```yaml
+ type: model
+ name: orders
+
+ dimensions:
+ - name: internal_tracking_id
+ spotlight:
+ filter_by: false # hide from filter dropdown
+ segment_by: false # hide from segment-by dropdown
+ ```
+
+
+
+### Allowlist specific dimensions for a metric
+
+Use an array of dimension names at the metric level to create an allowlist of dimensions for that specific metric:
+
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: amount
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ filter_by:
+ - status
+ - region
+ - order_date
+ segment_by:
+ - status
+ - customer_segment
+ ```
+
+
+ ```yaml
+ models:
+ - name: orders
+ columns:
+ - name: amount
+ config:
+ meta:
+ metrics:
+ total_revenue:
+ type: sum
+ spotlight:
+ filter_by:
+ - status
+ - region
+ - order_date
+ segment_by:
+ - status
+ - customer_segment
+ ```
+
+
+ ```yaml
+ type: model
+ name: orders
+
+ dimensions:
+ - name: amount
+
+ metrics:
+ total_revenue:
+ type: sum
+ sql: ${TABLE}.amount
+ spotlight:
+ filter_by:
+ - status
+ - region
+ - order_date
+ segment_by:
+ - status
+ - customer_segment
+ ```
+
+
+
+### How it works
+
+- **Dimension-level (boolean, default `true`)**: Controls whether a dimension appears in dropdowns for all metrics in that model.
+- **Metric-level (array of dimension names)**: Creates an allowlist of dimensions for that specific metric.
+- **Metric-level allowlists override dimension-level settings**: If a dimension has `filter_by: false` but a metric includes it in its `filter_by` array, it will still be available for that metric.
+
+### Use cases
+
+- Hide internal/technical dimensions that aren't useful for analysis.
+- Curate the exploration experience per metric (e.g., revenue metrics only filterable by business dimensions).
+- Reduce clutter in models with many dimensions.
+
+## Configuring default time settings in .yml
+
+We recommend setting up default time fields to make it easier for your business users and save them time.
+
+To pre-select a time field in the explore view, simply define the default settings in your Lightdash `.yml` files.
+
+### Set a table-level default time dimension
+
+1. Create or modify your table configuration in the .yml file. For example, to set a default time dimension on the events table:
+
+
+
+ ```yml
+ models:
+ - name: events
+ columns:
+ - name: event_date
+ description: "Event date"
+ meta:
+ dimension:
+ label: "Event date"
+ type: date
+ time_intervals:
+ - DAY
+ - name: event
+ description: "Event"
+ meta:
+ dimension:
+ type: string
+ metrics:
+ count:
+ type: count
+ ```
+
+
+ ```yml
+ models:
+ - name: events
+ columns:
+ - name: event_date
+ description: "Event date"
+ config:
+ meta:
+ dimension:
+ label: "Event date"
+ type: date
+ time_intervals:
+ - DAY
+ - name: event
+ description: "Event"
+ config:
+ meta:
+ dimension:
+ type: string
+ metrics:
+ count:
+ type: count
+ ```
+
+
+ ```yml
+ type: model
+ name: events
+
+ dimensions:
+ - name: event_date
+ description: "Event date"
+ label: "Event date"
+ type: date
+ time_intervals:
+ - DAY
+ - name: event
+ description: "Event"
+ type: string
+
+ metrics:
+ count:
+ type: count
+ sql: ${TABLE}.event
+ ```
+
+
+
+2. Add the default time dimension at the table level:
+
+
+
+ ```yaml
+ models:
+ - name: events
+ meta:
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+ columns:
+ # ... your column definitions here
+ ```
+
+
+ ```yaml
+ models:
+ - name: events
+ config:
+ meta:
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+ columns:
+ # ... your column definitions here
+ ```
+
+
+ ```yaml
+ type: model
+ name: events
+
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+
+ dimensions:
+ # ... your dimension definitions here
+ ```
+
+
+
+3. [Compile your project](/references/integrations/dbt-projects)
+
+4. Navigate to the metrics catalog
+
+5. Open any metrics from the events table
+
+6. All metrics with that default time set will be plotted against the `event date` with day granularity `in the last 30 days`
+
+### Set a metric-level default time dimension
+
+This will override the time dimension defined on the table level.
+
+1. Modify your existing table configuration to add a metric-level default time dimension:
+
+
+
+ ```yaml
+ models:
+ - name: events
+ meta:
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+ columns:
+ - name: event
+ description: "Event"
+ meta:
+ metrics:
+ count:
+ type: count
+ # This will override the table level default time dimension
+ default_time_dimension:
+ field: event_date
+ interval: MONTH
+ ```
+
+
+ ```yaml
+ models:
+ - name: events
+ config:
+ meta:
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+ columns:
+ - name: event
+ description: "Event"
+ config:
+ meta:
+ metrics:
+ count:
+ type: count
+ # This will override the table level default time dimension
+ default_time_dimension:
+ field: event_date
+ interval: MONTH
+ ```
+
+
+ ```yaml
+ type: model
+ name: events
+
+ default_time_dimension:
+ field: event_date
+ interval: DAY
+
+ dimensions:
+ - name: event
+ description: "Event"
+
+ metrics:
+ count:
+ type: count
+ sql: ${TABLE}.event
+ # This will override the table level default time dimension
+ default_time_dimension:
+ field: event_date
+ interval: MONTH
+ ```
+
+
+
+2. [Compile your project](/references/integrations/dbt-projects)
+
+3. Navigate to the metrics catalog
+
+4. Explore the Events' count metric
+
+5. The metric will be plotted against the `event date` with **month** granularity, instead of the default **day** granularity applied to the table
+
+## FAQs
+
+**a. What time intervals are supported?**
+
+Currently, we only support: DAY, WEEK, MONTH, YEAR
+
+**b. What pre-filled filters are applied?**
+
+* Time grain Year -> past 3 years
+
+* Time grain Month -> past 12 months
+
+* Time grain Week -> past 12 weeks
+
+* Time grain Day -> past 30 days
+
+So if one of your business users explores a metric with a default time grain of DAY, metrics will be shown for the past 30 days with granularity of days with the default time dimension prefilled.
+
+**c. Can I pull through other metadata from my .yml files?**
+
+Not yet, but soon you'll be able to manage metadata directly in the UI and sync it back to dbt.
+
+**d. Which other metrics can I compare my selected metric by?**
+
+1. **Metrics with defaults in `.yml`:** Metrics with a default time dimension specified in the `.yml` file will always appear.
+
+2. **Metrics with a single time dimension:** Metrics from tables with only one time dimension will appear as it's assumed to be the most relevant.
+
+3. **Metrics from joined tables:** Metrics from joined tables that meet the criteria in points 1 and 2 will also appear.
+
+**e. How can I be sure that my yml changes are correct?**
+
+If you use VSCode, you can use our Lightdash schema validation to check your yml files are correct.
+
+1. Install this YAML extension for VSCode: [https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml)
+
+2. Open your user settings in JSON format and add the following:
+
+```json
+"[yaml]": {
+ "editor.defaultFormatter": "redhat.vscode-yaml"
+},
+"yaml.schemas": {
+ "https://raw.githubusercontent.com/lightdash/lightdash/refs/heads/main/packages/common/src/schemas/json/lightdash-dbt-2.0.json": [
+ "*.yml",
+ "/**/models/**/*.yml",
+ "/**/models/**/*.yaml",
+ "!lightdash.config.yml",
+ "!dbt_project.yml"
+ ],
+ "https://raw.githubusercontent.com/lightdash/lightdash/refs/heads/main/packages/common/src/schemas/json/lightdash-project-config-1.0.json": [
+ "lightdash.config.yml"
+ ]
+}
+```
+
+This will add schema validation to your model yml files and your lightdash.config.yml file.
+
+3. Reload VSCode
+
+4. You'll see a red squiggly line under any errors in your yml files as well as suggestions for how to fix them and what is allowed.
+
+
+
+## Roles and permissions
+
+| **Action** | **Project Admin** | **Project Developer** | **Project Editor** | **Project Interactive Viewer** | **Project Viewer** |
+| :---------------------------- | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: | :-------------------------------------------: |
+| Browse the 'Metrics catalog' | | | | | |
+| Add/edit /delete 'Categories' | | | | | |
+| Open the 'Metrics Explorer' | | | | | |
diff --git a/images/guides/metrics-catalog/canvas-saved-trees-dark.png b/images/guides/metrics-catalog/canvas-saved-trees-dark.png
new file mode 100644
index 00000000..7826ce27
Binary files /dev/null and b/images/guides/metrics-catalog/canvas-saved-trees-dark.png differ
diff --git a/images/guides/metrics-catalog/canvas-saved-trees.png b/images/guides/metrics-catalog/canvas-saved-trees.png
new file mode 100644
index 00000000..a9c84e70
Binary files /dev/null and b/images/guides/metrics-catalog/canvas-saved-trees.png differ