Bug fix

Author: v-meluri

…re-content-filters-custom-blocklists.yml …e-content-filters-custom-block-lists.ymllearn-pr/wwl-azure/secure-azure-openai-content-safety-controls/3-configure-content-filters-custom-blocklists.yml renamed to learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/3-configure-content-filters-custom-block-lists.yml learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/3-configure-content-filters-custom-blocklists.yml renamed to learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/3-configure-content-filters-custom-block-lists.yml

@@ -10,4 +10,4 @@ metadata:
   ms.topic: unit
 durationInMinutes: 18
 content: |
-  [!include[](includes/4-exercise-deploy-content-safety-controls-azure-.md)]
+  [!include[](includes/4-exercise-deploy-content-safety-controls-azure.md)]

…eploy-content-safety-controls-azure-.yml …deploy-content-safety-controls-azure.ymllearn-pr/wwl-azure/secure-azure-openai-content-safety-controls/4-exercise-deploy-content-safety-controls-azure-.yml renamed to learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/4-exercise-deploy-content-safety-controls-azure.yml learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/4-exercise-deploy-content-safety-controls-azure-.yml renamed to learn-pr/wwl-azure/secure-azure-openai-content-safety-controls/4-exercise-deploy-content-safety-controls-azure.yml

@@ -1,12 +1,12 @@
 With Azure AI Content Safety integrated into your Azure OpenAI deployment, you gain three distinct control layers: Microsoft-managed default filters, custom severity thresholds, and organization-specific blocklists. Each layer addresses different governance requirements, working together to create comprehensive content protection aligned with your business policies.
 
-Microsoft-managed default filters provide baseline protection that applies automatically to every Azure OpenAI deployment. These filters use continuously updated machine learning models that detect harmful content across all four categories without requiring configuration. You cannot disable default filters—they represent Microsoft's minimum responsible AI standards for the platform. While defaults protect against obvious policy violations, most organizations need finer control over what content their specific use cases allow. This is where custom filter thresholds and blocklists become essential.
+Microsoft-managed default filters provide baseline protection that applies automatically to every Azure OpenAI deployment. These filters use continuously updated machine learning models that detect harmful content across all four categories without requiring configuration. You can't disable default filters—they represent Microsoft's minimum responsible AI standards for the platform. While defaults protect against obvious policy violations, most organizations need finer control over what content their specific use cases allow. This is where custom filter thresholds and blocklists become essential.
 
 ## Configure custom content filter thresholds
 
 Custom filter thresholds let you adjust the strictness of content blocking for each harm category independently. Unlike default filters that apply uniform protection, custom thresholds acknowledge that different applications have different risk profiles. A healthcare chatbot might accept violence severity level 4 when discussing medical procedures, while a children's education app blocks anything above level 0. You configure these thresholds at the Azure OpenAI deployment level through the Azure portal's content filters blade.
 
-When you create a custom content filter configuration, you see four severity sliders corresponding to hate/fairness, sexual content, violence, and self-harm categories. Moving a slider to the right increases blocking sensitivity—level 0 blocks only the most severe content, while level 6 blocks nearly any reference to the category. The portal displays example content at each level, helping you understand the trade-offs between safety and functionality. For instance, setting violence to level 2 blocks graphic descriptions but allows mentions of historical conflicts or news events. Setting it to level 6 blocks even metaphorical references like "the deadline is killing me."
+When you create a custom content filter configuration, you see four severity sliders corresponding to hate/fairness, sexual content, violence, and self-harm categories. Moving a slider to the right increases blocking sensitivity—level 0 blocks only the most severe content, while level 6 blocks nearly any reference to the category. The portal displays example content at each level, helping you understand the trade-offs between safety and functionality. For instance, setting violence to level 2 blocks graphic descriptions but allows mention of historical conflicts or news events. Setting it to level 6 blocks even metaphorical references like "the deadline is killing me."
 
 At the same time, you can configure different thresholds for prompts versus completions. Some organizations apply stricter filtering to model outputs than to user inputs, reasoning that they control what the model generates but not what users submit. Others use identical settings for both directions, preferring consistent policy enforcement regardless of content origin. Your choice depends on whether you prioritize preventing users from seeing harmful content (strict output filtering) or preventing users from submitting harmful requests (strict input filtering). Most compliance-focused deployments choose the stricter of the two thresholds for both directions to minimize risk.
 
