Intent Engine: Natural-Language Intent Translation for Intent-Driven Orchestration in the Compute Continuum

Introduction

• The compute continuum integrates edge and cloud resources to balance edge constraints with the latency, throughput, and scalability needs of distributed microservices.Placement must meet requirements such as low latency, high availability, storage efficiency, and QoS.Source: §1 · p. 2
• Existing orchestration frameworks generally require structured SLOs, so expressing intents as natural language could reduce users’ need to specify precise metrics and system parameters.However, LLM-generated system-critical specifications can hallucinate, producing invalid configurations or system failures; prompt-only generation lacks guarantees for fluctuating resources.Source: §1 · pp. 2–3
• Intent Engine converts natural-language service-placement intents into validated, platform-agnostic SLO artifacts for existing orchestration and placement frameworks.It is an intent-acquisition and SLO-construction layer; placement and runtime QoS optimization are outside its scope.Source: §1 · p. 3
• Its multi-stage pipeline separates semantic extraction, intermediate SLO representation, infrastructure-aware grounding, and schema validation before emitting an artifact.Grounding resolves implicit constraints, such as highest or lowest resource values, from monitored compute-continuum state.Source: §1 · p. 3
• The evaluation uses a released 716-record intent-to-SLO dataset from a real compute-continuum testbed, covering valid, ambiguous, conflicting, malformed, and unsupported intents.The paper evaluates translation accuracy, grounding, hallucination reduction, invalid-intent rejection, overhead, scalability, and downstream placement impact.Source: §1 · p. 3

2.1. Intent-Driven Orchestration in the Compute Continuum

• IDO lets users state high-level goals for autonomous orchestration, but edge–cloud placement remains dynamic and Kubernetes-based systems still demand low-level configuration and expertise.Source: §2.1 · p. 3

2.2. Intent Specification and Acquisition Approaches

• Prior acquisition systems accept structured intents, keywords, or formal SLOs, leaving users to provide the precise inputs needed to guide placement.Source: §2.2 · p. 4

2.3. Natural Language–Based Intent Translation

• Prior natural-language translation spans NLP and LLM methods, but lacks reliable, placement-specific SLO construction with structured, deterministic guarantees.Source: §2.3 · pp. 4–5

2.4. Service Placement Methods

• Placement studies optimize resource allocation or QoS, but the cited approaches do not use high-level user intent to guide compute-continuum placement.Source: §2.4 · p. 5

2.5. Retrieval-Augmented Grounding for LLM-Based Systems

• Inference-time retrieval can ground intent values in fluctuating runtime metrics, yet existing retrieval-and-reasoning methods target workflows, APIs, or QA rather than constrained orchestration specifications.Source: §2.5 · p. 5

2.6. Research Gaps

• Intent Engine addresses the gap by constructing schema-bounded, infrastructure-grounded SLOs and rejecting unsupported, ambiguous, or conflicting placement requests.Source: §2.6 · p. 5

3. System Architecture

• Intent Engine is a control-plane SLO construction layer that extracts constraints, grounds context-dependent requirements, and validates specifications before downstream orchestration.It does not replace placement algorithms or runtime assurance; the consuming IDO framework handles placement and deployment execution.Source: §3 · pp. 5–6

3.1. System Input

• Each request supplies a service name and natural-language intent, while a configurable supported SLO schema constrains metrics, operators, units, and value formats for downstream compatibility.Schema validation excludes unsupported constraints and formats before specifications are emitted.Source: §3.1 · pp. 6–7

3.2.1. SLO Parser

• The SLO Parser uses an LLM to extract explicit metrics, operators, and values into a fixed intermediate schema, then rejects unsupported or inconsistent clauses before grounding.It normalizes units and operators, excludes unsupported parameters, and prepares placeholders for context-dependent requirements.Source: §3.2 · p. 7, §3.2.1 · p. 7

3.2.2. Intermediate SLO Specification Builder

• The Intermediate SLO Specification Builder normalizes parser output, maps explicit values to canonical fields, checks schema conformity, and marks values requiring contextual grounding.This validated intermediate representation separates language understanding from final specification generation.Source: §3.2.2 · p. 7

3.3. Retrieval-Augmented SLO Specification Generation

