A request may be incomplete or impossible as written
A cloud-service discovery paper studies users who describe needs in ordinary language instead of a complete structured specification. A request may omit required resources, contain conflicting preferences or ask for something absent from the available catalog.
The proposed framework uses a language model to refine the intent and detect conflicts, then represents it in a provider-independent TOSCA template. That intermediate structure gives the discovery stage concrete requirements to match, rather than asking a model to invent a plausible service name.
Match offers and negotiate remaining conflicts
The framework retrieves candidate offers through deterministic matching grounded in provider offerings. Some conflicts can be identified during interpretation; others emerge only after searching the catalog. In both cases, it returns to the user through iterative natural-language negotiation.
This separates clarifying what the user wants from establishing what a provider actually offers. A well-written specification can still be unsatisfied, and a semantically similar service description may fail a particular required value.
Read the result within the evaluated catalog
The authors evaluate seventy diverse intents against single-shot and enhanced-prompting baselines. They report better recall and F1 for conflict detection and service discovery, with no hallucinated offers in that evaluation. This is a result for the tested framework and catalog, not proof that all generated cloud configurations are correct or deployable.
For an applied test, retain the original request, the negotiated changes, the structured requirements and the matched catalog entry. Check whether the final offer meets each required value and whether a user-approved compromise is visible. The contribution is a more grounded interpretation-and-discovery process; deployment validation, the freshness of provider data and the consequences of a chosen architecture remain separate questions.
Comments