Department of Computer Science and Engineering

2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea rna0415@skku.edu http://iotlab.skku.edu/people-Moses-Gu.php

Department of Computer Science and Engineering

2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea +82 31 299 4957 pauljeong@skku.edu http://iotlab.skku.edu/people-jaehoon-jeong.php

Department of Computer Science and Engineering

2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea +82 31 299 4106 tlarlguswh@skku.edu https://iotlab.skku.edu/people-KiHyun_Shim.php

Network Management Internet Research Task Force Agentic AI, Intent, Intent-Based Networking, Policy, Network Management, Internet of Things, Schema-Constrained Generation This document describes an agentic AI workflow for detecting and mitigating structural and semantic errors, including hallucinated policy content, when translating a natural-language network intent into structured policies. The workflow coordinates role-specialized language-model functions with deterministic validation tools within a predefined action space and a bounded retry budget. Schema-constrained generation limits structural defects, while cross-slot checks and intent-faithfulness assessment identify a potentially unsupported or inconsistent policy content. Structured validation traces guide targeted re-extraction and regeneration. Unresolved cases retain explicit failure status for downstream review. This document describes component interactions, validation outcomes, and recovery behavior, and also presents a 3GPP TS 28.312-based instantiation for mobile network management.

The increasing scale and heterogeneity of networks and services make manual policy configuration and management increasingly difficult. Intent-Based Management is a paradigm that allows an administrator to specify desired outcomes through high-level intents, often expressed in natural language , , . These intents must then be interpreted, validated, and translated into structured policy representations that can be executed by network functions and orchestrators. Recent work has explored the use of large language models for this translation step . Standards such as 3GPP TS 28.312 define lifecycle procedures, and an OpenAPI schema for managing intents in mobile networks (e.g., 5G networks) and TR 28.812 describe the scenarios that motivate them. However, they do not specify mechanisms for interpreting natural language or translating it into compliant policy structures. A central difficulty observed in recent industry benchmarks is the so-called structural-semantic gap. A policy document may be syntactically valid against the schema while still being semantically incoherent across slots (e.g., declaring an object type that is incompatible with the chosen target metric). Linguistic proficiency of a language model alone is insufficient to close this gap. Standards-grounded structural constraints and post-generation validation are also required. This document defines a framework for detecting and mitigating structural and semantic errors in the translation of a natural-language network intent into structured policies. The contributions in this document includes the explicit connection between constrained policy generation, complementary validation checks, and failure-directed recovery. The proposed framework retains the parallel extraction and translation pipeline and illustrates its use through the policy modeling and management service interfaces defined in 3GPP TS 28.312 . The framework is composed of four functional components that operate in a partially parallel pipeline, plus a deterministic merge step and a feedback router: Scenario Extractor: It classifies an input intent along two axes - the management role (e.g., service customer, service provider, or network operator) and the deployment scenario (e.g., radio network, radio service, edge service support, or 5G core network) - producing a coordinate that routes downstream processing. Slot Extractor: It extracts entities and structured slot values (e.g., target name, target value, target unit, and target condition) from the same natural language input, in parallel with the Scenario Extractor. Intent Composer: It merges the outputs of the two Extractors into a single structured intermediate representation that the Policy Generator consumes. Policy Generator: It synthesizes a candidate policy document, typically serialized as YAML or JSON, under schema-as-grammar constraints derived from the target schema. Policy Validator: It evaluates the candidate policy along three dimensions: schema validity, cross-slot semantic invariants, and semantic faithfulness to the original natural language input. It produces a failure-mode trace when violations occur. A trace-driven recovery agent consumes the validator's failure-mode trace and dispatches targeted regeneration to the appropriate upstream component, rather than performing a generic retry. The design promotes modularity, transparency, and alignment with existing network automation architectures, enabling consistent translation of an operator's goals into policies that are interoperable with standard orchestration and management systems in network environments.

The scope is natural-language intent interpretation, policy generation, and pre-deployment validation and recovery. Checks are limited to the original intent, the selected schema and relational rules, and authoritative context explicitly supplied to the workflow. Few-shot examples illustrate representations; they do not establish facts or requirements for the current request. Autonomous control of operational networks, device-level policy enforcement, runtime intent assurance, and verification of network conditions not supplied to the workflow are outside this document's scope. The document does not specify independent agent runtimes, agent discovery or inter-agent communication protocols, or network digital twin integration. These capabilities are not prerequisites for the translation workflow. Error-free translation, quantified hallucination reduction, superiority over non-agentic approaches, and generalization across domains or models are not established by the preliminary implementation description. These are unvalidated claims, distinct from the architectural scope exclusions above; relevant evaluation considerations are given in .

