Pólya’s How to Solve It: Heuristics as Infrastructure
This Wednesday’s classic: George Pólya’s How to Solve It (1945). Four phases — understand the problem, devise a plan, carry out the plan, look back — wrapped around a dictionary of named heuristics: decompose and recombine, work backward, use analogy, solve a related problem, specialize and generalize. The radical move was treating problem-solving methods as teachable, nameable procedures rather than inspiration — which is precisely the premise of the Reasoning Library. Several of our problem-solving graphs are Pólya heuristics given executable form and gates, and his look back — the phase unaided generation skips — is the one gates make mandatory.
The book
In 1945, the Hungarian mathematician George Pólya, then at Stanford, published How to Solve It — a small book for students and teachers that became one of the most widely read books about mathematical thinking ever printed. Its skeleton is four phases. Understand the problem: what is the unknown, what are the data, what is the condition? Devise a plan: find the connection between data and unknown, reaching for known methods by name. Carry out the plan, checking each step. Look back: examine the result, test it another way, ask what transfers to the next problem.
Around the phases sits the book’s most durable furniture: a short dictionary of heuristic, an alphabetized catalog of named methods. Decomposing and recombining — split the problem, work the parts, reassemble. Working backward — start from what is required and chain toward what is given, a method Pólya traces to the Greek geometers. Analogy — borrow the structure of a solved problem. Auxiliary problems — solve a related or simpler problem and use its result or its method. Specialization and generalization — move between the concrete case and the general pattern. Each entry is described, exemplified, and — the crucial part — given a name.
The radical move: methods you can name
Pólya’s contemporaries largely treated problem solving as talent: you had it or you did not, and what happened between reading a problem and solving it was inspiration. His claim was that it is a craft with methods, that the methods can be named, and that what has a name can be taught, asked for, and reached for deliberately. The teacher’s questions in the book — could you decompose the problem? could you work backward from what is required? — are heuristics invoked by name, on purpose, at the right moment. That is precisely the premise of a strategy library. If a reasoning method can be named and described, it can be catalogued; if it can be catalogued, it can be selected deliberately rather than performed by accident. The Reasoning Library is a descendant of the short dictionary, with one demand Pólya never had to meet: the entries must run.
From dictionary to graphs
Several of the library’s problem-solving graphs are Pólya entries given executable form. Decomposing and recombining is the decomposition graph: a dedicated node names the parts, each part is solved in its own scope, and a coverage gate refuses any recomposition that dropped a piece. Working backward is the working-backward graph: chain prerequisites in reverse from the required end state until the chain grounds in what is already true today. Analogy is the analogical-reasoning graph, the subject of an earlier essay in this series. And the four phases become enforceable. “Understand the problem” is a node whose output — the problem as understood — is recorded and challengeable rather than silently assumed. Most important is the fourth phase. Look back is exactly what a single fluent forward pass omits: unaided generation has no look back, because the pass ends when the answer is emitted. In an IRG graph, looking back is not a virtue but a gate — a verification node re-measures, and a result that fails re-measurement does not proceed. The phase everyone skips is the one the architecture makes mandatory.
Limits, honestly stated
Heuristics are guidance, not algorithms, and Pólya was insistent on the point: heuristic reasoning is provisional and plausible — it suggests candidates, it does not determine answers. Nothing about encoding changes that. A graph disciplines the application of a heuristic — the phases happen, in order, on the record — but the judgment inside each step remains judgment: which decomposition to propose, which prerequisite is genuinely necessary, which solved problem is actually analogous. The gates catch proposals that fail their stated criteria; they do not make the proposals wise. Later research added an honest complication: work in mathematics education, notably Schoenfeld’s, found that students taught the heuristics often failed to deploy them — knowing the dictionary is not knowing when to open it — and strategy selection remains a judgment that sits above any single graph. The library’s claim is correspondingly modest: named, inspectable method — not automated insight.
The takeaway for a compliance reader
Two of Pólya’s questions travel well beyond mathematics, and they apply directly to any reasoning system a vendor puts in front of you. First: can it name its method? A system that cannot say which procedure it is following cannot be checked against that procedure. Second: where is its look back? If there is no phase where the result is re-examined before it ships, the system is asking to be trusted on fluency. Pólya wrote the checklist in 1945. Gates are how it stops being optional.