W-24181252 Renaming Universal to Open

modules/ROOT/nav.adoc

@@ -38,7 +38,7 @@
      *** xref:exp-scanners-manage.adoc[]
      *** xref:exp-providers-manage.adoc[]
    ** xref:exp-policies-overview.adoc[]
-     *** xref:exp-policies-universal.adoc[]
+     *** xref:exp-policies-open.adoc[]
      *** xref:exp-policies-apply-manage.adoc[]
      *** xref:exp-policies-activity-log.adoc[]
      *** xref:exp-policies-provider-reference.adoc[]

modules/ROOT/pages/af-get-started.adoc

@@ -265,7 +265,7 @@ You also need these permissions:
 | Apply, edit, enable, disable, or remove policies | API Manager: Manage Policies
 |===
 
-Learn more: xref:exp-instances-add.adoc[], xref:exp-policies-apply-manage.adoc[], and xref:exp-policies-universal.adoc[].
+Learn more: xref:exp-instances-add.adoc[], xref:exp-policies-apply-manage.adoc[], and xref:exp-policies-open.adoc[].
 
 === Create Governance Strategies
 

modules/ROOT/pages/agent-fabric-overview.adoc

@@ -1,7 +1,7 @@
 = Agent Fabric Overview
 :keywords: mulesoft agent fabric, mcp server, mcp bridge, mcp connector, a2a bridge, a2a connector, agent broker, enterprise actionability, ai agents, mulesoft integration, model context protocol
 
-Teams build AI agents, MCP servers, and APIs across multiple platforms. As a result, it's challenging to easily reuse, apply consistent security controls, or track end-to-end cost. Agent Fabric is the AI control plane for that landscape. With Agent Fabric, gain visibility across every asset, let agents take action in your existing tech stack, enforce universal policies at runtime, and see and optimize what your AI investments are costing.
+Teams build AI agents, MCP servers, and APIs across multiple platforms. As a result, it's challenging to easily reuse, apply consistent security controls, or track end-to-end cost. Agent Fabric is the AI control plane for that landscape. With Agent Fabric, gain visibility across every asset, let agents take action in your existing tech stack, enforce open policies at runtime, and see and optimize what your AI investments are costing.
 
 
 [[how-agent-fabric-works]]
@@ -209,17 +209,17 @@ Use governance strategies when agents, APIs, and MCP servers must follow the sam
 
 Learn more: xref:exp-governance-work-with-strategies.adoc[]
 
-=== Universal Policies
+=== Open Policies
 
-On a multi-vendor gateway landscape, the same control is a different native policy on each platform, so gaps appear. Author the intent once with Universal Policies. MuleSoft translates it for each API gateway.
+On a multi-vendor gateway landscape, the same control is a different native policy on each platform, so gaps appear. Author the intent once with Open Policies. MuleSoft translates it for each API gateway.
 
 * Author a policy once and apply it across gateways from multiple vendors.
 * Enforce common controls such as API key enforcement, CORS, header manipulation, IP allowlisting, and JWT validation.
 * Keep the same governance as services move or scale across platforms.
 
-Use Universal Policies when you run gateways from more than one vendor and need the same controls on all of them.
+Use Open Policies when you run gateways from more than one vendor and need the same controls on all of them.
 
-Learn more: xref:exp-policies-universal.adoc[]
+Learn more: xref:exp-policies-open.adoc[]
 
 === Cross-Gateway and Third-Party API Governance
 

modules/ROOT/pages/exp-glossary.adoc

@@ -122,8 +122,8 @@ A governance control that filters or modifies tool inputs and outputs before the
 Unmanaged instance::
 A lighter-weight instance deployment that does not route traffic through Omni Gateway. Choose unmanaged instances when a full managed path does not match your operating model.
 
-Universal (canonical) policy::
-A provider-agnostic policy you configure once and apply across a mix of gateway providers. Anypoint translates a universal policy into each provider's native policy. Universal is a creation experience, not a managed entity: after you apply it, only native policies exist. Those native policies behave like any other native policy on the provider. You can edit, remove, enable, or disable them where the provider supports those actions. In the UI, universal policies carry a *Universal* badge.
+Open (canonical) policy::
+A provider-agnostic policy you configure once and apply across a mix of gateway providers. Anypoint translates an open policy into each provider's native policy. Open is a creation experience, not a managed entity: after you apply it, only native policies exist. Those native policies behave like any other native policy on the provider. You can edit, remove, enable, or disable them where the provider supports those actions. In the UI, open policies carry an *Open* badge.
 
 View-only policy::
