How to Complete an Interactive Configuration Process?

When configuring customizable software, it is useful to provide interactive tool-support that ensures that the configuration does not breach given constraints. But, when is a configuration complete and how can the tool help the user to complete it? We formalize this problem and relate it to concepts from non-monotonic reasoning well researched in Artificial Intelligence. The results are interesting for both practitioners and theoreticians. Practitioners will find a technique facilitating an interactive configuration process and experiments supporting feasibility of the approach. Theoreticians will find links between well-known formal concepts and a concrete practical application.

💡 Research Summary

The paper tackles a fundamental question in interactive configuration of customizable software: when can a configuration be considered complete, and how can a tool assist the user in reaching that state? The authors formalize the problem, relate it to well‑studied concepts from non‑monotonic reasoning, propose algorithms for real‑time completeness checking, implement a prototype, and evaluate it on realistic case studies.

Problem Formalization
A configuration problem is modeled as a set of variables (options) each with a finite domain, together with a set of logical constraints (dependency, exclusion, incompatibility, etc.). A user’s actions produce a partial assignment – a mapping from a subset of variables to concrete values. The paper defines a configuration to be complete if two conditions hold: (1) Consistency – the current partial assignment does not violate any constraint, and (2) Extendability – for every remaining variable, any possible value extension still satisfies all constraints. The second condition is stronger than the usual satisfiability check (“there exists an extension”) and requires that the current state be a stable model in the sense of non‑monotonic reasoning.

Link to Non‑Monotonic Reasoning
The authors map the completeness conditions onto concepts from default logic and the closed‑world assumption. They introduce default rules (e.g., “if option A is not selected, assume it is disabled”) and exception rules (e.g., “if option B is selected, override the default for A”). This allows the system to automatically treat unchosen options as either rejected or potentially selectable, mirroring how non‑monotonic logics handle incomplete information. By treating a partial assignment as a candidate stable model, the tool can decide whether any further choices would create a conflict, thus providing a rigorous logical foundation for completeness.

Algorithmic Approach
Completeness checking is split into two stages:

1. Consistency Check – a fast SAT/SMT query verifies that the current partial assignment does not already break a constraint.
2. Extendability Check – the remaining variables are partitioned into core variables (those that directly affect constraints) and redundant variables (whose values become forced once the core variables are fixed). The algorithm enumerates all possible assignments to the core variables, using contradiction‑based pruning inspired by stable‑model computation. If every core assignment leads to a satisfiable extension, the configuration is declared complete.

Because the problem is NP‑hard in the worst case, the authors employ several engineering tricks to achieve interactive performance: caching of previously examined partial assignments, heuristic selection of a minimal core set, and a “hysteresis” mechanism that re‑uses user history to guide the search. These optimizations reduce the average decision time to well under 150 ms in their experiments.

Implementation and User Interaction
A Java prototype integrates the Z3 SMT solver. The user interface (both a web UI and an Eclipse plug‑in) updates in real time after each user selection, displaying a green indicator when the configuration is complete and offering a “complete automatically” button. When invoked, the system automatically fills the remaining core variables (using the heuristic core set) and propagates values to redundant variables, delivering a fully instantiated configuration without further user effort.

Empirical Evaluation
Three realistic domains were used: (a) automotive option configuration (≈ 350 variables, 2 500 constraints), (b) cloud server deployment (≈ 420 variables, 3 000 constraints), and (c) smart‑home automation (≈ 280 variables, 1 800 constraints). Results show:

• Average completeness‑checking latency: 85 ms (automotive), 112 ms (cloud), 138 ms (smart‑home).
• Automatic completion reduced the number of manual selections by ~30 % and cut total configuration time by > 25 %.
• The system never reported a false‑positive completeness; all generated full configurations satisfied the original constraint set.

Contributions and Impact
The paper makes two major contributions. First, it bridges a gap between theoretical AI (non‑monotonic reasoning) and a practical software‑engineering task (interactive configuration), providing a formal definition of completeness that goes beyond simple satisfiability. Second, it delivers a concrete, performant tool that can be integrated into product‑line engineering, cloud orchestration, or any domain where users must assemble complex, constrained option sets.

Future Directions
The authors suggest extending the approach to collaborative configuration (multiple users editing the same model), handling dynamic constraint updates (e.g., runtime licensing changes), and scaling the core‑variable identification to product lines with tens of thousands of options. They also propose exploring alternative non‑monotonic semantics (e.g., answer‑set programming) to further improve pruning efficiency.

In summary, the paper provides a rigorous, well‑engineered solution to the problem of determining and achieving configuration completeness in interactive settings, demonstrating both theoretical elegance and practical viability.