Language for Ambiguity, Solvers for Commitments

Language handles messy intent. A solver handles exact constraints. The translation between them is the step that breaks. A solver can be perfectly wrong about a badly stated problem.

Language models are not good at every kind of planning. They sound coherent and violate constraints in the same paragraph.

One Missed Constraint Kills the Plan

Travel planning makes the failure obvious. One plan must satisfy dates, budgets, locations, preferences, availability, and ordering at the same time. Miss one and the itinerary is impossible to execute, however well it reads.

A plan that reads well and breaks one rule is worse than a plan that fails on its face. The first one gets executed.

Three Ways Out, and One Works Now

Researchers take three routes out of this.

• Make the language model better at planning on its own.
• Combine the language model with a symbolic solver.
• Train models so that symbolic structure emerges inside the network.

The middle route is the one a team can build this quarter. Route one waits for a better model, and route three waits for a training run. The middle route needs an interface between two components you already have.

A Solver Holds Every Constraint at Once

A symbolic solver is boring in the best way. Formalize the constraints correctly and the solver does not drop one because that sentence sat far away in the prompt. It searches the space with rules.

The split is clean. The model translates natural language into a structured problem. The solver searches that space and returns a valid plan. The model translates the result back into language a person can act on.

The reasoning note put reflection inside the model and verification outside it. The solver is that outside check, aimed at constraints instead of arithmetic.

Formalization Is the Fragile Step

The hard part is the translation from messy language into the correct formal problem. A user asks for something cheap but not terrible. The system must decide what cheap means and what terrible means. The system must also decide whether either one is a hard constraint or a soft preference.

A solver enforces whatever it is handed. Nothing inside it knows the difference between a constraint the user meant and one the model invented.

The tools note said it plainly: the weakest interface sets the ceiling. Here the weakest interface is the sentence that becomes a constraint list.

The model still earns its place at that boundary. It handles the ambiguity and asks the question that settles it. Then it hands over a structure the solver can search.

I review the constraint list, not the plan. Expose the structured object before the solver runs. Show the list in the user's own words, and mark each constraint hard or soft. Let a person or a test reject a malformed structure before any action runs.

Catch a wrong list and the fix costs one sentence. Miss it and the fix costs whatever the plan already committed.

Solver Traces Teach the Search Path

The third route becomes practical here. SearchFormer and DualFormer-style work trains on solver traces, and uses search dynamics and reasoning traces to teach better planning behavior.

The model sees more than the final answer. It sees the path that a stronger search process took.

A hybrid system writes those traces while it runs. The training data for route three is a by-product of route two.

Use the Pattern Where Correctness Is Checkable

Use the hybrid pattern when correctness depends on constraints you can examine. Schedules, routes, resource allocation, budgets, dependencies, access policies, inventory, and proof-like structure all qualify.

Skip it when the real problem is taste, strategy, judgment, or open-ended synthesis. Solvers can help at the edges there, and they will not define the target for you.

The pattern also gets thin when you ask the model to reason through everything in prose. That breaks when the environment has hard rules, long horizons, or costly invalid actions.

The Builder Test

Take one task you own this week and draw it. Label the part that reads ambiguity and the part that searches or plans. A single component doing both is the joint that fails first.

Name the part of that task that must be exact. Put it behind a tool, solver, verification step, or safety gate. Do not hope that the model stays careful.

• List the constraints that cannot be violated, before anything is generated.
• Name the one place where learned ranking beats a rule, and give the ranker only that job.
• Write down the point where the plan becomes an action, and put the gate there.
• Make the symbolic layer report the constraint it failed to satisfy, and never swallow it.

A step that needs a guarantee belongs to a planner, a verifier, a controller, or a policy gate. Compose learned judgment and explicit constraints on purpose. Otherwise you ship a system where nobody can name the part that decided.

What Carries

Use language where language is strong. Use external structure where language is weak. Inspect the handoff between them, because by default that boundary has no owner.

Every mistake in this note is a wrong plan on a screen, and a screen has an undo. Fix the handoff while that is still true. The next note puts this loop inside a body, and the undo goes away.