The framework addresses the intent-translation function discussed in and . It focuses on errors within the translation workflow, while downstream orchestration and operational assurance remain separate functions. The broader application of agentic AI to the IBN lifecycle and network management is discussed in and . This document uses a bounded workflow definition of agentic behavior rather than prescribing a general autonomous-agent architecture. Model specialization and adapter composition are discussed in . The present framework instead focuses on validation evidence and recovery of candidate policy artifacts, regardless of whether the underlying model is specialized. Human review and audit of LLM-assisted network-management decisions are addressed in ; degraded translation results can be handed to such review processes. The separation of outcome and process metrics in informs the proposed evaluation considerations, without implying that this framework has demonstrated end-to-end network configuration correctness. These Internet-Drafts are work in progress and do not provide a universal normative definition of agentic AI.

This document uses the terminology defined in , , , , and . In addition, the following terms are defined for the purpose of this document: Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver), defined in a declarative manner without specifying how to achieve or implement them . Intent-Based Management (IBM): It enforces an intent from a user (or administrator) into a target system. An intent can be expressed as a natural language sentence and translated into a high-level policy using natural language interpretation and structured policy mapping , . This high-level policy is then transformed into low-level policies that are dispatched to appropriate Service Functions (SFs). Based on monitoring feedback, new rules may be generated or existing policies refined. Agentic Workflow: A coordinated translation process in which role-specialized language-model functions use structured validation feedback to revise intermediate representations or candidate policies under a bounded recovery policy. The term describes system-level feedback-driven behavior and does not prescribe independently autonomous agents, separate model instances, or a particular inter-agent protocol. Fixed routing policies and model-assisted selection are implementation choices; model-assisted planning is not required or claimed as an implemented capability by this document. Translation Hallucination: Generated policy content that asserts entities, attributes, relationships, or target values that are unsupported by or inconsistent with the input intent and explicitly supplied authoritative context, including declared schema rules and authorized defaults. Failure modes describe observed defects; a validation failure alone is not proof of hallucination or of a particular generating cause. Scenario Extractor: A logical function that receives a natural language input from the user or operator and classifies it along two axes: the management role (e.g., Communication Service Customer, Communication Service Provider, or Network Operator, as defined in 3GPP ) and the deployment scenario (e.g., RadioNetwork, RadioService, EdgeServiceSupport, or 5GCNetwork, corresponding to the IntentExpectation subclasses defined in 3GPP ). The output is a coordinate that constrains downstream component behavior. Slot Extractor: A logical function that, in parallel with the Scenario Extractor and given the same natural language input, extracts named entities and structured slot values (such as target name, target value, target unit, and target condition) required to populate the policy document. Intent Composer: A logical function that merges the outputs of the Scenario Extractor and the Slot Extractor into a single structured intermediate representation (typically a JSON document) consumed by the Policy Generator. The Intent Composer is a deterministic, schema-shaped aggregation step and does not itself perform language understanding. Policy Generator: A logical function that produces a machine-readable policy document, typically in a format such as YAML or JSON, from the merged outputs of the Scenario Extractor and the Slot Extractor. The Policy Generator operates under schema-as-grammar constraints that constrain per-token decoding against the target schema, such as that defined in 3GPP . Policy Validator: A logical function that evaluates a candidate policy document along three dimensions: (i) schema validity against the OpenAPI specification of the target standard, (ii) cross-slot semantic invariants such as the relation between object type and target name, and (iii) semantic faithfulness between the original natural language intent and the candidate policy. The Policy Validator emits a failure-mode trace identifying which dimension(s), if any, were violated. Trace driven recovery agent: A logical recovery-control function that consumes the Policy Validator's failure trace and selects permitted regeneration, re-extraction, or termination actions under a configured policy. The name denotes its role in the agentic workflow and does not require an independently autonomous or language-model-based controller. Policy Knowledge Base: A repository that maintains domain-specific knowledge used during translation, including the schema of the target standard, examples of valid policy documents (such as those provided in informative annexes of 3GPP ), and the relational invariants between schema fields (such as the mapping from object type to the set of valid target names). The Policy Knowledge Base supports schema-as-grammar compilation, few-shot retrieval, and cross-slot constraint checking. Schema-as-Grammar: A constrained-decoding technique that compiles a target schema (such as an OpenAPI specification or a JSON Schema) into a schema-derived grammar consumed by a language model decoder, so that each token continuation is constrained to keep the partial output extendable to a schema-admissible completion . The expressiveness of this grammar depends on the constrained-decoding implementation; not all schema features are expressible as efficient grammars, and post-generation validation is therefore still necessary. Schema-as-grammar may be applied at multiple levels, including the intermediate JSON representation produced by the Extractors and the candidate policy document produced by the Policy Generator. Failure Modes: Four complementary categories of observed intent-to-policy translation failure: (i) F-syn, syntactic or schema invalidity; (ii) F-sem, semantic mis-grounding or unfaithfulness to the original intent; (iii) F-val, value-range or unit errors; and (iv) F-xs, cross-slot inconsistency. Categories can co-occur, and a trace can carry multiple labels. A detecting component does not by itself establish the originating cause. F-val may be detected at the schema level or through comparison with the original intent. Not every structural defect or value-conversion error is a translation hallucination. Degraded Intent: A translation result returned when the retry budget is exhausted without satisfying the configured required checks. It records the residual failures or unresolved assessments and the most recent candidate policy. Its status remains explicit when it is passed to a human operator or a downstream validation pipeline; schema conformity alone does not establish that the result is semantically faithful or free of hallucination.

