Grounding Is the New Scaling: When Declarative Dreams Hit Memory Walls

Configuration sounds like the kind of problem declarative AI was born to solve.

A customer specifies requirements. A system knows the rules. The machine fills in the valid product structure: modules into frames, frames into racks, capacities respected, incompatible combinations avoided, technical constraints satisfied. Nobody hand-codes every possible arrangement. Nobody manually enumerates the combinatorial swamp. Lovely.

Then the grounder enters the room.

In Answer Set Programming (ASP), the usual workflow is not simply “write rules, solve rules.” It is “write compact first-order rules, expand them into a ground propositional form, then solve.” That middle step is grounding. It is not glamorous. It does not look like intelligence. It is also where many declarative dreams quietly run out of memory.

Veronika Semmelrock and Gerhard Friedrich’s paper, Investigating the Grounding Bottleneck for a Large-Scale Configuration Problem: Existing Tools and Constraint-Aware Guessing, studies this problem through a simplified version of large-scale electronic system configuration.¹ The paper’s practical question is brutally simple: can current ASP technology scale to configuration problems where industrial systems may involve tens of thousands of modules?

The answer is not a clean no. That would be too merciful. The answer is: standard approaches fail early; lazy grounding and incremental solving help; a new rewriting method called constraint-aware guessing helps much more on memory; and yet the gap to full industrial scale remains wide enough to make optimism wear a hard hat.

The important lesson is not “ASP is bad.” The paper is more interesting than that. The lesson is that in declarative AI systems, scaling can fail before the solver begins doing the thing everyone calls reasoning.

The expensive mistake is generating choices that were already impossible

Most readers will expect the main bottleneck to be search. The machine must explore many possible configurations, so surely the solver gets lost in the combinatorial maze.

That intuition is only partly right. In this paper, the sharper problem is earlier: ASP systems can generate grounded rules for choices that existing constraints already make impossible.

Here is the simplified mechanism.

A compact ASP program says, in effect:

1. a thing may go into a cabinet;
2. each thing must be placed;
3. a cabinet has limited capacity;
4. a cabinet or room cannot mix ownership across people;
5. ordering rules restrict which numbered thing can go into which numbered cabinet.

Written declaratively, this is elegant. But the grounder has to instantiate rule variables over concrete domains. If there are many things and many cabinets, the potential placement atoms multiply quickly. Some of those placements are obviously inconsistent once a partial solution already exists. Yet a conventional grounding process may still generate the guess and then generate constraints to reject it.

That is the software equivalent of printing a million invalid tickets so the gate can reject them one by one. Very principled. Also very expensive.

The paper illustrates this with a small module/frame example. Suppose module 1 is already placed in frame 2, and each module can be placed in only one frame. A guess that places module 1 in frame 1 is doomed. Another guess may violate frame capacity. The unfiltered grounding still includes these doomed options and the checking rules that kill them. The solver may eventually avoid them, but memory has already been spent.

Constraint-aware guessing changes the sequence. Instead of allowing every syntactically possible guess and relying on constraints to reject invalid ones later, it derives filter conditions from existing constraints and adds those filters directly to the guessing rules. The grounded program becomes smaller because many invalid guesses are never materialized.

The difference is subtle but operationally huge:

This is why the paper deserves a mechanism-first reading. If we start with benchmark numbers, the result looks like another solver comparison. If we start with the mechanism, the benchmark becomes a diagnosis: the system is not merely searching badly; it is manufacturing avoidable work.

The benchmark is deliberately favorable, which makes the failure more serious

The paper uses the House Configuration Problem (HCP), a technology-independent benchmark originally formulated by Siemens. In the paper’s mapping, “things” correspond to modules, “cabinets” to frames, and “rooms” to racks. The configuration has to assign things to cabinets and cabinets to rooms while satisfying capacity, ownership, placement, and ordering constraints.

This is not a full industrial electronic configuration model. The authors are explicit about that. They do not include cables, different module types, or complex physical constraints such as balancing technical quantities. The benchmark is a simplified lower bound, not a digital twin of a production configurator.

That matters because the setup already favors ASP systems in several ways.

The synthetic instances grow in a controlled pattern. Each step adds five persons, each with ten things. Cabinet and room domains are expanded proportionally, using two cabinets and one room per person. The construction provides exactly the required number of cabinets and rooms, avoiding extra scarcity complications. The task is to find the first answer set within a one-hour timeout on a machine with 32 GB RAM and four CPU cores.

