Hourglass Reasoning: structural context isolation for reliable rule discovery

Each step is a separate request in a new conversation. Only what's shown on the arrows gets passed between steps.

INPUT: Examples (S) — several "input → output" pairs

STEP 1: Induction
  Input: Examples S
  Does: Extracts the input data structure → schema φ
        + intermediate breakdown of examples → draft z
  → Passes forward: φ and z

STEP 2: Deduction
  Input: Examples S + φ + z
  Does: Formulates the transformation rule T
        z is DESTROYED after this step
  → Passes forward: only φ and T

STEP 3: Implementation
  Input: Examples S + φ + T
  Does: Produces the final answer/text/plan (artifact P)
  → If P is correct: done
  → If P contains errors: go to Step 4

STEP 4: Refinement (if errors)
  Input: S + φ + T + P + error description
  Does: Updates φ and T (does NOT patch P directly!)
        Regenerates P from the updated φ and T in a clean context
  → Loop: return to Step 3 with the new φ and T

Critically important: draft z never crosses the boundary between Step 2 and Step 3. Error history never carries over into the next iteration. Only φ and T do.

Task: You're a social media manager running a community page for a coffee shop called "Coffee Mania." You want to teach the model to write posts in the brand's style. You have 5 sample posts and need to generate new ones for different occasions.

STEP 1 — Prompt in a new conversation:

Here are 5 posts from a coffee shop's community page. Your task is NOT to write a post,
but to extract the structure.

Post 1: [paste here]
Post 2: [paste here]
Post 3: [paste here]
Post 4: [paste here]
Post 5: [paste here]

Do TWO things:

**SCHEMA φ** — how each post is structured:
- What blocks it consists of (structure)
- Which elements are mandatory
- How it opens, how it closes
- Tone and register

**DRAFT z** — specific observations from these 5 posts:
- What exactly the brand uses in each example
- Specific phrases, patterns

STEP 2 — New conversation:

Here are 5 coffee shop post examples [paste here],
here's schema φ [paste from Step 1],
here are observations z [paste from Step 1].

Formulate RULE T — an algorithm for creating a post in this style.
Don't write a post. Only the rule.

The rule must work for ANY occasion (not just these five).
z is no longer needed after this step.

STEP 3 — New conversation:

Create a post for the "Coffee Mania" coffee shop.

Schema φ: [paste here]
Rule T: [paste here]
Occasion: opening of a new location on Fifth Avenue, November 15

Use only φ and T. I'm only showing the examples for verification:
[5 posts]

If you don't like the result — STEP 4 in a new conversation:

Here's the post [paste P], here's what's wrong: [description]

Schema φ: [paste here]
Rule T: [paste here]
Examples: [paste S]

Don't fix the post directly.
First, update φ and T — identify exactly what's wrong in them.
Then write a brand-new post from scratch using the updated φ and T.

Result: In Step 2, the model produces a formal algorithm, like a blueprint: "opening = emotion/scene, middle = fact/benefit, ending = call to action without an exclamation point." In Step 3, you get a post that structurally matches the brand — not just something that "feels similar." If there's an error, Step 4 revises the actual rule instead of cosmetically patching the text.

The failure of standard refinement — the model gets everything in one context at once: examples, its previous attempt, and the error description. In that "noise," it doesn't update the rule — it patches the specific output to fix the specific error. The next version passes the old tests but creates new problems elsewhere.

What the model is genuinely good at — formulating explicit rules from examples. That's exactly φ + T. The model handles "describe the pattern" beautifully — and much worse at "reproduce the pattern while keeping every past mistake in mind."

How the method exploits this strength — by forcibly isolating each stage. The implementer (Step 3) never sees the error history. The refinement agent (Step 4) never edits the output directly. Every fix has to go through updating φ and T. It's the difference between "fix the typo in the code" and "reformulate the theorem, then rewrite the code from scratch."

Control levers: - Level of detail in φ → the more detailed the schema, the more precise the implementation. Ask in Step 1 for "describe at least 7 structural elements" - Number of iterations → cap Step 4 at 2-3 repeats: quality usually stops improving after three rounds - Rigor of draft z → ask in Step 1 for "quote directly from the examples," which produces a more precise schema - Explicit stopping criterion → in Step 4, add "if the rule hasn't changed, don't rewrite — just say so"

Step 1 — Induction

Here are {number} examples of {content_type}:

{examples}

Do two things — don't create {content_type}, just analyze:

**SCHEMA φ** — the universal structure of {content_type} in this style:
- What blocks it consists of
- What's mandatory
- Tone, register, characteristic devices

**DRAFT z** — specific observations from these examples:
- What exactly is used in each one
- Specific phrasings and patterns

Step 2 — Deduction

{examples}

Schema φ: {paste from Step 1}
Draft z: {paste from Step 1}

Formulate RULE T — an algorithm for creating {content_type} in this style.
The rule must work for any task in {context},
not just for these examples.
Don't create {content_type}. Only the rule.

Step 3 — Implementation

Create {content_type} for the following task: {task}

Schema φ: {paste from Step 2}
Rule T: {paste from Step 2}

Rely only on φ and T.
Examples are only a reference for checking: {examples}

