CounterWorlds

CounterWorlds turns a class's misconceptions into playable experiments—so students discover which laws survive contact with evidence.

Comment

Inspiration

I entered the Education track wanting to build something that felt genuinely different.

I did not want to make another AI tutor that simply gives students the correct answer. I also did not want to build another dashboard that reduces a learner's thinking to “right” or “wrong.” I wanted something more experimental and out of the box, but for a while, I could not find an idea that lived up to that ambition.

That changed when I tested GPT-5.6 Sol as a thinking partner. What impressed me most was not a flashy response, but how thoughtfully it planned. It helped turn my vague ambition into one question:

What if a student's misconception could become a playable universe, and evidence, rather than authority, decided which world held up?

That question became CounterWorlds.

The project is built around a simple belief: a wrong answer is not always random. Students often have coherent mental models that happen to be incorrect. Instead of immediately correcting those models, CounterWorlds lets students test them.

What it does

CounterWorlds turns a class's real misconceptions into interactive, competing worlds.

A teacher creates a STEM question, learning objective, and canonical model. Students join anonymously and explain what they currently believe. CounterWorlds then identifies the dominant misconception and compiles two synchronized universes:

  • World A follows the students' misconception.
  • World B follows the accepted scientific or mathematical model.

Students make a prediction before the answer is revealed. They manipulate identical controls in both worlds, observe the results, record evidence, and revise their original explanation.

For example, if students believe that a heavier object accelerates faster under the same force, CounterWorlds does not immediately tell them they are wrong. It creates one world where that belief is true and another governed by:

[ a = \frac{F}{m} ]

Students can then compare both worlds and decide which one matches the evidence.

The teacher sees more than a final answer. They can observe the complete learning sequence:

[ \text{Initial explanation} \rightarrow \text{Prediction} \rightarrow \text{Experiment} \rightarrow \text{Evidence} \rightarrow \text{Revised explanation} ]

How we built it

CounterWorlds is built with Next.js, TypeScript, React, Supabase, Better Auth, Vercel Workflows, Vertex AI, GPT-5.6 Sol, and the OpenAI Codex SDK.

The platform has two connected experiences:

  1. A teacher workspace for creating classrooms, reviewing anonymous explanations, generating CounterWorlds, and inspecting belief revision.
  2. An anonymous student experience for predicting, experimenting, recording evidence, and revising an explanation.

Supabase provides persistent classroom data, realtime updates, and private storage for generated worlds. Better Auth and Google OAuth give teachers persistent ownership of their classrooms, while students participate without creating accounts or sharing email addresses.

The generation system converts real student explanations into a structured WorldManifest. This contract describes the misconception clusters, laws of each world, synchronized controls, expected evidence, reveal, and reflection prompts.

GPT-5.6 Sol can generate both the structured manifest and a self-contained interactive experiment. The output is validated before publication. Generated worlds cannot use external assets, network requests, browser storage, popups, navigation, dynamic code evaluation, or parent-frame access. Each experiment runs inside a sandboxed iframe with a restrictive Content Security Policy.

Codex played a major role in the development process. After GPT-5.6 Sol helped shape the original product thesis, Codex helped produce roughly 80% of the initial implementation pass in one focused session. That included routes, data contracts, UI states, persistence, validation, and tests.

I treated that output as a first draft rather than a finished product. I made the educational decisions, defined the school-pilot and privacy boundaries, reviewed the generated implementation, refined the visual direction, debugged deployment issues, and made sure the final experience used real classroom records instead of fabricated demo data.

About MCP

I have not presented MCP as a shipped CounterWorlds feature because the current project does not yet include a verifiable Model Context Protocol server or client integration. MCP is part of the future direction: it could allow CounterWorlds to securely connect approved educational resources, simulation libraries, curriculum repositories, and school systems through clearly scoped capabilities.

I would rather describe that honestly as planned work than claim an integration that judges cannot verify in the repository.

Challenges we ran into

The hardest challenge was not generating an explanation. It was safely turning untrusted student text into executable educational content.

Student responses may contain prompt injection attempts, personal information, irrelevant text, or incomplete reasoning. Generated HTML introduces another security boundary. A useful experiment still needs interactivity, but it must not receive unrestricted access to the network, browser storage, navigation, or the surrounding application.

We addressed this with structured output contracts, input boundaries, generated-HTML validation, presentation sanitization, CSP injection, and sandboxed rendering.

Another challenge was maintaining neutrality before the reveal. The interface could not visually suggest that one world was “correct” before students had made a prediction and inspected the evidence.

Authentication and deployment also required significant debugging. We encountered issues involving Supabase pooler TLS behavior and an authentication cookie-prefix redirect loop. Solving those problems required working from runtime evidence rather than assuming local behavior would match production.

Finally, we deliberately avoided fake classrooms, sample students, fabricated analytics, and canned fallback worlds. That makes the first demo slightly less immediate, but it means every success state shown by the product represents a real persisted interaction.

Accomplishments that we're proud of

I am proud that CounterWorlds became more than a concept or a chatbot wrapper.

It now includes:

  • A complete teacher and anonymous-student classroom flow.
  • Realtime collection of student explanations.
  • Structured misconception clustering.
  • Two synchronized, interactive worlds.
  • Prediction, evidence, reveal, and belief-revision records.
  • Durable AI generation workflows.
  • Schema-constrained model output.
  • Sandboxed and CSP-restricted generated experiments.
  • Encrypted teacher-provided OpenAI keys.
  • Privacy-conscious anonymous student participation.
  • Automated tests covering generation contracts, sandbox boundaries, identity, encryption, and school-pilot behavior.
  • A working deployment using real persistence rather than mock success states.

The accomplishment I value most is the central interaction itself: CounterWorlds does not ask students to trust the AI. It asks them to test a model and follow the evidence.

What we learned

I learned that productive AI collaboration still requires strong human ownership.

GPT-5.6 Sol was excellent at turning an unclear ambition into a coherent plan. Codex dramatically accelerated implementation. But neither removed the need to decide what the product should teach, what data it should collect, what generated code should be allowed to do, or what was safe enough for a classroom.

I also learned that educational AI becomes more interesting when it stops behaving like an answer machine. A model can do more than explain established knowledge. Under the right constraints, it can help construct an environment where learners discover why one explanation survives testing and another does not.

On the engineering side, I learned that generated interactive content must be treated as untrusted code. Structured generation alone is not enough. It needs validation, sanitization, isolation, explicit failure states, and tests around every boundary.

Most importantly, I learned that a misconception can be valuable. It reveals the model a student is using. Once that model becomes visible and testable, correction can become discovery.

What's next for CounterWorlds

The next step is to pilot CounterWorlds with real teachers and measure whether the experience improves conceptual revision compared with conventional explanations.

Planned directions include:

  • Expanding beyond the initial STEM use cases.
  • Giving teachers more control over generated laws, variables, and evidence.
  • Building reusable experiment templates for common misconceptions.
  • Improving accessibility and support for different devices.
  • Adding teacher-approved curriculum and simulation libraries.
  • Developing a verifiable MCP integration for approved educational resources and school systems.
  • Measuring learning outcomes across the full explanation-to-revision sequence.
  • Supporting collaborative experiments where groups defend and test competing models.
  • Building clearer review and approval controls before a generated world is released to students.

The long-term vision is not to replace teachers or make AI the authority in the classroom. It is to give teachers a new kind of learning environment, one where students can step inside an idea, test it, and change their own minds.

Built With

Share this project:

Updates