Home › Datasets › Logical Reasoning & Puzzles
Reasoning & Math PackHow to Fine-Tune an LLM for Logical Reasoning & Puzzles
Deductive and inductive reasoning, logic puzzles, syllogisms, and structured argument analysis.
- 568 instruction-response pairs
- Format JSONL
- Pack Reasoning & Math
- Dataset $29 one-time
$29 for the dataset. Training is priced separately by model, starting at $47.
What can this kind of fine-tuning teach an LLM?
A general-purpose model may already know some of this subject. Fine-tuning serves a different purpose: it repeatedly demonstrates the kinds of requests, response patterns, terminology, decisions and workflows you want the model to handle more consistently.
For Logical Reasoning & Puzzles, the dataset focuses on deductive and inductive reasoning, logic puzzles, syllogisms, and structured argument analysis. Fine-tuning shapes recurring model behavior; it does not turn the model into a live database or guarantee correctness on every new case.
What training data should cover
Useful supervised fine-tuning data should resemble the work you expect the model to perform. This Rebiha dataset's domain definition is organized around 15 coverage areas:
- solving a classic logic grid puzzle; working through a deductive reasoning chain; identifying a flaw in an argument; solving a 'who owns what' style constraint puzzle; evaluating whether a syllogism is valid
- solving a sequence or pattern-recognition puzzle; working through a truth-teller/liar logic problem; identifying an unstated assumption in an argument; solving a scheduling or arrangement constraint puzzle; distinguishing correlation from causation in a scenario
- working through a probability-based logic puzzle; evaluating the strength of an inductive argument; solving a river-crossing or resource-constraint puzzle; identifying a logical fallacy by name and explaining why; working through a conditional (if-then) reasoning chain
How Rebiha prepared the training material
This page contains 568 instruction-response pairs from the existing Rebiha dataset. Its domain definition was designed around the coverage areas above so the training material spans multiple realistic tasks rather than one narrow prompt pattern.
Rebiha's broader dataset workflow uses structured quality review to help identify problems such as contradictions, unsupported claims, unsupported assumptions, calculation errors and other weak training examples. You can inspect real examples on this page before deciding whether the dataset fits your model and use case.
What is in this dataset
568 instruction-response pairs covering deductive and inductive reasoning, logic puzzles, syllogisms, and structured argument analysis. Each pair is a realistic instruction with a full written response, in the JSONL format used for supervised fine-tuning. No synthetic filler, no duplicated rows.
Example pairs
Real rows from the dataset, shown in full.
Three friends—Alice, Ben, and Carla—each own exactly one pet: a cat, a dog, or a fish. They each live in a different colored house: red, blue, or green. Clues: 1) The person who owns the dog does not live in the blue house. 2) Alice lives in the red house. 3) Ben owns the cat. 4) Carla does not own the fish. Determine who owns which pet and who lives in which colored house. Show your full reasoning chain.
Let's denote people A=Alice, B=Ben, C=Carla. Pets: Cat, Dog, Fish. Houses: Red, Blue, Green. Step 1: From clue 3, Ben owns the cat. So Ben's pet is Cat. Step 2: The remaining pets are Dog and Fish for Alice and Carla. Clue 4: Carla does not own the fish, so Carla must own the Dog. Therefore Alice owns the Fish. Step 3: Now houses. Clue 2: Alice lives in Red house. So Alice's house = Red. Step 4: Clue 1: The dog owner does not live in Blue. The dog owner is Carla (from step 2). So Carla does not live in Blue. Since Alice is Red, Carla cannot be Red either (each house unique). So Carla must live in Green. Step 5: The only remaining house for Ben is Blue. Final assignment: Alice – Fish – Red; Ben – Cat – Blue; Carla – Dog – Green. Check all clues: Dog owner (Carla) not in blue ✓; Alice red ✓; Ben cat ✓; Carla not fish ✓. Logic holds.
You are a detective. Given these premises: (P1) If the butler was in the library at midnight, then the safe was not opened. (P2) Either the safe was opened or the maid is lying. (P3) The maid is not lying. (P4) The butler's fingerprints are on the safe only if he was in the library at midnight. (P5) The butler's fingerprints are on the safe. Deduce whether the safe was opened. Provide a step-by-step deductive chain and state the conclusion.
Let L = butler in library at midnight; S = safe opened; M = maid lying; F = fingerprints on safe. Given: P1: L → ¬S. P2: S ∨ M. P3: ¬M. P4: F → L. P5: F. Step 1: From P5 (F) and P4 (F → L), by modus ponens, we derive L. Step 2: From L and P1 (L → ¬S), by modus ponens, we derive ¬S. Step 3: From P3 (¬M) and P2 (S ∨ M), the disjunctive syllogism gives S. Step 4: Now we have both ¬S (step 2) and S (step 3), which is a contradiction. This means the premises are inconsistent. However, if we treat the premises as reliable, the contradiction indicates at least one premise is false. But as a pure deduction, the set of premises entails a contradiction, so no consistent world satisfies all. If forced to answer 'was the safe opened?' under the assumption all premises must hold, the inference is explosive; but in standard reasoning, we conclude the premises are inconsistent. In practice, the most likely culprit premise is P4 or P5, because if fingerprints are on safe, and if that implies library, then butler in library leads to not opened, but maid not lying forces opened. So the only consistent resolution is that either P4 is false (fingerprints don't guarantee library) or P5 is false (no fingerprints) or P1 is false. Therefore, from the given premises alone, you cannot validly conclude a single answer; the argument is unsound due to inconsistency. The logical conclusion: the premises contradict, so no valid deduction of S or ¬S from all of them exists without rejecting one.
Identify the flaw in the following argument: 'All successful entrepreneurs take risks. John takes risks. Therefore, John will be a successful entrepreneur.' Explain why the reasoning is invalid, and provide a corrected version or a counterexample.
The argument commits the fallacy of affirming the consequent. The structure is: All entrepreneurs who are successful (S) are risk-takers (R) — formally ∀x(Sx → Rx). Premise: John is a risk-taker (Rj). Conclusion: John is successful (Sj). The valid inference would require the converse: ∀x(Rx → Sx), but that is not given. Risk-taking is a necessary condition for success among entrepreneurs, not a sufficient condition. Counterexample: John might take risks but lack capital, market timing, or execution skills, so he could fail. Another counterexample: A person who takes reckless risks without planning is unlikely to succeed. Corrected argument: 'All successful entrepreneurs take risks. John is a successful entrepreneur. Therefore, John takes risks.' That is valid (modus ponens on the universal). Or if you want to infer success, you need an additional premise like 'Everyone who takes risks is successful' which is false. So the flaw is the invalid logical form: treating a necessary condition as sufficient.
Who this is for
Builders who want their fine-tuned model to reliably perform this specific capability, as part of a broader assistant or agent.
Which models this works with
The dataset is plain JSONL, so it works with any instruction-tuned open model. On Rebiha you can train it directly on:
- Qwen — Qwen3.8, Qwen3.6, Qwen3.5, Qwen3, Qwen2.5, Qwen2.5-Coder
- Granite — Granite 4.1 (3B, 8B, 30B)
- OLMo — OLMo 3, OLMo 3.1
- GLM — GLM-4
- Gemma, Phi, DeepSeek, Mistral, and Llama families
Training uses LoRA, or QLoRA on a 4-bit base for larger models. Your base model's weights are never modified — training produces a separate adapter.
How it works
- Pick this dataset and a base model.
- Rebiha runs the job on a managed GPU. You set up nothing.
- Download your model: a ready-to-run GGUF, plus developer assets (adapter, tokenizer, configs).
Fine-tuning or RAG?
Use RAG when the model needs facts that change — your prices, your documents, today's inventory. Use fine-tuning when you want consistent behavior and structure without prompting for it every time. This dataset teaches the shape of this capability, not facts to look up.
How managed fine-tuning works
- Inspect the dataset examples and choose a compatible base model.
- Rebiha runs the training job on managed GPU infrastructure using LoRA or QLoRA as appropriate.
- Download portable model assets for your own workflow, including the available ready-to-run and developer outputs for the selected training path.
Fine-tuning or RAG?
Use fine-tuning when the objective is recurring behavior: response structure, domain patterns, terminology, workflow, or how the model approaches a class of requests. Use RAG when answers depend on changing or proprietary facts that should be retrieved at request time. The two approaches can also work together.
Know what goes in. Own what comes out.
You can inspect real examples before training, choose the model you want to adapt, and keep portable model assets when training is complete.
Related datasets
- General Instruction Following — 978 pairs
- Multi-Turn Conversation — 466 pairs
- Rewriting & Editing — 854 pairs
- Summarization — 781 pairs