]> Huawei

christopher.janz@huawei.com

Huawei

henry.yu1@huawei.com

Huawei

hesam.rahimi@huawei.com

Ciena

ndavis@ciena.com

Telefónica

diego.r.lopez@telefonica.com

Network Management Research Group ontology ontology mediation large language models agentic AI cognitive network management data model translation This document describes a possible direction for inter-system communication in network management, in which two cognitive software agents establish between themselves the basis for exchanging information, without depending on a single rigid data model agreed by their implementers in advance. The agents bring relevant knowledge, can extend it through learning, can reason, and can converse in natural language. The approach is framed as a workflow in which each agent makes explicit the ontology implicit in its data model, the two agents address their differences through conversation, and a translator artefact is produced that is then used during ordinary operation. A central property is that language-model inference is consumed during the agents' conversation rather than on each subsequent message. The document situates the direction relative to adjacent work and illustrates it through three use cases drawn from network management.

Introduction Inter-system communication in network management is, today, predominantly arranged through shared data models: where systems implement the same model, or compatible profiles of it, the exchange is straightforward, and where they do not, the integration is engineered. Engineering the bridge between two data models is a substantial, recurring cost. Standard models do not anticipate every measurement source, every vendor extension, every operational subtlety; new sources need to be integrated as deployments evolve; occasional transactions need information at an abstraction level different from that of the ongoing conversation. The arrival of large language models, together with the broader move toward agentic software architectures, makes a different option conceivable. A software system that holds relevant knowledge, can extend it, can reason, and can converse in natural language is in principle able to do for itself - in dialogue with a peer that has the same capabilities - much of the bridging work that integrators do today. This document explores that direction. It describes a workflow under which two such systems might construct, between themselves, a translator that runs deterministically thereafter, and gives three illustrations of how the workflow might apply in network management. Pitfalls and considerations for implementation are collected in .

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used:

Cognitive Agent:

an autonomous software entity built around a Large Language Model and one or more controlled stores of knowledge, with the ability to extend its knowledge through learning, to reason about what it has been presented with, and to communicate in natural language.

Ontology:

an explicit account of what a domain admits as entities and of the relationships among them.

Data Model:

a syntactic and structural artefact - for example a YANG module or a JSON Schema - that carries an ontology implicitly through the structures it prescribes.

Ontology Mediation:

the activity of bridging two ontologies so that information expressed under one is intelligible under the other; comprises alignment (correspondence discovery), mapping (expressing correspondences as transformation rules), and merging (combining two ontologies into one, where appropriate).

Translator:

executable code or a set of declarative rules applied at the boundary between two systems that converts instances expressed under one data model into instances expressed under another; produced from a mediation and run deterministically thereafter.

Variable Abstraction:

the operational practice of presenting information at the level of detail appropriate to a particular interaction .

Background Communication between two systems depends on three things being sufficiently aligned: the ontologies that determine what each can talk about, the semantics that govern what particular utterances mean, and the syntactic conventions that govern how those utterances are expressed. Standard data models are an attempt to settle all three by agreement, in advance of any specific exchange. Where the agreement is complete, no further work is needed at exchange time. Where it is not, the residual gaps need to be closed by other means. Network management offers many reasons why complete prior agreement is not always available: deployments evolve; vendor extensions accumulate; different communities settle on different conventions for the same operational territory. A further consideration is that the appropriate level of abstraction depends on the purpose of an exchange. Two systems may communicate at a high level of abstraction for ordinary purposes and need a more detailed view for an audit or a diagnostic question. The operational practice of presenting information at the abstraction appropriate to a given interaction is known as Variable Abstraction Management , and it implies that no single fixed model is uniformly appropriate even between the same two systems. It is also worth recognising that some differences between ontologies are not bridgeable by any amount of description. Where one party has concepts the other has no basis for, no quantity of explanation will install them. A workflow of the kind discussed here MUST be able to acknowledge such a case and report it, rather than fabricate a correspondence.

Problem Statement Two systems are required to communicate for some purpose, but the data models they implement do not, between them, cover the matter unambiguously. The common situations are two: each system implements a recognisable standard model with partial overlap to the other, or the relationship between the two models is more ad-hoc. The customary response - hand-engineered translation logic, often with tool support - is expensive to produce and expensive to maintain across the evolution of the models. The direction explored in this document is whether two systems with the cognitive capabilities described in can construct that translation between themselves, calling on human expertise only where they cannot make further progress on their own.

A Reconciliation Workflow