-A discovered policy that Anypoint displays but can't create or edit, such as any policy that isn't one of the supported universal-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled.
+A discovered policy that Anypoint displays but can't create or edit, such as any policy that isn't one of the supported open-backed policies. Depending on the provider, a view-only policy can still be removed or enabled/disabled.

modules/ROOT/pages/exp-governance-policy-library-apply.adoc

@@ -1,9 +1,9 @@
-= Apply Universal Policies
-:keywords: policy library, universal policies, canonical policies, governance policies, apply policy, policy catalog
+= Apply Open Policies
+:keywords: policy library, open policies, canonical policies, governance policies, apply policy, policy catalog
 
-Governance provides two entry points for applying *universal policies*: the *Apply Policy* flow on the Governance Strategies page, and the *Policy Library* on an individual API instance. A universal policy expresses a policy once and applies it as the correct vendor-native policy on each supported gateway, so you can enforce consistent controls across MuleSoft, Google Apigee, Kong Gateway, and Azure API Management without authoring a policy per gateway.
+Governance provides two entry points for applying *open policies*: the *Apply Policy* flow on the Governance Strategies page, and the *Policy Library* on an individual API instance. An open policy expresses a policy once and applies it as the correct vendor-native policy on each supported gateway, so you can enforce consistent controls across MuleSoft, Google Apigee, Kong Gateway, and Azure API Management without authoring a policy per gateway.
 
-This topic covers both entry points and the apply flow. For the full universal policy model, the apply and management workflow, activity tracking, and per-provider support, see xref:exp-policies-overview.adoc[] and xref:exp-policies-universal.adoc[].
+This topic covers both entry points and the apply flow. For the full open policy model, the apply and management workflow, activity tracking, and per-provider support, see xref:exp-policies-overview.adoc[] and xref:exp-policies-open.adoc[].
 
 == Before You Begin
 
@@ -26,9 +26,9 @@ For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experien
 Policy write actions respect your permissions. If you don't have permission for an action, that action is unavailable and the experience explains that the action isn't permitted. If the platform can't verify your permissions for an instance, the actions remain available and the gateway enforces authorization when you submit the request. See xref:exp-policies-apply-manage.adoc[].
 ====
 
-== Browse Universal Policies
+== Browse Open Policies
 
-You can start applying a universal policy from two places:
+You can start applying an open policy from two places:
 
 * On the Governance Strategies page, select *Add Strategy*, then *Apply Policy*.
 * On an API instance, select the *Apply Policy* action to open the Policy Library.
@@ -42,7 +42,7 @@ Each policy appears with its name, category, and a short description of what it
 
 Select *All Domains* to see every policy, or *Custom* to see policies that don't fall into the preceding categories. Each filter shows the number of policies it contains.
 
-== Apply a Universal Policy
+== Apply an Open Policy
 
 The apply steps vary depending on where you start.
 
@@ -67,12 +67,12 @@ When you apply a policy, the platform validates it against your governance confi
 
 Applying a policy is an asynchronous, tracked operation, not a fire-and-forget action. When you apply a policy to more than one instance, each instance reports its own result, so you can see which instances succeeded and which failed. To confirm the outcome on each target, review the *Activity log* tab of the instance. See xref:exp-policies-activity-log.adoc[].
 
-For how universal policies map to each provider's native policy, and which policies you can then edit, enable, disable, or remove afterward, see xref:exp-policies-universal.adoc[] and xref:exp-policies-apply-manage.adoc[].
+For how open policies map to each provider's native policy, and which policies you can then edit, enable, disable, or remove afterward, see xref:exp-policies-open.adoc[] and xref:exp-policies-apply-manage.adoc[].
 
 == See Also
 
 * xref:exp-policies-overview.adoc[]
-* xref:exp-policies-universal.adoc[]
+* xref:exp-policies-open.adoc[]
 * xref:exp-policies-apply-manage.adoc[]
 * xref:exp-policies-activity-log.adoc[]
 * xref:exp-policies-provider-reference.adoc[]