This section defines the architecture of the Intent Translator Framework for natural-language intent translation, validation, and bounded recovery. The following role-and-scenario classifications, target schemas, and relational invariants describe a 3GPP TS 28.312-based instantiation for mobile network management. Applying the same pipeline to another domain requires corresponding domain-specific definitions; such applicability is not established by the current preliminary experiments.

The Intent Translator is a modular subsystem responsible for converting natural language intent into a structured, machine-readable policy document suitable for enforcement in intent-based management systems. It forms the core of the intent translation framework, providing parallel extraction, schema-constrained generation, multi-dimensional validation, and trace-based adaptive retry. The final output is expressed in a structured format such as YAML and adheres to the policy modeling defined in . Architecturally, the Intent Translator operates as a partially parallel pipeline composed of four functional components, a deterministic merge step (the Intent Composer), and a feedback router (the trace driven recovery agent). The two Extractors execute in parallel on the same input; their outputs are merged by the Intent Composer and consumed by the Policy Generator. The Policy Validator then evaluates the candidate policy along three complementary dimensions, and the trace driven recovery agent uses the resulting failure-mode trace to dispatch targeted regeneration when needed. The pipeline supports schema-grounded extraction, schema-as-grammar generation, failure-mode-specific validation, and adaptive retry. It is designed to support transparent, extensible, and standards-aligned translation of human goals into actionable configurations.

The main components of the Intent Translator (Scenario Extractor, Slot Extractor, Intent Composer, Policy Generator, Policy Validator, and trace driven recovery agent) are illustrated in . Scenario Extractor: A component that classifies the input intent into a structural coordinate. In the 3GPP-based instantiation described here, the role is selected from Communication Service Customer (CSC), Communication Service Provider (CSP), and Network Operator (NOP), as defined in . The scenario is selected from four IntentExpectation subclasses in : RadioNetwork, RadioService, EdgeServiceSupport, and 5GCNetwork. These selected roles and scenarios form twelve cells that constrain downstream policy choices for this instantiation. Schema-as-grammar constraints restrict the output to this configured set; it is not a universal classification of network-management intent. Slot Extractor: A component that, in parallel with the Scenario Extractor and given the same natural language input, extracts named entities (such as area codes, user groups, or service identifiers) and structured slot values required to populate the policy document. Typical slots include target name, target value, target unit, and target condition. The Slot Extractor is also realized under schema-as-grammar constraints, so that entity types and slot enumerations (such as units and comparison conditions) are restricted to valid values at decoding time. Intent Composer: A component that merges the outputs of the two Extractors into a single structured intermediate representation (the Intermediate JSON) that the Policy Generator consumes. The Intent Composer performs a deterministic, schema-shaped aggregation - it does not itself perform language understanding. Policy Generator: A component that synthesizes a candidate policy document. It consumes the merged Intermediate JSON produced by the two Extractors and emits a candidate policy document, typically in YAML, that targets the schema defined in . The Policy Generator operates under schema-as-grammar constraints derived from the target OpenAPI specification, limiting token continuations to those admitted by the compiled grammar. Post-generation validation remains necessary because not all semantic or cross-slot constraints are expressible in the generation grammar. Optionally, the Policy Generator may be specialized to the target domain through supervised adaptation, for example by parameter-efficient fine-tuning over a corpus of intent-policy pairs. Policy Validator: A component that evaluates the candidate policy along three complementary dimensions and emits a failure-mode trace. The three sub-components are described in . Unlike a single pass/fail check, the failure-mode trace identifies which structural or semantic invariant was violated, enabling the trace driven recovery agent to take a targeted corrective action. Trace driven recovery agent: A component that consumes the failure-mode trace from the Policy Validator and dispatches targeted regeneration. The router supports failure-mode-specific corrective actions, such as regenerating the policy under additional structural constraints when a cross-slot violation is detected, or re-extracting slot values when a value-range violation is detected. The router enforces a bounded retry budget and emits a degraded intent if the budget is exhausted without successful validation. Policy Knowledge Base: A repository component that supplies domain knowledge consumed by the other components. It maintains the schema of the target standard (used by the Policy Generator for schema-as-grammar compilation), examples of valid policy documents (used for few-shot retrieval), and the relational invariants between schema fields (used by the Policy Validator for cross-slot consistency checking). The Policy Knowledge Base may be extended over time as new schema versions and new examples become available. Together, these components support a transparent transformation of user-defined goals into system-aligned candidate policies that can be validated before downstream use. The architecture is modular and extensible, allowing domain-specific enhancements (such as substitution of the underlying language model, the constrained decoder, or the validator implementation) without modification to the end-to-end pipeline.

