diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index a8d51b0e18..e314b8dd1c 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -229,6 +229,11 @@ Inside the workflow, reference them as `{{ inputs.alert_id }}` (the reference fo
 
 Supported input types are `string`, `number`, `boolean`, `choice` (with an `options` array), and `array` (with optional `minItems` and `maxItems`). `required` defaults to `false`; provide a `default` to give optional inputs a fallback value. The legacy array-of-fields form documented here is being migrated to a JSON Schema form; both are accepted today.
 
+:::{note}
+:applies_to: stack: ga 9.5+
+A `default` value can be a Liquid expression as well as a literal. For example, `default: "{{ 'now' | date: '%Y-%m-%dT%H:%M:%SZ' }}"` resolves to the current timestamp each time the workflow runs, instead of staying the literal template string. On {{stack}} 9.3–9.4, only literal defaults resolve. A Liquid expression in `default` is passed through as-is.
+:::
+
 :::{note}
 The trigger defines *when* a workflow runs. Inputs define *what values* it accepts at runtime. A manual-triggered workflow typically has explicit inputs the user fills in. An alert-triggered workflow usually has no inputs, because the alert payload arrives as `event` automatically. You can still add inputs if you need values the alert payload doesn't carry.
 :::
diff --git a/explore-analyze/workflows/authoring-techniques/troubleshooting.md b/explore-analyze/workflows/authoring-techniques/troubleshooting.md
index a5b5848f81..11247ebc77 100644
--- a/explore-analyze/workflows/authoring-techniques/troubleshooting.md
+++ b/explore-analyze/workflows/authoring-techniques/troubleshooting.md
@@ -298,7 +298,7 @@ stack: ga 9.3-9.4
 
 **Cause.** Liquid expressions are evaluated only inside the step's `with:` block. On fields outside `with:` (including `agent-id`, `connector-id`, and `inference-id`) the engine sends the text to the runtime as-is. So `agent-id: "{{ consts.agent_id }}"` arrives at the API as the literal text `{{ consts.agent_id }}`, instead of being substituted with the value of `consts.agent_id`.
 
-**Resolution.** Use literal values in top-level fields. For `ai.agent`, drop `connector-id`. The step falls back to the space's **Default AI Connector**. Refer to [](/explore-analyze/ai-features/manage-access-to-ai-assistant.md) to configure this setting. For fields that need templating, place them inside `with:` in snake-case (for example, `conversation_id`).
+**Resolution.** Use literal values in top-level fields. For `ai.agent`, drop `connector-id`. The step falls back to the space's **Default AI Connector**. Refer to [](/explore-analyze/ai-features/manage-access-to-ai-assistant.md) to configure this setting.
 
 ```yaml
 # Not evaluated on 9.3-9.4; resolves on 9.5+
@@ -316,7 +316,7 @@ stack: ga 9.3-9.4
 ```
 
 :::{note}
-:applies_to: stack: ga 9.5
+:applies_to: stack: ga 9.5+
 Top-level field templating was fixed, so `agent-id`, `connector-id`, and `inference-id` resolve Liquid expressions like any other field. A literal value still keeps an example portable across all versions. Tracked in [elastic/security-team#17236](https://github.com/elastic/security-team/issues/17236).
 :::