diff --git a/4.Prevent job execution using credential with no Organization.md b/4.Prevent job execution using credential with no Organization.md
index e9ae48a..b590e15 100644
--- a/4.Prevent job execution using credential with no Organization.md	
+++ b/4.Prevent job execution using credential with no Organization.md	
@@ -1,12 +1,16 @@
-# 4.Prevent job execution using credential with no Organization
+# 4. Preventing Job Execution Using Credentials Without an Organization
 
-Ansible Automation Platform provides a robust and highly customizable RBAC system; however, no matter how much we try we are not able to meet every customer's unique need.
+## Overview
 
-For example, Ansible Automation Controller allows you to create a credential that does not belong to any organization, and can be used by any user. We have a RFE in progress that prevents the use of these global credentials in specific organizations. This is not something that our current RBAC system will allow us to do, and we cannot think of a good way to make this happen.
+Ansible Automation Platform includes a powerful RBAC system that enables robust and highly customizable control over access. However, no matter how robust and customizable our RBAC system is, there will be unique needs required by customers.
 
-With Policy as Code feature we achieve this easily.
+For example, Ansible Automation Controller allows you to create a credential that does not belong to any organization, and this credential can be assigned to used by any user. For some organizations, these global credentials that can be used by any user present a security risk or compliance concern in environments with strict boundaries.  
 
-Example policy [aap_policy_examples/global_credential_allowed_false.rego](aap_policy_examples/global_credential_allowed_false.rego):
+Currently, there is no method within our RBAC system to prevent the use of these global credentials within a specific organization, but with Policy Enforcement we can restrict access with ease.
+
+## Example Policy [aap_policy_examples/global_credential_allowed_false.rego](aap_policy_examples/global_credential_allowed_false.rego)
+
+The following policy identifies and blocks the use of credentials that do not belong to any Organization:
 
 ```rego
 package aap_policy_examples
@@ -28,7 +32,7 @@ global_credential_allowed_false := {
 }
 ```
 
-Example input:
+### Input:
 
 ```json
 {
@@ -47,7 +51,7 @@ Example input:
 }
 ```
 
-Example output:
+###  Output:
 
 ```json
 {
@@ -58,6 +62,52 @@ Example output:
 }
 ```
 
-When you apply this policy to an organization all jobs launched from that organization's inventory and job template will ERROR and prevent playbook execution.
+## Enforcement Behavior
+
+When this policy is applied to a Job Template, it prevents job execution for that organization if any unscoped (global) credentials with no ties to any organization are used.
+
+- ✅ Credentials tied to the Organization: **Allowed**  
+- 🚫 Credentials with `organization: null`: **Blocked/ERROR**
+
+Jobs using a violating credential will immediately **ERROR**, and the playbook will not run.
+
+## Try It Yourself
+
+Explore and experiment with this policy in the [Rego Playground](https://play.openpolicyagent.org/p/pN0juD8foG)!
+
+## Real World Use Case: Enforcing Credential Boundaries 
+
+### Scenario
+
+An enterprise uses Ansible Automation Platform to manage automation across multiple internal teams, each represented by a separate Organization within the platform. For example:
+
+- `Infrastructure Team`
+- `Security Team`
+- `DevOps Team`
+
+Each team operates independently, with its own credentials, inventories, and job templates. RBAC ensures users can only see resources tied to their Organization.
+
+However, during a security review, the platform team discovers that several credentials were created without an assigned Organization (`organization: null`). These global credentials are not restricted by RBAC and could be used across any Organization if referenced by a job template or workflow.
+
+To eliminate this risk, the platform engineering team enforces a Policy Enforcement rule that blocks job execution when unscoped (global) credentials are detected. This ensures that all credentials must be explicitly assigned to an Organization in order to be used in automation jobs.
+
+## Impact of Policy Enforcement in Ansible Automation Platform
+
+When the policy is applied:
+
+- 🚫 **Jobs referencing global credentials will error** – preventing unauthorized use.
+- ✅ **Jobs using credentials tied to an organization continue to run** – preserving normal automation flow for compliant configurations.
+- ✅ **Clear violation messages are surfaced** – allowing teams to quickly identify and fix unscoped credentials.
+
+This policy gives platform administrators confidence that no credential can bypass organization-level isolation, even if mistakenly created without an organization
+
+## Why This Matters
+
+- **Security** – Prevents accidental or unintended use of global credentials across boundaries that may not be privy to all organizations.
+- **Enforced Governance** – Ensures credentials are owned and managed by the appropriate teams.
+- **Audit Readiness** – Demonstrates credential ownership and scope compliance during audits.
+- **RBAC Enhancement** – Fills a critical gap not covered by Ansible Automation Platform’s built-in access control.
+
+
+
 
-Rego playground: https://play.openpolicyagent.org/p/pN0juD8foG