Back to Rankings

From Natural Language to Exact Cover: A Neuro-Symbolic Approach to Zebra Puzzles

Paulius Skaisgiris, Thomas Pammer, Veronika Semmelrock, Mykyta Ielanskyi, Maximilian Heisinger, Erich Kobler

Nov 2, 2026arXiv:2611.03641v1
cs.AI
Share
Scorecard· 16/16
4.5/10 impact

Solid, well-engineered neuro-symbolic pipeline with strong numbers on a narrow benchmark, but incremental over Logic.py/Logic-LM and with confounded comparisons.

Abstract

Chain-of-Thought (CoT) generation has substantially improved the performance of Large Language Models (LLMs) on complex reasoning tasks, including code generation, data analysis, and exam-style question answering. Despite these advances, purely neural LLMs continue to struggle with elementary logical reasoning problems and lack the determinism, soundness, and reliability characteristic of symbolic reasoning systems. Conversely, classical symbolic methods such as SAT solving and exact cover guarantee correctness and completeness, but require problems to be expressed in highly specialized formal encodings, limiting their applicability to natural language inputs. In this work, we present a synergistic neuro-symbolic framework that bridges this gap by combining neural semantic parsing with deterministic exact cover reasoning. Given a Zebra-style logic puzzle in natural language, an LLM translates entities and constraints into structured tool calls that construct an exact cover instance. A symbolic solver then computes the solution and provides feedback to iteratively refine invalid, under- or overconstrained encodings, exploiting the uniqueness property of Zebra puzzles. We conduct a comprehensive empirical evaluation across multiple parameter scales, post-training paradigms, and LLM families. The results demonstrate that our hybrid approach consistently outperforms strong plain neural baselines, including CoT prompting, as well as recent neuro-symbolic methods.

AI Impact Assessments

(1 model)

Core Contribution

