Enabling Boundless Intelligent Collaboration: UModel Now Open Source, Launching the Universal Semantics Standard Initiative

Let data speak the same language and enable boundless intelligent collaboration.

Hangzhou, May 20, 2026 — At the 2026 Alibaba Cloud Summit, Alibaba Cloud officially open sourced Unified Model (UModel) and launched the Universal Semantic Standard (USS) industry initiative, aiming to break down the fundamental barriers of semantic fragmentation in enterprise data and build a semantic foundation for large-scale AI implementation.

Every system in an enterprise faithfully records facts. The alerting system records anomalies, the log platform saves fault samples, the Trace system records invocation chains, Kubernetes manages running status, the release systemrecords changes, the Configuration Management Database maintains configurationrelationships, CRM tracks customers, and ERP manages orders and inventory.However, enterprise digitalization and intelligent transformation faces a long-underestimated fundamental barrier — semantic fragmentation.

• Pervasive data silos: According to industry research, enterprises use more than 30 Software as a Service tools and internal systems on average.Data is scattered across hundreds of "data chimneys" such as O&M monitoring, business systems, financial platforms, and customer management. A "checkout-service error rate spike" may simultaneously be associated with a recent release, a downstream dependency timeout, abnormal restarts of three pods, and an SLO violation — these clues are scattered across five or six systems with no unified object border, relationship structure, or evidence chain between them. Engineers rely on experience to jump between systems and piece together context, spending over 80% of their time "finding info" rather than "making judgments."
• Semantic inconsistency as a pervasive problem: For the same "sales" indicator, finance, operations, and e-commerce each have their own set — three numbers, three meanings, and three definitions sharing the same name. The same problem is equally common in the O&M realm: different monitoring platforms use different collection methods, formulas, and time windows for "error rate." Cross-platform troubleshooting often becomes a semantic translation marathon. To snap the different expressions of the concept "customer" across three systems (account, buyer, and customer_id), data analysts may need to spend two days on caliber mapping before they can begin actual analysis work.
• Large-scale AI implementation blocked: Without unified semantic context, AI agents cannot reliably understand the meaning of data across platforms and frequently hallucinate, significantly undermining intelligent decision-making quality. In the past, human experience could bridge this semantic gap at the cost of low efficiency but controllable results. However, when enterprises begin involving AI agents in O&M, customer service, analysis, and automated decision-making, the gap shifts from an "efficiency problem" to a "capability problem" — an agent can invoke ten tools and retrieve ten sets of data, but cannot determine whether they belong to the same service, the same change, or the same causal chain. Without semantics, AI cannot establish cross-system data associations and causality. It can only summarize single-source data and cannot support end-to-end intelligent decision-making.
• Collaboration costs increase exponentially: Data semantics across departments, systems, and tools are disconnected, resulting in persistently high communication friction. A simple data analytics task can take 3–5 days to snap definitions, translate fields, and confirm meaning — less than 20% of the time is actually spent on analysis and decision-making. Businesses don't lack data, and they don't lack tools. What's missing is a unified semantic runtime that makes the enterprise world understandable to people, systems, and AI. To solve the above problems, Alibaba Cloud officially open sourced Unified Model (UModel) at the Cloud Summit on May 20.

1.UModel: Object Graph Semantic Runtime for Enterprise AI

As the core technical solution built by Alibaba Cloud to solve the above problems,UModel is an object graph semantic runtime for enterprise AI. It uses objects and relationships to describe the enterprise world, making these descriptions queryable, authenticatable, and programmable for Agent invocation. It is not another observability tool, Configuration Management Database, or knowledge graph. It sits on top of these systems and organizes the existing facts within them into a unified object graph. By combining the corresponding capabilities, it transforms enterprise data from "being recorded separately by each system" to "being uniformly organized, queried, authenticated, and invoked around objects." For the core problems of enterprises, UModel provides clear solutions:

(I) Design Choices of UModel
The UModel approach differs from most data integration solutions. The following three design choices determine its engineering form — first define the object, make the specification verifiable, and then connect existing systems based on a stable specification.

• Object First: Define borders before mapping data A common override path is "data first" — connecting data from multiple systems to the same platform and then trying to aggregate objects from it. The problem with this path is that the same business entity has different expressions in different data sources, each aggregation requires remapping, and the mapping result is unstable — the "service A" aggregated today and the one aggregated tomorrow may not be the same thing.

UModel chooses to bear the upfront modeling cost: an object is defined once, and its identity and relationship structure remain stable regardless of pod reconstruction, data source switching, or new system integration. This cost is naturally amortized across multiple scenarios—the same EntitySet can be shared by O&M agents, analysis agents, and Customer Service agents.