The Conversation The workflow described here treats reconciliation as an iterative conversation between two cognitive agents, each acting on behalf of one of the communicating systems. At each iteration, the agents attempt to interpret material they have been presented with - a data-model instance, an ontology fragment, a description in natural language - against the knowledge each already holds. Where an interpretation is partial, the agents request and supply further information; the exchange can take a variety of forms, including natural-language description, examples and counter-examples, references to standards or to documentation that both agents can consult, structural sketches, and questions put to a human expert. When the two agents have a sufficient working understanding of one another's representation, each proposes the correspondences it will use to translate between the two and validates those proposals against representative cases. Where a translation, once exercised against later material, exposes a difference that the original conversation did not anticipate, the agents can return to the conversation and refine the artefact. In this sense the translator produced by the workflow is maintained rather than delivered. Implementations SHOULD make this iteration explicit, both to enable principled re-engagement and to support audit of the decisions made during the conversation.

Kinds of Difference, and Self-Extension Differences encountered between two ontologies fall into three textures that admit different treatments. Where both parties recognise a concept but name it differently, the resolution is a dictionary entry between the two names. Where both parties recognise a concept but one represents it more finely than the other, the resolution is for the finer party to convey the distinctions the exchange actually needs; pursuing distinctions beyond what the exchange needs is wasted effort. Where one party has an element with no counterpart on the other side, the treatment is more delicate. Three responses are available, and they are not equally good. The deficient side may refuse to accept the concept, which forces the peer to lose information that may be essential to its purposes. It may escalate to a human, which - if applied to every such case - undermines the value of automating the workflow in the first place. Or it may extend its own ontology, auditably, to host the foreign concept. This last option, which this document refers to as self-extension, is the response a reconciliation workflow SHOULD prefer where the available descriptions support it, with escalation reserved for cases in which no description suffices.

Lift, Mediate, Generate summarises the workflow. Each side begins with its data model and makes the ontology that the model carries explicit; the two agents mediate the differences by the conversational mechanism of ; and each side then generates the translator that will be used during ordinary operation. A useful property of this arrangement is that the language-model inference - the expensive part - is invoked during the conversation, not during ordinary message exchange. The translator runs deterministically thereafter, with the operational characteristics of conventional interface code. When the model on either side evolves, or when the translator begins to encounter instances it cannot handle cleanly, the workflow can be re-entered and the artefact refreshed; implementations SHOULD provide explicit triggers for this re-entry.

The reconciliation workflow. | | (description, examples, | | references, expert input) | v v +-----------------------------------------------+ | Agreed correspondences + decision record | +-----------------------+-----------------------+ | | generate v +-----------------------------------------------+ | Translator A <-> B (deterministic) | +-----------------------+-----------------------+ | v +-----------------------------------------------+ | Ordinary operation (no further | | language-model inference per message) | +-----------------------------------------------+ ]]>

Related Work The workflow described above touches several adjacent lines of research and engineering. Ontology mediation has a long-standing literature, with tools such as PROMPT and MAFRA and algorithms such as GLUE and S-Match , evaluated through the Ontology Alignment Evaluation Initiative using matchers including LogMap and AgreementMakerLight . This body of work has historically targeted large, published ontologies (biomedical references most prominently), and it routes the harder disambiguation decisions to a human reviewer; the present document is concerned with situations in which the ontologies are smaller and more locally scoped, and in which the decisions that classical tools route to a human are instead handled by the cognitive agents themselves. Since 2023, large language models have been incorporated into ontology matchers in several ways - as one-shot oracles on candidate correspondences , as components inside conventional pipelines , and through generation of textual definitions that are then embedded and compared . Agent-OM arranges the matcher itself as two cooperating LLM-driven agents, though those agents remain roles within a single matching system whose inputs and outputs are ontologies and alignments rather than communicating systems and translators. The idea of agents negotiating ontologies through dialogue is older still: Bailin and Truszkowski and van Diggelen and colleagues set out the shape of such negotiation when the cognitive substrate available was much thinner than today's large-language-model-equipped agents can offer. Two recent contributions - Gateway-X , building on earlier work , and AICEP - place language-model inference on the runtime data path, translating or grounding on each call. The workflow described here is not in opposition to either of those lines; where two large published ontologies must be aligned at scale, the classical matchers are more apt, and where genuinely unanticipated instances must be handled at the moment they arrive, runtime translation is an appropriate complement to a negotiated translator.

Illustrative Use Cases Three situations from network management practice illustrate where the workflow of might be applied. None of them is presented as a worked engineering case; each is a sketch of how the workflow could be used.