The paper presents NeuralExactCover (NEC), a neuro-symbolic pipeline for Zebra (logic grid) puzzles. An LLM harmonizes the puzzle text, extracts clues, and emits JSON tool calls, one per clue. The calls build a colored exact-cover instance, which is solved by Knuth's Algorithm C via the MiniExact solver. The solver's outcome (no solution, multiple solutions, or a wrong number of calls) is fed back as a retry prompt. The feedback exploits the uniqueness property of Zebra puzzles: a unique solution signals a plausible encoding, since an over- or under-constrained encoding must contain an error. The contributions are:

  • A colored exact-cover encoding of the 8 clue types, with a Python tool API.
  • The feedback loop.
  • ZebraExtreme, 400 new puzzles of size up to 8×10, in the XXL and XXXL bins.
  • The reported results are a new ZebraLogic "SOTA" (97.9% puzzle accuracy with Devstral-Small-2-24B, versus 91.7% for o3-mini-high) and the first ZebraExtreme baseline.

    The conceptual novelty is modest. Translating puzzles into solver encodings with solver feedback is well established (Logic-LM, SATLM, Logic.py, CP-Agent, Berman et al.). The new elements are the choice of exact cover as the target and the tight fit of that encoding to the puzzle structure. Doing the semantic parsing with a fixed, puzzle-specific tool API leaves the LLM little to do beyond clue classification and argument extraction. The paper is therefore closer to a well-engineered domain-specific pipeline than a general method.

    Methodological Rigor

    The study evaluates four method families (Plain, Logic-LM, Logic.py, NEC with and without feedback) across several model families, sizes (0.6B–30B), and post-training modes (base, instruct, thinking). Metrics are puzzle and cell accuracy, with bins by solution-space size and runtime analysis. A failure-trace analysis of 21 Devstral failures shows that 86% come from the neural parsing stage and 14% from de-harmonization bugs. This is useful and honest.

    Several weaknesses limit how far the comparisons can be trusted:

  • Fairness of baselines. The Logic-LM baseline is the authors' own adaptation, with a custom prompt and no feedback. The Logic.py prompt was also modified. NEC uses a hand-designed, puzzle-specific tool API with clue-type-aware functions, synonyms, and few-shot examples. The baselines are generic, so this is partly an advantage of domain engineering rather than of exact cover itself. No ablation isolates the encoding (exact cover versus the same tool API backed by a CP/SAT solver) from the tool-API design and prompt.
  • Post-hoc fuzzy matching. Name normalization with Ratcliff–Obershelp is applied to NEC outputs, and it is unclear whether the baselines get the same treatment.
  • Token budgets. The budgets are inconsistent: 4096 for Plain, default model lengths for Logic.py and NEC, and 30K for ZebraExtreme. Plain thinking models are truncated at 4K, which makes the Plain baselines artificially weak. The claim that "thinking hurts" is confounded by this.
  • Statistics. There are no error bars, seeds, or significance tests. Temperature 0 gives a single run, and the 400-puzzle ZebraExtreme subsets are small.
  • Contradictory results. Logic.py beats NEC on several configurations (e.g., Magistral, gpt-oss on ZebraLogic, and Qwen3-30B-Thinking), so "consistently outperforms" is overstated. NEC with feedback is worse than without feedback for gpt-oss-20b on XL (33.5% versus 8% without feedback, but 82% for Logic.py), and the no-feedback Qwen-Thinking results are poor.
  • SOTA claim. Comparing a 24B model with a tool pipeline to o3-mini Plain on a leaderboard is not apples to apples. Leaderboard entries are not tool-augmented, and there are no comparisons with strong frontier models given a solver tool or code execution.
  • Possible evaluation leakage. The few-shot example puzzles and the generator for ZebraExtreme follow the ZebraLogic recipe. The feedback loop uses uniqueness, which is available at test time only because the puzzle is known to have a unique solution; this is a domain-specific assumption.
  • Potential Impact

    For the LLM-reasoning community, the work reinforces a known lesson: offloading search to a solver and having the LLM do only parsing scales much better than CoT. This is useful as a data point, especially the evidence that small models (4B) can reach 80%+ with this scheme. The ZebraExtreme dataset can serve as a modest benchmark extension, because plain LLMs, including reasoning models, collapse on it. The exact-cover framing may interest the symbolic and constraint-programming community, and the MiniExact tool could see some uptake.

    However, the approach is tied to a narrow, template-like puzzle genre with 8 fixed clue types and a synthetic, templated clue language. The paper's own claim that it "bridges natural language and formal encodings" is only demonstrated where the encoding is already designed by hand and the LLM merely selects among predefined functions. Generalization to arbitrary combinatorial problems, the paper's stated future work, is the hard part and is not addressed. Practical impact beyond puzzle benchmarks is therefore limited.

    Timeliness

    The topic fits the interest in neuro-symbolic reasoning, tool use, and the scaling limits of reasoning models (ZebraLogic). The tool-calling setup with open-weight models is current. The venue (NeSy) is appropriate, but the novelty is incremental relative to Logic.py and similar work.

    Strengths

  • Clear architecture and a natural encoding choice.
  • Broad model coverage across sizes and families.
  • Large gains on the hardest puzzle bins, plus runtime analysis.
  • Code and data released, with detailed prompts and an honest failure analysis.
  • Limitations

  • Narrow domain with a hand-built tool API.
  • No ablation separating exact cover from other solver backends.
  • Baseline adaptations and uneven token budgets.
  • No variance estimates.
  • The SOTA framing is questionable, and the "consistently outperforms" claim is not fully supported.
  • Name-matching post-processing and parsing bugs affect scores.
  • Minor sloppiness (a citation mix-up in the appendix, e.g., attributing Logic.py to Pan et al.).
  • Rating:4.5/ 10
    Significance 4Rigor 4.5Novelty 4Clarity 6.5

    Generated Nov 3, 2026

    Comparison History (0)

    No comparisons yet.