• Specification as Code: Turning Semantic Specifications into Verifiable Engineering Assets Most enterprises also have data dictionaries or semantic specifications—usually wiki pages or Excel sheets. The problem is: outdated documents don't throw errors, renamed fields don't trigger diff tooltips, and there's no way to verify whether two teams understand the same concept consistently. Over time, specifications gradually drift from reality and become untrusted artifacts that no one relies on.

UModel manages semantic specifications as code: model changes go through PR review, imports include schema checksum validation, and whether different implementations understand the same set of semantics is automatically verified using Conformance Cases. Specifications aren't "valid just because they're written"—they "only count when tests pass," solving the disconnect between specifications and reality at the root.

• Connect, Don't Replace: No Data Migration, Just Semantic Bridges The object graph stores "who the object is, what the relationship is, and where the evidence can be found."

UModel connects to existing data sources through semantic mapping — describing "where to look up an object's indicators and where to find its logs" instead of moving data over. Data stays in place, semantically organized in UModel. Compared with aggregating all data to a unified platform (high cost, long epoch, and fragile MPS queue), the cost of connecting existing systems is far lower than replacing them. Enterprises can implement incrementally without refactoring their existing IT architecture.

2.Technical Advantages of UModel

• Object graph traversability: automatically assemble complete context along relationships This is the most core technical capability of UModel. In the object graph, each entity is connected to other entities through typed relationships: a devops.service is associated with the devops.deployment that deploys it, the devops.slo that measures it, the devops.team it belongs to, and the k8s.workload that runs it. These relationships are not diagrams drawn in documents — they are topology data queryable at runtime.

Given any object, its complete relation network can be traversed through a .topo query. The agent does not need to know in advance "which systems should be checked to troubleshoot a service failure" — it starts from the failure object and traverses the graph to find associated deployments, changes, SLO violations, and downstream dependencies. The causal chain emerges along the graph structure, without relying on prompt engineering guesses.

• Link system: turning "where is the data" into a property of an object UModel doesn't just define "what objects exist" — it connects objects and their evidence completely through the Link system. DataLink connects entities with observed data: a devops.service is associated with its indicator set, log set, and trace set through DataLink, and describes how to locate specific monitoring data from the entity through field mapping (for example, entity field service_id corresponds to indicator label monitored_service_id). StorageLink connects datasets with physical storage: which MetricStore the indicators are stored in and which LogStore the logs are stored in are described by StorageLink — this makes "where the data is" part of the object graph instead of being scattered in configuration files or in the memory of O&M engineers. EntitySetLink defines the topology relationship semantics between objects.

The three types of Links combine to make the object graph a complete semantic description of "who the object is, where the evidence is, and how to query the data." After obtaining an object, an agent can follow Links to find the query paths and storage positions of its indicators, logs, and traces — even if the agent currently needs to execute queries against the corresponding data sources itself, it at least knows where to query and what conditions to use.

• Vendor-neutral, specification-first: the semantic layer is not bound to any platform
  Neither the semantic definition nor the runtime services of UModel are tied to a specific vendor or platform:

• GraphStore Provider abstracts the storage backend — currently providing three implementations: memory, file.memory, and local.ladybug. Enterprises can develop their own providers to connect to existing graph databases or storage systems.

• Multi-domain coexistence — Models for DevOps, Kubernetes, and business systems can be defined in different domains of the same workspace and associated through cross-domain EntitySetLink. In the previous traversable object graph example, devops.service → k8s.workload is a cross-domain relationship.

• Model definitions and public contracts (OpenAPI, MCP schema, and software development kit types) are standard format files that do not depend on specific toolchains.
  This design allows enterprises to adopt incrementally: first define the model for one realm, authenticate the value, and then extend to other realms — the evolution of the semantic layer is not affected by underlying storage changes or platform switching.

3.Umodel Evolution Route Planning

This open source release and initiative is just the first step for UModel. The following capabilities have been internally authenticated and will be gradually available in subsequent versions:

• USearch:unified semantic search. The current Query Service provides structured object graph queries (.umodel, .entity, .topo), suitable for exact access to known object types and IDs. USearch complements the ability to quickly locate entities based on entity fields — supporting inverted index exact match, vector semantic approximate search, and hybrid retrieval. When an Agent faces blur clues (a service name fragment, a fault description), USearch allows it to quickly converge to a specific entity, then expand the context through the object graph.
• Platform as a Service API: object-level semantic query. The open source version of Query Service queries the object graph itself (model, entity, topology). The Platform as a Service query proxy solves the next problem: given an entity, how to obtain its associated data? Based on the mapping between DataLink and StorageLink, it translates object-level intents such as "query checkout-service fault rate indicators" into executable search statements — but is not responsible for execution. The returned search statements are executed by the AI Agent or upper-layer system in the corresponding data source.
• More realm models and providers: Continuously expand model packages across realms such as databases, MSMQ, Cloud Products, network devices, and business systems. At the same time, more GraphStore Provider implementations are available to support enterprises in persisting object graphs to the Graph Database or storage backend of their choice.