• Retrieval-augmented generation grounds implicit requirements, including extrema requests and constraints dependent on fluctuating system conditions, rather than relying on prompt-only generation.The Query Resolver identifies what needs grounding and forms queries specifying the metric, scope, and objective before combining retrieved evidence with the intermediate template.Source: §3.3 · p. 7, §3.3.1 · p. 7

3.3.2. Context Retriever and Encoder

• The Context Retriever searches a vector database and falls back to stored snapshots when evidence is unavailable or insufficient; the deterministic Context Encoder creates retrieval-ready infrastructure chunks without an LLM.Chunks include node-level states, edge–cloud summaries, and structured resource metadata.Source: §3.3.2 · p. 7

3.3.3. Monitoring Module

• The monitoring module periodically collects static and dynamic compute, utilization, and network metrics across edge and cloud nodes, storing raw snapshots and encoded representations for grounding.These monitored infrastructure states provide contextual evidence for SLO construction.Source: §3.3.3 · p. 7

3.4. Compute Continuum Infrastructure

• The architecture is infrastructure-agnostic; the testbed supplies context for grounding intents and constructing ground-truth SLO labels, while evaluating downstream placement decisions is outside the translation layer’s scope.The architecture can integrate with a range of edge–cloud platforms and orchestration systems.Source: §3.4 · pp. 7–8

4. Implementation and Experimental Setup

• The implementation pairs a monitored compute-continuum testbed with an SLO-construction pipeline; the testbed supports grounding and label construction, not placement or runtime QoS evaluation.The pipeline performs intent decomposition, retrieval-augmented grounding, and SLO specification generation.Source: §4 · p. 8

4.1. Compute Continuum Infrastructure Testbed

• A geographically distributed physical testbed collects resource-state traces across heterogeneous edge and cloud resources under deployment-like conditions and variability.It uses Raspberry Pi edge devices and AWS EC2 workers within a six-node Kubernetes cluster.Source: §4.1 · p. 8

4.2. Natural Language Intent Decomposition

• Unstructured natural-language service-placement intents are processed by the intent-decomposition component into structured intermediate specifications.This provides the input to the SLO construction pipeline.Source: §4.2 · p. 8

4.2.1. SLO Parser

• The SLO Parser uses GPT-4.1-mini at temperature 0.0 and exposes a Python Flask API that accepts JSON requests and returns structured JSON.The parser prompt template is shown in Figure 7, and its response proceeds to normalization and grounding.Source: §4.2.1 · pp. 8–9

4.2.2. Intermediate SLO Specification Builder

• The intermediate-specification builder normalizes fields, fills missing values with nulls, validates constraints, canonicalizes metrics, units, and operators, and flags constraints requiring grounding.It serializes the resulting schema-compliant representation as JSON for the retrieval-augmented stage.Source: §4.2.2 · p. 9

4.3. Retrieval-Augmented SLO Specification

• The RAG component retrieves monitored context to ground parameters, generates final SLOs, and checks structural and schema completeness.Prometheus collects capacity and utilization metrics; periodic infrastructure snapshots stored in S3 provide a deterministic fallback for contextual grounding.Source: §4.3 · p. 9, §4.3.1 · p. 9

4.3.2. Context Encoder; 4.3.3. Context Retriever

• The Context Encoder stores deterministic, retrieval-ready chunks in Qdrant, while the Context Retriever uses similarity search and falls back to the latest S3 snapshot when retrieval is insufficient or unavailable.The encoder returns the top 8 relevant chunks; retrieved values are aggregated deterministically with unit normalization and metadata filtering as needed.Source: §4.3.2 · p. 10, §4.3.3 · p. 10

4.3.4. Query Resolver; 4.3.5. SLO Specification Validation

• The Query Resolver creates retrieval queries with aggregation semantics, passes retrieved context to the LLM for implicit values, and bypasses retrieval for explicit constraints; final SLOs are validated and serialized as JSON.Validation checks structural completeness, schema consistency, and value correctness against snapshot representations.Source: §4.3.4 · p. 10, §4.3.5 · p. 10

5. Evaluation

• The evaluation examines constraint and specification correctness, hallucination reduction, retrieval grounding, invalid-intent rejection, latency and scalability, and downstream placement feasibility.It focuses on the intent-acquisition and SLO-construction layer, not runtime orchestration behavior.Source: §5 · p. 10

5.1. Dataset