The two Extractors share the same natural language input but address cognitively distinct sub-tasks. The Scenario Extractor performs abstraction-level reasoning and taxonomy classification, determining how the intent maps to a coordinate in the role-scenario space. The Slot Extractor performs token-level pattern matching and schema-aware slot filling, identifying entity spans and structured values in the surface text. Decomposing these sub-tasks permits each inference to use a narrower task and schema-as-grammar specification. Any resulting reduction in translation errors requires evaluation.

The internal flow of the parallel extraction step is illustrated in . Scenario Extractor: In this 3GPP-based instantiation, the logical function selects one of the three management roles (CSC, CSP, NOP) and one of four selected IntentExpectation subclasses (RadioNetwork, RadioService, EdgeServiceSupport, 5GCNetwork). The selected roles and scenarios define twelve permitted (role, scenario) combinations. Decoding is constrained to emit one of these combinations, recorded as a small JSON object. Slot Extractor: A logical function that, in parallel with the Scenario Extractor and from the same natural language input, identifies the named entities (such as area codes, user groups, or service identifiers) and the structured slot values (target name, target value, target unit, target condition) that the policy will carry. Slot values are constrained at decoding time to belong to valid enumerations (for example, a closed set of comparison conditions and a closed set of units), so that downstream schema validation cannot fail on out-of-vocabulary slots. Intent Composer: A deterministic step that merges the two Extractor outputs into a single Intermediate JSON document of the form {role, scenario, entities, slot values}. The Intent Composer does not invoke a language model. The two Extractors operate on the same input independently, so any cross-output inconsistency that may arise is left to the Policy Validator to detect downstream. The two Extractors may share the underlying language model instance, differing only in their prompt and in the schema-as-grammar specification applied at decoding time. This sharing can keep the number of distinct model artifacts low and reduce the operational complexity of maintaining heterogeneous model families. The two inferences are independent, so they may be executed either sequentially on a single accelerator or concurrently when batched inference is supported by the runtime. Parallel decomposition can be preferable to sequential decomposition (in which the output of the Scenario Extractor is injected as context to the Slot Extractor) for two reasons. First, parallel execution can reduce cascading errors from the Scenario Extractor into the Slot Extractor. Second, the two outputs may be cross-checked downstream, providing an additional consistency signal to the Policy Validator and the trace driven recovery agent. Role separation is logical. The Extractors and Policy Generator provide language-model functions; the Semantic Judge may also use a language model. Intent Composer and the schema and relational validators provide deterministic processing or checking. These functions may share model instances and need not be deployed as independent agents. The agentic property described here is their bounded feedback-driven coordination.

The Policy Generator synthesizes a candidate policy document from the merged Intermediate JSON. The principal design constraint is that candidate output should remain within the structural language admitted by the target OpenAPI-derived schema grammar. This constraint is enforced through schema-as-grammar , in which the schema is compiled into a schema-derived grammar consumed by the language model decoder. The general efficacy and known limitations of schema-as-grammar across heterogeneous schemas have been characterized in recent benchmarks ; not all schema features are expressible as efficient grammars, which is one reason post-generation validation remains part of the framework.