A New Source Joining a Knowledge Graph A management system that organises its working knowledge as a graph of entities and relationships needs, from time to time, to integrate a new source of evidence - a measurement instrument, an analytic engine, or a derived signal feed - into that graph. Today, such integrations are typically engineered. The workflow of suggests an alternative, in which the new source presents itself in natural language against a loose convention for describing what an evidence source has to offer (what is observed, on which entities, with what triggers, in what units, with what accuracy and how fresh). A cognitive agent acting on behalf of the management system - here called the Gateway - interprets that presentation against the current graph, identifying whether the kind of evidence is one the system already understands. If it is, the new source is registered as a further instance of a known kind, and no further interpretive work is needed. If the kind is new, the Gateway poses clarifying questions appropriate to what has been advertised, receives natural-language answers, and commits, in a single atomic step, both the augmentation of the graph's schema and the registration of the source. An acknowledgement closes the exchange, and the data subscription begins. Two properties of this arrangement are worth noting. First, the consequential work happens once per kind of evidence, not once per source: adding a second source of an already-understood kind is a routine registration, whereas adding the first source of a new kind requires interpretation. Second, every onboarding leaves an auditable trace - the presentation, any clarifying exchange, the schema change committed, and the registration - that can be inspected after the fact and, if a later observation casts doubt on the interpretation, revisited. sketches the message exchange. It is not intended as a protocol specification.

A possible exchange for onboarding a new source. Clarifying questions are needed only when the kind of evidence is new. | | | | (interpret against current graph) | | | | clarifying questions (only when | |<------------------ the kind | | answers ---- is new) | |-------------------------------------->| | | | (commit: schema augmentation if | | needed, registration, binding) | | | |<------------ acknowledgement ---------| | | | data follows | |-------------------------------------->| ]]>

Two Data Models, Independently Designed The second illustration is the more general one. Two systems hold data models for roughly the same operational territory but designed independently, and they need to be made to communicate. The workflow of would, in outline, have each agent first make explicit the ontology carried by its model, then engage in conversation to address the differences, and finally generate the translator that runs at its side of the boundary. To make the discussion concrete, the optical-transport domain offers two well-known YANG models in this shape: ONF TAPI on one side and the IETF TEAS family on the other, with over the network base , extended for optical transport by and . Both describe nodes, links, termination points, layering, switching, and services, in YANG, but each cuts the same operational reality in its own way. The TAPI and TEAS models are named here purely for illustration; the points that follow are intended to apply to two-data-model reconciliation in general. Several kinds of difference can be expected to arise. Some are matters of terminology - the same concept named differently in the two models, often recognisable as cognates. Some are matters of identity - one model naming elements through flat identifiers, the other through hierarchical ones - which the workflow can accommodate by recording a bijection between identity spaces that the translator subsequently applies. Some are matters of granularity - one model resolving a concept more finely than the other - which the workflow addresses by having the finer side convey the distinctions the exchange actually requires. Of greater interest are differences in how the same reality is decomposed. In the illustrative pair, TAPI represents the transport network as one multi-layer topology, with layer information attached to the termination points; the TEAS family represents the same reality as separate networks per layer, linked by supporting-network references. The workflow would, at this point, have to settle a structural translation that explodes one shape into the other and collapses back again, with the correspondences validated against worked instances before the translator is generated. Such a structural negotiation is the part of the workflow that would benefit most from explicit human attention during mediation. Of greatest interest are differences of scope: elements that one model represents and the other has no native place for. In the illustrative pair, IETF's TunnelTerminationPoint and TAPI's ServiceInterfacePoint are examples of concepts that have no direct counterpart on the other side. indicated that the workflow's preferred response to such cases is self-extension by the deficient side - extending its own ontology, auditably, to host the foreign concept - with escalation reserved for concepts that no description can install. Whether a particular case admits self-extension is a judgement the agents make in the moment, on the basis of the descriptions available to them; not every concept can be installed in this way, and the workflow is required to recognise when it cannot. Whether reconciliation by this workflow would succeed in any particular two-model case depends on properties of the models, on the knowledge the participating agents can bring to bear, and on the amount and quality of expert attention during mediation. This document does not claim that every such reconciliation can be completed without human intervention. Its claim is that the workflow is a direction worth exploring, that the kinds of difference encountered are bounded and broadly understood, and that the artefact produced - a deterministic translator generated once and then run - has the operational properties an IETF audience would expect of interface code.

