Reasoning Scaffolds: Scratchpads, Tables, Decision Matrices, and Code

The model gets the answer wrong, and it is not because it did not know something. It dropped a constraint. It merged two cases that should have stayed separate. It skipped a comparison it was supposed to make. The knowledge was there; the structure was not.

That distinction matters because it changes what you fix. A knowledge gap calls for better context, retrieval, or examples. A structure gap calls for an external representation the model fills in — one where the intermediate state is visible enough that you can point at the broken slot and name it. That representation is what I mean by a reasoning scaffold, and the engineering question is not "how do I make the model think harder." It is "which representation makes this specific error inspectable."

Why "Think Step by Step" Is Not a Scaffold

"Think step by step" is a request to deliberate. A scaffold is a data structure with named slots, types, and ordering. The difference is not philosophical; it is operational.

Here is the test I use: after the model produces its output, can I point at the intermediate state and say which slot is wrong? If the answer is "the reasoning felt off," I do not have a scaffold. I have a fluent paragraph that is easy to rationalize after the fact and hard to grade before it.

Free-form deliberation has a second problem. A written trace is not a verified record of the computation that produced the answer. It is a plausible narrative generated alongside the answer, and it can be internally consistent while the actual derivation went somewhere else. Treat any trace as evidence to check, not as proof of process.

If you already write prompt contracts and few-shot examples, you have the foundation. A contract defines objectives, inputs, constraints, and acceptance criteria. A scaffold is the part of that contract that specifies the shape of the intermediate state — the slots the model must fill before it is allowed to conclude. The rest of this article assumes that foundation and focuses on the selection problem: four representations, each externalizing a different kind of state, each catching a different error class.

The Four Representations and What Each One Makes Visible

The decision axis is simple. Each representation externalizes a different kind of intermediate state, and that state determines which errors you can localize.

Read the table as a map from error class to representation. If you cannot name the error class you are trying to remove, you are not ready to pick a scaffold — you are guessing.

Scratchpads: Sequential Derivation With a Fixed Skeleton

A free-form scratchpad is the weakest version of this technique because it has no skeleton. The fix is to give it one: named steps, required inputs per step, and an explicit carry-forward of intermediate values.

Step 1 — Extract quantities
  input: problem statement
  output: {name: value, unit} for each quantity
  carry: all quantities

Step 2 — Derive
  input: carried quantities
  output: one line per operation, restating the running value
  carry: final value before rounding

Step 3 — Answer
  input: carried final value
  output: the answer, plus the unit

The failure mode this catches is silent step-skipping. Without a skeleton, the model jumps from premise to conclusion and the trace still reads as plausible. With the carry-forward requirement, a dropped quantity becomes visible: Step 2 references a value Step 1 never produced, or the running value changes without an operation to explain it.

The constraint has a limit. Scratchpads do not enforce coverage. Nothing in the skeleton forces the model to consider a case it never mentions. If your error is "it forgot to handle the empty-input case," a scratchpad will not help, because the missing case produces no missing step. That is a table problem.

A scratchpad trace is a claim about reasoning, not a transcript of it. Grade the intermediate values, not the fluency of the prose around them.

Tables: Forcing Coverage Across Cases and Dimensions

The scaffold in a table is the header row. Choosing dimensions is choosing what the model is allowed to compare, and that choice is the actual design decision — the cells are downstream of it.

Tables catch omission errors that scratchpads hide, because an empty cell is visible and a missing sentence is not. If you ask for a row per input class and a column per behavior, a class the model never considered shows up as an absent row instead of an invisible gap.

The failure mode is subtler than it looks. The model fills cells with plausible prose instead of the typed value the column promised. A column headed "latency (ms)" comes back with "generally fast." A column headed "handles null?" comes back with a paragraph about robustness. The shape is compliant; the content is not comparable.

Constrain cell content by type and length:

| input class | returns value? | raises? | notes (<= 8 words) |
|---|---|---|---|
| empty string | no | no | returns default |
| null | no | yes | TypeError |
| valid int | yes | no | — |

Now an empty cell is a real signal, and a cell that violates its type is a detectable defect rather than a style choice.

The boundary: when the dimension set is unknown or open-ended, a table becomes a cage. It forces premature commitment to axes you guessed, and the model will dutifully fill columns that should not exist. If you cannot name the columns before you see the answer, do not use a table yet.

Decision Matrices: Making Tradeoff Judgment Auditable

A decision matrix is a table with three additions: explicit criteria, weights, and a scoring rule. That extra structure moves the inspectable state from the option level to the criterion level. You can now disagree about one weight instead of the whole recommendation.

The main benefit is disagreement localization. When a recommendation feels wrong, you do not have to argue with the conclusion. You point at the criterion whose weight or score is doing the work, and you argue about that.