• The dataset contains 716 intent records: 521 valid intent-to-SLO pairs and 195 invalid cases, each linked to a point-in-time infrastructure snapshot.Valid records support translation-correctness evaluation; invalid records support robustness and failure-handling analysis.Source: §5.1 · p. 11
• Real records come from monitored edge–cloud testbed traces, while Llama 3.3 70B generates synthetic language variants; TeaStore supplies reference workload traces, not an application-specific task.Synthetic records retain the target schema and complexity structure; implicit values are derived from snapshots, and records are checked against the supported SLO schema.Source: §5.1 · p. 11

5.2. Candidate Models

• Llama 3.3 70B is used only to generate synthetic intents; GPT-4.1 mini, Claude Sonnet 4.5, and DeepSeek V4-Flash evaluate translation.Separating generation and evaluation models reduces model-bias risk, while multiple backends test gains across model families.Source: §5.2 · p. 11

5.3. Baseline Methods

• Baselines comprise Zero-shot, Few-shot, Zero-shot CoT, Few-shot CoT, and a generic rule-based parser; prompting baselines receive snapshots when grounded values are required.The parser uses schema-constrained rules and snapshot resolution; Intent Engine retrieves only metric- and intent-relevant context rather than injecting the full snapshot into one prompt.Source: §5.3 · pp. 11–12

5.4. Metrics and Definitions

• Constraint scoring uses exact matches on canonical tuples of resource type, metric, comparator, value, and normalized unit; specification structure is assessed with Exact Match and Jaccard similarity.Strict matching reflects threshold-based SLO use: even small numeric deviations can change constraint satisfaction and downstream placement decisions.Source: §5.4 · p. 12
• Hallucination scoring tracks three binary response indicators and averages triggered categories; invalid-intent rejection measures correct rejection, with false accepts occurring when invalid requests yield validated constraints.The desired invalid-intent behavior is rejection or returning no orchestration-consumable SLO specification.Source: §5.4 · p. 12
• Downstream placement failure is evaluated with a deterministic placement generator, counting cases where predicted SLOs find no matching node or return a node violating a ground-truth constraint.The analysis considers valid records whose ground-truth SLO label has at least one feasible placement in the corresponding snapshot.Source: §5.4 · p. 12

5.5. Hallucination Analysis

• 85.1% lower aggregate hallucination than Zero-shot (0.6006→0.0894), with reductions in unsupported constraints, value issues, and structural errors.H1 falls 97.2% (0.3045→0.0084), H2 falls 60.7% (0.1955→0.0768), and H3 falls 95.8% (0.1006→0.0042); remaining hallucinations are mostly value-related, the hardest SLO-construction step.Source: §5.5 · p. 13

5.6. Retrieval-Grounding Ablation

• No-RAG achieves zero F1 on implicit snapshot-dependent constraints across Levels 2–5, while retrieval-enabled Intent Engine recovers nonzero F1.Without RAG, explicit placement requirements and numeric thresholds remain extractable, but implicit highest/lowest resource or utilization values cannot be resolved from infrastructure state.Source: §5.6 · p. 13, Table 6 · p. 14

5.7. Correctness of Generated SLO Specifications; 5.7.1. Contextual Accuracy

• 0.941 total F1 with GPT-4.1 mini exceeds Few-shot CoT’s 0.758 by 24.1%, and Intent Engine achieves the highest F1 across every model family and data source.F1 rises from 0.794 to 0.870 for Claude Sonnet 4.5 and from 0.779 to 0.903 for DeepSeek V4-Flash.Source: §5.7.1 · p. 14, Table 7 · p. 14

5.7.2. Structural Accuracy; 5.7.3. Rule-based Parser Baseline

• Intent Engine has the strongest structural accuracy across models, while the rule-based parser’s overall F1 is 0.666, below few-shot prompting and Intent Engine.Structural accuracy assesses whole-specification fidelity through Exact Match and Jaccard similarity; the rule-based parser outperforms zero-shot prompting and performs similarly on real and synthetic records.Source: §5.7.2 · p. 14, §5.7.3 · p. 14, Table 8 · p. 14

5.8. Failure Mode Analysis

• 98.5% of invalid records are correctly rejected, including 93.9% of conflicting intents; prompting baselines are less consistent in safely rejecting invalid requests.Intent Engine has only 3 false accepts among 195 invalid intents; few-shot variants often over-generate SLOs for conflicting intents, while zero-shot variants reject many ambiguous and unsupported inputs.Source: §5.8 · pp. 15–16, Figure 6 · p. 16