4.Administration Models and Participation Paths

UModel is now officially open source: the core closed loop can run locally, semantic specifications and Query Service are stable, and AgentGateway / MCP is active. Production-level graph storage providers, broader realm model coverage, and large-scale performance authentication are the directions that need to be advanced by the community together — which also means now is the most effective participation window to influence the project direction.

• 1 minute: Star the project and follow the latest developments.
• 5 minutes:Try the demo. Pull the code and execute make quickstart. Open the Web UI to browse example object graphs and get an intuitive understanding of the solution capabilities.

• Half a day: Make your first commit. Read the model definitions in examples/quickstart multidomain/→ Define 3 EntitySets for a realm you are familiar with → Add relationships and sample data → Submit a PR.
  Ongoing contribution directions (see project documents for detailed contribution guidelines):

• Realm model: Contribute EntitySet and relationship definitions for realms such as databases, MSMQ, Cloud Products, and business systems.

• GraphStore Provider: Connect to a new graph storage backend to drive production-grade storage capabilities

• Agent tools: Contribute MCP tools, query templates, and prompts to reduce agent exploration cost

• Conformance Case: Write consistency authentication use cases to ensure different implementations understand the same set of semantics

5.Quick Start

Quick Start
This open source release provides a complete closed loop that can run locally: define the model → import workspace → write entities and relationships → unified query → agent exploration → consistency authentication. The repository contains the full test suite (contract / integration / e2e / golden tests) constraining the public contract.

Startup

make quickstart

Three portals are active after startup:

• API: localhost:8080 (REST + MCP)
• Web UI: localhost:5173 (browse object graph, execute queries, view agent tool list)
• Preloaded data: demo workspace with multi-domain model examples including DevOps, Kubernetes, and supply chain

Developer Perspective: Command-Line Interface (CLI) and Web UI

Query the object graph with the command-line interface (CLI):

# What does the checkout-service object look like?
umctl query run demo \
  ".entity with(domain='devops', name='devops.service', query='checkout') | limit 10"
# What objects is it directly related to?
umctl query run demo \
  ".topo | graph-call getDirectRelations([(:\"[e-mail]\" {__entity_id__: '10000000000000000000000000000101'})]) | limit 10"

You can also open the Web UI directly — browse object types and instances in the Explorer view, interactively execute the above queries in the Query view, and visualize the object relationship topology in the Graph view. For complete query syntax, see the document. Agents do not need to handwrite these statements when invoking through MCP.

AI Deep Scenario: Agent Systematic Troubleshooting Through MCP + Runbook

The checkout-service example above is single-cause, interference-free — the agent can find the answer by walking a few steps along the graph. However, failures in real production environments are often more complex: the cause is not a single change but a superposition of multiple changes, misleading clues interfere with judgment, and key evidence is scattered across different systems managed by different teams. When there are more than 5 clues involving more than 3 management domains, pure graph traversal is not enough — you need a structured diagnostic protocol to ensure the completeness and correctness of the troubleshooting.

Scenario: 02:17 AM, payment-gateway P99 latency breaches SLO

The on-duty SRE is woken up by an alert. payment-gateway is a platinum-level service — every minute of abnormal behavior means direct business loss. A quick determination is needed: roll back the most recent deployment? Scale out? Or is there another cause?

Timeline:

• T-24h: The retry configuration of checkout-service was changed from 2 to 5 (a routine Configuration Change; traffic was normal at the time and no issues occurred)
• T-4h: The 618 promotion was activated, and traffic began climbing to 3.5x
• T-0: Alerting triggered, P99 latency > 2000ms What makes this difficult? The root cause is not a single management event, but the superposition of two independent changes within a specific time window: the Configuration Change alone would not cause issues (4000 × 2.5 = 10,000 QPS, within capacity); the promotion traffic alone would not cause issues either (4000 × 3.5 = 14,000 QPS, acceptable). But when both take effect simultaneously: 4000 × 3.5 × 2.5 = 35,000 QPS, 8.75 times the normal capacity — payment-gateway is overwhelmed.

