diff --git a/modules/ROOT/images/omni-pillars.png b/modules/ROOT/images/omni-pillars.png
new file mode 100644
index 00000000..31520df6
Binary files /dev/null and b/modules/ROOT/images/omni-pillars.png differ
diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
index 1201163b..45202f9d 100644
--- a/modules/ROOT/nav.adoc
+++ b/modules/ROOT/nav.adoc
@@ -1,5 +1,26 @@
 .xref:index.adoc[Anypoint Platform]
 * xref:index.adoc[Documentation]
+* xref:learning-map-omni.adoc[Enhanced MuleSoft Experience]
+  ** xref:omni-overview.adoc[Overview]
+    *** xref:omni-compare.adoc[Enhanced Experience and Anypoint Platform Comparison]
+  ** xref:omni-start-home.adoc[]
+  ** xref:omni-view-portfolio-overview.adoc[]
+  ** xref:omni-add-services-to-portfolio.adoc[]
+    *** xref:omni-connect-providers-to-add-services.adoc[]
+    *** xref:omni-register-services-manually.adoc[]
+    *** xref:omni-create-mcp-server.adoc[]
+    *** xref:omni-add-semantic-services.adoc[]
+    *** xref:omni-view-service-details.adoc[]
+  ** xref:omni-add-scanners-from-providers.adoc[]
+    *** xref:omni-manage-scanners.adoc[] 
+  ** xref:omni-add-instances.adoc[]
+  ** xref:omni-create-governance-strategies.adoc[]
+  ** xref:omni-view-token-usage-response-performance.adoc[]
+  ** xref:omni-monitor-your-services.adoc[]
+  ** xref:omni-view-detailed-metrics-for-services.adoc[]
+  ** xref:omni-configure-notifications-for-alerts.adoc[]
+  ** xref:omni-access-experience-from-slack.adoc[]
+  ** xref:omni-connect-experience-to-claude-desktop.adoc[]
 * xref:learning-map-mulesoft-ai.adoc[]
 * xref:learning-map-agent-fabric.adoc[Agent Fabric]
   ** xref:agent-fabric-release-notes.adoc[]
