Reasoning step back

Step-Back Prompting — abstract first, instantiate second

What this is (honestly): a two-hop retrieval-and-application order, not a capability upgrade. The model does not learn any new principle by doing this. What changes is the SEQUENCE: instead of reasoning directly on the concrete instance (where the specific numbers/names/dates crowd out the governing rule and the model pattern-matches to "a similar-looking answer"), the model first steps back and states the general, context-free question or principle that governs the case, answers THAT in the abstract, then plugs the specific facts into the validated abstraction. This is the published "Take a Step Back" pattern (Zheng et al., 2023): abstraction-before-instantiation measurably helps on STEM, knowledge-QA, and multi-hop reasoning specifically because it stops surface details from hijacking which rule gets applied.

What it isn't:

• Not chain-of-thought — CoT reasons step by step at the same level of abstraction, on the concrete problem, from the start. Step-back inserts one deliberate level-SHIFT (concrete → abstract → concrete) before any CoT-style chaining begins.
• Not least-to-most — least-to-most decomposes a hard instance into a sequence of easier instances of the same kind. Step-back doesn't decompose the case; it asks what higher-level concept the whole case is an instance OF.
• Not retrieval/RAG — nothing external is fetched. The "general principle" is generated by the model itself, which is exactly why it needs the guardrail below.

When to use

• The question hinges on a named principle, law, formula, legal test/element, doctrine, or strategic framework that the model plausibly knows in the abstract but risks skipping or misapplying when it dives straight into the specific numbers or facts.
• Domains where this reliably pays off: physics/chemistry problems with conditions or edge cases (which law applies here?), legal questions that turn on which test/element/exception governs a fact pattern, strategy or business questions governed by a general framework (e.g., which negotiation principle, which economic effect), differential-diagnosis-style reasoning (what syndrome/class before this specific presentation).
• Signal to watch for: if you'd expect a competent human expert to say "wait, what rule are we even applying here?" before touching the specific numbers, this technique fits.

When NOT to use

• Pure factual lookup, extraction, formatting, summarization, or translation — there is no governing principle to step back to, so the extra hop is pure overhead.
• The correct principle is already stated in the prompt or is trivially unambiguous — skip straight to application.
• Niche or obscure domains where the model is likely to confidently invent a plausible-sounding but nonexistent "general principle" (a fake legal doctrine, a misremembered formula) and no way exists to check it — see guardrail below; in that case a verifier-loop or external reference is a prerequisite, not optional.
• Arbitrary/idiosyncratic questions with no meaningful "general case" (e.g., "what's my coworker's favorite color") — nothing to abstract.

Inputs required

1. Specific question/case — the concrete instance to be solved.
2. Domain hint (optional but recommended) — physics, contract law, negotiation, etc. — primes which family of principles to search.
3. Reference material (optional, strongly recommended when stakes are high) — a textbook rule, statute text, or known-correct formula to check the stepped-back principle against, so the abstraction isn't taken purely on the model's say-so.

Procedure

1. Read, don't answer yet. State the specific question but do not compute or conclude anything about it in this step.
2. Step back. Ask explicitly: "What is the general principle / law / rule / question that governs a case like this?" Write it as a standalone, context-free statement — it should make sense with the specific names, numbers, and parties removed entirely.
3. Answer the abstraction. Resolve the general question on its own terms (state the law, formula, test, or framework, including its conditions and known exceptions), independent of the case's specific facts.
4. Guardrail — check before applying. Ask: does this principle actually fit the case, or does a condition/exception in the specific facts point to a different principle? If reference material is available, verify the stated principle against it now, before using it. This is the step most failures skip, and skipping it is how step-back goes wrong: a confidently wrong "general law" applied cleanly to correct facts still produces a confidently wrong answer.
5. Instantiate. Substitute the case's specific facts, numbers, or parties into the checked general answer.
6. Derive the specific answer, keeping the link from principle → instance explicit, so if the final answer is wrong, it's diagnosable whether the principle was wrong or the substitution was wrong.
7. Report both layers (format below) — never collapse the abstraction and the application into one paragraph; keeping them separate is what makes this technique auditable.

Output format

## Step back
**Abstract question:** <the case with names/numbers stripped out>
**General principle:** <the law/rule/formula/test, with its conditions>
**Check:** <verified against <source> | not verified — flag as risk>

## Apply to the case
**Specific facts:** <the actual names/numbers/parties>
**Instantiation:** <the principle with the specific facts substituted in>

## Answer
<final result, derived from the instantiation>

Worked example

Task: "An ideal gas is held at temperature T1 and volume V1 with pressure P1. The temperature is increased to 2×T1 and the volume is increased to 8×V1, with the amount of gas unchanged. What happens to the pressure?"

1. Read, don't answer yet: noted — do not touch the "2×" and "8×" factors yet.
2. Step back: "What is the general relationship between pressure, volume, temperature, and amount of gas for an ideal gas?"
3. Answer the abstraction: the ideal gas law, PV = nRT, holding for a fixed amount n of an ideal gas — so P = nRT / V, and for two states with the same n: P1·V1/T1 = P2·V2/T2.
4. Guardrail: does the ideal gas assumption hold here? The problem states "ideal gas" and "amount of gas unchanged" (n constant) explicitly — no exception applies, so the law is safe to use. (If the problem had instead said "real gas near its critical point," this step is where you'd catch that PV = nRT is the wrong model.)
5. Instantiate: P1·V1/T1 = P2·V2/T2 → P2 = P1 · (V1/V2) · (T2/T1) = P1 · (V1 / 8V1) · (2T1 / T1) = P1 · (1/8) · 2.
6. Derive: P2 = P1 / 4 — the pressure drops to one quarter of its original value.
7. Report:

## Step back
Abstract question: For a fixed amount of ideal gas, how are pressure, volume, and temperature related?
General principle: Ideal gas law, PV = nRT ⇒ P1V1/T1 = P2V2/T2 for constant n.
Check: verified — problem explicitly states "ideal gas" and constant amount, no phase-change or high-pressure exception flagged.

## Apply to the case
Specific facts: V2 = 8·V1, T2 = 2·T1, n constant.
Instantiation: P2 = P1 · (V1/8V1) · (2T1/T1) = P1 · (1/8) · 2

## Answer
P2 = P1 / 4 — the pressure falls to a quarter of its starting value.

See also

chain-of-thought (reasons within the concrete instance; step-back happens before it starts), least-to-most (decomposes into easier same-level sub-problems; step-back moves up a level instead), verifier-loop (pair with it to check the stated general principle itself when no external reference is available), reasoning-budget-router (if the abstraction step is a known weak spot for the cheap tier, escalate just that step).