ansible · g-murray · Jul 24, 2025 · Jul 24, 2025 · Jul 24, 2025 · Jul 25, 2025
diff --git a/bin/sync_docs.sh b/bin/sync_docs.sh
@@ -0,0 +1,19 @@
+#!/bin/bash
+
+######
+# This script synchronizes content to the downstream repository.
+# A Jenkins job configures the source and target repositories and runs this script directly.
+# If you commit changes to this script you should verify the Jenkins job runs successfully.
+######
+
+# Set the path to the source and target directories.
+# The source directory contains the content that you want to synchronize.
+source=source
+# The target directory is the location where you want to synchronize content.
+target=target
+
+# Clean the existing downstream and release-note folders.
+rm -rf $target/downstream
+
+# Copy the content of the downstream and release-note folders.
+cp -r $source/downstream $target/downstream
diff --git a/bin/sync_ocp_latest.sh b/bin/sync_ocp_latest.sh
@@ -0,0 +1,13 @@
+#!/bin/bash
+
+# Set the path to the file that contains the ":OCPLatest:" attribute.
+attributes=../downstream/attributes/attributes.adoc
+
+# Retrieve the OCP attributes file from the OpenShift docs repository.
+curl https://raw.githubusercontent.com/openshift/openshift-docs/main/_attributes/ocp-attributes.adoc -o ocp-attributes.adoc
+# Save the value of the "product-version" attribute as a variable.
+ocpversion=$(sed -n -e 's/^:product-version: //p' ocp-attributes.adoc)
+# Replace the value of the "OCPLatest" attribute with the value of the "product-version" attribute.
+sed -i -e "s/^:OCPLatest:.*/:OCPLatest: $ocpversion/" $attributes
+# Delete the OCP attributes file.
+rm -f ocp-attributes.adoc
diff --git a/downstream/aap-common/apache-2.0-license.adoc b/downstream/aap-common/apache-2.0-license.adoc
@@ -4,7 +4,7 @@
 
 = Open Source license
 
-.Apache license
+*Apache license*
 
 Version 2.0, January 2004
 

diff --git a/downstream/aap-common/assembly-aap-common.adoc b/downstream/aap-common/assembly-aap-common.adoc
@@ -1,3 +1,5 @@
+:_mod-docs-content-type: ASSEMBLY
+
 ifdef::context[:parent-context: {context}]
 [preface]
 [id='ansible-automation-platform']

diff --git a/downstream/aap-common/gplv3-license-text.adoc b/downstream/aap-common/gplv3-license-text.adoc
diff --git a/...eam/archive/archived-assemblies/builder/assembly-definition-file-breakdown.adoc b/...eam/archive/archived-assemblies/builder/assembly-definition-file-breakdown.adoc
@@ -19,4 +19,4 @@ include::builder/con-additional-custom-build-steps.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* For example definition files for common scenarios, see the link:https://ansible.readthedocs.io/projects/builder/en/latest/scenario_guides/scenario_copy/[Common scenarios section] of the _Ansible Builder Documentation_
+* link:https://ansible.readthedocs.io/projects/builder/en/latest/scenario_guides/scenario_copy/[Common scenarios section]
diff --git a/...am/archive/archived-assemblies/dev-guide/assembly-migrate-ansible-versions.adoc b/...am/archive/archived-assemblies/dev-guide/assembly-migrate-ansible-versions.adoc
@@ -22,8 +22,8 @@ The Ansible _Porting Guide_ is a series of documents that provide information on
 [role="_additional-resources"]
 == Additional resources
 
-* Refer to the link:https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.9.html#ansible-2-9-porting-guide[Ansible 2.9] for behavior changes between Ansible 2.8 and Ansible 2.9.
-* Refer to the link:https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.10.html[Ansible 2.10] for behavior changes between Ansible 2.9 and Ansible 2.10.
+* link:https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.9.html#ansible-2-9-porting-guide[Ansible 2.9]
+* link:https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_2.10.html[Ansible 2.10]
 
 
 ifdef::parent-context[:context: {parent-context}]

