diff --git a/website/docs/docs/collaborate/column-level-lineage.md b/website/docs/docs/collaborate/column-level-lineage.md
index 20aeb2c1bb3..94c1c7f1a7a 100644
--- a/website/docs/docs/collaborate/column-level-lineage.md
+++ b/website/docs/docs/collaborate/column-level-lineage.md
@@ -26,10 +26,13 @@ You can use the column evolution lineage lens to determine when a column is tran
 
 ### Inherited column descriptions
 
-A reused column, labeled as *passthrough* or *rename*, inherits its description from source and upstream model columns. In other words, source and upstream model columns propagate their descriptions downstream whenever they are not transformed, meaning you don’t need to manually define the description. Passthrough and rename columns are clearly labeled and color-coded.
+A reused column, labeled as **Passthrough** or **Rename** in the lineage, automatically inherits its description from the source and upstream model columns. The inheritance goes as far back as possible. As long as the column isn't transformed, you don't need to manually define the description; it'll automatically propagate downstream.
 
-<Lightbox src="/img/docs/collaborate/dbt-explorer/example-prop-inherit.png" width="70%" title="Example of propagate and inherit column descriptiions"/>
+Passthrough and rename columns are clearly labeled and color-coded in the lineage.
 
+In the following `dim_salesforce_accounts` model example (located at the end of the lineage), the description for a column inherited from the `stg_salesforce__accounts` model (located second to the left) indicates its origin. This helps developers quickly identify the original source of the column, making it easier to know where to make documentation changes.
+
+<Lightbox src="/img/docs/collaborate/dbt-explorer/example-prop-inherit.jpg" width="100%" title="Example of lineage with propagated and inherited column descriptions."/>
 
 ## Column-level lineage use cases {#use-cases}
 
diff --git a/website/docs/docs/use-dbt-semantic-layer/setup-sl.md b/website/docs/docs/use-dbt-semantic-layer/setup-sl.md
index 9fddb58785e..2d4c4c7b8b8 100644
--- a/website/docs/docs/use-dbt-semantic-layer/setup-sl.md
+++ b/website/docs/docs/use-dbt-semantic-layer/setup-sl.md
@@ -49,10 +49,14 @@ import SlSetUp from '/snippets/_new-sl-setup.md';
 - [Optimize querying performance](/docs/use-dbt-semantic-layer/sl-cache) using declarative caching.
 - [Validate semantic nodes in CI](/docs/deploy/ci-jobs#semantic-validations-in-ci) to ensure code changes made to dbt models don't break these metrics.
 - If you haven't already, learn how to [build you metrics and semantic models](/docs/build/build-metrics-intro) in your development tool of choice.
+- Learn about commonly asked [dbt Semantic Layer FAQs](/docs/use-dbt-semantic-layer/sl-faqs).
 
-## Related docs
+## FAQs
 
-- [Build your metrics](/docs/build/build-metrics-intro)
-- [Semantic Layer APIs](/docs/dbt-cloud-apis/sl-api-overview)
-- [Get started with the dbt Semantic Layer](/guides/sl-snowflake-qs)
-- [dbt Semantic Layer FAQs](/docs/use-dbt-semantic-layer/sl-faqs)
+<detailsToggle alt_header="How does caching interact with access controls?">
+
+Cached data is stored separately from the underlying models. If metrics are pulled from the cache, we don’t have the security context applied to those tables at query time.
+
+In the future, we plan to clone credentials, identify the minimum access level needed, and apply those permissions to cached tables.
+
+</detailsToggle>
diff --git a/website/docs/docs/use-dbt-semantic-layer/sl-cache.md b/website/docs/docs/use-dbt-semantic-layer/sl-cache.md
index 5f1460b07f5..49af039bc4c 100644
--- a/website/docs/docs/use-dbt-semantic-layer/sl-cache.md
+++ b/website/docs/docs/use-dbt-semantic-layer/sl-cache.md
@@ -132,6 +132,16 @@ If an upstream model has data in it that was created after the cache was created
 
 You can manually invalidate the cache through the [dbt Semantic Layer APIs](/docs/dbt-cloud-apis/sl-api-overview) using the `InvalidateCacheResult` field.
 
+## FAQs
+
+<detailsToggle alt_header="How does caching interact with access controls?">
+
+Cached data is stored separately from the underlying models. If metrics are pulled from the cache, we don’t have the security context applied to those tables at query time.
+
+In the future, we plan to clone credentials, identify the minimum access level needed, and apply those permissions to cached tables.
+
+</detailsToggle>
+
 
 ## Related docs
 - [Validate semantic nodes in CI](/docs/deploy/ci-jobs#semantic-validations-in-ci)
diff --git a/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.jpg b/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.jpg
new file mode 100644
index 00000000000..425725f1149
Binary files /dev/null and b/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.jpg differ
diff --git a/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.png b/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.png
deleted file mode 100644
index 696ef5b9eb1..00000000000
Binary files a/website/static/img/docs/collaborate/dbt-explorer/example-prop-inherit.png and /dev/null differ