The failure mode is back-filling. The model reaches a conclusion, then assigns scores that justify it, producing a matrix that looks rigorous and proves nothing. The tell is a suspiciously clean alignment between weights and outcome, or scores that cluster at round numbers with no stated basis.

Two mitigations work well together. First, require scores before the recommendation, in that order, so the conclusion cannot steer the inputs. Second, require the model to state which single criterion would have to change to flip the outcome:

Scoring rule: score = sum(weight_i * rating_i), ratings 1-5.
Output order: criteria -> weights -> per-option ratings -> totals -> recommendation.
Then: "The recommendation flips if <criterion> moves from <x> to <y>."

That last line is the audit. If the model cannot name a flip condition, either the decision is dominated by one criterion or the matrix is decorative.

Which brings us to when not to use it. If the decision is dominated by one hard constraint — a compliance requirement, a hard latency ceiling — a matrix adds ceremony without changing the answer. Score the constraint first; if it eliminates all but one option, stop.

Code as the Scaffold: When Reasoning Should Be Executed

When the intermediate state is deterministic, code is the right representation. The model writes the procedure, the runtime produces the value, and the value is not a matter of interpretation. This removes an entire error class: arithmetic, unit conversion, aggregation, and string manipulation done in prose.

The scaffold is the interface, not the code. Define inputs, outputs, and the assertion that must pass before the result is accepted:

def total_cost(line_items, tax_rate):
    """line_items: list of (unit_price, quantity). tax_rate: decimal."""
    subtotal = sum(price * qty for price, qty in line_items)
    return subtotal * (1 + tax_rate)

# The check tests the intended property, not just that it ran.
assert total_cost([(10.0, 2), (5.0, 1)], 0.1) == 27.5

The failure mode here is specific and easy to miss: the model writes code that runs cleanly and computes the wrong thing. A green run proves the code executed, not that it computed what you meant. The assertion has to test the intended property — the invariant, the boundary, the unit — or it is theater.

Successful execution is not correctness. If your check only confirms the code ran, you have automated the appearance of verification.

The boundary is judgment. Ambiguity resolution and open-ended synthesis do not become more reliable by being written as code. If the task requires deciding what the requirement means, code will faithfully compute the wrong interpretation.

Choosing a Scaffold: A Short Decision Procedure

Start from the error you actually observe, not the technique you want to try.

• Dropped steps, lost intermediate values → scratchpad skeleton with carry-forward.
• Missing cases, uneven coverage → table with a row per case.
• Contested tradeoffs, unauditable recommendations → decision matrix with scores before conclusions.
• Deterministic computation, unit or arithmetic errors → code with a property assertion.

Combine only when each representation carries a distinct part of the state. A scratchpad that produces values, a table that checks coverage, and code that computes a final aggregate can coexist because each owns a different slot. Stacking two representations that both try to hold the same state multiplies tokens and failure surface for no gain.

Evaluating a Scaffold Before You Trust It

Do not decide by how good the trace reads. Decide by evidence.

Build a small set of tasks with known correct answers and known error classes, including at least one case the scaffold should fail. That last case is the control — if the scaffold "passes" it, your evaluation is measuring format compliance, not reasoning.

Grade the intermediate state, not only the final answer. A correct answer from a broken trace is a warning, not a success, because the next input will expose the same broken structure.

Measure the failure mode you were trying to remove and confirm it actually dropped. Then watch for new failures the scaffold introduced — a table that forces wrong dimensions, a matrix that invites back-filling, code that runs and computes the wrong thing.

Track cost. Scaffolds add output tokens and latency. The accuracy gain has to justify the added surface, and on simple tasks it often does not.

Failure Modes and Overkill

The recurring trap is scaffold theater: elaborate structure that produces a confident-looking artifact with no verifiable intermediate state. A beautiful matrix with back-filled scores is theater. A table full of prose is theater. A scratchpad with no carry-forward is theater.

The second trap is format compliance without reasoning. The model fills the shape, and the shape hides the error instead of exposing it. This is why the check matters more than the format.

Over-scaffolding simple tasks adds tokens, latency, and new failure points for no measurable gain. And a scaffold that encodes the wrong decomposition is worse than none: it locks in a bad mental model and makes the error harder to see, because now the error has a structure that looks intentional.

Add structure only when you can name the error class it removes and the check that proves it. If you cannot name both, you are decorating.

The Next Move

Pick one task that currently fails intermittently. Name the error class in a sentence — "it drops the unit conversion," "it forgets the empty case," "it recommends without showing the tradeoff." Choose the single representation that makes that error visible, and run a small before/after comparison that grades the intermediate state as well as the answer.

A scaffold earns its place only when it makes a specific failure inspectable and the added cost is smaller than the error it removes. Everything else is ceremony.