Step 4 — Refinement (if there's an error)

Result: {paste from Step 3}
What's wrong: {problem description}

Schema φ: {paste here}
Rule T: {paste here}
Examples S: {paste here}

Don't fix the result directly.
First: update φ and T — identify exactly what's wrong in them and how to improve them.
Then: create a new {content_type} from scratch using the updated φ and T.

Placeholders: - {content_type} — posts, emails, scripts, briefs, headlines - {task} — the specific request for the new item - {context} — industry, brand, platform - {examples} — 3-7 samples (5 is the sweet spot)

🚀 Quick start — paste this into the chat:

Here's the Hourglass Reasoning template — a technique for precisely reproducing
patterns from examples. Adapt it to my task: {your task}.

Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask about content type, examples, and the task — because it needs input for each of the four steps. It'll take the isolation logic from the template and tailor it to your case.

⚠️ Tasks requiring implicit knowledge: For some linguistic and cultural patterns, explicitly verbalizing the rule performs worse than intuitive application. On GPT-5.5, Hourglass lost to a direct prompt on linguistic puzzles (pass@1: 46.5 vs 58.3). If a task requires a "feel for language" rather than a structural rule, the method can actually hurt.

⚠️ Requires a verifiable result: Step 4 only works when there's a clear error criterion. "Write it better" isn't a criterion. "Doesn't match the format" / "no call to action" is a criterion.

⚠️ Four separate sessions: You need to meticulously copy φ and T between chats. If you accidentally leak extra context in, the isolation breaks and the gains disappear. Ablations confirm it: isolation itself is the source of the improvement, not structured output on its own.

⚠️ The first step is critical: A weak induction in Step 1 isn't compensated for by strong refinement later. If schema φ starts out bad, Step 4 won't rescue it — the refinement agent alone, without a good starting schema, produces results roughly at baseline level.

A researcher at Peking University asked: why does self-refinement so often make results worse? Instead of improving answers, repeated "fix it" requests often made things worse — especially on hard tasks. The idea was simple: physically isolate the rule from the implementation by splitting the task into separate API calls with no shared history.

Tested on three deliberately different benchmarks chosen to represent different flavors of difficulty: ARC-AGI-2 (visual puzzles — guess the grid transformation rule), ChipBench (Verilog circuit synthesis — zero tolerance for errors), and BBEH-Linguini (linguistic olympiad problems, where verbalizing rules is already known from prior research to be problematic on its own). Models used: GPT-5.5 and Gemini 3.1 Pro.

The most telling result comes from the ablations. The researchers deliberately broke the method piece by piece: removed isolation while keeping the structured output; weakened the initial induction step; stripped out all the auxiliary instructions from the prompts. Key finding: without context isolation, results dropped almost to baseline, even when φ and T remained in the prompt. Structured output without physical isolation is a placebo. This ran counter to the intuition that "the main thing is just writing the rule explicitly."

On ChipBench with GPT-5.5, Verilog synthesis accuracy rose from 31% to 58% — nearly doubling. On ARC-AGI-2, best-of-5 improved by 14 points. A particularly intriguing result showed up on the linguistics benchmark: Self-Refine there performed twice as badly as the raw prompt, while Hourglass didn't. This confirms that the problem isn't "explicit rules" per se — it's mixing them with the mess of corrections in a single context.

The authors' original prompts (for ARC-AGI-2) are on GitHub: https://github.com/ZhuHuan09/hourglass-reasoning

Information flow structure from the paper's table:

Stage        | Input              | Output        | Role
-------------|--------------------|-`--------------|--------------------------
Induction    | S                  | φ, z          | Generate schema + scaffold
Deduction    | S, φ, z            | T             | Derive rule; discard z
Implementation | S, φ, T          | P             | Compile (φ,T) into artifact
Refinement   | S, φ, T, P, ŷ     | φ_new, T_new  | Revise (φ,T); regenerate P
             |                    | P_new         |

Context: This is the formal table from Section 3.2, describing the exact architecture of the information flows. The key fact — z (transient scaffold) is destroyed after Step 2 and never passed forward.

💡 Adaptation: Hourglass for competitor analysis

A classic case — you have 5-7 examples of a competitor's successful products (product listings, landing pages, ad copy). You want to understand their logic and apply it to your own.

Step 1: Extract schema φ (the offer's structure) + draft z (specific usage examples). Step 2: Formulate rule T (positioning principle, the logic behind their value proposition). Step 3: Apply it to your own product.

The advantage: you're not "copying phrasing" (shallow mimicry) — you're reproducing the structure. The model can't cheat by leaning on the original text, because it literally doesn't see it during the implementation stage.

🔧 Technique: explicitly forbid direct edits

By default, the model will try to edit the output directly — that's its strong default pattern. Add an explicit ban in Step 4:

Forbidden: editing the current result line by line.
Required: first update φ and T, then create the result again from scratch.
Write "Updated φ:" first, then "Updated T:", then the result.

Effect: The model doesn't "polish" the text stylistically — it reconsiders the logic and regenerates from scratch. The difference becomes noticeable by the second or third refinement pass.

🔧 Technique: z as a diagnostic tool

By default, draft z is meant to be discarded. But for debugging purposes, you can keep z around and compare it against T:

Also: show me z before formulating T.
I need to check the logic behind the jump from observations to the rule.

Effect: You can see exactly where the model "cut corners" when formulating the rule — which specific observations it used to derive T. If z is rich but T is thin, ask it to expand T.

Paper: Think Through a Bottleneck: Hourglass Reasoning for Rigorous Induction Author: Huan Zhu, Peking University Code and prompts: https://github.com/ZhuHuan09/hourglass-reasoning

Related work cited in the paper: - Self-Refine (Madaan et al., 2023) — the baseline self-refinement method - ARC-AGI-2 (Chollet, 2019) — visual induction benchmark - BBEH-Linguini / BIG-Bench Extra Hard (Kazemi et al., 2025) - Information Bottleneck Theory (Tishby et al., 1999)