@@ -17,15 +17,15 @@ Once configured, custom filters apply immediately to new requests without requir
 
 ## Implement custom blocklists for organization-specific terms
 
-Beyond category-based severity filtering, custom blocklists provide exact-match blocking for specific terms, phrases, or patterns unique to your organization. While content filters catch broad harmful patterns, blocklists target content that violates your specific policies but might not trigger category-level detection. Common blocklist use cases include competitor brand names, internal project codenames, regulated terminology in financial or healthcare contexts, and deprecated product names that should not appear in customer-facing communications.
+Beyond category-based severity filtering, custom blocklists provide exact-match blocking for specific terms, phrases, or patterns unique to your organization. While content filters catch broad harmful patterns, blocklists target content that violates your specific policies but might not trigger category-level detection. Common blocklist use cases include competitor brand names, internal project code names, regulated terminology in financial or healthcare contexts, and deprecated product names that shouldn't appear in customer-facing communications.
 
-You create blocklists as shared resources within your Azure OpenAI account, then associate them with one or more deployments. Each blocklist supports up to 10,000 terms with exact matching or wildcard patterns. For example, adding "competitor*" blocks "CompetitorBrand," "competitor-product," and any variation containing that prefix. Blocklists operate independently from content filters—even if a prompt receives safe severity scores across all categories, blocked terms trigger immediate rejection with a 400 error response. This layered approach ensures both broad content safety and precise policy enforcement coexist.
+You create blocklists as shared resources within your Azure OpenAI account, then associate them with one or more deployments. Each blocklist supports up to 10,000 terms with exact matching or wildcard patterns. For example, adding "competitor" blocks "CompetitorBrand," "competitor-product," and any variation containing that prefix. Blocklists operate independently from content filters—even if a prompt receives safe severity scores across all categories, blocked terms trigger immediate rejection with a 400 error response. This layered approach ensures both broad content safety and precise policy enforcement coexist.
 
 :::image type="content" source="../media/create-blocklists-shared-resources.png" alt-text="Diagram showing how blocklists operate independently from content filters.":::
 
-Building on this concept, blocklists excel at preventing leakage of confidential information. Suppose your organization uses internal codenames for unreleased products or maintains lists of regulated terminology that requires special handling. Adding these terms to a blocklist ensures they never appear in Azure OpenAI responses, regardless of what prompts users submit or how models attempt to generate them. Compliance officers typically maintain these lists, updating them as new confidential projects launch or regulatory requirements change. The Azure portal supports bulk CSV import for initial blocklist population and REST API updates for programmatic lifecycle management.
+Building on this concept, blocklists excel at preventing leakage of confidential information. Suppose your organization uses internal code names for unreleased products or maintains lists of regulated terminology that requires special handling. Adding these terms to a blocklist ensures they never appear in Azure OpenAI responses, regardless of what prompts users submit or how models attempt to generate them. Compliance officers typically maintain these lists, updating them as new confidential projects launch or regulatory requirements change. The Azure portal supports bulk CSV import for initial blocklist population and REST API updates for programmatic lifecycle management.
 
-Consider what happens when both content filters and blocklists evaluate the same request. Azure AI Content Safety checks blocklists first for performance reasons—exact string matching completes faster than machine learning inference. If a prompt contains blocked terms, the service returns an error immediately without invoking category detection. If the prompt passes blocklist checks, content filters then analyze severity across all categories. This evaluation order means blocklists provide a fast-path rejection mechanism for known policy violations, reducing processing time and costs for requests that would fail anyway. Security engineers use this characteristic to optimize filtering performance when managing large-scale deployments with thousands of daily requests.
+Consider what happens when both content filters and blocklists evaluate the same request. Azure AI Content Safety check blocklists first for performance reasons—exact string matching completes faster than machine learning inference. If a prompt contains blocked terms, the service returns an error immediately without invoking category detection. If the prompt passes blocklist checks, content filters then analyze severity across all categories. This evaluation order means blocklists provide a fast-path rejection mechanism for known policy violations, reducing processing time and costs for requests that would fail anyway. Security engineers use this characteristic to optimize filtering performance when managing large-scale deployments with thousands of daily requests.
 
 ## Layer multiple protection mechanisms