diff --git a/modules/ROOT/pages/learning-map-omni.adoc b/modules/ROOT/pages/learning-map-omni.adoc
new file mode 100644
index 00000000..24ad9dba
--- /dev/null
+++ b/modules/ROOT/pages/learning-map-omni.adoc
@@ -0,0 +1,82 @@
+= Enhanced MuleSoft Experience
+:page-article-style: learning-map
+
+The enhanced MuleSoft experience helps you manage, optimize, and govern a multi-agent ecosystem from one place. Work with agents, APIs, MCP servers, LLMs, and gateways as a single portfolio. View asset relationships, apply governance and cost discipline, and act on observability signals instead of working in separate silos. The experience pairs this portfolio view with an in-product assistant to connect integrations, tune configurations, and get answers in context.
+
+* Register agents, MCP servers, and LLM proxies from any provider or registry.
+* Monitor latency, cost, invocations, and failures in real time.
+* Secure instances with compatible policies across your entire registry.
+* Transcode existing REST APIs into MCP servers instantly.
+
+image::omni-pillars.png[]
+
+The end-to-end journey for the experience consists of these tasks, each with links to relevant content to assist you in completing them.
+
+[.lm-table, cols="1a,1a,1a", grid="none"]
+|===
+| image::lm_start.png[]
+[.lm-bold]##Learn About Enhanced MuleSoft Experience##
+
+The experience helps you manage, optimize, and govern a multi-agent ecosystem from one place.
+
+//- ToDo [Video]
+//- ToDo [Trailhead]
+- xref:omni-overview.adoc[]
+- xref:omni-compare.adoc[]
+- xref:omni-start-home.adoc[]
+- xref:omni-access-experience-from-slack.adoc[]
+- xref:omni-connect-experience-to-claude-desktop.adoc[]
+
+
+| image::lm_explore_1.png[]
+[.lm-bold]##Register##
+
+Register agents, APIs, and MCP servers from any provider or registry, and add LLM proxies and gateways.
+
+- xref:omni-add-services-to-portfolio.adoc[]
+- xref:omni-connect-providers-to-add-services.adoc[]
+- xref:omni-register-services-manually.adoc[]
+- xref:omni-create-mcp-server.adoc[]
+- xref:omni-add-semantic-services.adoc[]
+- xref:omni-view-service-details.adoc[]
+- xref:omni-add-scanners-from-providers.adoc[]
+
+
+
+| image::lm_build_1.png[]
+[.lm-bold]##Monitor##
+
+Monitor latency, cost, invocations, and failures in real time.
+
+- xref:omni-monitor-your-services.adoc[]
+- xref:omni-view-token-usage-response-performance.adoc[]
+- xref:omni-view-detailed-metrics-for-services.adoc[]
+- xref:omni-configure-notifications-for-alerts.adoc[]
+
+|===
+
+[.lm-table, cols="1a,1a", width="66%", grid="none"]
+|===
+| image::lm_build_1.png[]
+[.lm-bold]##Secure##
+
+Secure instances with compatible policies across your entire registry.
+
+- xref:omni-add-instances.adoc[]
+- xref:omni-create-governance-strategies.adoc[]
+
+| image::lm_analyze_1.png[]
+[.lm-bold]##Transcode##
+
+Transcode existing REST APIs into MCP servers instantly.
+
+- xref:omni-create-mcp-server.adoc[]
+
+
+|===
+
+
+== See Also
+
+* xref:omni-start-home.adoc[]
+* xref:omni-compare.adoc[]
diff --git a/modules/ROOT/pages/omni-access-experience-from-slack.adoc b/modules/ROOT/pages/omni-access-experience-from-slack.adoc
new file mode 100644
index 00000000..0b526b97
--- /dev/null
+++ b/modules/ROOT/pages/omni-access-experience-from-slack.adoc
@@ -0,0 +1,24 @@
+= Access the Enhanced Experience from Slack
+
+When your administrator installs and configures the Slack integration, you can receive notifications, run shortcuts, and open deep links that land in the enhanced MuleSoft experience with your existing identity. Slack becomes a companion surface for alerts and collaboration while *Portfolio* and *Governance* remain the source of truth for configuration.
+
+Available commands, message templates, and workspaces depend entirely on how your organization wired the Slack app. Internal runbooks should list the slash commands or shortcuts approved for your workspace.
+
+== Sign In and Open the Experience
+
+. Open Slack in the workspace your company uses for MuleSoft or platform notifications.
+. Use the app your administrator added (the display name is set during installation).
+. Follow a notification action, a pinned link, or a slash command your internal documentation describes to authenticate and open the enhanced experience in the browser or embedded client your organization chose.
+
+If authentication fails, confirm you are in the correct Slack workspace and that your Anypoint user is linked according to your IT team's instructions.
+
+== Common Tasks from Slack
+
+* **Respond to alerts** — Open a thread from an alert message and follow the link into the service or dashboard referenced in the payload.
+* **Share context** — Post links back into Slack after you verify state in *Portfolio* so incident channels stay aligned with what you saw in the product.
+
+== See Also
+
+* xref:omni-start-home.adoc[]
+* xref:omni-overview.adoc[]
+* xref:omni-connect-experience-to-claude-desktop.adoc[]
diff --git a/modules/ROOT/pages/omni-add-instances.adoc b/modules/ROOT/pages/omni-add-instances.adoc
new file mode 100644
index 00000000..f8616fbc
--- /dev/null
+++ b/modules/ROOT/pages/omni-add-instances.adoc
@@ -0,0 +1,31 @@
+= Creating and Managing Instances
+
+Instances represent how a service runs in a specific environment—for example production or sandbox—and how traffic reaches it through gateways or runtimes your organization manages. Creating the right instance type helps you balance governance, monitoring, and operational overhead.
+
+Managed paths through MuleSoft Flex Gateway typically expose richer policy and monitoring integration when your tenant supports them. Unmanaged or external paths remain valid when that matches your operating model. *Gateways* in *Portfolio* do not use an *Instances* tab the way APIs and agents do; use gateway-specific flows your UI exposes.
+
+== Open the Instances Experience
+
+. In *Portfolio*, open the catalog for the service (*APIs*, *Agents*, *MCP Servers*, or *LLM Proxies*).
+. Open the service to reach its detail page.
+. Select the *Instances* tab.
+. Use the add or edit controls your organization enabled to create a new instance or change an existing one.
+
+Field names, required metadata, and gateway choices depend on service type and what your administrator configured.
+
+== After You Create or Change an Instance
+
+* Apply or verify policies on the service or instance so access and traffic rules match your governance goals. Use the *Policies* tab described in xref:omni-view-service-details.adoc[].
+* Review xref:omni-monitor-your-services.adoc[monitoring] on the service or instance when metrics are available for the path you selected.
+* Coordinate with platform owners if DNS, certificates, or upstream routing must change outside the product.
+
+== Permissions (high level)
+
+Creating instances uses Anypoint Platform permissions such as *API Creator* for API-related flows. Viewing or editing instance configuration requires the matching view or edit permissions for API configuration. Your internal access guide lists the exact roles your organization mapped.
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-view-service-details.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-monitor-your-services.adoc[]
diff --git a/modules/ROOT/pages/omni-add-scanners-from-providers.adoc b/modules/ROOT/pages/omni-add-scanners-from-providers.adoc
new file mode 100644
index 00000000..2c0d4f03
--- /dev/null
+++ b/modules/ROOT/pages/omni-add-scanners-from-providers.adoc
@@ -0,0 +1,37 @@
+= Add Scanners from Providers
+
+Add scanners from providers to enable automated discovery for your organization. A scanner is the configured link between the system and a supported cloud provider so discovery jobs can find services (such as APIs, agents, and MCP servers) and register them in the right *Portfolio* catalogs. Adding a scanner is how you turn on—or extend—that automated discovery for your organization.
+
+For how provider connection and catalogs fit together, see xref:omni-connect-providers-to-add-services.adoc[] and xref:omni-add-services-to-portfolio.adoc[].
+
+== Why Add Provider Scanners
+
+* **Keep catalogs current** — New and changed services in the provider surface in the system without someone re-entering each registration by hand.
+* **Centralize visibility** — Discovered services land in *Portfolio* where teams can govern, monitor, and deploy from one place.
+* **Stay aligned with the provider** — Scheduled or on-demand scans pick up releases and configuration drift according to the options your administrator allows.
+
+== Where You Open the Scanner Flow
+The system exposes the same underlying connect-and-configure wizard from more than one place; the label depends on context:
+
+* *Home* — Start from the general *Add Services* area and choose the path that connects a provider and defines a scanner (*Connect to Provider*).
+* *Providers* — Use the area dedicated to provider and scanner management when your navigation includes it; you add or refine scanners alongside other provider work.
+* *Portfolio* — Open the catalog that matches the service type you care about (*Agents*, *APIs*, *MCP Servers*, and others your tenant supports). Use that catalog’s add control—the label usually reflects the type (for example *Add API*)—then choose provider connection when you intend to discover into that catalog.
+
+Exact strings can vary by release; follow the UI your organization ships.
+
+== What You Are Configuring
+
+Regardless of entry point, adding a scanner is about establishing trust and scope: which provider platform to reach, how the system authenticates, how you validate connectivity, and how the scanner is named and scheduled (or otherwise triggered) so discovery runs on a basis your team expects. Saving the configuration activates the scanner for the catalogs and entitlements your administrator enabled.
+
+== After the Scanner Runs
+
+When the scanner is active, discovery results are applied according to its settings and your organization’s rules. You review outcomes on the *Providers* page and on scanner detail pages, and you manage discovered services from the relevant *Portfolio* catalogs.
+
+For ongoing operations (pause, edit, or delete), see xref:omni-manage-scanners.adoc[].
+
+== See Also
+
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-manage-scanners.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-add-semantic-services.adoc b/modules/ROOT/pages/omni-add-semantic-services.adoc
new file mode 100644
index 00000000..140e0cd2
--- /dev/null
+++ b/modules/ROOT/pages/omni-add-semantic-services.adoc
@@ -0,0 +1,35 @@
+= Add Semantic Services
+
+Add semantic services to improve how LLM-driven requests are interpreted and routed across your portfolio. Semantic services help teams apply context-aware behavior so requests are handled by the most relevant tools, services, or pathways your organization configured.
+
+Use this capability when your workflows need more than static routing. With semantic context in place, the system can support better request matching, more consistent response behavior, and stronger control as usage grows across agents, APIs, MCP servers, and related integrations.
+
+At a high level, adding semantic services means:
+
+* Defining the semantic service your organization uses for contextual matching.
+* Associating that semantic capability with the relevant Omni experience (for example LLM-related routing paths where supported).
+* Operating the service as part of your broader governance and monitoring model so behavior remains reliable as traffic and use cases evolve.
+
+== Create a Semantic Service
+In the navigation, under *Portfolio*, expand *LLM Proxies*, and select *Semantic Services*.
+
+Create a semantic service by selecting the scale model that matches your traffic profile and operational needs.
+
+* *Basic scale* — Best for smaller topic sets (up to 6 topics and 10 utterances per topic). Uses managed internal LLM proxy configuration.
+* *Advanced scale* — Best for larger utterance sets per topic. Uses external semantic infrastructure, including an embedding API connection and a vector database connection.
+
+At a high level, semantic service setup defines the embedding connection used for contextual matching:
+
+* *Embedding service provider*
+* *Service label* 
+* *Endpoint URL*
+* *Model*
+* *Authentication key*
+
+Choose *Basic scale* for faster managed setup. Choose *Advanced scale* when you need greater scale and external infrastructure control.
+
+== See Also
+
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-view-service-details.adoc[]
+* xref:omni-monitor-your-services.adoc[]
\ No newline at end of file
diff --git a/modules/ROOT/pages/omni-add-services-to-portfolio.adoc b/modules/ROOT/pages/omni-add-services-to-portfolio.adoc
new file mode 100644
index 00000000..7ccf2b47
--- /dev/null
+++ b/modules/ROOT/pages/omni-add-services-to-portfolio.adoc
@@ -0,0 +1,58 @@
+= Add Services to Your Portfolio
+
+Add services to your portfolio to manage lifecycle and policy for that integration. Your *Portfolio* is organized into catalogs—*Agents*, *APIs*, *MCP Servers*, *LLM Proxies*, and *Gateways*. Each catalog holds the services (or gateway entries) your organization registered or imported so you can govern, monitor, and deploy them from one place.
+
+This topic summarizes how APIs, agents, MCP servers, and LLM proxies get into those catalogs. For step-by-step procedures, use the topics linked in the sections.
+
+== Two Ways to Add Services
+
+[cols="1,2",options="header"]
+|===
+|Approach |What Happens
+
+|xref:omni-connect-providers-to-add-services.adoc[]
+|You add a provider scanner from *Home* or from a catalog in *Portfolio*. Scans discover services on supported cloud platforms and register them in the matching catalog.
+
+|xref:omni-register-services-manually.adoc[]
+|You start an *Add …* workflow from *Home* or from the catalog for that service type. You supply metadata, specifications, endpoints, or cards to register the service without a provider scanner.
+|===
+
+Gateways follow the same entry points; gateway-specific behavior is covered in the same linked topics where it applies.
+
+== Where You Start the Workflow
+
+* *Home* — Use *Add Services* to open provider connection or manual registration, then pick the service type.
+* *Portfolio* — Open the *Agents*, *APIs*, *MCP Servers*, or *LLM Proxies* catalog. Use the add control for that type (labels such as *Add API* or *Add Agent*), then choose *Connect to Provider* or *Register Manually*.
+
+Labels can vary by catalog; match what you see in the UI.
+
+== How Each Service Type is Added 
+
+*APIs*::
+Register with an API specification and instance details, or connect an API provider so scans import APIs into the *APIs* catalog.
+
+*Agents*::
+Register by connecting to an A2A endpoint, uploading an agent card, or registering without a card—or connect an agent provider for discovery.
+
+*MCP servers*::
+Register with an MCP URL or a schema file, or connect an MCP server provider.
+
+*LLM proxies*::
+Register manually by configuring a gateway and routing strategy, or use provider flows your tenant exposes for LLM proxies.
+
+*Gateways*::
+
+For gateways, add a new gateway or add an existing gateway runtime using provider discovery to add them to the *Gateways* catalog. 
+
+Create a new gateway runtime by configuring a gateway and routing strategy. This flow establishes gateway identity, connection context, and metadata so teams can govern and monitor gateway traffic in the system.
+
+Browse the marketplace catalog of pre-configured gateway options to import them into the *Gateways* catalog.
+
+For more information about registering any of these types, see xref:omni-register-services-manually.adoc[] and xref:omni-connect-providers-to-add-services.adoc[].
+
+== See Also
+
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-register-services-manually.adoc[]
+* xref:omni-add-scanners-from-providers.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-compare.adoc b/modules/ROOT/pages/omni-compare.adoc
new file mode 100644
index 00000000..79da9ae6
--- /dev/null
+++ b/modules/ROOT/pages/omni-compare.adoc
@@ -0,0 +1,75 @@
+= Enhanced MuleSoft Experience and Anypoint Platform Comparison
+
+Both the enhanced MuleSoft experience and Anypoint Platform include robust capabilities, but they emphasize different strengths, especially when you manage AI assets such as agents, LLMs, and MCP servers next to APIs and gateways.
+
+Adopting the new experience gives you a fuller way to manage and optimize AI assets, with the flexibility and governance modern AI-driven environments need. You configure AI policies and map relationships among assets faster and more seamlessly in the new experience because the UI targets that portfolio. This is helpful when AI is central to your strategy.
+
+You still rely on MuleSoft Anypoint Platform for API and integration work, such as designing and evolving specifications, implementing and testing Mule apps in Anypoint Studio or Anypoint Code Builder, running CI/CD, deploying to runtimes such as CloudHub or Runtime Fabric, and using *Exchange* and *API Manager* for publishing, deep lifecycle policy, and runtime depth.
+
+== Benefits of Adopting the Experience
+
+Unified Relationships Across Entity Types:: *Overview* and graph-style context show how agents, MCP servers, LLMs, APIs, and gateways connect. You reason about dependencies and impact more easily than when each silo lives only in its legacy console.
+Governance Framed for AI As Well As APIs:: You apply and review governance across domains such as access and security, performance and cost, data privacy and integrity, and compliance and observability, aligned to the asset you're viewing. Policy and conformance work stays next to the asset instead of only in a separate API-only mental model.
+Cost and Usage Signals for AI Operations:: The experience includes cost management tooling aimed at portfolio spend, including visibility into token usage and optimization angles that matter for MCP servers and related AI paths. Use it when you need instance-level usage context tied to the same catalog as the rest of the portfolio.
+Instance-Level Policy Control:: For instances backed by Flex Gateway where the product supports it, the experience surfaces instance-level governance, including options to tune policy order and draw from a named policy catalog. Use that when you need fine-grained control in the portfolio UI, and keep deeper runtime-only workflows in Anypoint when the experience links you there.
+Provider Breadth for AI Connections:: *Platform* includes *Providers* and related configuration so the experience can connect AI and integration assets across multiple vendors, such as AWS Bedrock and Google Vertex AI, in addition to your existing MuleSoft footprint. That supports multi-vendor AI stacks without forcing each vendor's console to be your only view.
+Managed and unmanaged instances:: The experience supports creating managed instances on Flex Gateway when you want full support paths including authentication and monitoring, or unmanaged-style instances when you want a lighter footprint. Pick the model per asset and gateway strategy.
+Assistant Across the Portfolio:: The in-product assistant targets setup, questions, and recommendations across the assets the experience tracks. The classic Anypoint Platform control plane doesn't center that same assistant-led experience.
+
+
+== What to Manage Where
+
+The enhanced MuleSoft experience and Anypoint Platform each offer distinct capabilities that can guide where you perform different tasks. Understanding each platform's strengths helps you pick the right environment and still combine tools when a workflow spans both.
+
+[cols="1,1,2a,2a",options="header"]
+|===
+| Task | Preferred Experience | Why | Example for Dual Use
+
+| API design and documentation
+| Anypoint Platform
+a|
+Anypoint Platform offers powerful tools like Anypoint Studio and Design Center for crafting APIs with RAML or OAS and publishing detailed documentation.
+a|
+To cross-reference API design with specific governance policies already established in the new experience, consult this documentation for quick access to compliance details.
+
+| Policy enforcement and governance
+| Enhanced MuleSoft experience
+a|
+The new experience excels in applying and managing governance policies across agents, APIs, and other assets with detailed compliance tracking and reporting features.
+a|
+Use Anypoint Platform for initial policy setup when launching a new API. Use the new experience for ongoing monitoring and adjustment to ensure policies remain effective and compliant.
+
+| Integration development
+| Anypoint Platform
+a|
+Anypoint Studio is specifically designed for developing integrations and flows, offering seamless tools for connecting systems and designing workflows.
+a|
+If an integration involves workflows managed by multiple AI agents, you can start working in Anypoint Platform and then use the new experience to ensure each agent's compliance with integration standards.
+
+| Multi-agent ecosystem management
+| Enhanced MuleSoft experience
+a|
+The new experience is designed to monitor and optimize interactions between AI agents, ensuring cohesive operation across the ecosystem.
+a|
+Conduct initial API integration testing in Anypoint to verify functionality, then switch to the new experience for monitoring agents that interact with those APIs.
+
+| Cost and performance optimization
+| Enhanced MuleSoft experience
+a|
+The new experience provides comprehensive tools for monitoring and optimizing cost, token usage, and performance metrics across various entities.
+a|
+Use Anypoint Platform to initially monitor API performance under load during development, and use the new experience for ongoing cost optimization when APIs are in full production.
+
+| Runtime application management
+| Anypoint Platform
+a|
+Anypoint Runtime Manager is robust for deploying, managing, and monitoring Mule applications during runtime operations.
+a|
+Deploy applications via Anypoint to leverage its runtime monitoring, then switch to the new experience for broader operational oversight involving governance and policy application across running assets.
+|===
+
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-start-home.adoc[]
diff --git a/modules/ROOT/pages/omni-configure-notifications-for-alerts.adoc b/modules/ROOT/pages/omni-configure-notifications-for-alerts.adoc
new file mode 100644
index 00000000..c266fbab
--- /dev/null
+++ b/modules/ROOT/pages/omni-configure-notifications-for-alerts.adoc
@@ -0,0 +1,28 @@
+= Configure Notifications for Alerts
+
+Notifications route API and runtime alerts from Anypoint Platform into channels your team already monitors, such as email, Slack, or ticketing integrations your administrator configured. Connecting alerts to the enhanced experience helps responders jump from a signal into *Portfolio* or *Observability* with less context switching.
+
+Delivery channels and alert types depend on Anypoint API Manager, Runtime Manager, and any add-on connectors your organization purchased. You configure the subscription side in those products; the enhanced experience surfaces links and context when your entry path integrates them.
+
+== What You Typically Configure
+
+* **Who receives alerts** — Assign viewers or managers for API alerts in API Manager and for runtime alerts in Runtime Manager according to your team's on-call model.
+* **Severity and routing** — Map critical alerts to high-priority channels and informational alerts to lower-noise destinations so engineers trust the feed.
+* **Deep links** — When your organization uses Slack or another integrated client, follow notifications back into the enhanced experience using the shortcuts your administrator enabled.
+
+Exact steps live in Anypoint Platform documentation for API Manager and Runtime Manager; use those guides for click-by-click procedures.
+
+== Relate Alerts to Portfolio Work
+
+When an alert references a service you govern in the enhanced experience, open the service from *Portfolio* and review *Monitoring*, *Policies*, and *Instances* together. xref:omni-monitor-your-services.adoc[Monitoring] explains how service-level signals relate to organization-wide observability.
+
+== Permissions (high level)
+
+Managing alert subscriptions typically requires *API Manager* > *Manage API Alerts* or *Runtime Manager* > *Manage Alerts*. Viewing alerts uses the corresponding view permissions. See xref:omni-start-home.adoc#permissions[Enhanced Experience Permissions] for how those roles appear in access guides.
+
+== See Also
+
+* xref:omni-monitor-your-services.adoc[]
+* xref:omni-view-detailed-metrics-for-services.adoc[]
+* xref:omni-start-home.adoc[]
+* xref:omni-overview.adoc[]
diff --git a/modules/ROOT/pages/omni-connect-experience-to-claude-desktop.adoc b/modules/ROOT/pages/omni-connect-experience-to-claude-desktop.adoc
new file mode 100644
index 00000000..171cc14f
--- /dev/null
+++ b/modules/ROOT/pages/omni-connect-experience-to-claude-desktop.adoc
@@ -0,0 +1,28 @@
+= Connect the Enhanced Experience to Claude Desktop
+
+Some organizations connect Claude Desktop (or similar assistants) to the enhanced MuleSoft experience so developers can jump from conversational workflows into governed catalogs and policies without leaving their preferred environment. Your IT team controls whether this integration is available, which OAuth scopes apply, and which actions the assistant may initiate on your behalf.
+
+This topic summarizes what you need from your administrator; it does not replace your organization's internal setup guide or Anthropic's client documentation.
+
+== Prerequisites
+
+* A supported Claude Desktop release and any enterprise controls your company applies to assistant software.
+* Network access from your workstation to both the assistant vendor endpoints and MuleSoft endpoints your security team approved.
+* An Anypoint account with permissions appropriate for the tasks you plan to run after you deep link into the enhanced experience.
+
+== What Your Administrator Configures
+
+* **Identity and consent** — Map your Anypoint identity to the assistant context and document which business groups may use the integration.
+* **Allowed actions** — Decide whether the workflow is read-only (for example opening catalog links) or may trigger guarded operations, then enforce that with roles and internal process.
+
+== Use the Integration Day to Day
+
+Follow the internal instructions your platform team published—typically a starter prompt, a packaged connector, or a bookmark that opens the enhanced experience with the right query parameters. When you land in the browser, complete any additional sign-in or step-up authentication your organization requires.
+
+If the connection stops working after a client or policy update, revalidate certificates, proxy settings, and token expiry with your administrators before opening a support case.
+
+== See Also
+
+* xref:omni-start-home.adoc[]
+* xref:omni-access-experience-from-slack.adoc[]
+* xref:omni-overview.adoc[]
diff --git a/modules/ROOT/pages/omni-connect-providers-to-add-services.adoc b/modules/ROOT/pages/omni-connect-providers-to-add-services.adoc
new file mode 100644
index 00000000..620c27f8
--- /dev/null
+++ b/modules/ROOT/pages/omni-connect-providers-to-add-services.adoc
@@ -0,0 +1,38 @@
+= Connect to Providers to Add Services
+
+Connecting a provider lets the system run scanners against supported cloud platforms, discover services (such as agents, APIs, and MCP servers), and register them in the matching catalog in *Portfolio*. You supply credentials and scanner metadata so the integration is repeatable and auditable.
+
+You can start the flow from *Home* or from a specific catalog in *Portfolio*. For how this fits with manual registration, see xref:omni-add-services-to-portfolio.adoc[]. For creating and tuning scanners themselves, see xref:omni-add-scanners-from-providers.adoc[].
+
+== Why Use Provider Connection
+
+Provider connection is for teams that maintain services in an external platform and want those services to appear automatically in your portfolio catalogs after authentication and discovery, instead of registering each one by hand.
+
+== Where You Start
+
+* *Home* — Use *Add Services*, choose *Connect to Provider*, then work through the wizard to pick a provider, validate access, and save scanner settings. Use this path when you're not starting from a single catalog view.
+* *Portfolio* — Open the *Agents*, *APIs*, or *MCP Servers* catalog. Use the add control for that service type (for example *Add API* or *Add MCP Server*), choose *Connect to Provider*, and complete the same style of wizard scoped to that catalog.
+
+Labels can vary by catalog and release; match what you see in the UI.
+
+== What the Wizard Establishes
+
+Across *Home* and *Portfolio* entry points, provider connection generally covers the same kinds of decisions:
+
+* **Which provider or platform** to target for discovery and import.
+* **Credentials and authentication** so the system can reach the provider safely and securely.
+* **Connection validation** so you know discovery can run against live data.
+* **Scanner identity and settings**—name, description, and options your administrator expects—before you save the connection.
+
+When the scanner runs successfully, discovered service types are registered in the catalog that matches the workflow you started from (for example APIs land in the *APIs* catalog).
+
+== Catalogs and Discovery Scope
+
+Agents, APIs, and MCP servers catalog-specific flows emphasize the service type you are enriching; discovery results populate that catalog when the system supports the provider mapping for that type.
+
+== See Also
+
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-register-services-manually.adoc[]
+* xref:omni-add-scanners-from-providers.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-create-governance-strategies.adoc b/modules/ROOT/pages/omni-create-governance-strategies.adoc
new file mode 100644
index 00000000..571af437
--- /dev/null
+++ b/modules/ROOT/pages/omni-create-governance-strategies.adoc
@@ -0,0 +1,30 @@
+= Creating Governance Strategies
+
+Governance strategies bundle the rules and controls your organization wants to enforce across agents, APIs, MCP servers, LLM proxies, and gateways. They connect policy intent to conformance reporting, cost management, and runtime behavior so teams can align releases with risk and compliance targets.
+
+Strategy authoring is available when your tenant includes *Governance* capabilities and your account has the appropriate administrator role. Exact rule catalogs and scopes depend on your organization's configuration.
+
+== Open Governance Strategy Workflows
+
+. Sign in through your organization's entry path and open *Governance*.
+. Use the area your UI labels for strategies or organization governance (names can vary by release).
+. Create a strategy, attach the domains your organization uses—such as access and security, data privacy, performance and cost, or compliance and observability—and map them to the services or scopes your administrators approved.
+
+Work with your governance lead so strategy changes match change-management processes outside the product.
+
+== Tie Strategies to Day-to-Day Operations
+
+* Apply policies at the service or instance level from *Portfolio* so runtime traffic reflects the strategy. See xref:omni-view-service-details.adoc[] for where policies appear on a service.
+* Review xref:omni-overview.adoc[conformance reporting] on supported catalog types to confirm rules pass after you update a strategy or deployment.
+* Use cost-related controls where the experience exposes them—for example under *Governance* > *Cost Management* when your tenant enables token and spend signals.
+
+== Permissions (high level)
+
+Creating governance strategies typically requires *Governance Administrator*. Viewing reports may be available to *Governance Viewer* or *Governance Administrator* depending on how your organization mapped roles.
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-start-home.adoc#permissions[Enhanced Experience Permissions]
+* xref:omni-view-service-details.adoc[]
+* xref:omni-view-token-usage-response-performance.adoc[]
diff --git a/modules/ROOT/pages/omni-create-manage-apis.adoc b/modules/ROOT/pages/omni-create-manage-apis.adoc
new file mode 100644
index 00000000..681c1f18
--- /dev/null
+++ b/modules/ROOT/pages/omni-create-manage-apis.adoc
@@ -0,0 +1,83 @@
+= Create and Manage APIs in Omni
+
+In Omni, APIs are registered as services defined by formal specifications and managed within a unified experience alongside other service types.
+
+Creating an API establishes its structure and makes it available in the portfolio, while instances represent deployed or managed versions of that API across environments or providers.
+
+== Create an API
+
+To create an API in Omni, add it to the APIs catalog either by registering it manually or by connecting to a provider.
+
+* *Register manually* – Upload a specification file to define a new API.
+* *Connect to provider* – Discover and import APIs from external platforms. See xref:omni-connect-providers-to-add-services.adoc[].
+
+
+=== Register an API Manually
+
+When you register an API manually, you provide a specification file that defines the API structure, including endpoints, operations, and data types.
+
+. In the navigation pane, select *APIs*.
+. Click *Add API*.
+. Select *Register manually*.
+. Enter a name for the API.
+. Select the API type.
+. Upload the specification file.
+. Click *Create*.
+
+Omni supports multiple API types and specification formats:
+
+* REST APIs (OAS, RAML)
+* gRPC APIs (Proto files)
+* Async APIs (AsyncAPI specification)
+
+== View API Details
+
+After creating or selecting an API, Omni displays its details as a service with multiple views that expose its structure, runtime state, and governance status.
+
+The API view is organized into tabs:
+
+* *Overview* – Displays API structure and metadata
+* *Instances* – Lists and manages API instances
+* *Monitoring* – Displays performance metrics
+* *Policies* – Displays applied policies
+* *Conformance Report* – Displays governance status
+* *Versions* – Displays available API versions
+
+NOTE: Monitoring, policies, and conformance details are managed in their respective sections.
+
+=== Overview Tab
+
+The *Overview* tab displays information derived from the API specification.
+
+Depending on the API type, this includes:
+
+* Endpoints or resources defined in the API
+* Available methods (such as GET, POST, PUT, and DELETE)
+* Request and response details
+* Parameters and headers
+* Example requests and responses
+* Data types and schemas
+* Security definitions
+
+This view reflects the structure and behavior defined in the uploaded specification.
+
+== Create and Manage API Instances
+
+API instances represent concrete deployments or runtime configurations of an API across environments or providers.
+
+Use the *Instances* tab to:
+
+* View existing instances
+* Create new instances
+* Manage or remove instances
+
+Each instance corresponds to a specific deployment or configuration of the API.
+
+Instances enable you to apply runtime-specific configurations and interact with APIs across different environments.
+
+== See Also
+
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-register-services-manually.adoc[]
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-view-service-details.adoc[]
\ No newline at end of file
diff --git a/modules/ROOT/pages/omni-create-mcp-server.adoc b/modules/ROOT/pages/omni-create-mcp-server.adoc
new file mode 100644
index 00000000..c4e0a4ec
--- /dev/null
+++ b/modules/ROOT/pages/omni-create-mcp-server.adoc
@@ -0,0 +1,31 @@
+= Create an MCP Server
+
+Create MCP servers to define identity, runtime connectivity, and exposed tools/resources for MCP clients.
+
+Use the MCP server create experience to define a new MCP service to be recognized, validated, and operated. Creating an MCP server means building a new MCP implementation (for example, by transcoding an existing REST API) or creating a runtime deployment where your environment supports it. At a high level, you establish the server identity, define how the system reaches the runtime, and declare the MCP capabilities (such as tools and resources) the server exposes to clients.
+
+Creating an MCP server is different from adding one to *Portfolio*. Creation defines the MCP implementation and runtime behavior. Adding to *Portfolio* registers an existing MCP server so teams can govern, monitor, and manage lifecycle in Omni.
+
+The create flow has this information:
+
+* **Service definition** — Name, description, and ownership metadata so teams can identify the server in catalogs and governance views.
+* **Connection/runtime details** — Endpoint and access settings Omni uses to connect to and validate the server.
+* **Capability surface** — The MCP tools and resources clients can discover and invoke.
+* **Validation and readiness** — Checks that confirm the server is reachable and that the declared MCP surface is usable.
+
+== Steps to Create an MCP Server
+
+. Open MCP Servers and choose Add MCP Server > Create MCP Server.
+. In Select Source, Instance & Tools, choose the APIs or SaaS systems you want to expose, select the source instance/version, and choose the tools to publish (including optional read-only filtering).
+. In SaaS Credentials, provide the credentials required for the selected sources so the MCP server can call them securely.
+. In Review, validate the selected sources, tools, and credential mappings, then complete creation.
+
+== After You Create an MCP Server
+After saving, the MCP server is created and available for governance and operations. You can then register or confirm the MCP server in *Portfolio* so it appears in the *MCP Servers* catalog for ongoing governance, monitoring, and operations.
+
+== See Also
+
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-register-services-manually.adoc[]
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-manage-scanners.adoc b/modules/ROOT/pages/omni-manage-scanners.adoc
new file mode 100644
index 00000000..795119fd
--- /dev/null
+++ b/modules/ROOT/pages/omni-manage-scanners.adoc
@@ -0,0 +1,26 @@
+= Manage Scanners
+
+Once scanners are configured, your team runs them day to day: starting discovery when needed, reading run history, updating schedules and credentials, and removing scanners that are no longer in use. Most of that work happens under *Providers*, where your organization lists provider connections, scanners, and scan activity in one place.
+
+== Where This Work Happens
+
+Use the *Providers* area (or equivalent navigation your administrator labels) to see which scanners exist for your business group, open a scanner’s detail context, and act on schedules, runs, and configuration. Exact layout can vary by release and entitlement.
+
+== What You Can Do With a Scanner
+
+* **Run discovery on demand** — Kick off a manual scan when you want fresh metadata without waiting for the next scheduled window. Successful runs update or add services in the matching *Portfolio* catalogs according to your rules.
+* **Review status and history** — Inspect connection health, the last completed run, and scan history so you can tell whether discovery is healthy, slow, or failing authentication.
+* **Pause scheduled scans** — Temporarily stop scheduled triggers when you need a quiet period—for example during maintenance or while you fix credentials—without deleting the scanner.
+* **Edit configuration** — Change names, descriptions, credentials, provider scope, or scan-related settings your product exposes, then save so future runs use the new definition.
+* **Delete a scanner** — Remove the scanner from *Providers* when the provider link is no longer authorized or useful. Consider impact on discovered services in *Portfolio* and on dependent teams before you delete.
+
+== How Scans Are Triggered
+
+Scanners typically run on a schedule you or an administrator configured, or manually when someone starts a run. 
+
+== See Also
+
+* xref:omni-add-scanners-from-providers.adoc[]
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-monitor-your-services.adoc b/modules/ROOT/pages/omni-monitor-your-services.adoc
new file mode 100644
index 00000000..8017505a
--- /dev/null
+++ b/modules/ROOT/pages/omni-monitor-your-services.adoc
@@ -0,0 +1,36 @@
+= Monitor Your Services
+
+Monitoring helps you see whether the services in your portfolio—and the paths that carry their traffic—are healthy, performant, and stable over time. You work from service context (what a single API, agent, MCP server, LLM proxy, or gateway is doing) and, when your administrator enables it, from broader observability surfaces that sit alongside *Portfolio* and *Governance*.
+
+== What You Use Monitoring For
+
+* **Spot regressions early** — Compare latency, errors, and throughput (or equivalent signals the system to expose for your integration type) against what you expect after a release or policy change.
+* **Triage incidents** — Correlate spikes or failures on a service with recent deployments, instances, or gateway paths your team manages.
+* **Support capacity and cost conversations** — Use sustained load or usage patterns as inputs when you tune scaling, routing, or token-related spend with your platform owners.
+
+Exact metrics depend on how the service is hosted, which gateway or runtime path applies, and what your organization is connected.
+
+== Where Monitoring Appears 
+
+* *Portfolio* and service detail — Open a catalog entry and use the *Monitoring* tab on the service (and, where the product exposes it, on instances) to read metrics scoped to that service. That is the day-to-day place engineers live when they ask, “Is this API or agent degrading?”
+* *Observability* — When your tenant includes it, *Observability* aggregates dashboards, reports, or notifications so you can compare what you see on a service with organization-wide views your administrator wired up.
+* *Home* — Your entry path may highlight alerts or shortcuts back into *Portfolio* or *Observability*; use whatever your organization configured after sign-in.
+
+Navigation labels and depth vary by entitlement and release; follow the UI your business group was given.
+
+== What Kinds of Signals You Typically See
+
+The system emphasizes runtime health for managed integration paths—for example latency, error rates, and request volume when the new experience surfaces Flex Gateway data for routes your team operates under policy. Not every catalog type exposes the same charts; some services show richer series only after you complete instance setup or connect the observability backend your administrator approved.
+
+If a tab is missing, confirm with your administrator that monitoring data is flowing for that environment and that your account has the right permissions.
+
+== Permissions 
+
+The system relies on Anypoint Platform access control. Roles such as *Monitoring Viewer* or *Monitoring Administrator* control whether you can open monitoring views at the service or instance level and whether you can change monitoring configuration where the product allows it. 
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-start-home.adoc[]
+* xref:omni-view-service-details.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
diff --git a/modules/ROOT/pages/omni-overview.adoc b/modules/ROOT/pages/omni-overview.adoc
new file mode 100644
index 00000000..a2f1fa11
--- /dev/null
+++ b/modules/ROOT/pages/omni-overview.adoc
@@ -0,0 +1,58 @@
+= Enhanced MuleSoft Experience Overview
+
+Grow and tune your AI portfolio by registering and monitoring agents, APIs, and gateways in centralized catalogs. Sign in through the entry point your organization provides, such as Anypoint Platform, Slack, or a direct URL, to access dashboards and governance strategies based on your assigned permissions. You can review live performance metrics, manage security policies, and track rule-level compliance through automated conformance reports.
+
+These tools ensure your AI assets remain audit-ready while providing clear visibility into cost and runtime health across your organization.
+
+== Enhanced Experience Capabilities
+
+The enhanced MuleSoft experience supports the full lifecycle of AI-connected integration assets:
+
+Entity Management:: Register and manage agents, REST and GraphQL APIs, MCP servers, LLMs, and gateways, including MuleSoft Flex Gateway, external gateways, and unmanaged gateways. Each type has a dedicated catalog under *Portfolio*.
+
+Governance and Compliance:: Define and apply policies across domains such as access and security, performance and cost, data privacy and integrity, and compliance and observability. Conformance reporting summarizes rule violations and severity so you can close gaps systematically.
+
+Cost and Performance Optimization:: Monitor token usage, per-instance signals, and daily cost where the product exposes them. Apply governance strategies and related controls, such as tool mapping and tool sanitization, to reduce spend and risk where the experience supports them.
+
+Instance Management:: Create and review instances for supported asset types. Choose managed paths through Flex Gateway when you need deeper monitoring and policy enforcement, or choose lighter models when that matches your operating model.
+
+== Enhanced Experience High-Level Workflow
+
+Manage and tune your AI portfolio by registering assets, applying security policies, and monitoring runtime health. Access centralized catalogs to track agents and gateways while verifying compliance through conformance reports and cost management tools. These integrated features help you optimize performance and maintain audit readiness across your environment
+
+. Complete onboarding and access
++
+Confirm your credentials and the permissions your administrator assigned, as described in xref:omni-start-home.adoc#permissions[Enhanced Experience Permissions]. Finish integration setup for supporting systems, such as connected providers under *Platform* > *Providers*, before you depend on the experience in production.
+. Learn the layout
++
+Sign in through your entry path and land on *Home*. Scan *Portfolio* catalogs, *Governance*, *Observability*, and *Platform* so you know where to register assets, apply policies, read health signals, and manage providers.
+. Register assets in Portfolio
++
+Under *Portfolio*, open *Agents*, *MCP Servers*, *LLMs*, *APIs*, or *Gateways*. Add assets to work with. Register manually or use connected providers under *Platform* > *Providers* if your organization enables discovery flows.
+. Create and manage instances
++
+On *Agents*, *MCP Servers*, *LLMs*, and *APIs*, open *Instances* to create managed or unmanaged deployments that match your needs. Managed instances on Flex Gateway give stronger governance and monitoring when the new experience exposes them. *Gateways* don't include an *Instances* tab.
+. Configure policies
++
+On the *Policies* tab for a service or instance, apply governance policies that match access control, data privacy, performance, and compliance goals. Use *Governance* for gateway-wide policy work, organization strategies, and cost tools.
+. Review compliance
++
+On *Agents*, *APIs*, and *MCP Servers*, open *Conformance Report* to review scores, violations, and warnings, then address the findings your governance team prioritizes. For gateways, use *Governance* for the same compliance story at the scope the experience supports.
+. Monitor runtime health
++
+On *Monitoring*, review live metrics such as latency, error rates, and request volume when the new experience surfaces Flex Gateway data for managed paths. Compare what you see with dashboards, reports, or notifications under *Observability* when your administrator enabled those views for your team.
+. Manage cost
++
+Under *Governance*, open *Cost Management* to study token usage and related spend signals. Apply the cost reduction strategies your organization adopted, such as tool mapping or tool sanitization, where the new experience supports them.
+. Operate and tune the portfolio
++
+Coordinate agents, APIs, gateways, MCP servers, and LLMs so traffic, policies, and integrations stay aligned. Open *Versions* when you need configuration history before you change instances or policies. Adjust policies, instances, or registrations when monitoring and governance insights show drift or new risk.
+. Improve on each cycle
++
+Feed findings from monitoring and governance back into planning for the next change window.
+
+== See Also
+
+* xref:omni-start-home.adoc[]
+* xref:omni-compare.adoc[]
+* xref:learning-map-omni.adoc[]
diff --git a/modules/ROOT/pages/omni-register-services-manually.adoc b/modules/ROOT/pages/omni-register-services-manually.adoc
new file mode 100644
index 00000000..e5e308eb
--- /dev/null
+++ b/modules/ROOT/pages/omni-register-services-manually.adoc
@@ -0,0 +1,63 @@
+= Register Services Manually
+
+Register a service to add it to your portfolio when you already have the metadata, specification, endpoint, or card the new experience needs—without running a provider scan. You start from *Home* or from the catalog for that service type in *Portfolio*; completed registrations appear in the matching catalog.
+
+For how manual registration fits with connecting providers, see xref:omni-add-services-to-portfolio.adoc[].
+
+== Where You Start
+
+* *Home* — Open *Add Services*, choose the service type, then choose manual registration when the UI offers it.
+* *Portfolio* — Open the *Agents*, *APIs*, *MCP Servers*, or *LLM Proxies* catalog, use the add control for that type (for example *Add API*), and choose *Register Manually*.
+
+Exact labels can vary by release; follow the options your tenant shows.
+
+== Agents
+
+You register an agent by supplying one of the following:
+
+* **A2A connection** — Point to an A2A endpoint to fetch an agent card.
+* **Uploaded card** — Provide an agent card file you already have.
+* **No card** — Register with metadata and connection details when you are not using a card workflow.
+
+The connection gets validated, makes it possible to review metadata, and saves the agent into the *Agents* catalog.
+
+== APIs
+
+Manual API registration expects an API specification and a way to reach a running instance (or instance-only registration when that path is enabled). The choices are:
+
+* **Link to spec** — Reference a specification by URL so the system ingests it.
+* **Upload spec** — Upload a specification file from your environment.
+* **Use instance only** — Supply instance details when your flow doesn't start from a standalone spec file.
+
+The system uses the spec to discover endpoints, parameters, and related metadata where applicable, then writes the API into the *APIs* catalog after you confirm.
+
+== MCP Servers
+
+You define how the system reaches the MCP server and validates runtime access:
+
+* **MCP URL** — Connect over a URL and test the live server so tools and metadata can be discovered.
+* **Schema file** — Upload a schema and supply the details needed to register and test the server.
+
+Successful registration stores the MCP server in the *MCP Servers* catalog.
+
+== LLM proxies
+
+LLM proxy registration is a two-part configuration: you associate the proxy with a gateway (and related deployment context), then define routing (and any provider connections your flow requires). When the wizard completes, the LLM proxy appears in the *LLM Proxies* catalog.
+
+== Gateways
+
+Register gateways manually when you want to add an existing gateway runtime to *Portfolio* without using provider discovery. This flow establishes gateway identity, connection context, and metadata so teams can govern and monitor gateway traffic in Omni.
+
+At a high level, manual gateway registration includes:
+
+* Defining gateway identity and descriptive metadata used in catalog and governance views.
+* Providing environment and runtime connection details so the gateway maps to your organization topology.
+* Validating registration inputs before saving so the gateway is ready for operational workflows.
+
+After registration, the gateway appears in the *Gateways* catalog in *Portfolio*, where teams can review details and apply supported governance workflows.
+
+== See Also
+
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-connect-providers-to-add-services.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-start-home.adoc b/modules/ROOT/pages/omni-start-home.adoc
new file mode 100644
index 00000000..3a857b85
--- /dev/null
+++ b/modules/ROOT/pages/omni-start-home.adoc
@@ -0,0 +1,193 @@
+= Get Started with the Enhanced Experience
+:page-aliases:
+
+Grow and tune your AI portfolio by registering and monitoring agents, APIs, and gateways in centralized catalogs. Sign in through the entry point your organization provides, such as Anypoint Platform, Slack, or a direct URL, to access dashboards and governance strategies based on your assigned permissions. You can review live performance metrics, manage security policies, and track rule-level compliance through automated conformance reports.
+
+These tools ensure your AI assets remain audit-ready while providing clear visibility into cost and runtime health across your organization.
+
+== Access Enhanced Experience
+
+Your organization determines how you access the new experience. Common options include these environments.
+
+* Anypoint Platform
++
+In Anypoint Platform, look for the new experience banner or shortcut and choose *Go to the new experience*. Your administrator can also add a direct link in the main navigation or workspace.
+* Slack
++
+If your organization integrates the new experience with Slack, use the new experience Slack app to receive notifications and alerts, and follow links back into the product. Your workspace can also offer shortcuts or slash commands your admin configures.
+* Coding assistants
++
+If your organization connects the new experience to a supported assistant, such as Claude Code, follow your internal instructions to open the new experience features from that development environment.
+* Direct URL
++
+Your organization can share a standalone URL that signs you in to the new experience outside other apps. Use the address your administrator or internal documentation provides.
+* Custom integrations
++
+Your organization can build access through another tool. Follow the internal access instructions for custom integrations.
+
+[NOTE]
+Available access points depend on how your administrators configured the new experience's integrations with other platforms.
+
+
+== Before You Begin
+
+Before you rely on the new experience in production, complete these checks with your administrator. Requirements vary by entry point and how your administrator integrates the new experience with other systems.
+
+Access and Credentials::
++
+* Confirm that you have a user account for your organization's entry path, such as Anypoint Platform, and valid credentials to log in.
+* Confirm that you can reach the new experience and integrated services, such as Anypoint Platform, Slack, or a connected coding assistant, from the networks and locations you use.
+
+Platform and Product Access::
++
+* Confirm that your organization has the entitlements required for the new experience and an administrator enabled it for your Anypoint business group or organization.
+* Confirm that required integrations with Anypoint Platform, Slack, or your development environment work end to end.
+* If the new experience connects to other services, work with your administrator to configure authentication, such as API keys or OAuth tokens, to ensure successful connections.
+* Confirm that your administrator approved and configured required external connections, such as cloud providers under *Providers*.
+
+
+[[permissions]]
+== Enhanced Experience Permissions
+// make this a partial in access management and include there as well.
+
+The new experience uses Anypoint Platform access control. Your administrator maps jobs to roles and permissions in Anypoint Access Management. Exact permission names differ by organization. Use this table with your internal access guide.
+
+[cols="20%,~,~",options="header"]
+|===
+|To... |Required Permissions |Notes
+
+|View service
+a|
+Any of these permissions:
+
+* Exchange Viewer
+* Exchange Contributor
+* Exchange Administrator
+a|With these permissions, users can view services under the portfolio and open the catalog overview in Anypoint Exchange.
+
+|Create service
+a|
+Any of these permissions:
+
+* Exchange Contributor
+* Exchange Administrator
+* Exchange Creator
+a|With these permissions, users can use Add workflows to register MCP servers, agents, LLMs, or APIs.
+
+|Create instance
+a|
+* API Creator
+|With this permission, users can run the create-instance workflow and create or add instances.
+
+|View instance
+a|
+* View APIs Configuration
+a|With this permission, users can view instances for services and open the Instances tab.
+
+|Edit instance
+a|
+* Edit APIs Configuration
+a|With this permission, users can edit instances for services.
+
+|Create scanners
+a|
+* Exchange Administrator
+a|With this permission, users can create scanners from *Providers* and through Add MCP, Agent, or API when the organization enables the matching scanner capabilities.
+
+|View monitoring
+a|
+Any of these permissions:
+
+* Monitoring Viewer
+* Monitoring Administrator
+a|With these permissions, users can open the monitoring tab at the service and instance levels and see monitoring in navigation.
+
+|View policies
+a|
+* View Policies
+a|With this permission, users can view and apply policies on instances and use the Governance tab for policy access.
+
+|Apply policies
+a|
+* Manage Policies
+a|With this permission, users can edit policy configurations and add policies.
+
+|Send prompts to agent
+a|
+* Mule Developer Generative AI User
+|With this permission, users can use the native agent in the new experience.
+
+|Create governance strategy
+a|
+* Governance Administrator
+|With this permission, users can create governance strategies.
+
+|View governance report
+a|
+Any of these permissions:
+
+* Governance Viewer
+* Governance Administrator
+a|With these permissions, users can view governance reports at the service and governance-strategy level.
+
+|View alerts
+a|
+Any of these permissions:
+
+* *API Manager* > *View API Alerts*
+* *Runtime Manager* > *Read Alerts*
+a|With these permissions, users can view API alerts in API Manager and read alerts in Runtime Manager.
+
+|Manage alerts
+a|
+Any of these permissions:
+
+* *API Manager* > Manage API Alerts
+* *Runtime Manager* > Manage Alerts
+a|With these permissions, users can manage API alerts in API Manager and manage alerts in Runtime Manager.
+
+|===
+
+If you can't complete an action or a page shows an authorization error, ask your Anypoint organization administrator for the matching permission or role.
+
+////
+== High-Level Enhanced Experience Workflow
+
+Manage and tune your AI portfolio by registering assets, applying security policies, and monitoring runtime health. Access centralized catalogs to track agents and gateways while verifying compliance through conformance reports and cost management tools. These integrated features help you optimize performance and maintain audit readiness across your environment
+
+. Complete onboarding and access
++
+Confirm your credentials and the permissions your administrator assigned, as described in <<permissions>>. Finish integration setup for supporting systems, such as connected providers under *Platform* > *Providers*, before you depend on the new experience in production.
+. Learn the layout
++
+Sign in through your entry path and land on *Home*. Scan *Portfolio* catalogs, *Governance*, *Observability*, and *Platform* so you know where to register assets, apply policies, read health signals, and manage providers.
+. Register assets in Portfolio
++
+Under *Portfolio*, open *Agents*, *MCP Servers*, *LLMs*, *APIs*, or *Gateways*. Add assets to work with. Register manually or use connected providers under *Platform* > *Providers* if your organization enables discovery flows.
+. Create and manage instances
++
+On *Agents*, *MCP Servers*, *LLMs*, and *APIs*, open *Instances* to create managed or unmanaged deployments that match your needs. Managed instances on Flex Gateway give stronger governance and monitoring when the new experience exposes them. *Gateways* don't include an *Instances* tab.
+. Configure policies
++
+On the *Policies* tab for a service or instance, apply governance policies that match access control, data privacy, performance, and compliance goals. Use *Governance* for gateway-wide policy work, organization strategies, and cost tools.
+. Review compliance
++
+On *Agents*, *APIs*, and *MCP Servers*, open *Conformance Report* to review scores, violations, and warnings, then address the findings your governance team prioritizes. For gateways, use *Governance* for the same compliance story at the scope the new experience supports.
+. Monitor runtime health
++
+On *Monitoring*, review live metrics such as latency, error rates, and request volume when the new experience surfaces Flex Gateway data for managed paths. Compare what you see with dashboards, reports, or notifications under *Observability* when your administrator enabled those views for your team.
+. Manage cost
++
+Under *Governance*, open *Cost Management* to study token usage and related spend signals. Apply the cost reduction strategies your organization adopted, such as tool mapping or tool sanitization, where the new experience supports them.
+. Operate and tune the portfolio
++
+Coordinate agents, APIs, gateways, MCP servers, and LLMs so traffic, policies, and integrations stay aligned. Open *Versions* when you need configuration history before you change instances or policies. Adjust policies, instances, or registrations when monitoring and governance insights show drift or new risk.
+. Improve on each cycle
++
+Feed findings from monitoring and governance back into planning for the next change window.
+////
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-compare.adoc[]
diff --git a/modules/ROOT/pages/omni-view-detailed-metrics-for-services.adoc b/modules/ROOT/pages/omni-view-detailed-metrics-for-services.adoc
new file mode 100644
index 00000000..b8123728
--- /dev/null
+++ b/modules/ROOT/pages/omni-view-detailed-metrics-for-services.adoc
@@ -0,0 +1,25 @@
+= View Detailed Metrics for Your Services
+
+Detailed metrics go beyond high-level status to show time series, breakdowns, and dimensions your observability stack forwards into the enhanced experience. Engineers use them to debug incidents, validate policy changes, and compare behavior across instances or environments.
+
+Available series depend on the gateway or runtime path, whether the deployment is managed through Flex Gateway, and what your organization connected under *Platform* and *Observability*.
+
+== Open Detailed Views
+
+* From *Portfolio*, open a service and go to the *Monitoring* tab for charts scoped to that service or instance when the product exposes them.
+* From *Observability*, open dashboards or explorers your administrator pinned for the organization. Use filters to narrow to the service, environment, or route you are investigating.
+
+If you need a metric that never appears, ask your platform team whether the integration or retention policy supports it.
+
+== Practices That Keep Metrics Useful
+
+* **Baseline after changes** — Capture before-and-after windows when you deploy instances or change policies so you can attribute shifts.
+* **Align with alerts** — Pair detailed charts with xref:omni-configure-notifications-for-alerts.adoc[alert notifications] so on-call engineers land in the right context.
+* **Respect data boundaries** — Some dimensions may be redacted or aggregated for privacy; follow your organization's data-handling standards.
+
+== See Also
+
+* xref:omni-monitor-your-services.adoc[]
+* xref:omni-configure-notifications-for-alerts.adoc[]
+* xref:omni-view-service-details.adoc[]
+* xref:omni-overview.adoc[]
diff --git a/modules/ROOT/pages/omni-view-portfolio-overview.adoc b/modules/ROOT/pages/omni-view-portfolio-overview.adoc
new file mode 100644
index 00000000..71b5e6b3
--- /dev/null
+++ b/modules/ROOT/pages/omni-view-portfolio-overview.adoc
@@ -0,0 +1,25 @@
+= View an Overview of Your AI Portfolio
+
+Use portfolio-level views to see how your agents, APIs, MCP servers, LLM proxies, and gateways fit together before you drill into a single service. Summaries help you spot gaps in registration, policy coverage, or health signals your organization cares about.
+
+The exact layout depends on how your tenant is configured and which catalogs your administrator enabled. Labels and widgets can differ by release.
+
+== Where You Open Portfolio Overview
+
+* *Home* — After sign-in, your landing page may highlight portfolio activity, shortcuts into *Portfolio*, or high-level counts your organization chose to surface.
+* *Portfolio* — Open *Portfolio* to browse catalogs (*Agents*, *APIs*, *MCP Servers*, *LLM Proxies*, *Gateways*). Each catalog lists or tiles the services your team registered or imported. Use search and filters to narrow the set before you open a service detail page.
+
+If you do not see a catalog or a summary you expect, confirm entitlements and permissions with your Anypoint organization administrator.
+
+== What You Typically Review
+
+* **Coverage** — Which service types are registered and which environments or instances they map to.
+* **Health and cost signals** — Summary metrics or badges when the experience exposes them at list level (for example status or daily cost on cards).
+* **Next actions** — Entry points to add services, connect providers, or open governance and observability areas described in xref:omni-overview.adoc[].
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-start-home.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-view-service-details.adoc[]
diff --git a/modules/ROOT/pages/omni-view-service-details.adoc b/modules/ROOT/pages/omni-view-service-details.adoc
new file mode 100644
index 00000000..814eac3d
--- /dev/null
+++ b/modules/ROOT/pages/omni-view-service-details.adoc
@@ -0,0 +1,69 @@
+= View Service Details
+
+Open a catalog entry in *Portfolio* to see its service detail page: a single view of one service—an API, agent, MCP server, or LLM proxy—or a gateway, depending on the catalog. From there you can review status and cost, relationships to other services, deployments, policies, monitoring, conformance, and change history without switching contexts.
+
+//placeholder for image of service detail page
+
+== What You See
+
+The page is organized into tabs. The following table lists each tab, what it shows, and whether that tab appears on the detail page for each catalog type. *Yes* means the tab is shown in typical configurations; *No* means it is omitted or you use another area of  for the same job (see the note after the table). Labels and fields inside a tab can differ by service type and release. For end-to-end portfolio tasks that reference these tabs, see xref:omni-overview.adoc[].
+
+[cols="2,3,^.^,^.^,^.^,^.^,^.^",options="header"]
+|===
+|Tab |What You See |API |Agent |MCP server |LLM proxy |Gateway
+
+|*Overview*
+|Status, average latency, daily cost, and a short summary of what the service does.
+|Yes |Yes |Yes |Yes |Yes
+
+|*Connections*
+|Relationships and integrations with other services, such as APIs, agents, or MCP servers.
+|Yes |Yes |Yes |Yes |Yes
+
+|*Instances*
+|Deployed instances, environments (for example production or sandbox), and gateways when that catalog type supports instances.
+|Yes |Yes |Yes |Yes |No
+
+|*Policies*
+|Governance policies attached to the service or its instances (access, data, performance, compliance, and related domains your organization uses).
+|Yes |Yes |Yes |Yes |Yes
+
+|*Monitoring*
+|Runtime metrics and analytics for health and usage when the system surfaces them for the service or gateway you are viewing.
+|Yes |Yes |Yes |Yes |Yes
+
+|*Conformance Report*
+|Compliance score and rule-level analysis for conformance reporting where that tab is available.
+|Yes |Yes |Yes |No |No
+
+|*Governance*
+|Governance policies and rules for the service and its instances, including gateway-wide or organization-level views where the system exposes them.
+|Yes |Yes |Yes |Yes |Yes
+
+|*Versions*
+|History of changes to the service configuration so you can compare before and after updates.
+|Yes |Yes |Yes |Yes |Yes
+|===
+
+[NOTE]
+====
+* *Instances* tab is available on *Agents*, *MCP Servers*, *LLMs*, and *APIs*; *Gateways* do not include an *Instances* tab. See xref:omni-overview.adoc[].
+
+* *Conformance Report* on the detail page aligns with *Agents*, *APIs*, and *MCP Servers*; for gateways, compliance work is framed through *Governance* and related flows at the scope the system supports. See xref:omni-overview.adoc[].
+====
+
+== Open a Service Detail Page
+
+. In *Portfolio*, open the catalog for the service type (for example *APIs* or *Agents*).
+. Use the search box to find the service by name or description, or scan the list or grid.
+. Click the service card to open its detail page.
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-add-services-to-portfolio.adoc[]
+* xref:omni-add-instances.adoc[Add Instances to a Service]
+* xref:omni-add-policies.adoc[Add Policies to a Service]
+* xref:omni-add-monitoring.adoc[Add Monitoring to a Service]
+* xref:omni-add-governance.adoc[Add Governance to a Service]
+* xref:omni-add-versions.adoc[Add Versions to a Service]
diff --git a/modules/ROOT/pages/omni-view-token-usage-response-performance.adoc b/modules/ROOT/pages/omni-view-token-usage-response-performance.adoc
new file mode 100644
index 00000000..a3f91f7b
--- /dev/null
+++ b/modules/ROOT/pages/omni-view-token-usage-response-performance.adoc
@@ -0,0 +1,26 @@
+= View Token Usage and Response Performance
+
+Token usage and model response characteristics help you understand cost drivers and quality for LLM-backed services in your portfolio. When the enhanced experience surfaces these signals, you can compare traffic patterns across environments and tune governance controls your organization adopted.
+
+Charts and tables appear only when your tenant connects the right data sources and your service type supports the metrics. If a view is empty, confirm with your administrator that usage telemetry is flowing and that your account has access.
+
+== Where These Signals Appear
+
+* *Governance* > *Cost Management* — Organization- or strategy-level views of token usage and related spend indicators when your administrator enabled cost tooling.
+* Service detail pages — Some LLM proxies and related services expose usage or performance summaries on the *Overview* tab or dedicated analytics areas your release provides.
+* *Observability* — When configured, dashboards or reports may aggregate token and latency series alongside other runtime signals.
+
+Navigation labels can differ; follow the UI your business group was assigned.
+
+== How You Use the Data
+
+* **Cost optimization** — Identify high-volume tools, models, or routes so you can apply xref:omni-create-governance-strategies.adoc[strategies] such as tool mapping or sanitization where supported.
+* **Performance triage** — Correlate spikes in latency or errors with deployments, policy changes, or upstream model behavior.
+* **Planning** — Share stable trends with finance and platform teams when you forecast capacity or licensing needs.
+
+== See Also
+
+* xref:omni-overview.adoc[]
+* xref:omni-create-governance-strategies.adoc[]
+* xref:omni-monitor-your-services.adoc[]
+* xref:omni-view-detailed-metrics-for-services.adoc[]