Merge branch 'current' into psycopg2-installation

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}
 

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>

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)