The internal workflow of the Policy Generator is illustrated in . Grammar Compiler: A component that compiles the target schema, such as the OpenAPI-derived schema of , into a grammar supported by the constrained decoder. It reads the schema from the Policy Knowledge Base. Reference resolution and normalization of constructs such as discriminator, allOf, and oneOf may be necessary, but transformations must preserve the relevant source constraints; replacing allOf by oneOf is not a general equivalence. Constraints not enforced by the compiled grammar remain subject to post-generation validation, and the implementation should identify the supported constraint subset. Constrained Decoder: A component that runs the language model with the compiled grammar applied at every decoding step. At each step, the grammar restricts the set of token continuations to those that keep the partial output extendable to a schema-admissible completion. The Constrained Decoder consumes the Intermediate JSON produced by the Intent Composer and emits the candidate policy document. Schema-as-grammar enforcement reduces syntactic invalidity (F-syn) by constraining the output language, but it does not, by itself, establish semantic coherence across slots. For example, a candidate document may satisfy every individual field constraint while combining an object type and a target name that are incompatible under the IntentExpectation type hierarchy of . Such cross-slot violations are detected downstream by the Policy Validator. The Policy Generator may optionally be specialized through supervised adaptation, including Low-Rank Adaptation (LoRA) . The model, adaptation method, and any claimed reduction in translation errors are deployment and evaluation choices, not prerequisites or demonstrated guarantees of this architecture.

The Policy Validator evaluates schema conformance, cross-slot consistency, and faithfulness to the original intent as complementary dimensions. Its observations support diagnosis and recovery, but do not prove statistical independence of the checks, a unique upstream cause, or the absence of hallucination.

The internal architecture of the Policy Validator is shown in . The checks execute in order and produce structured observations. Each check reports pass, fail, or not assessed, with a reason when assessment is uncertain, blocked by an earlier failure, or cannot be completed. A check that was not assessed is not treated as a pass. The declared acceptance policy determines the final disposition and any retry. Schema Validator (syntax check): This sub-component checks the candidate instance against the selected target schema. A YAML candidate is first parsed and, where needed, normalized to the data representation expected by the validator. The relevant schemas and external references are resolved from the OpenAPI specification, with any dialect adaptation required by the chosen JSON Schema validator, such as a Draft 2020-12 implementation . It detects F-syn and schema-expressible F-val. Schema compilation or resolution failures are reported as configuration or assessment failures, rather than attributed automatically to hallucination. Grammar enforcement does not remove the need for these checks. Semantic Solver (cross-slot check): This sub-component checks configured relational and domain constraints not fully captured or enforced by the selected schema and generation grammar. For the described 3GPP instantiation, these include the permitted relationship between object type and target name. A Satisfiability Modulo Theories (SMT) solver such as Z3 may implement these checks and report F-xs. A solver result applies only to the encoded constraints and does not establish correctness of facts outside the supplied context. Semantic Judge (meaning check): This sub-component evaluates the semantic faithfulness between the original natural language intent and the candidate policy document. It detects semantic mis-grounding (F-sem), such as the selection of a schema branch that is structurally valid but does not match the user's stated goal, and the portion of value-range errors (F-val) that depend on natural language context. The Semantic Judge may be realized as a language model judge with calibrated few-shot examples, optionally supplemented by deterministic lexical overlap checks for robustness. An LLM-based assessment can be incorrect or uncertain and is not ground truth. Lexical overlap may supply diagnostic evidence, but is not sufficient by itself to establish faithfulness. The labels F-syn, F-xs, F-sem, and F-val correspond to the four failure-mode categories defined in . The mapping associates each failure-mode category with its primary detecting sub-component: the Schema Validator emits F-syn and the schema-expressible portion of F-val; the Semantic Solver emits F-xs; and the Semantic Judge emits F-sem and the natural-language-context-dependent portion of F-val. F-val therefore has two detection paths, reflecting the practical observation that some value-range or unit errors are caught at the schema level while others require natural language context. The failure-mode trace produced by the Policy Validator is consumed by the trace driven recovery agent described in . A deployment declares which checks are required or advisory and how their outcomes are combined. For example, acceptance may require the Schema Validator and Semantic Solver to pass and a semantic assessment to meet the stated criteria. A deterministic alternative to the Semantic Judge must cover those semantic criteria; lexical overlap alone is not an acceptance gate. Failed or unassessed required checks remain explicit and prevent a clean validation-success result. Advisory warnings and any acceptance with warnings are recorded separately from clean acceptance. A logical validation trace should identify the intent and candidate, the candidate version, the schema/profile and relational-rule versions, each check and its outcome, applicable failure-mode labels, the affected fields, and references to available evidence. Recovery records should identify the selected retry target, attempt count, remaining budget, and final disposition. Evidence may include input spans or constraint identifiers; unavailable evidence is not fabricated. These are functional reporting requirements, not a new wire encoding or inter-agent protocol. Their coverage in a particular prototype must be verified separately.