In other words, this is not the paper trying to make ASP look bad. It is closer to asking: if we give current systems a clean, structured, simplified version of the industrial shape, how far do they get?

The answer: not far enough.

The authors compare standard ground-and-solve systems such as clingo and DLV, a lazy-grounding system with domain-specific heuristics, ProASP’s compilation approach, and newground’s body-decoupled grounding. In the one-step setting, where the complete problem instance is passed to the solver, the results show severe scaling limits.

The paper reports that lazy grounding reaches roughly 2,100 things within the one-hour limit. Standard ground-and-solve approaches reach about 400 things. ProASP reaches about 350 things, with comparatively low grounding size but time-efficiency problems. Newground solves only the first 50-thing instance; the next instance of 100 things times out during solving.

The uncomfortable part is the denominator. Real-world electronic systems may involve more than 30,000 modules, plus cables and other components. A method that reaches 400, 2,100, or even a few thousand things in a simplified lower-bound problem is not yet industrial-scale configuration. It is a proof that the wall is real.

Lazy grounding helps, but it does not repeal arithmetic

Lazy grounding is the intuitive workaround: do not ground everything upfront; interleave grounding and solving, and generate only what the solver currently needs. With good domain-specific heuristics, this can be powerful.

In the paper’s first benchmark, lazy grounding is the best-performing one-step approach. It reaches around 2,100 things, far beyond the standard ground-and-solve approaches. That is not a trivial gain.

But the result has two important boundaries.

First, the approach uses effective heuristics for the HCP. The authors note that simple and effective heuristics are available for configuring such systems. That is good news for this domain, but it is not a generic guarantee for every enterprise configuration problem. If a company’s product rules are messy, exception-heavy, or historically accumulated by committees — a shocking possibility, obviously — heuristic design becomes part of the engineering burden.

Second, even the best one-step result remains far below the industrial target scale. The paper’s conclusion states that, for ground-and-solve approaches, polynomial regression predicts more than 5 exabytes of grounding size and more than 10,000 years of runtime for 30,000 modules. This is an extrapolation, not a measured production run. Still, as warning labels go, “exabytes and millennia” is fairly legible.

So lazy grounding is not dismissed. It earns its place. But it does not change the core interpretation: grounding size is not a secondary nuisance. It is the scaling problem.

Incremental solving changes the game by making the problem arrive in batches

The paper then explores a more favorable scenario: incremental solving.

Industrial configuration often has useful structure. If partial solutions can be extended step by step, the system does not need to solve the whole instance from scratch as one giant monolith. The authors model this by dividing input facts into batches. At each iteration, the solver receives the previous answer set converted into facts plus the next batch of input facts. The implementation is stateless: the solver is reinitialized each time, rather than preserving internal solver state across calls.

The assumption is intentionally generous. The paper assumes that a partial solution can be extended to a full solution and that the process makes a “perfect guess” about which input facts to add so that no backtracking is required. That is not a casual detail. It means the incremental experiment tests the boundary under favorable conditions, not the worst case.

The results improve substantially.

Incremental ProASP shows the largest relative improvement compared with its one-shot version, reaching about 5,900 things. Incremental clingo improves over one-shot clingo and, after optimizing the persons-per-iteration parameter, reaches 2,850 things rather than 2,100. Newground also improves, reaching 400 things. DLV and I-DLV+clasp improve as well.

This part of the paper is best read as main evidence, not an ablation. It shows that problem decomposition and incremental extension can push ASP further on structured configuration tasks. It also reveals the new ceiling. Even after incrementalization, memory and grounding remain dominant.

The paper gives an especially telling time breakdown. For constraint-aware guessing, about 94% of execution time is still allocated to grounding, while solving accounts for only about 1.5%. For optimized incremental clingo, grounding accounts for about 97%, while solving is about 0.6%.

That is the whole plot in one statistic. The solver is not the star of the bottleneck. The grounder is.

Constraint-aware guessing is a rewriting trick with architectural consequences

Constraint-aware guessing is introduced after the paper has already shown that existing tools and incremental solving hit memory limits. Its role is not to replace ASP with a different paradigm. It rewrites the ASP encoding so that guessing rules become aware of constraints that would make certain guesses impossible.