diff --git a/downstream/archive/archived-assemblies/dev-guide/assembly-tools-components.adoc b/downstream/archive/archived-assemblies/dev-guide/assembly-tools-components.adoc
@@ -28,8 +28,8 @@ include::core/con-about-ansible-cli.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* For more information on how to use Ansible as a command line tool, refer to link:https://docs.ansible.com/ansible/latest/command_guide/command_line_tools.html[Working with command line tools] in the Ansible _User Guide_.
-* To upload content to {HubName}, see link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html/getting_started_with_automation_hub/uploading-content-hub[Uploading content to automation hub] in the {PlatformNameShort} product documentation.
+* link:https://docs.ansible.com/ansible/latest/command_guide/command_line_tools.html[Working with command line tools]
+* link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html/getting_started_with_automation_hub/uploading-content-hub[Uploading content to automation hub]
 
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/...ive/archived-assemblies/platform/assembly-supported-installation-scenarios.adoc b/...ive/archived-assemblies/platform/assembly-supported-installation-scenarios.adoc
@@ -4,8 +4,6 @@
 
 Red Hat supports the following installations scenarios for {PlatformName}:
 
-[role="_additional-resources"]
-.Additional resources
 To edit inventory file parameters to specify a supported installation scenario, see link:{BaseURL}/red_hat_ansible_automation_platform/{PlatformVers}/html/red_hat_ansible_automation_platform_installation_guide/assembly-platform-install-scenario#con-install-scenario-examples[Inventory file examples based on installation scenarios] in the _{PlatformName} Installation Guide_.
 
 //[dcd 12/8/2022 Removing links until new guides are published because some topics were removed and others were added.]

diff --git a/...ived-assemblies/platform/assembly-using-rhsso-operator-with-automation-hub.adoc b/...ived-assemblies/platform/assembly-using-rhsso-operator-with-automation-hub.adoc
@@ -35,9 +35,10 @@ include::platform/proc-installing-hub-using-operator.adoc[leveloffset=2]
 include::platform/proc-determine-hub-route.adoc[leveloffset=2]
 include::platform/proc-update-rhsso-client.adoc[leveloffset=2]
 
+[role="_additional-resources"]
 == Additional resources
 
-* For more information on running operators on {OCPShort}, see link:{BaseURL}/openshift_container_platform/{OCPLatest}/html/operators/index[Working with Operators in {OCPShort}] in the {OCPShort} product documentation.
+*  link:{BaseURL}/openshift_container_platform/{OCPLatest}/html/operators/index[Working with Operators in {OCPShort}]
 
 
 ifdef::parent-context[:context: {parent-context}]

diff --git a/...ream/archive/archived-modules/aap-hardening/ref-complex-patching-scenarios.adoc b/...ream/archive/archived-modules/aap-hardening/ref-complex-patching-scenarios.adoc
@@ -17,5 +17,7 @@ The following workflow visualization shows how the components of the example com
 
 image:workflow.png[Workflow representation]
 
+[role="_additional-resources"]
 .Additional resources
-For more information on workflows, see link:{URLControllerUserGuide}/controller-workflows[Workflows in automation controller].
+
+* link:{URLControllerUserGuide}/controller-workflows[Workflows in automation controller]
diff --git a/downstream/archive/archived-modules/builder/con-ansible-config-file-path.adoc b/downstream/archive/archived-modules/builder/con-ansible-config-file-path.adoc
@@ -1,6 +1,7 @@
 [id="con-ansible-config-file-path"]
 
 = Ansible config file path
+
 The `ansible_config` directive allows specifying the path to an `ansible.cfg` file to pass a token and other settings for a private account to an {HubName} server during the Collection installation stage of the build. The config file path should be relative to the definition file location, and will be copied to the generated container build context.
 
 The `ansible.cfg` file should be formatted like the following example:

diff --git a/downstream/archive/archived-modules/devtools/proc-create-molecule-scenario.adoc b/downstream/archive/archived-modules/devtools/proc-create-molecule-scenario.adoc
@@ -4,6 +4,10 @@
 
 [role="_abstract"]
 
+You can use this procedure to create a Molecule scenario for testing an Ansible playbook. The `molecule init scenario` command creates a `default/` scenario directory, which you must then rename to correspond with the playbook.
+
+.Procedure
+
 . Navigate to the top level directory of your playbook project.
 . Initialize a Molecule scenario:
 +
@@ -51,7 +55,7 @@ molecule
     └── molecule.yml
 ----
 
