Deployed 29ece9e with MkDocs version: 1.3.1

source-matching-post-processing/index.html

@@ -286,8 +286,8 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
 
         <li class="md-nav__item">
-  <a href="#introduction-to-wca-content-source-matching-and-attribution" class="md-nav__link">
-    Introduction to WCA content source matching and attribution
+  <a href="#introduction-to-wca-content-source-matching-and-post-processing-capabilities" class="md-nav__link">
+    Introduction to WCA content source matching and post-processing capabilities
   </a>
 
 </li>
@@ -378,8 +378,8 @@
     <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix>
 
         <li class="md-nav__item">
-  <a href="#introduction-to-wca-content-source-matching-and-attribution" class="md-nav__link">
-    Introduction to WCA content source matching and attribution
+  <a href="#introduction-to-wca-content-source-matching-and-post-processing-capabilities" class="md-nav__link">
+    Introduction to WCA content source matching and post-processing capabilities
   </a>
 
 </li>
@@ -425,7 +425,7 @@ <h1 id="_1"></h1>
 <p><strong>Christopher Bienko</strong> (<em>IBM, Learning Content Development</em>) demonstrates key elements of the <code>Content Source Matching and Post-Processing</code> module. <em>[10 min]</em></p>
 </div>
 <p><br/></p>
-<h2 id="introduction-to-wca-content-source-matching-and-attribution"><strong>Introduction to WCA content source matching and attribution</strong></h2>
+<h2 id="introduction-to-wca-content-source-matching-and-post-processing-capabilities"><strong>Introduction to WCA content source matching and post-processing capabilities</strong></h2>
 <p>At this point, you should now be well acquainted with <em>Ansible Tasks</em> and <em>Playbooks</em>. Ansible Playbooks are comprised of multiple Tasks — which you have been using <em>IBM watsonx Code Assistant's</em> (<strong>WCA</strong>) generative AI capabilities to define and expand upon.</p>
 <p>If a Playbook contains multiple "tasks" that together achieve some singular goal or purpose, you might want to group these tasks into a single reusable unit. For example, a string of "tasks" might provision infrastructure for separate development, test, and production clusters from a major cloud vendor. Patterns for automating endpoints from these vendors can be codified into <strong>Ansible Modules</strong>, which are supported by Red Hat and the Ansible community writ large.</p>
 <p>And finally, collections of Playbooks and Modules can be organized into "blueprints" for automation tasks that are frequently used together to achieve some goal; a goal which you might want to make repeatable or shareable with other teams within your business. These blueprints are referred to as <strong>Ansible Roles</strong>. They provide a structured way to organize tasks, templates, files, and variables, and are available to drop directly into Ansible Playbooks. Roles make it possible to easily manage and set up complex automation tasks, essentially providing a rubric to streamline automation projects.</p>