A Punctual Shift in Abstraction The third illustration extends the second. Two systems have already established a working translation at one level of abstraction - say, intent-based service provisioning, where the consumer states what it wants and the provider satisfies the intent without exposing the resources used. On occasion, one side puts a question that the established translation cannot answer: an audit, for example, demonstrating that the resources carrying a service lie inside (or outside) a particular geographic region . The question requires information that the established mediation does not represent. A punctual application of the same workflow can address the situation: the agents extend the established vocabulary just far enough to support the response, produce the response under the extended vocabulary, and either retire the extension at the close of the transaction or retain it if further questions of the same kind are anticipated. In many cases this extension is asymmetric: where the response is intended for consumption by a human operator on the requesting side, the requesting system need not extend its own ontology at all; it receives the response as content, and the human consumes it directly. The responding system extends, produces, and then retires (or retains) the extension on its side alone.

Pitfalls and Considerations for Implementation Several considerations should inform any implementation that pursues the direction described above.

• A correspondence committed with high confidence but incorrect is more damaging than a flagged uncertainty. Implementations SHOULD surface uncertainty early and preserve the basis on which a decision was made, so that later review is possible.
• Agreement on what a term means does not, in itself, settle how the term is used in operation. Implementations SHOULD consider behaviour in addition to denotation, and validation SHOULD include exercise of the translated message in its consuming context.
• The depth of mediation should be governed by the purpose of the exchange. Pursuing parity for its own sake will spend effort that the exchange does not need.
• Some differences are not bridgeable by description. The workflow MUST be capable of recognising and reporting such cases.
• Engagement with human expertise SHOULD be designed - the route to the expert, the form of the question, the way the answer flows back into the agents' knowledge. Ad-hoc escalation is unlikely to age well.
• Every decision committed during a mediation SHOULD be traceable to the evidence that produced it. Building provenance in from the start is materially less costly than adding it after operational stress.
• The workflow assumes both sides are cognitive in the sense of . Where one side is a non-cognitive legacy system emitting only strict instances, the cognitive side has to do the work unilaterally, drawing what it can from the instances and from accessible documentation.

Security Considerations The workflow introduces security considerations beyond those of conventional model-driven exchange. The natural-language descriptions and worked examples exchanged during mediation are inputs to the agents' knowledge, and an adversary in a position to influence those inputs could attempt to mislead the resulting translator. Implementations SHOULD attach provenance and confidence to incoming descriptions and SHOULD support revocation of integrations whose origin is later found untrustworthy. Any decision that augments the system's effective ontology - onboarding a new source, accepting a self-extension during mediation, accepting a punctual extension - MUST be subject to authorisation appropriate to the operational role of the agent and MUST be auditable after the fact. Where a mediation involves presenting information at a level of detail more granular than would ordinarily be exchanged, policy controls MUST be enforced on what may be disclosed, to whom, and under what conditions, and anonymised or aggregated forms SHOULD be supported where finer detail cannot be released. The cognitive agents inherit the general risks of large-language-model-based systems, including prompt injection, hallucination, and miscalibrated confidence; implementations SHOULD apply the usual mitigations and require human review for decisions whose consequences are operationally significant.

IANA Considerations This document has no IANA actions.

Normative References Informative References Work in Progress Work in Progress Open Networking Foundation (ONF) ONF/OTCC specifications ETSI ISG ZSM ETSI GR ZSM 019 V1.1.1 International Journal of Human-Computer Studies, Vol. 59, No. 6, pp. 983-1024 EKAW 2002, LNCS 2473, pp. 235-250 VLDB Journal ESWS 2004 ISWC 2011 OTM Conferences, 2013 Ontology Alignment Evaluation Initiative CEUR-WS Vol. 4144 Ontology Matching Workshop, ISWC 2023, arXiv:2308.09217 arXiv:2309.07172 arXiv:2404.10317 (authors not listed) arXiv:2508.08500 GenOM Team World Wide Web journal, arXiv:2508.10703 Proceedings of the VLDB Endowment, Vol. 18, No. 3, pp. 516-529 NASA Technical Reports Server The Knowledge Engineering Review, Vol. 17, No. 1, pp. 7-19 International Journal of Agent-Oriented Software Engineering, Vol. 1, No. 1, pp. 63-90 IEEE/IFIP NOMS 2014 NetSys 2019 AIMLOps Workshop, IEEE/IFIP NOMS 2026 IEEE/IFIP NOMS 2026, Technische Universität Chemnitz

Acknowledgments The authors thank colleagues for discussions that shaped the ideas in this document, and members of the NMRG and NMOP for ongoing exchanges on the role of agentic AI in network management.