-== Creating scenarios for every playbook
+.Next Steps
 
 Create a separate scenario for every playbook in your project. 
 

diff --git a/downstream/archive/archived-modules/devtools/proc-rhdh-add-additional-scm.adoc b/downstream/archive/archived-modules/devtools/proc-rhdh-add-additional-scm.adoc
@@ -12,9 +12,9 @@ Follow the procedure below to add support for additional Source Control Manageme
 . In your repository, update the `enum` and `enumNames` keys with the SCM values.
 . Update the software template `action` to match your SCM type.
 . Register the forked repository with your customized templates in {RHDH}.
-
++
 For example, if you wanted to add GitLab as an SCM, your software template file would look similar to the following: 
-
++
 ----
 ...
 spec:
@@ -35,8 +35,8 @@ spec:
 
 ----
 
-Under the `steps` section, use the appropriate action for your SCM:
-
+. Under the `steps` section, use the appropriate action for your SCM:
++
 ----
   steps:
   ...

diff --git a/...s/proc-devtools-run-roles-collection.adoc → ...ls/ref-devtools-run-roles-collection.adoc b/...s/proc-devtools-run-roles-collection.adoc → ...ls/ref-devtools-run-roles-collection.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: REFERENCE
 
 [id="devtools-run-roles-collection_{context}"]
 = Running and testing your collection

diff --git a/downstream/archive/archived-modules/eda/proc-eda-set-up-token.adoc b/downstream/archive/archived-modules/eda/proc-eda-set-up-token.adoc
@@ -28,4 +28,5 @@ The token must be in write-scope.
 ====
 . Select btn:[Create controller token].
 
+.Results
 After saving the new token, you are brought to the *Controller Tokens* tab where you can delete the token.
diff --git a/downstream/archive/archived-modules/platform/proc-aap-controller-yaml-restore.adoc b/downstream/archive/archived-modules/platform/proc-aap-controller-yaml-restore.adoc
@@ -1,6 +1,7 @@
 [id="aap-controller-yaml-restore"]
 
 = Using YAML to recover the {ControllerNameStart} deployment
+
 See the following procedure for how to restore a deployment of the {ControllerName} using YAML. 
 
 .Prerequisite

diff --git a/downstream/archive/archived-modules/platform/proc-controller-host-metrics.adoc b/downstream/archive/archived-modules/platform/proc-controller-host-metrics.adoc
@@ -1,6 +1,7 @@
 [id="proc-controller-host-metrics"]
 
 = Host Metrics
+
 //[ddacosta] I don't see a Host Metrics menu selection off the standalone navigation panel. Should it be Resources > Hosts? If so, add replace with {MenuInfrastructureHosts}
 //[ddacosta] For 2.5 Host Metrics is off the Analytics menu. Use {MenuAAHostMetrics}
 * From the navigation panel, select menu:Host Metrics[] to see the activity associated with hosts, which includes counts on those that have been automated, used in inventories, and deleted.

diff --git a/downstream/archive/archived-modules/platform/proc-creating-a-secret.adoc b/downstream/archive/archived-modules/platform/proc-creating-a-secret.adoc
@@ -1,6 +1,7 @@
 [id="proc-creating-a-secret_{context}"]
 
 = Creating a {RHSSO} connection secret
+
 Use this procedure to create a connection secret for {RHSSO}.
 
 .Procedure

diff --git a/...tream/archive/archived-modules/platform/proc-creating-controller-form-view.adoc b/...tream/archive/archived-modules/platform/proc-creating-controller-form-view.adoc
@@ -1,6 +1,7 @@
 [id="proc_creating-controller-form-view_{context}"]
 
 = Creating your {ControllerName} form-view
+
 Use this procedure to create your {ControllerName} using the form-view.
 
 .Procedure

diff --git a/downstream/titles/updating-aap/docinfo.xml → .../archived-titles/updating-aap/docinfo.xml b/downstream/titles/updating-aap/docinfo.xml → .../archived-titles/updating-aap/docinfo.xml
diff --git a/downstream/titles/updating-aap/master.adoc → .../archived-titles/updating-aap/master.adoc b/downstream/titles/updating-aap/master.adoc → .../archived-titles/updating-aap/master.adoc
@@ -21,4 +21,4 @@ Upgrades from 2.4 to 2.5 are unsupported at this time. For more information, see
 
 include::platform/assembly-update-rpm.adoc[leveloffset=+1]
 include::platform/assembly-update-container.adoc[leveloffset=+1]