The method starts from a partition of the program into guessing rules and checking rules. For a guessing rule whose head appears in a constraint body, the method derives filter conditions from the rest of that constraint. These filters are then added to the guessing rule, often through aggregate expressions such as #count ... < 1.

For the HCP, the authors apply this to rules such as guessing whether a cabinet contains a thing. The adapted rule includes filters corresponding to requirements such as each thing being placed in at most one cabinet, ordering constraints between things and cabinets, and ownership constraints preventing a cabinet from mixing things belonging to different persons.

The paper includes a proposition showing that, under its assumptions, replacing a guessing rule with its filtered version preserves solutions. The filtered program may have answer sets that are not syntactically identical to the original program’s answer sets, but the checking part ensures they still correspond to valid solutions. For a business reader, the practical translation is simpler: the rewrite is designed to remove useless search space without removing valid configurations.

This is not magic. It is disciplined laziness: do not generate work that constraints can already prove pointless.

The operational consequence is large. CAG, built on incremental clingo, solves the largest instance in the paper’s experiments: 6,200 things within one hour. Compared with optimized incremental clingo at 2,850 things, CAG gives a 118% performance advantage in solvable instance size.

The memory-side result is more striking. At the largest common instance of 2,100 things, CAG reduces grounding size by 99.6% compared with incremental clingo using the same persons-per-iteration value. Compared with optimized incremental clingo, CAG’s grounding size is 93.1% smaller at the largest common instance, even though CAG grounds five times as many new facts in the last iteration. Against incremental ProASP, at their largest common instance of 5,900 things, CAG’s grounding size is 95% smaller than incremental ProASP’s memory consumption.

Those percentages should not be read as universal constants. They are results on this benchmark, this encoding, this implementation, and this machine. But they are large enough to shift the interpretation. The improvement is not a minor tuning gain. It attacks the specific mechanism that made grounding explode.

What each experimental block actually supports

The paper contains several experimental and technical components. Mixing them together would make the article sound more confident and less useful. So let’s separate their roles.

This table is not decorative. It prevents a common reading error: treating every benchmark as a general leaderboard. The paper is more diagnostic than that. It asks where memory is spent, which engineering tactics reduce it, and which assumptions make those tactics work.

The business lesson is about translation cost, not solver cleverness

For companies building CPQ systems, product configurators, engineering design automation, or rule-based planning tools, the paper’s message is not “use CAG tomorrow.” The message is more basic: declarative systems have a translation layer, and that layer can dominate cost.

A business user sees a compact rule:

Each module must fit into one frame, frames have capacities, and ownership constraints must be respected.

An engineer sees a compact encoding.

The grounder sees domains and variables that can instantiate into a vast number of concrete atoms and constraints. That expansion can become the true production bottleneck. In a small demo, the rules look elegant. At scale, the expansion bill arrives.

Cognaptus would read the paper’s business implications in three layers.

This is where the paper quietly touches a broader AI theme. In LLM applications, teams often learn that prompt quality is not enough; retrieval, schema design, tool calling, and evaluation infrastructure determine whether the system behaves. In declarative AI, the equivalent lesson is that rule expressiveness is not enough. The compilation and grounding path determines whether the rules can operate at scale.

The dream is declarative. The invoice is architectural.

The result is impressive because the benchmark is still far from production

The strongest CAG result is 6,200 things within one hour. That is a major improvement over the standard approaches in the paper. It is also still far below the 30,000-module scale mentioned for large electronic systems.

This is not a contradiction. It is the paper’s useful tension.

CAG demonstrates that much of the grounding burden was avoidable. The method filters guesses that constraints already make inconsistent, saving memory by orders of magnitude in the tested setting. That is real progress.

But the benchmark is intentionally simplified. It has few technical constraints and low component variety. It does not include cables, different module types, or complex physical balancing constraints. The synthetic data adds domain capacity in a friendly way. The incremental setup assumes no backtracking. The experiments use a one-hour timeout and 32 GB RAM. Those are legitimate experimental choices, but they define the interpretation.

So the right business conclusion is neither cynicism nor hype. CAG is an engineering direction for making declarative configuration more scalable. It is not proof that ASP, as currently tooled, can handle full industrial product configuration just by sprinkling filter conditions on the encoding and smiling confidently at the server rack.

A less theatrical way to say it: CAG expands the feasible region, but it does not erase the scaling frontier.

Where this matters beyond electronic configuration

