Failure is not permitted. It is required.
A learning framework that deliberately designs individual learning inside team projects.
You run team-project-based education but keep thinking, "The deliverables come out, yet I can't tell what each individual learned." You want a class that runs on structure, not on any one person's talent.
You want to break the role entrenchment where members "just do what they already do" in side projects, hackathons, or onboarding. You want a clear priority between the team's growth and its deliverables.
You feel nothing sticks even after finishing courses. You want to raise the density of your learning — alone or in a study group — by forming hypotheses before you learn, and then breaking them.
The more rationally a team project runs, the more each member takes on what they are already good at. The quality of the output rises, but individual learning curves flatten. Learning gets pushed aside as a byproduct you pick up by luck while solving problems.
"Solve a valuable problem, and learning will naturally follow"
"Learning is guaranteed only when it is intended"
HypoLoop starts by replacing this premise. It takes back the bet placed on accidental learning and makes learning a named goal from the very beginning.
This is not about abandoning problem-solving — it is about changing the order. The ultimate, real problem cannot be solved with today's skills. Because only learning makes tomorrow's harder problems solvable, HypoLoop puts learning ahead of deliverables. Small challenges are not detours; they are the only stairway up to the ultimate problem.
All four concepts are explained with one running example — 🍞 baking bread. The team's goal is "open a neighborhood bakery people love," and I am a team member who doesn't yet understand fermentation.
With no information yet, you first form a hypothesis, split it into verifiable questions, break it through investigation, and evaluate the delta. The moment a hypothesis breaks is the point of maximum learning, and the moment of verification is the exam itself.
You write before you learn — "I understand that bread rises because of baking powder. Baking a loaf without yeast will reveal whether that's true." The loaf comes out flat. At the moment this hypothesis breaks, the real principle — yeast fermentation — is burned in. Had you started with a web search, that knowledge would have slipped right past.
The team runs a hypothesis aimed at a problem in the world, and each individual nests their own learning hypothesis inside it. "While solving this team problem, I will deliberately learn X." Two layers, one cycle.
The team runs the hypothesis "people in our neighborhood want freshly baked healthy bread in the morning." Inside it, I nest my learning hypothesis: "while preparing this bakery, I will learn fermentation." The team opens the bakery, and I learn fermentation — two layers, one cycle.
The ultimate, real problem is hierarchically decomposed down to an attemptable size. Even the smallest challenge is connected by lineage to the real problem. Whether it is a toy or a stepping stone is decided not by its size but by the visibility of that connection.
Open a neighborhood bakery people love → develop a signature healthy bread → bake sourdough → grow a natural starter (leaf). Even the small one-week challenge of raising a starter in a glass jar, when you climb the tree, is connected by lineage to the real problem — the bakery. That is why it is a stepping stone, not a toy.
The criterion of success is not "was the problem solved" but "what changed relative to the hypothesis." The problem is real and the attempt is real, but what gets graded is the amount of change. That is why a drop in deliverable quality can be officially accepted.
Today's sourdough came out flat — a failure. But at the start of the cycle I didn't know what fermentation temperature changes, and now I can explain that "cold fermentation builds flavor, and over-fermentation collapses the dough." What gets graded is not the shape of the bread but this distance (Δ).
A framework driven by structure, not by one organizer's talent. Copy each step's template, fill it in as is, and your first cycle begins.
Declare, as the ultimate challenge, a problem that exists in the world and that the team genuinely wants to solve. It should be not impossible yet not easy, and it should touch the members' interests and feel relevant to them. The authenticity of this problem becomes the authenticity of the entire tree.
Our team sets out to solve [real-world problem P]. This is a problem [who] actually faces [in what situation]. When it is solved, we will know by [what has changed].
Unfold the sub-challenges that must be met before the ultimate challenge can be solved, and keep decomposing until you reach leaves small enough for an individual to attempt within one cycle. Post the tree in the team's shared space so the path from every leaf up to the ultimate challenge is always visible.
To solve [parent challenge], [sub-challenges A / B / C] must come first. Leaf test — is it small enough for one person to try breaking a hypothesis within 1–2 weeks? (No → decompose once more)
You don't invent a challenge from a blank page. Pick from the leaves of the tree, with a single rule — pick what you can't do right now. For a beginner, the leaf is a foundational skill; for an expert, it is an adjacent area (design, domain, market) that will amplify their expertise.
I pick [leaf L]. Right now I can't do this — evidence: [what happens when I try]. This leaf connects to the team challenge via the path [leaf → intermediate → ultimate].
Before searching, before watching a lecture, fill in the hypothesis template with no information at all — only your current understanding. The more awkward and wrong it is, the better. This hypothesis becomes the cognitive hook that every piece of information you meet afterward will catch on.
Right now I understand/expect [subject X] [like this]. Trying [verification action Y] will reveal whether this understanding holds. If this hypothesis breaks, I will learn [what I will come to know].
Not the author of the hypothesis but a teammate asks — "If this hypothesis breaks, what will you learn?" If you can't answer, refine the hypothesis and write it again. This ritual keeps verification running without a Loop Keeper, and the act of asking trains the asker's metacognition too. The Loop Keeper is not an intervener but an infrastructure manager who watches whether this structure runs well.
Question: "If this hypothesis breaks, what will you learn?"
Pass — the answer points to one concrete piece of understanding.
Reject — the verification action is vague / there is nothing to learn
/ it is something already known.
If rejected, refine the hypothesis and write it again.Not in separate study time — the very process of solving the team problem is the testing ground for your hypothesis. Record the moment a hypothesis breaks, right there on the spot — the bigger the gap between expectation and reality, the bigger the update to your understanding.
[Investigation log — every time a hypothesis breaks] Expected: [what I expected] Reality: [what actually happened] Learned from the gap: [updated understanding]
At the end of the cycle, each person takes out their starting hypothesis and measures the distance (the delta) between the understanding they had then and the understanding they have now. Record, too, how far that learning advanced the team challenge — learning and solving become one right here.
At the start, I understood [this]. Now I understand [this]. Delta (Δ): [what was updated] Contribution to solving: [how far this learning advanced the team challenge]
The understanding updated in the retrospective is the starting point of the next cycle. Pick the next leaf as something you know even less about, and the team layer turns on the same rhythm — the rejection of a team hypothesis is not a failure but grounds for a pivot. The loop never stops.
Next leaf: [something I know even less about than this time] Next hypothesis: [rewritten with my updated understanding] Team-layer update: [if a team hypothesis was rejected → pivot direction]
The Loop Keeper (facilitator) is neither someone who delivers knowledge nor someone who inspects challenges. They are an infrastructure manager who watches whether the structure runs well, and someone who throws in a single question at the right moment — the person who keeps the loop turning, hence the name. They give no answers — because finding the answer is the learner's cycle. The questions below are not the Loop Keeper's monopoly. Even without a keeper, as long as teammates ask them of each other, the framework keeps running.
Every sentence frame the cycle needs, gathered in one place. The form is the filter — if you can't fill in the blanks, you're not ready yet.
Right now I understand [subject X] as [this understanding/expectation]. Trying [verification action Y] will reveal whether this understanding holds. If this hypothesis breaks, I will learn [what I will come to know].
The last line is the answer to the peer-verification question. Write it in advance and you can answer "If it breaks, what will you learn?" on the spot; if you can't write it, the hypothesis isn't ready yet.
Paste into Notion or a doc and fill in this single sheet over one cycle. A condensed version of the 8 step templates below.
[Cycle sheet — name: · period: ~ ] Leaf: [something from the tree I can't do right now] Why I can't do it yet: [what happens when I try] Lineage: [leaf → intermediate → ultimate challenge] Hypothesis: Right now I understand/expect [subject X] [like this]. Verification action: [a Y I can try within 1–2 weeks] What breaking reveals: [one concrete piece of understanding] Peer check: pass / rejected — [peer's name · date] Investigation log (every break): - Expected: → Reality: → Learned: - Expected: → Reality: → Learned: Delta (Δ): [starting understanding] → [current understanding] Contribution to the solution: [how far the team challenge advanced] Next leaf: [something I know even less about than this time]
At kickoff, the whole team fills it in together, reads it aloud, and makes it official.
Our team sets out to solve [real-world problem P]. This is a problem [who] actually faces [in what situation]. When it is solved, we will know by [what has changed].
Ask the leaf-test question of every node; if the answer is no, split once more.
To solve [parent challenge], [sub-challenges A / B / C] must come first. Leaf test — is it small enough for one person to try breaking a hypothesis within 1–2 weeks? (No → decompose once more)
One rule — something you can't do right now. It isn't done until the evidence is written.
I pick [leaf L]. Right now I can't do this — evidence: [what happens when I try]. This leaf connects to the team challenge via the path [leaf → intermediate → ultimate].
Before searching, 15 minutes, from your current understanding only. The wronger, the better.
Right now I understand/expect [subject X] [like this]. Trying [verification action Y] will reveal whether this understanding holds. If this hypothesis breaks, I will learn [what I will come to know].
The asker asks questions only — no advice. Keep the round trip under 3 minutes.
Question: "If this hypothesis breaks, what will you learn?"
Pass — the answer points to one concrete piece of understanding.
Reject — the verification action is vague / there is nothing to learn
/ it is something already known.
If rejected, refine the hypothesis and write it again.On the spot where the hypothesis broke, within 5 minutes. It doesn't need to be well written.
[Investigation log — every time a hypothesis breaks] Expected: [what I expected] Reality: [what actually happened] Learned from the gap: [updated understanding]
The change, not the deliverable. Write it with your original starting hypothesis at hand.
At the start, I understood [this]. Now I understand [this]. Delta (Δ): [what was updated] Contribution to solving: [how far this learning advanced the team challenge]
The next leaf is something you know even less about. A rejected team hypothesis becomes the pivot direction.
Next leaf: [something I know even less about than this time] Next hypothesis: [rewritten with my updated understanding] Team-layer update: [if a team hypothesis was rejected → pivot direction]
Study groups compress the cycle to one week and run it on this agenda. 60–90 min.
[Weekly meeting agenda — 60–90 min] 1. Delta sharing (3 min each) Read your original hypothesis aloud, exactly as written, and speak only about the distance to your current understanding. No deliverable show-and-tell. 2. Bragging about breaks One moment that defied expectations each. If nobody's hypothesis broke → everyone levels up their leaf. 3. Write the next hypothesis (15 min, on the spot) Written before searching. 4. Peer check (in pairs) "If this hypothesis breaks, what will you learn?" Until it passes. Questions only, no answers.
Five samples across different team sizes, skill levels, and domains. The first case is a detailed walkthrough that follows all eight steps day by day — start there to see how the framework actually runs. (These samples are reconstructed from operating scenarios.)
Have a question that isn't answered here? Send it to leeo [at] kakao.com — good questions get added to this list.
All you need is one real problem, one tree, and one hypothesis that is ready to be wrong.
Want to try it, or have a question? — leeo [at] kakao.com