-// [hherbly]: moved to Installing on OCP guide per AAP-34122 include::platform/assembly-update-ocp.adoc[leveloffset=+1]
+// [hherbly]: moved to Installing on OCP guide per AAP-34122 include::platform/assembly-update-ocp.adoc[leveloffset=+1]
diff --git a/downstream/assemblies/aap-migration/assembly-migration-artifact.adoc b/downstream/assemblies/aap-migration/assembly-migration-artifact.adoc
@@ -3,6 +3,7 @@
 [id="migration-artifact"]
 = Migration artifact structure and verification
 
+[role="_abstract"]
 The migration artifact is a critical component for successfully transferring your {PlatformNameShort} deployment. It packages all necessary data and configurations from your source environment.
 
 This section details the structure of the migration artifact and includes a migration checklist for artifact verification.

diff --git a/downstream/assemblies/aap-migration/assembly-migration-prerequisites.adoc b/downstream/assemblies/aap-migration/assembly-migration-prerequisites.adoc
@@ -3,6 +3,7 @@
 [id="migration-prerequisites"]
 = Migration prerequisites 
 
+[role="_abstract"]
 Prerequisites for migrating your {PlatformNameShort} deployment. For your specific migration path, ensure that you meet all necessary conditions before proceeding.
 
 include::aap-migration/con-rpm-to-containerized-prerequisites.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/aap-migration/assembly-source-containerized.adoc b/downstream/assemblies/aap-migration/assembly-source-containerized.adoc
@@ -3,6 +3,7 @@
 [id="source-containerized"]
 = Container-based {PlatformNameShort}
 
+[role="_abstract"]
 Prepare and export data from your container-based {PlatformNameShort} deployment.
 
 include::aap-migration/proc-containerized-source-environment-preparation-assessment.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/aap-migration/assembly-source-rpm.adoc b/downstream/assemblies/aap-migration/assembly-source-rpm.adoc
@@ -3,6 +3,7 @@
 [id="source-rpm"]
 = RPM-based {PlatformNameShort}
 
+[role="_abstract"]
 Prepare and export data from your RPM-based {PlatformNameShort} deployment.
 
 include::aap-migration/proc-rpm-environment-source-prep.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/aap-migration/assembly-target-containerized.adoc b/downstream/assemblies/aap-migration/assembly-target-containerized.adoc
@@ -3,6 +3,7 @@
 [id="target-containerized"]
 = Container-based {PlatformNameShort}
 
+[role="_abstract"]
 Prepare and assess your target container-based {PlatformNameShort} environment, and import and reconcile your migrated content.
 
 include::aap-migration/proc-containerized-target-prep.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/aap-migration/assembly-target-managed-aap.adoc b/downstream/assemblies/aap-migration/assembly-target-managed-aap.adoc
@@ -3,6 +3,7 @@
 [id="target-managed-aap"]
 = Managed {PlatformNameShort}
 
+[role="_abstract"]
 Prepare and migrate your source environment to a Managed {PlatformNameShort} deployment, and reconcile the target environment post-migration.
 
 include::aap-migration/proc-managed-target-migration.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/aap-migration/assembly-target-ocp.adoc b/downstream/assemblies/aap-migration/assembly-target-ocp.adoc
@@ -3,6 +3,7 @@
 [id="target-ocp"]
 = {OCPShort}
 
+[role="_abstract"]
 Prepare and assess your target {OCPShort} environment, and import and reconcile your migrated content.
 
 include::aap-migration/proc-ocp-target-prep.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/devtools/assembly-devtools-create-roles-collection.adoc b/downstream/assemblies/devtools/assembly-devtools-create-roles-collection.adoc