Trickier still: there was a deployment 12 hours ago. An SRE's first instinct is to suspect it—"what changed recently" is a cognitive shortcut for troubleshooting. But this time it's a red herring: the change was a log format adjustment, unrelated to latency. If you intuitively rollback this deployment first, the problem won't be resolved, and you'll have wasted valuable time.

Moreover, key clues belong to different management domains: alerting and deployment records are in the Platform domain (managed by the O&M team), while promotions are in the Business domain (managed by the business team). In traditional troubleshooting, SREs may not even know a promotion is underway—until they call the business team.

payment-gateway (degraded, platinum SLO)
  ← calls ← checkout-service
               ← affects ← cfg-checkout-retry (max_retries 2→5, 24h ago)
                              ← triggers ← 618 Flash Sale (3.5x traffic)
Exclusion: payment-gw v3.2.1 (12h ago, trivial logging change)
Root cause: 4000 × 3.5 × 2.5 = 35,000 QPS → 8.75x overload

UModel's answer: Runbook—a diagnostic protocol executable by agents

UModel solves such complex scenarios through Runbook. A runbook is not a document or a wiki—it is a structured protocol that agents can execute programmatically, comprising three layers:

Observation (what to check): Defines the specific steps for each check item—which entities to query, which relationships to traverse, and which fields to compare.
Conclusion (how to judge): Define matching conditions for each observation—what conditions are met to draw what conclusions, and what the severity level is.
Knowledge (why it is a problem): Provides interpretations and compute formulas for failure patterns to help the Agent understand rather than just match.
Unlike retrieval-augmented generation, which allows the Agent to infer on its own after retrieving documents (prone to omissions and non-reproducible), Runbook ensures two things: completeness—it will not forget to check the key factor of service traffic; determinism—the same data, executed at different times by different models, yields consistent conclusions.

In this scenario, the platform.service.ops Runbook defines three observations for the Agent: upstream_retry_amplification (check upstream retry configuration), recent_deployment_correlation (exclude or confirm recent deployment), and business_traffic_pressure (detect service traffic pressure). The Agent executes them one by one according to the protocol and does not skip subsequent checks just because there was a "recent deployment."

From UModel to Universal Semantic Standards: Something No Single Enterprise Can Accomplish Alone

Alibaba Cloud serves more than 4 million enterprise customers worldwide and has deep product expertise in observability, data governance, and enterprise intelligence. Through years of serving enterprise customers, we have come to recognize the systematic barriers that semantic fragmentation poses to unlocking data value and implementing AI. Enterprise semantics spans too many realms, too many scenarios, and too many existing systems — O&M has its own object models, business has its own entity definitions, and each industry has its own domain knowledge. This is by no means something a single company can accomplish alone. We firmly believe that unification and openness are the only keys to unlocking the full value of enterprise data and the full potential of AI.

Therefore, alongside the open source release of UModel, Alibaba Cloud officially launches the Universal Semantic Standard (USS) industry initiative — an open source collaboration schedule for the entire industry that aims to fundamentally solve the "semantic dialect" problem of enterprise data and reshape the way humans interact with data and data interacts with applications.

We have joined hands with the first batch of founding members, including industry benchmark enterprises such as Chanjet, Shenzhou Shanglong, XPeng, Zhuoyu Technology, and JLCPCB, as well as industry institutions such as CAICT and the Chinese Academy of Sciences, covering ecosystem partners in cloud computing, observability, BI analysis, enterprise software, and other fields, to jointly lay the foundation for building a more open, interconnected, and intelligent enterprise data ecosystem. Through the USS initiative, we aim to work with partners to confront the core obstacle to artificial intelligence in the enterprise domain — the lack of unified semantic standards. This is an industry collaboration that transcends competition, with the goal of jointly solving the fundamental problem of enterprise data intercommunication and mutual recognition.

(I) Core goals and principles of the Universal Semantic Standard initiative
The core objectives of the USS initiative are: to establish a set of common, vendor-neutral enterprise-level semantic model specifications that provide unified semantic representation for all types of enterprise data, including indicators, logs, traces, management events, and business entities; to enable seamless semantic interoperability among enterprise business software, O&M tools, and AI agents; and to accelerate digital transformation and large-scale AI implementation across industries. By providing unified, standard semantic specifications, the initiative ensures that all enterprise data is defined consistently and value-aligned across platforms, departments, and systems, completely eliminating semantic ambiguity across tools, departments, and systems. The initiative follows five core principles:

• Standardization: Establishes a unified enterprise semantic model definition language and data structure, covering core elements such as business entities, indicator definitions, log fields, trace labels, and alerting rules, ensuring consistency and interpretability across tools and systems.
• Interoperability: Facilitates seamless data exchange and cross-platform application of semantic models among diverse enterprise systems such as application performance management, log platforms, artificial intelligence for IT operations, BI tools, CRM, and ERP.
• Scalability: The semantic model supports flexible extension and customization, meeting evolving requirements from monolithic applications to cloud-native microservices, from traditional IT to large-scale distributed systems, and from general business to industry-specific scenarios.
• Open source collaboration: Driven by the open source community, encouraging global developers, vendors, and enterprises to participate and contribute, ensuring the frame maintains sustained vitality and relevance amid rapid technological iteration.
• Domain-specific modeling: Provides standardized semantic representations for typical enterprise scenarios—such as O&M golden signals, SLO/Service-Level Agreement definitions, business indicator systems, customer entity models, and supply chain relationships—simplifying the integration and reuse of multi-source data. USS fully respects and is compatible with existing excellent industry standards. It is not intended to override them, but to provide a unified semantic framework at a higher abstraction layer. OpenTelemetry defines the naming conventions for traces/metrics/logs in the observability realm but does not cover business data semantics—USS extends upon this foundation to cover all enterprise scenarios. Open Semantic Interchange (OSI) addresses the problem of semantic model exchange between BI/analysis platforms—USS collaborates and complements it, covering a wider range of enterprise application scenarios. The Schema.org/W3C Semantic Web standards provide common semantic tagging and ontology modeling capabilities—USS draws on their design philosophy but focuses on the practical requirements of an enterprise's internal data ecosystem. USS serves as a semantic unified layer for all enterprise scenarios, bridging downward to domain-specific proprietary standards while providing a unified semantic context across systems for AI agents.

(II) Expected Results
Through the USS initiative, we will jointly achieve:

• Accelerate enterprise AI scaling: A unified semantics standard enables AI models to truly "understand" the meaning of data from different platforms and departments, significantly improving the accuracy and deployment speed of AI applications across all scenarios, including artificial intelligence for IT operations, intelligent customer service, intelligent analysis, and intelligent prediction.
• Reduce data governance costs by an order of magnitude: A universal semantics standard provides a common language for enterprise data architectures spanning multiple data sources, tools, and systems, freeing data teams from tedious metric snap and field translation so they can focus more on data value mining.
• Ensure vendor neutrality and freedom of choice: The frame is independent of any specific platform or AI tool vendor, giving enterprises true freedom of choice when building digital infrastructure and avoiding vendor lock-in.
• Build an enterprise-grade "semantics operating system": Upgrade from a passively consulted "data dictionary" to a live, proactive semantics runtime that can be programmatically invoked by AI agents, laying the foundation for future large-scale multi-agent collaboration across enterprises.

6.Conclusion

At this pivotal moment when AI is penetrating enterprise production systems at scale, semantic unification of data has become the core foundation for industrial upgrade. The UModel and USS initiatives are our answer for this era — ensuring data is no longer scattered fragments and enabling AI to truly understand how enterprises run.

The core philosophy of UModel is clear and resolute: reconstruct an enterprise's business and data worlds into a unified object graph, enabling AI to understand the complete context along the relationships between entities and make reliable judgments based on traceable evidence. As the capability boundaries of agents continue to expand, what truly constrains the release of their value will no longer be the upper limit of the model itself, but whether the enterprise's business world can be truly understood and perceived by AI. The mission of UModel is to bridge this critical semantic gap — so far, we have taken the lead in completing the implementation and validation of this path in the observability realm, proving its feasibility.

Achieving this goal is by no means something a single team can accomplish alone. That is why we chose to open source the project and launch the Universal Enterprise Semantic Standards initiative — we firmly believe that the right path for this undertaking is rooted in the spirit of open collaboration, and we uphold three open principles: open standards and specifications, open technology implementation, and open effect verification. Starting from observability scenarios, we have completed the initial implementation of our methodology. Now, we look forward to working hand in hand with community partners to gradually extend the capabilities of the enterprise object graph from this realm to the broader landscape of data governance, business systems, and cross-domain collaboration.

We sincerely invite every industry peer — whether you are an enterprise software vendor, an AI solutions provider, a developer in the open source community, or an enterprise user across industries — to join us on this pivotal journey to build a more open, more connected, and more intelligent enterprise data ecosystem. We believe that through open collaboration, we will jointly drive the transformation of enterprise AI from "fragment summarization" to "deep understanding," and together create a truly AI-perceptible intelligent enterprise future.

Let data speak the same language. Let intelligence collaborate without boundaries.