When the Policy Validator emits a failure trace, the recovery-control function uses the observations and the configured policy to select a permitted corrective action. A trace can contain multiple failure labels, and the detecting component does not uniquely determine the originating cause. The controller may follow fixed routing rules; independently autonomous planning or a model-driven routing implementation is not required by this architecture.

One possible routing policy for the trace driven recovery agent is summarized in and described below. The mapping is a deployment policy and can be adjusted based on implementation experience and local validation data. F-syn (syntactic invalidity): Route to the Policy Generator for regeneration. This case may occur when the generation constraints are incomplete, miscompiled, or not fully aligned with the validator used after generation. F-xs (cross-slot inconsistency): Route to the Policy Generator with additional configured constraints or corrective guidance, such as binding the object type to a trusted (role, scenario) coordinate. A prompt directive provides guidance; a hard constraint requires enforcement by the generation grammar or a validation tool. F-val (value-range error): Route to the Slot Extractor for re-extraction of the affected slot values. F-sem (semantic mis-grounding): Route to the Scenario Extractor if the failure trace indicates an incorrect (role, scenario) coordinate; otherwise route to the Policy Generator with an additional semantic hint. In some deployments, F-sem alone may not justify retry because the Semantic Judge has inherent calibration limits. The trace driven recovery agent enforces a bounded retry budget. When the budget is exhausted without successful validation, the router emits a degraded intent that records the residual failure mode and the most recent candidate policy. Degraded intents are suitable for routing to a human operator or to a downstream validation pipeline before deployment. The routing policy itself is subject to validation. A deployment should verify that a selected retry target is likely to reduce the observed failure mode and should update the routing table if local data indicates a different dominant cause. For example, an F-xs trace may be routed to the Policy Generator with an additional hard constraint when the role-and-scenario coordinate is trusted, but another deployment might route the same failure to re-extraction if the coordinate is uncertain. Recovery preserves the original intent. When a Scenario or Slot Extractor result changes, the Intent Composer merges the updated outputs, the Policy Generator regenerates the candidate, and the applicable checks run again. Candidate versions and evidence remain correlated so that stale results are not reused as proof of a revised candidate's validity. The controller does not silently relax user requirements to obtain a pass. Ambiguous inputs and unresolved failures are returned with an explicit review-needed disposition. A deployment specifies its retry-count limit and any additional time or token limits; exhaustion terminates the workflow with the residual status recorded.

Policy artifacts are data instances serialized in formats supported by the target model, such as YAML , JSON, or XML. YANG defines a data model rather than a serialization. NETCONF , RESTCONF , or REST may carry an artifact only through an appropriate model-specific encoding and interface binding; changing serialization alone does not provide a semantic mapping between models. For the 3GPP instantiation, validation uses the relevant schemas from the OpenAPI specification of . A deployment or evaluation identifies the exact schema version and artifact references, the selected role/scenario taxonomy, and the relational-rule set. This document does not define a new intent language or a new transport protocol. As described in the modular architecture of the framework, user-defined natural language intent is processed through a partially parallel pipeline that includes the Scenario Extractor, the Slot Extractor, the Policy Generator, the Policy Validator, and the trace driven recovery agent. The schema and the cross-slot relational invariants are sourced from the Policy Knowledge Base, enabling schema-as-grammar enforcement and failure-mode-specific detection. This design is intended to help translate operational goals - even when imprecisely expressed - into policy representations that can be checked for schema conformance, cross-slot coherence, and semantic faithfulness to the user's intent. Therefore, this document defines a practical and extensible architecture for intent translation in management systems. Through this architecture, high-level user goals can be mapped to structured policy outputs that are suitable for validation and downstream automation. The framework enables intent-based management to support scalable, knowledge-grounded automation in complex service domains such as networks, vertical-specific networks, and intelligent edge infrastructures.

This document does not require any IANA actions.

