The deadline in the print shop is tomorrow morning.
Five people are dead on King Street. Two witnesses disagree about what happened. Paul Revere's engraving offers a vivid version of the event, but it is not a photograph. You are the printer's apprentice, and Boston will read whatever headline you set in type.
The tempting headline makes the accusation simple. The evidence does not.
Choose the overconfident version in *The King Street Proof* and the game pushes back. It sends you to the source, asks what the engraving can actually establish, and makes you reconsider what you are willing to print.
That moment is the reason I built Counterpoint. It is also where I drew the boundary around its use of AI.
The model can help author the mission before class. It does not improvise with the student during class. A teacher sees the proposed experience, changes it if needed, and decides whether it is allowed to ship. The student then plays the accepted version as a fixed game.
That distinction sounds small. I think it changes the right question from "Should students talk to an AI?" to "What has to happen between generated material and something a teacher can responsibly put in front of a class?"
An AI tutor was the wrong frame
The obvious version of this project was an AI tutor: paste a passage, open a chat, and let the model guide each student through it.
I chose a different frame. Reasoning often depends on committing to a choice, seeing its consequence, and revisiting the evidence. A live chatbot is not required for that. In some classrooms, its variability is a liability rather than a feature.
This is not an argument that all student-facing AI is wrong. It is a narrower design claim: if a lesson can achieve its purpose with a teacher-approved, deterministic activity, there should be a serious reason before adding a live model to the student experience.
The broader evidence base points in the same direction. The OECD Digital Education Outlook 2026 argues that generative AI can support learning when it is guided by clear teaching principles, while improved task performance by itself does not prove learning. UNESCO's guidance for generative AI in education similarly emphasizes human-centred, age-appropriate ethical validation and pedagogical design.
Those are larger policy principles. Counterpoint is one small prototype of what they can look like in a product architecture.
The five-stage contract
Counterpoint treats generation as the beginning of an authoring workflow, not the end.
1. Start with a bounded source
The teacher supplies the lesson passage. That passage establishes the factual boundary for the generated mission.
This matters because "make a game about the Boston Massacre" and "make a game from this passage" are different requests. The second gives the authoring system something concrete to stay inside and gives the reviewer something concrete to check against.
2. Compile a structured blueprint
The authoring agent does not return a polished blob of lesson prose. It returns a strict mission blueprint: characters, evidence, choices, consequences, endings, and the links between them.
Structure makes the draft inspectable. A teacher can see the choice graph rather than trusting a fluent description of what the game is supposed to do.
3. Run deterministic validators
The blueprint must pass a battery of checks. Are all required fields present? Can the player reach an ending? Do choices point to real nodes? Are evidence and consequences wired into the graph? Does the mission remain inside its encoded reading-level and structural constraints?
If the blueprint fails, the errors are returned for one bounded repair attempt. If it still fails, the system returns the validation problems instead of quietly substituting a different mission.
4. Give the teacher an explicit gate
A valid blueprint is not automatically a good lesson.
The teacher can inspect the graph, revise the mission in plain language, review the new result, and choose whether to apply it. The same validation process runs again after revision.
The important interface is not the Generate button. It is the Apply gate.
5. Freeze the student runtime
Once a blueprint is accepted, student play is deterministic. The model is no longer in the loop. Dialogue, scoring, consequences, persistence, and the source-check response come from the accepted graph and make no model calls.
Every student can still make different choices. What remains fixed is the designed possibility space and the feedback attached to it.
In shorthand:
Agents author. Validators check. Teachers gate. Students think.
What a validator can prove
Validation is useful precisely because its claim is limited.
A structural validator can prove that required fields exist, references resolve, an ending is reachable, a choice has a consequence, or a configured reading constraint is satisfied. It can reject a graph that cannot be played as designed.
It cannot prove that a historical interpretation is correct. It cannot decide whether a fictional witness is pedagogically appropriate for a particular class. It cannot guarantee freedom from bias, establish classroom safety, or demonstrate that students learned.
Those decisions require sources, subject expertise, teacher judgment, and eventually real classroom evidence.
The honest promise is not "the validator makes AI trustworthy." It is "the validator makes certain failures visible before the teacher decides."
A six-question review for classroom AI
You do not need Counterpoint to use this checklist. Before putting any AI-generated activity in front of students, ask:
is allowed to draw from, or is it quietly importing facts and assumptions from elsewhere?
required path, and do the choices lead somewhere coherent?
sentence complexity, instructions, and accommodations for this class?
supported claim, or merely a confident answer?
artifact, revision history, and explicit approval step?
model introduce new claims, feedback, or behavior after approval?
- What are the source boundaries? Can I identify the material the activity
- Is the experience reachable? Can a student actually complete every
- Is the reading demand appropriate? Has someone checked vocabulary,
- Does the student have to use evidence? Is the activity rewarding a
- Can the teacher inspect and change it? Is there a legible intermediate
- What changes during student use? Is the runtime fixed, or can a live
The answers do not all have to be the same for every lesson. They do need to be visible enough for an educator to make a real decision.
What Counterpoint has not proved
Counterpoint is a submitted OpenAI Build Week prototype, not a completed classroom study.
Its documented playtest personas are deterministic simulations, not real students. Missions currently use one scene. Generated subjects are mapped into three launch art kits, which limits the visual vocabulary. A classroom pilot and real-student evaluation are still pending.
I am not claiming that the prototype improves learning outcomes. The current evidence supports a smaller claim: the architecture can turn a passage into a structured mission, expose encoded failures before application, preserve a teacher approval step, and run the accepted experience without a live model.
That is enough to make the next experiment worth discussing. It is not enough to skip the experiment.
Try the boundary, not just the pitch
You can play The King Street Proof without an account or API key. Try the unsupported headline. Inspect the evidence. See whether the correction makes you reconsider the claim rather than simply revealing the answer.
The Counterpoint repository includes the blueprint contract, validators, deterministic runtime, historical guardrails, and the limitations I have described here.
If you teach, design curriculum, or build education software, I would especially like to know which of the six review questions you would inspect first, and which one is missing.