modules/ROOT/pages/exp-policies-activity-log.adoc

@@ -22,7 +22,7 @@ The *Activity log* tab lists recent policy operations for the API instance. By d
 
 Each entry has these columns:
 
-* *Action*: the type of operation, such as *Apply*, *Update* (edit), *Toggle* (enable/disable), *Remove*, or *Universal* (a universal policy apply).
+* *Action*: the type of operation, such as *Apply*, *Update* (edit), *Toggle* (enable/disable), *Remove*, or *Open* (an open policy apply).
 * *Policy*: the policy the operation applies to.
 * *Status*: one of three states:
 ** *Running*
@@ -42,5 +42,5 @@ For a failed operation, open it to see why. The failure detail explains the erro
 
 * xref:exp-policies-overview.adoc[]
 * xref:exp-policies-apply-manage.adoc[]
-* xref:exp-policies-universal.adoc[]
+* xref:exp-policies-open.adoc[]
 * xref:exp-policies-provider-reference.adoc[]

modules/ROOT/pages/exp-policies-apply-manage.adoc

@@ -28,12 +28,12 @@ Button state is a hint, not the final authorization. The *Policies* tab enables
 Policy naming applies to Apigee only, where the name is the policy's unique identity on the gateway, not just a label. Choose it deliberately: the name is required at creation and you can't change it later. Other providers don't use policy names. See <<policy-naming-and-identity>>.
 . Apply the policy. Anypoint accepts the request and performs it in the background. Confirm the outcome in the *Activity log* tab. See xref:exp-policies-activity-log.adoc[].
 
-To apply a universal policy across multiple providers at once, use the *Policy Library* instead. See xref:exp-policies-universal.adoc[].
+To apply an open policy across multiple providers at once, use the *Policy Library* instead. See xref:exp-policies-open.adoc[].
 
 [[policy-edit-restrictions]]
 == Policy Edit Restrictions
 
-Having permissions is necessary but not sufficient to edit a policy. Anypoint supports editing the curated set of policies that back the universal use cases, plus several additional native Kong policies (see xref:exp-policies-universal.adoc[]); other recognized policies are view-only. Native policies created from a universal use case are editable like any other supported native policy. When *Edit Configuration* is unavailable, the UI explains why. Common reasons include:
+Having permissions is necessary but not sufficient to edit a policy. Anypoint supports editing the curated set of policies that back the open use cases, plus several additional native Kong policies (see xref:exp-policies-open.adoc[]); other recognized policies are view-only. Native policies created from an open use case are editable like any other supported native policy. When *Edit Configuration* is unavailable, the UI explains why. Common reasons include:
 
 * Anypoint doesn't recognize the policy's template, or doesn't yet support managing policies with its schema.
 * The policy's configuration doesn't match its expected schema. To resolve this issue, open a support case.
@@ -66,7 +66,7 @@ An Apigee edit that tries to change the name is rejected, because the name is th
 == See Also
 
 * xref:exp-policies-overview.adoc[]
-* xref:exp-policies-universal.adoc[]
+* xref:exp-policies-open.adoc[]
 * xref:exp-policies-activity-log.adoc[]
 * xref:exp-policies-provider-reference.adoc[]
 * xref:exp-services-view-details.adoc[]

modules/ROOT/pages/exp-policies-open.adoc