The deployment of the Intent Translator Framework requires alignment between the Policy Knowledge Base and the operational policies supported by the underlying infrastructure. The schema of the target standard, examples of valid policy documents, and the relational invariants between schema fields must be encoded within the Policy Knowledge Base so that schema-as-grammar enforcement, few-shot retrieval, and cross-slot validation are consistent with the deployment environment. Operators should validate the framework against representative intents and reference policies before enabling full automation. In particular, the routing table of the trace driven recovery agent should be calibrated using local failure traces and operational policy. The default routing policy described in is a starting point and may need to be adjusted based on deployment data. The computational requirements depend on the selected language models, constrained decoder, and validator implementation. Inference for the two Extractors and the Policy Generator can be served from a small number of accelerators when the underlying language models are of moderate size. The Schema Validator and the Semantic Solver are deterministic and inexpensive. The Semantic Judge, when realized as a language model, dominates the validator's computational cost, and may be replaced or supplemented by deterministic checks in latency-sensitive deployments. When the framework is deployed in a 5G system context , the resulting policy documents are consumed by the Intent Driven Management Service (IDM-MnS) defined in . The deployed model and prompt versions, schema/profile, relational rules, and acceptance policy should be recorded with translation results. The reporting and disposition conventions described here are implementation requirements to be checked, not evidence that every preliminary prototype already implements them.

The modular architecture of the framework allows individual components - such as the Scenario Extractor, the Slot Extractor, the Policy Generator, or any sub-component of the Policy Validator - to be adapted to different domains, languages, or knowledge representations. As such, implementers can substitute the language model, modify the schema-as-grammar specification, or replace the output schema (e.g., YAML, XML, JSON) without altering the end-to-end pipeline. The framework separates the pipeline from its domain profile. Schema evolution can require updates to the role/scenario taxonomy, examples, relational invariants, grammar compiler, and validator configuration as well as grammar recompilation. Compatibility with another release of or another domain must be checked through profile-specific validation and regression tests; it is not guaranteed by recompilation alone. The Policy Knowledge Base may be extended over time with new examples, new entity types, and new relational invariants to support evolving service capabilities. Such extensions should preserve backward compatibility by maintaining stable identifiers for core operational concepts.

When the retry budget is exhausted without satisfying the required checks, the framework returns a degraded intent containing residual failures or unresolved assessments and the most recent candidate. Implementations distinguish clean acceptance, acceptance with advisory warnings, review-needed degradation, and rejection in their result metadata. These dispositions describe the configured checks and policy; none is a general proof that a policy is free of hallucination or operationally safe. For high-assurance environments, degraded intents should be reviewed by a human operator or routed to a validation pipeline before policy deployment. Logging mechanisms should be used to record degraded cases, the residual failure modes, and their resolution outcomes, so that future iterations of the Policy Knowledge Base, the routing table, and any supervised specialization of the Policy Generator can incorporate the observed cases. Because the Semantic Judge has calibration limits, a deployment may designate particular F-sem observations as advisory under an explicit, evaluated acceptance policy. If that policy permits acceptance with warnings after schema and relational checks pass, the warning and decision remain attached to the candidate and are reported separately in evaluation. An exception for an advisory observation does not convert a failed or unassessed required semantic check into a pass. High-assurance environments should obtain human or downstream validation before deploying degraded candidates.

The Intent Translation Framework must operate over authenticated and confidential channels (e.g., TLS/HTTPS) to prevent eavesdropping, message tampering, or replay attacks by malicious actors. Implementations should enforce strict certificate validation and regularly rotate cryptographic keys to maintain transport-layer security. Because the system processes free-form natural language intents, it is vulnerable to adversarially crafted inputs designed to produce unintended or harmful policies. Schema-as-grammar enforcement bounds the space of syntactically possible outputs, and the cross-slot Semantic Solver bounds the space of structurally coherent outputs, but neither prevents an adversary from issuing a semantically harmful intent that is nonetheless schema-valid and cross-slot coherent. Deployments should incorporate input validation, semantic sanity checks, and confirmation interfaces for high-impact operations, and should rate-limit or quarantine suspicious requests for manual review. Deployments that use language-model components should also consider prompt-injection and instruction-confusion attacks. Inputs, retrieved examples, and schema descriptions should be separated by clear trust boundaries, and implementations should avoid allowing user-provided text to override validator, authorization, or deployment policies. Policy generation should be bound to an authorization model. A policy that is schema-valid and semantically faithful to an input intent may still exceed the authority of the requesting principal or may have an unacceptable operational blast radius. High-impact candidate policies should therefore be subject to approval, rollback, and audit procedures before enforcement. Intent collisions, in which contradictory or overlapping intents are submitted concurrently, can lead to policy conflicts or enforcement gaps. The framework must include conflict-detection logic that examines the relations between successive policy documents, and either automatically resolves detected collisions using a documented precedence model or escalates them to human operators for arbitration. When the Policy Generator is specialized through supervised adaptation, the training corpus must be protected against poisoning. An adversary that injects malicious intent-policy pairs into the training corpus could bias the Policy Generator toward emitting policies that are schema-valid but operationally harmful. Implementations should record the provenance of each training example and should validate that supervised adaptation does not regress the framework's behavior on a held-out test set of known-good intents. Schemas, relational rules, retrieved evidence, and validation traces influence both generation and acceptance decisions. Their provenance, versions, and integrity should be protected, and examples should not be promoted to authoritative facts about a request. Hallucination mitigation does not replace authorization, operational safety checks, or downstream assurance.