The paper is about ASP and electronic system configuration, but the pattern appears in many business automation problems.

A loan approval system may encode eligibility rules, risk categories, documentation requirements, and exception handling. A supply-chain planner may encode capacity, routing, timing, inventory, and supplier constraints. A product configurator may encode compatibility across components, customer requirements, regional variants, and compliance rules. In all these cases, compact rules can imply an enormous number of concrete combinations.

The key design question becomes:

Are we generating invalid combinations and rejecting them later, or are we preventing them from entering the executable search space?

That question is not limited to ASP. It applies to constraint programming, database query planning, workflow automation, and even LLM-agent tool orchestration. Systems scale better when impossibility is pushed earlier in the pipeline.

CAG is one answer within ASP: derive filters from constraints and attach them to guessing. In business language, it converts some downstream validation into upstream generation control.

That distinction often determines whether an automation system is merely correct in principle or usable in production. Correctness after explosion is not a product. It is a postmortem with syntax highlighting.

The boundary: CAG needs structure to exploit

The paper’s limitations are not a polite paragraph added because reviewers expect humility. They materially affect how the result should be used.

First, the HCP is a lower-bound benchmark. It captures the module/frame/rack structure, but excludes several sources of industrial complexity. Full configuration systems may include cables, heterogeneous components, physical constraints, thermal or electrical balancing, layout restrictions, and lifecycle rules.

Second, the incremental strategy assumes favorable decomposability. If partial configurations often need to be revised after later requirements arrive, the clean incremental story becomes harder. Backtracking across previously fixed partial solutions can reintroduce complexity.

Third, CAG depends on deriving useful filter conditions from constraints. Some constraints are structurally friendly: they clearly reveal when a guess would violate capacity, uniqueness, ordering, or ownership. Other constraints may be harder to convert into cheap filters. The paper itself notes complications around aggregates and auxiliary rules, and the attempted combination with incremental ProASP failed because of syntactic limitations related to aggregates.

Fourth, the experimental result compares specific tool versions and implementation choices. The authors used clingo 5.7.1, DLV 2.1.2, a specific Alpha version, newground’s NaGG version, and ProASP as retrieved from GitHub in December 2024. Future versions may change the landscape. Tooling is not theology; it updates.

These boundaries do not weaken the central result. They prevent the wrong purchase order.

Grounding-aware design should become a first-class engineering habit

The paper’s deeper contribution is not just a new technique. It is a shift in where engineers should look when declarative AI systems fail to scale.

The naive workflow is:

1. write expressive rules;
2. run solver;
3. if slow, tune solver or add hardware.

The grounding-aware workflow is different:

1. inspect how rules ground;
2. identify guesses that constraints will always reject;
3. move rejection logic earlier into generation;
4. exploit decomposability where the domain naturally supports it;
5. measure grounding size, memory, grounding time, and solving time separately.

This matters because solver time can be misleadingly small. In the paper’s best-performing CAG setup, solving is only about 1.5% of total execution time. In optimized incremental clingo, it is about 0.6%. If a team stares only at solver performance, it will optimize the wrong layer with admirable determination and minimal effect. Enterprise software has a long tradition of this. We call it “best practice” after the second budget cycle.

A practical grounding-aware review for a configurator should ask:

This is not glamorous work. It is also the difference between a declarative prototype and a system that survives contact with production-scale input.

The conclusion: the grounder is part of the product

The paper starts from an appealing premise: ASP lets users specify problems, and computers solve them. For many domains, that vision has worked well enough to earn serious attention. But large-scale configuration exposes the cost hidden between specification and solving.

The study shows that current ASP methods struggle on a simplified electronic configuration benchmark. Lazy grounding with heuristics reaches further than standard ground-and-solve systems. Incremental solving helps when partial solutions can be extended. Constraint-aware guessing then reduces memory demand dramatically by filtering impossible guesses before grounding fully materializes them.

The most important number is not only 6,200 things. It is not even the 99.6% grounding-size reduction against comparable incremental clingo. The most important fact is that grounding still takes around 94% of execution time in the best CAG setup. Even after a major improvement, the grounder remains the battlefield.

For business automation, that is the takeaway. Declarative AI does not scale merely because the rules are compact. It scales when the path from compact rules to executable search is engineered with the same seriousness as the solver itself.

Grounding is not plumbing. Grounding is the new scaling.

Cognaptus: Automate the Present, Incubate the Future.