@@ -42,7 +42,7 @@ include::devtools/proc-devtools-create-new-role-in-collection.adoc[leveloffset=+
 
 include::devtools/proc-devtools-docs-roles-collection.adoc[leveloffset=+1]
 
-// include::devtools/proc-devtools-run-roles-collection.adoc[leveloffset=+1]
+// include::devtools/ref-devtools-run-roles-collection.adoc[leveloffset=+1]
 
 // include::devtools/proc-devtools-molecule-test-roles-collection.adoc[leveloffset=+1]
 

diff --git a/downstream/assemblies/devtools/assembly-devtools-extension-set-language.adoc b/downstream/assemblies/devtools/assembly-devtools-extension-set-language.adoc
@@ -0,0 +1,21 @@
+ifdef::context[:parent-context-of-assembly-devtools-install: {context}]
+:_mod-docs-content-type: ASSEMBLY
+[id="extension-set-language"]
+
+= Manually adding the Ansible language to YAML files
+
+[role="_abstract"]
+
+The Ansible {VSCode} extension works only when the language associated with a file is set to Ansible.
+The extension provides features that help create Ansible playbooks, such as auto-completion, hover, and diagnostics.
+
+The Ansible {VSCode} extension automatically associates the Ansible language with some files.
+The procedures below describe how to set the language for files that are not recognized as Ansible files.
+
+include::devtools/proc-devtools-extension-set-language.adoc[leveloffset=+1]
+
+include::devtools/proc-devtools-extension-set-persistant-file.adoc[leveloffset=+1]
+
+
+ifdef::parent-context-of-assembly-devtools-install[:context: {parent-context-of-assembly-devtools-install}]
+ifndef::parent-context-of-assembly-devtools-install[:!context:]
diff --git a/downstream/assemblies/devtools/assembly-devtools-install.adoc b/downstream/assemblies/devtools/assembly-devtools-install.adoc
@@ -31,7 +31,7 @@ include::devtools/proc-devtools-install-vscode-extension.adoc[leveloffset=+2]
 
 include::devtools/proc-devtools-extension-settings.adoc[leveloffset=+2]
 
-include::devtools/proc-devtools-extension-set-language.adoc[leveloffset=+2]
+include::assembly-devtools-extension-set-language.adoc[leveloffset=+2]
 
 include::devtools/proc-devtools-ms-dev-containers-ext.adoc[leveloffset=+2]
 

diff --git a/downstream/assemblies/devtools/assembly-rhdh-subscription-warnings.adoc b/downstream/assemblies/devtools/assembly-rhdh-subscription-warnings.adoc
@@ -7,13 +7,13 @@ ifdef::context[:parent-context-of-rhdh-subscription-warnings: {context}]
 :context: rhdh-subscription-warnings
 
 [role="_abstract"]
-The Ansible plug-ins display a subscription warning banner in the user interface in the following scenarios:
+The {AAPRHDHShort} display a subscription warning banner in the user interface in the following scenarios:
 
-* xref:rhdh-warning-unable-connect-aap_rhdh-subscription-warnings[Unable to connect to Ansible Automation Platform]
-* xref:rhdh-warning-unable-authenticate-aap_rhdh-subscription-warnings[Unable to authenticate to Ansible Automation Platform]
-* xref:rhdh-warning-invalid-aap-config_rhdh-subscription-warnings[Invalid Ansible Automation Platform configuration]
-* xref:rhdh-warning-aap-ooc_rhdh-subscription-warnings[Ansible Automation Platform subscription is out of compliance]
-* xref:rhdh-warning-invalid-aap-subscription_rhdh-subscription-warnings[Invalid Ansible Automation Platform subscription]
+* link:{URLPluginRHDHInstall}/rhdh-subscription-warnings_aap-plugin-rhdh-installing#rhdh-warning-unable-connect-aap_rhdh-subscription-warnings[Unable to connect to Ansible Automation Platform]
+* link:{URLPluginRHDHInstall}/rhdh-subscription-warnings_aap-plugin-rhdh-installing#rhdh-warning-unable-authenticate-aap_rhdh-subscription-warnings[Unable to authenticate to Ansible Automation Platform]
+* link:{URLPluginRHDHInstall}/rhdh-subscription-warnings_aap-plugin-rhdh-installing#rhdh-warning-invalid-aap-config_rhdh-subscription-warnings[Invalid Ansible Automation Platform configuration]
+* link:{URLPluginRHDHInstall}/rhdh-subscription-warnings_aap-plugin-rhdh-installing#rhdh-warning-aap-ooc_rhdh-subscription-warnings[Ansible Automation Platform subscription is out of compliance]
+* link:{URLPluginRHDHInstall}/rhdh-subscription-warnings_aap-plugin-rhdh-installing#rhdh-warning-invalid-aap-subscription_rhdh-subscription-warnings[Invalid Ansible Automation Platform subscription]
 
 include::devtools/proc-rhdh-warning-unable-connect-aap.adoc[leveloffset=+1]
 

diff --git a/downstream/assemblies/eda/assembly-eda-credential-types.adoc b/downstream/assemblies/eda/assembly-eda-credential-types.adoc
@@ -3,14 +3,15 @@
 
 = Credential types
 
-{EDAcontroller} comes with several built-in credental types that you can use for syncing projects, running rulebook activations, executing job templates through {MenuTopAE} ({ControllerName}), fetching images from container registries, and processing data through event streams. 
+{EDAcontroller} comes with several built-in credential types that you can use for syncing projects, running rulebook activations, executing job templates through {MenuTopAE} ({ControllerName}), fetching images from container registries, and processing data through event streams. 
 
-These built-in credential types are not editable. So if you want credential types that support authentication with other systems, you can create your own credential types that can be used in your source plugins. Each credential type contains an input configuration and an injector configuration that can be passed to an Ansible rulebook to configure your sources.
+These built-in credential types are not editable. So if you want credential types that support authentication with other systems, you can create your own credential types that can be used in your source plugins. Each credential type contains an input configuration and an injector configuration that can be passed to an Ansible rulebook to configure your sources. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_decisions/eda-credential-types#eda-custom-credential-types[Custom credential types].
 
-For more information, see xref:eda-custom-credential-types[Custom credential types].
-//[J. Self] Will add the cross-reference/link later. 
+If you will be executing job templates through {ControllerName}, you can retrieve credential values from external secret management systems listed in link:https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_decisions/eda-credential-types#eda-external-credential-types[External secret management credential types].
 
 
+include::eda/con-external-credential-types.adoc[leveloffset=+1]
+
 include::eda/con-custom-credential-types.adoc[leveloffset=+1]
 
 include::eda/con-credential-types-input-config.adoc[leveloffset=+2]

diff --git a/downstream/assemblies/eda/assembly-eda-decision-environments.adoc b/downstream/assemblies/eda/assembly-eda-decision-environments.adoc
@@ -6,7 +6,7 @@ Decision environments are container images that run Ansible rulebooks.
 They create a common language for communicating automation dependencies, and give a standard way to build and distribute the automation environment.
 You can find the default decision environment in the link:https://quay.io/repository/ansible/ansible-rulebook[Ansible-Rulebook]. 
 
-To create your own decision environment, see xref:eda-controller-install-builder[Installing ansible-builder] and xref:eda-build-a-custom-decision-environment[Building a custom decision environment for Event-Driven Ansible within Ansible Automation Platform].
+To create your own decision environment, see link:https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_decisions/eda-decision-environments#eda-controller-install-builder[Installing ansible-builder] and link:https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5/html/using_automation_decisions/eda-decision-environments#eda-build-a-custom-decision-environment[Building a custom decision environment for Event-Driven Ansible within Ansible Automation Platform].
 
 include::eda/ref-eda-controller-install-builder.adoc[leveloffset=+1]
 include::eda/proc-eda-build-a-custom-decision-environment.adoc[leveloffset=+1]

diff --git a/downstream/assemblies/eda/assembly-eda-event-filter-plugins.adoc b/downstream/assemblies/eda/assembly-eda-event-filter-plugins.adoc
@@ -22,7 +22,8 @@ You can chain event filters one after the other, and the updated data is sent fr
 Event filters are defined in the rulebook after a source is defined.
 When the rulebook starts the source plugin it associates the correct filters and transforms the data before putting it into the queue.
 
-.Example
+[Example]
+====
 
 ----
 sources:
@@ -45,5 +46,6 @@ Since every event should record the origin of the event the filter `eda.builtin.
 The `received_at` stores a date time in UTC ISO8601 format and includes the microseconds.
 The `uuid` stores the unique id for the event.
 The `meta key` is used to store metadata about the event and its needed to correctly report about the events in the aap-server.
+====
 
 include::eda/con-eda-author-event-filters.adoc[leveloffset=+1]