Building Industry AI Semantic Foundations: MBSE Guides OPM & Ontology

The previous article "From Data to Model Flywheel: Why Model-Data Resonance Cannot Do Without Ontology" stated that "model-data resonance" must connect industry models, scenario data, and business practices into a continuous feedback flywheel. Ontology is important, but starting solely from ontology risks reducing the semantic foundation to a concept system, a knowledge graph, or a vocabulary list.

Industry AI deployed in real business scenes must address business understanding, process modeling, state tracking, interface collaboration, result verification, and continuous feedback — not just single-point knowledge representation. Therefore, the proper sequence is:

<ol><li><code>First, use MBSE to establish the methodology for complex system modeling and verification.</code></li><li><code>Then, use OPM to express how objects, processes, and states operate.</code></li><li><code>Finally, use ontology to consolidate unified concepts, relationships, and semantic assets.</code></li></ol>

In short, MBSE is the overarching methodology, OPM is the business runtime modeling method, and ontology is the semantic normalization and knowledge representation method. Combining all three yields a semantic foundation that truly meets industry AI needs.

MBSE: The Systems Engineering Methodology

MBSE (Model-Based Systems Engineering) is not merely drawing architecture diagrams or replacing documents with models. Its core value lies in using models to organize requirements, functions, architecture, behavior, interfaces, constraints, verification, and runtime feedback within complex systems. It addresses questions such as:

What are the business goals?

Which functions fulfill the requirements?

Which systems, components, or roles do functions depend on?

What interfaces exist between systems?

Does behavior comply with constraints?

How are output results verified?

How does runtime feedback feed back into the model?

This is critical for industry AI because industry AI must integrate with real business systems — processes, data, equipment, personnel, rules, tools, model outputs, and human confirmations. Without MBSE, AI remains a point capability:

<ol><li><code>Can answer questions but does not know the business closed loop.</code></li><li><code>Can generate content but does not know process state.</code></li><li><code>Can analyze but does not know how to verify results.</code></li><li><code>Can call tools but does not know boundaries and constraints.</code></li></ol>

The semantic foundation is not about size or completeness from the start. It must first answer: which business scenario is supported, which system problem is solved, and how to verify whether AI truly creates value. This is the engineering boundary MBSE sets for the semantic foundation.

OPM: Expressing Business Runtime Processes

MBSE provides the systems engineering methodology, but a modeling method capable of expressing objects, processes, and state changes is needed for concrete industry business operations. This is where OPM (Object-Process Methodology) adds value. OPM focuses on the relationships among objects, processes, and states. It emphasizes:

<ol><li><code>Objects participate in processes.</code></li><li><code>Processes change object states.</code></li><li><code>State changes affect subsequent processes.</code></li></ol>

This fits industry AI because many industry problems are not about "querying a knowledge point" but understanding how business is running. Examples include:

A device transitioning from normal operation to abnormal alarm.

An order moving from creation, review, execution to closure.

A product batch progressing from production, inspection to traceability.

A network alarm from detection, analysis to disposition.

A software requirement from proposal, design, development, testing to release.

In these scenarios, the key is not just objects or process nodes, but object state changes during processes. If AI cannot understand these state changes, it cannot know the current business stage, nor decide what to check, whom to alert, what content to generate, or which tool to call. OPM grounds the business processes from MBSE into expressible runtime models, answering:

<ol><li><code>What are the business objects?</code></li><li><code>What processes do objects undergo?</code></li><li><code>Which states do processes change?</code></li><li><code>What subsequent actions do state changes trigger?</code></li></ol>

With this step done, industry AI moves beyond "understanding data" to "understanding business operations."

OPM Enables AI Agents Beyond Prompts

The future key form of industry AI will not be just chat windows; more capabilities will enter business processes via AI Agents. However, Agents cannot run on prompts alone. They must know the current business object, the process it is in, whether state satisfies conditions, which actions can be automated, which require human confirmation, which results need audit trails, and which feedback can optimize models. OPM provides this process and state context. If an Agent only knows concepts and relationships, it can only explain and answer questions. If it understands objects, processes, and states, it can perform checks, prompts, generation, verification, tool calls, and feedback at business nodes. Further:

<ol><li><code>OPM gives Agents process and state context.</code></li><li><code>Ontology gives Agents semantic boundaries.</code></li><li><code>MBSE gives Agents verification and accountability boundaries.</code></li></ol>

This is the foundation for Agents to shift from "answering questions" to "understanding business actions within processes."

Ontology: Consolidating Models into Unified Semantic Assets

With MBSE's engineering boundaries and OPM's object-process-state models, ontology is still needed to solve unified semantics. "Last" does not mean unimportant; rather, ontology should not be built in isolation from business scenarios and process models. Its value lies in consolidating the preceding system boundaries, business processes, and state changes into reusable semantic assets.

In an industry, different systems, departments, and roles may use different names for the same object or interpret the same metric differently. For example, a "device anomaly" may be an alert in the O&M system, a product risk batch in the quality system, a process impact in the production system, and a statistical indicator in management reports. Without unified semantics, these data remain siloed and cannot be truly understood by models or reused across scenarios.

Ontology clarifies:

What are the business objects?

What attributes do objects have?

What relationships exist between objects?

Which relationships represent composition, ownership, influence, source, support, or constraint?

Which concepts in different systems actually refer to the same business meaning?

Which judgments must satisfy business rules?

It turns OPM's objects, processes, and states from project-local models into reusable, governable, extensible industry semantic assets. Ontology is not for prettier concept diagrams but to give models, data, systems, and business people a common language.

Three-Way Relationship: MBSE Defines Method, OPM Builds Process, Ontology Consolidates Semantics

Viewed together, the relationship is clear:

<ol><li><code>MBSE: Determines methodology for complex system modeling, verification, and feedback.</code></li><li><code>OPM: Expresses business objects, processes, and state changes.</code></li><li><code>Ontology: Unifies concepts, relationships, constraints, and semantic assets.</code></li></ol>

They are not simply stacked nor interchangeable. The proper relationship is:

<ol><li><code>Use MBSE to guide modeling boundaries and verification loops.</code></li><li><code>Use OPM to build object, process, and state models.</code></li><li><code>Use ontology to consolidate models into reusable semantic assets.</code></li></ol>

Such a semantic foundation is not a static knowledge graph but an engineered capability supporting industry AI entering business processes, system operations, and continuous optimization.

An Executable Modeling Path in Five Steps

Translating this thinking into a construction path yields five steps:

Step 1: Use MBSE to clarify business scenarios, system boundaries, and verification metrics. Answer what business goals the semantic foundation serves, which systems, roles, processes, and data are involved, how AI output is verified, which actions can be automated, and which require human confirmation.

Step 2: Use OPM to model business objects, processes, states, and state changes. Identify core objects, specify which processes they participate in, how processes change object states, and what subsequent actions state changes trigger.

Step 3: Use ontology to unify objects, attributes, relationships, rules, and constraints. Consolidate OPM's objects, processes, and states into unified concepts, relationships, rules, and constraints, avoiding redefinition of semantics in every project or system.

Step 4: Map the semantic model to data, system interfaces, tools, and Agents. The semantic foundation must connect source system data, business interfaces, tool invocations, and Agent execution chains so model outputs can be consumed by business systems.

Step 5: Feed execution results, human confirmations, and business feedback back into semantic assets. Industry AI value is not a single inference or generation but continuous feedback. Execution results, human opinions, exception handling, and model effectiveness evaluations should return to the semantic model as scenario data for the next optimization round.

These five steps constitute the concrete implementation of "MBSE defines method, OPM builds process, ontology consolidates semantics."

Placing It Within the "Model-Data Resonance" Flywheel

Returning to the "model-data resonance" flywheel:

<ol><li><code>Industry models empower application practice.</code></li><li><code>Application practice generates scenario data.</code></li><li><code>Scenario data optimizes industry models.</code></li></ol>

For this flywheel to truly spin, a semantic foundation layer is essential. MBSE ensures application practice is not just a pilot function but a systems engineering loop with requirements, boundaries, verification, and feedback. OPM puts scenario data back into business runtime processes, explaining which object, process, and state produced the data. Ontology unifies these objects, processes, states, rules, and data into common semantics, preventing scenario data from being mere fields, logs, and metrics. Thus, industry model outputs can be understood by business, accepted by systems, confirmed by humans, verified by results, and finally reverse-precipitated as new scenario data. Otherwise, "model-data resonance" degrades into three disconnected activities:

<ol><li><code>Models do models.</code></li><li><code>Data stays data.</code></li><li><code>Business still relies on human understanding and fallback.</code></li></ol>

This is not the state industry AI truly needs.

Don't Reverse the Order

In industry AI semantic foundation construction, the order is easily reversed:

Starting with ontology tends to produce a large concept system that, without business scenarios, process models, and verification loops, becomes "concepts complete, landing difficult."

Starting with process modeling gets close to business but, lacking MBSE's systems engineering boundaries and ontology's unified semantics, becomes "one project, one model," hard to reuse.

Connecting LLMs directly to data platforms yields quick results but often stays at Q&A, summarization, report generation, and text analysis, struggling to enter real business processes.

The more reasonable order is:

<ol><li><code>First, use MBSE to clarify business scenarios, system boundaries, and verification loops.</code></li><li><code>Then, use OPM to model objects, processes, and state changes.</code></li><li><code>Finally, use ontology to unify concepts, relationships, rules, and semantic assets.</code></li></ol>

This is also the key for industry AI to move from point capabilities to systemic capabilities.

Summary

Industry AI's semantic foundation cannot rely on ontology alone. Ontology solves "how to unify semantics," but before that we must answer "what is the system problem," "how does the business process run," and "how are results verified." Therefore, the proper modeling path is:

<ol><li><code>MBSE defines method.</code></li><li><code>OPM builds process.</code></li><li><code>Ontology consolidates semantics.</code></li></ol>

MBSE gives the semantic foundation engineering boundaries, OPM gives it understanding of business operations, and ontology gives it reusable semantic assets. Only by connecting all three can industry AI advance from "can answer, can generate, can analyze" to "can understand business processes, can support system operations, can continuously optimize the model and data flywheel."