@@ -0,0 +1,68 @@
+= Open Policies
+:keywords: open policies, canonical policies, policy library, multi-provider policies, apigee, azure api management, kong, anypoint platform
+:page-aliases: exp-policies-universal.adoc
+
+An open policy is a provider-agnostic authoring experience. You configure one policy once, and Anypoint translates it into each provider's native policy and applies it across the instances you select, even a mix of Google Apigee, Azure API Management, Kong Gateway, and Anypoint instances at the same time. In the UI, open policies carry an *Open* badge, indicating that they work across all gateways.
+
+You apply open policies from the *Policy Library*, which walks you through four steps: *Select Policy*, *Configure Policy*, *Select Instances*, and *Review & Apply*.
+
+== Open Use Cases
+
+At launch, there are five open use cases. Each maps to a specific native policy per provider. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[Supported Policies and Native Equivalents]:
+
+* API Key Enforcement
+* CORS (Cross-Origin Resource Sharing)
+* Header Manipulation
+* IP Allowlist
+* JWT Validation
+
+These are the primary policies you can create and edit across providers. Anypoint also supports several additional native Kong policies. See xref:exp-policies-provider-reference.adoc#supported-policies-and-native-equivalents[Supported Policies and Native Equivalents]. Other recognized policies are view-only. See xref:exp-policies-apply-manage.adoc#policy-edit-restrictions[Policy Edit Restrictions].
+
+== Open Is a Creation Experience
+
+Use an open policy to implement a use case across multiple native gateways from a single starting point. Only native policies remain on each provider. No separate open object exists, so you can't edit or remove it.
+
+After creation, the resulting native policies behave like any other native policy on each provider. From the *Policies* tab, you can edit, remove, enable, or disable them where the provider supports those actions. There is no open object to manage separately.
+
+== Confirming What Happened
+
+Because open is only a creation experience, there is no dedicated open activity view. To see the outcome on each target, open that instance's *Activity log* tab. Open applies appear there with the *Open* action type. See xref:exp-policies-activity-log.adoc[].
+
+[NOTE]
+====
+When an open policy targets Anypoint instances, there is currently no Activity log record for those targets, so there's no in-product way to confirm the outcome on Anypoint targets. This is a known limitation. For external providers (Apigee, Azure, and Kong), you can follow the outcome in each instance's *Activity log*.
+====
+
+== Open Policies vs. Automated vs. Governance
+
+These three are easy to confuse. Use this comparison to choose the right tool:
+
+[cols="1,2,2,2",options="header"]
+|===
+| | Open Policies | Automated Policies | Governance
+
+|What it is
+|A create-only authoring experience: configure once, applied as each provider's native policy across many instances, including external providers.
+|Policies that auto-attach to any API matching a set of criteria (runtime, technology, environment, and so on), applied by rule, not to one hand-picked target.
+|Reporting and compliance only: conformance reports for an API or instance. Doesn't apply policies.
+
+|Lifecycle
+|None after creation. There's no open object to edit or delete.
+|Fully managed: create, edit, delete, and coverage changes as APIs come in and out of scope.
+|Read-only reports.
+
+|Scope
+|Multi-provider, applied to the instances you select.
+|Anypoint native (Omni and Mule), applied automatically by matching rules.
+|Across APIs and instances.
+|===
+
+For automated policies and governance strategies, see xref:exp-governance-work-with-strategies.adoc[].
+
+== See Also
+
+* xref:exp-policies-overview.adoc[]
+* xref:exp-policies-apply-manage.adoc[]
+* xref:exp-policies-activity-log.adoc[]
+* xref:exp-policies-provider-reference.adoc[]
+* xref:exp-governance-work-with-strategies.adoc[]

modules/ROOT/pages/exp-policies-overview.adoc

@@ -22,7 +22,7 @@ There are two distinct ways you interact with provider policies:
 
 == The Editability Rule
 
-Anypoint recognizes and displays every policy it discovers, but you can create and edit only a curated set: the policies that back the universal use cases, plus several additional native Kong policies. See xref:exp-policies-universal.adoc[]. Other recognized policies are view-only.
+Anypoint recognizes and displays every policy it discovers, but you can create and edit only a curated set: the policies that back the open use cases, plus several additional native Kong policies. See xref:exp-policies-open.adoc[]. Other recognized policies are view-only.
 
 You can remove, enable, and disable policies more broadly than you can edit them, so it's normal to see a policy where *Edit Configuration* is unavailable while *Remove Policy* and the enable and disable actions remain available, as long as the provider supports that action. See xref:exp-policies-apply-manage.adoc[] and xref:exp-policies-provider-reference.adoc[].
 
@@ -32,7 +32,7 @@ Every policy change on an external provider, such as apply, edit, enable, disabl
 
 == See Also
 
-* xref:exp-policies-universal.adoc[]
+* xref:exp-policies-open.adoc[]
 * xref:exp-policies-apply-manage.adoc[]
 * xref:exp-policies-activity-log.adoc[]
 * xref:exp-policies-provider-reference.adoc[]