This section is included to provide an indication of implementation status, consistent with . It does not constitute an endorsement by the IETF or the IRTF, and it is expected to be removed or updated before publication as an RFC. A research prototype of the framework has been exercised using publicly available components: an open-weight language model for the Extractors and Policy Generator, a constrained-decoding engine for schema-derived generation constraints, a JSON Schema validator for schema-level checks, and an SMT solver for selected cross-slot invariants. The prototype used the OpenAPI specification of 3GPP TS 28.312 (as of Release 19) as the target schema source. Preliminary experiments were performed on a small synthesized data set of natural language intents and reference policy representations, derived from the OpenAPI schema via template-based synthesis and augmented by paraphrastic methods. The experiments were used to compare a single-extractor baseline with the parallel-extractor and validation-routing design described in this document. The observations suggest that parallel extraction and cross-slot validation reduce several classes of residual errors, especially cross-slot inconsistency. These results are preliminary and do not constitute a generalization claim; the data set and evaluation harness are not yet sufficient for that purpose. A future revision is expected to identify the prototype repository, the data set generation method, the exact schema version, and the evaluation harness once those artifacts are made publicly available. The preliminary description above does not establish implementation coverage of every reporting, disposition, or recovery convention clarified in this revision. It does not establish a quantified hallucination reduction rate, an advantage of agentic or model-directed routing over a fixed policy, cross-domain or cross-model generalization, or correctness of deployed network behavior. Those claims require additional implementation evidence and evaluation; the following considerations are an evaluation design, not reported results.

Future evaluations should compare a single translation call, schema-constrained generation, validation with generic retry, and the described failure-directed recovery, using comparable models, inputs, and call or token budgets. If model-directed routing is implemented, its effect should be isolated by comparison with fixed routing under otherwise matched conditions. Separating outcome and process measures follows the evaluation perspective in . Report residual semantic errors or hallucinations among accepted policies, erroneous acceptance, detection and recovery outcomes by failure mode, clean-acceptance coverage, warning/review/rejection rates, and latency and token or call cost. Error rates must be reported with acceptance coverage so that rejecting every input is not mistaken for successful mitigation. The Semantic Judge's own output is not the evaluation oracle; use independent reference constraints, validated policies, or expert assessments. Translation-quality measures do not by themselves establish operational intent fulfillment.

IEEE Transactions on Dependable and Secure Computing, Volume 21, Issue 6 Ph.D. Dissertation, University of California, Irvine Tools and Algorithms for the Construction and Analysis of Systems (TACAS 2008), LNCS 4963 IEEE Communications Surveys and Tutorials IEEE Network, Volume 38, Issue 5 GSMA GSMA Newsroom; Open-Telco LLM Benchmarks 2.0, TeleYAML Intent-to-Configuration task Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress

This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. RS-2024-00398199 and RS-2022-II221015). This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. 2025-RS-2022-II221199, Regional strategic industry convergence security core talent training business).

This document has greatly benefited from inputs and discussions within the IRTF Network Management Research Group (NMRG), with contributions from (Daejeon University) and (Dong-Eui University). The authors sincerely appreciate their contributions. The following are coauthors of this document: Department of Computer Science & Engineering

Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea +82 31 299 4106 ahnjs124@skku.edu http://iotlab.skku.edu/people-Ahn-Yoseop.php

The following changes are made from draft-gu-nmrg-intent-translator-03: This version addresses an agentic AI framework and its Intent Translator. The Intent Translator converts a natural-language network intent into a structured policy representation, that is, intent-to-policy translation. It reframes the document around detection and mitigation of structural and semantic errors, including hallucinated policy content, in the intent-to-policy translation. It clarifies the bounded agentic workflow and its 3GPP TS 28.312-based instantiation, including validation outcomes and targeted recovery. It makes scope limitations and evaluation considerations explicit.