5.9. System Overhead; 5.9.1. Latency

• 2.35 s median and 4.30 s P95 latency make GPT-4.1 mini the lowest-latency LLM-backed configuration; DeepSeek V4-Flash has the highest P95 at 17.43 s.The rule-based parser completes symbolic parsing and snapshot resolution in sub-millisecond time, but with lower F1; translation is intended for human-triggered or low-frequency orchestration updates, not individual service-request data paths.Source: §5.9.1 · p. 16, Table 10 · p. 16

5.9.2. Scalability

• At 1000 nodes, full snapshot prompting uses 501,726 tokens versus retrieved context stabilizing near 2,000 tokens after 25 nodes.With k=8, retrieved context is bounded by the retrieval budget; for multiple implicit SLOs it grows with grounding queries and is bounded by m×k chunks, where m is the number of implicit grounded constraints.Source: §5.9.2 · p. 17, Table 11 · p. 17

5.10. Downstream Placement Impact

• Table 12 concerns downstream placement failure using GPT-4.1 mini; Intent Engine is a platform-agnostic SLO construction layer, while the MicroIntent placement generator serves only as a deterministic evaluator.Source: Table 12 · p. 17, §5.10 · p. 17

System role and oversight

• Downstream IDO frameworks handle placement, execution, enforcement, re-grounding, and runtime assurance; system-critical SLOs should be inspected before execution.Stale context, malformed intents, or incorrectly accepted constraints may cause service disruption.Source: §6 · p. 17

Scope of supported intents

• The schema and evaluation exclude autoscaling, fault recovery, migration, cost optimization, closed-loop assurance, and business, privacy, energy, carbon, dependency, or workflow goals.Supported intents mainly cover infrastructure-oriented placement, compute capacity, utilization, storage, and network constraints.Source: §6 · p. 17

Snapshot-based grounding

• Grounded SLO values reflect monitored infrastructure snapshots and can become stale in dynamic environments; they are not always-current runtime guarantees.Re-grounding after initial placement remains part of downstream IDO intent assurance.Source: §6 · p. 17

Evaluation limitations

• Evaluation uses a six-node edge–cloud testbed and TeaStore records, leaving node-scale behavior and retrieval-augmented context selection in large continuum systems unevaluated.TeaStore is a reference application, while the pipeline is application-agnostic; broader evaluation awaits a richer public grounded intent-to-SLO dataset.Source: §6 · p. 17

Residual LLM errors

• LLMs can still make value-level errors despite schema constraints and validation, and the lack of a contextual dataset currently prevents domain-specific LLM training or fine-tuning.Intent Engine reduces unsafe outputs but does not eliminate all errors.Source: §6 · p. 18

Conclusion

• The architecture transforms unstructured placement intents into validated, orchestration-consumable SLO artifacts for downstream IDO and placement frameworks.It combines schema-bounded intent extraction, retrieval-grounded value construction, and schema validation, separating natural-language interpretation from orchestration decisions.Source: §7 · p. 18
• Intent Engine improves constraint-level correctness, structural accuracy, hallucination reduction, implicit-value grounding, and invalid-intent rejection over prompt-only LLM baselines and a non-LLM rule-based parser.The results indicate that infrastructure-aware grounding and schema-constrained validation are especially important for implicit, multi-constraint, and invalid intents.Source: §7 · p. 18
• Intent Engine treats generated SLOs as control-plane artifacts rather than free-form text, leaving placement optimization, deployment actuation, and runtime QoS assurance to the consuming orchestration system.This preserves the boundary between intent interpretation and downstream placement execution while enabling integration with existing IDO frameworks.Source: §7 · p. 18

Future Work

• Future work will investigate intent drift and closed-loop assurance by extending Intent Engine to verify runtime intent satisfaction after SLO artifacts are consumed.Planned capabilities include re-grounding, feasibility checking, conflict detection and resolution, and intent negotiation after initial service placement.Source: §7 · p. 18

• The authors used OpenAI’s ChatGPT for grammar checking and language refinement, reviewed and edited all content, and take full responsibility for the final manuscript’s accuracy and integrity.Source: Declaration of Generative AI and… · p. 18

A.2. Zero-Shot and Zero-Shot CoT prompt

• The zero-shot and zero-shot CoT prompt template is shown in Figure 8.The supplied passage does not provide the template contents.Source: §A.2 · p. 18