I built two tools for IB Digital Society exam practice. AI helped me make them. AI does not run them.
The deployed application is a regular browser-based tool. It does not send a student's response to an AI model, generate a mark, or produce live AI feedback. AI supported my planning, coding, debugging, visual design, and iteration. It helped with the making, not the running.
The interesting part is what students still have to do themselves.
They have to retrieve what they know. They have to explain it. They have to compare their work with criteria. Then they have to decide what needs revision.
That distinction shaped both tools: the technology can organize the practice, but it should not quietly take over the thinking or pretend to be an examiner.
Put more simply: AI should help students TRACE their thinking, not erase it.
It also saved me from building a very polished answer machine, which would have been impressive for approximately seven minutes.
I should also be clear about where I am coming from. I am a computer science teacher. I know enough about coding to inspect what an agent produces, follow the logic, spot when something smells wrong, and occasionally create an entirely new smell of my own.
I did not arrive at these tools as a non-technical observer asking AI to “make me an app.” I built them while the way we work with AI was changing underneath us.
What AI helped me do
Plan features, write and review code, debug problems, refine copy, and iterate on the design.
What the live tool does
Shows the task, response, rubric, movable annotations, and checklist so students can inspect their own work.
Prompting stopped being a magic sentence
The early version of prompting often felt like trying to discover the perfect combination of words. Add a role. Add five adjectives. Tell the model to breathe deeply. Hope it becomes a different machine.
That is not how I think about prompting now.
Structured frameworks such as CRAFT—Context, Role, Audience, Format, and Tone—are useful starting points. But once an agent can inspect files, use tools, run checks, and produce an artifact, a clever prompt is not enough. It needs a bounded job. (Joshi et al., 2026)
My prompts now look more like compact design briefs: define the outcome, provide the relevant evidence, identify what may change, state what must remain untouched, define the checks, and tell the agent when to stop. That approach also matches current guidance to make constraints and completion criteria explicit. (OpenAI, Prompting guidance)
The TRACE framework I now use
I needed a way to connect how I build with AI to how I want students to learn with it. I am calling that working framework TRACE.
For an AI job, TRACE means:
- Task: define the observable outcome.
- Relevant context: supply the sources, constraints, examples, and voice that actually matter.
- Actions and aids: specify the plan, tools, skills, files, and permitted changes.
- Checks: define the evidence, tests, rubric, or success criteria.
- Exit and escalation: say when the agent must stop and when a human decides.
The build prompt I now trust looks more like this:
Task: Add an evidence checklist to the practice tool.
Relevant context: Use the existing response view, rubric language,
and the approved student workflow.
Actions and aids: Preserve the student's text. Add a visible checklist
that the student controls. Do not generate a mark or rewrite the answer.
Checks: The student can compare the response with each criterion,
save the check state, and reopen it without losing work.
Exit: Stop after the feature and tests pass. Do not publish.
That is not prompt theatre. It is instructional design written in a form an agent can follow.
When a prompt becomes a skill
If I keep reusing the same prompt—or correcting the same mistake—I should not rebuild the workflow from memory. I can preserve it as a readable skill: instructions, references, and checks that travel with the project. (OpenAI, Build skills)
I also used the open-source skills command to install Matt Pocock's engineering workflows:
npx skills@latest add mattpocock/skills
That community command comes from the Matt Pocock skills repository and the open-source skills CLI. Inspect what a skill instructs the agent to do and install only workflows you trust.
There is still a safe place for everyone to land. A teacher can begin with plain language: the goal, context, output, and boundary. Coding knowledge gives me more ways to inspect the machinery; it is not the admission ticket for having a useful idea.
The classroom problem I was trying to solve
Exam practice can produce a lot of activity without making the important decisions visible.
A student writes a response. A teacher annotates it. Feedback arrives. Everyone moves on. Somewhere in that sequence, the student is supposed to work out what the response did well, what the criteria required, and what to change next time.
Those connections are not automatic.
For IB Digital Society teachers, the challenge is therefore larger than generating more practice questions. Students need a practical way to rehearse the whole response process without being encouraged to treat AI output as authoritative assessment.
My design question became:
Can a browser-based practice tool keep the student’s retrieval, explanation, self-assessment, and revision decisions at the centre of exam practice?
That question produced two related tools: the IB DigSoc Exam Practice Studio and the DigSoc Response Studio.
They approach the same problem from different directions.
Tool one: IB DigSoc Exam Practice Studio
The IB DigSoc Exam Practice Studio places an attempted response alongside visible rubric criteria and annotation.
That visible arrangement matters to the design. The student is not simply handed a verdict. The response, the criteria, and the annotations can be examined together.
The intended sequence is straightforward:
- Attempt the response.
- Examine the criteria.
- Look at how the response has been annotated.
- Identify what appears to be present, missing, or unclear.
- Decide what to revise.
The tool supports comparison, but comparison is not the same as surrendering judgment. Students drag annotation stamps onto the response, then use the visible checklist to decide whether the evidence is actually there. The tool does not establish an official IB mark, replace subject expertise, or settle every reasonable interpretation of the criteria.
That is where the teacher remains essential.
A teacher can question an annotation, clarify the meaning of a criterion, notice disciplinary nuance, and help a student distinguish between adding more words and improving an explanation. The interface can make material easier to inspect. It cannot make those professional judgments disappear.
Tool two: DigSoc Response Studio
The DigSoc Response Studio makes more of the practice sequence explicit.
It moves through:
- understanding;
- brainstorming;
- writing;
- annotation;
- self-assessment; and
- a feedback prompt.
Its distinct public URL has not yet been verified, so I am not linking to it here.
What I like about this sequence is that it does not begin with AI producing a finished response. It begins with the student working out what the task means and what they might say.
Writing still has to happen.
The later stages then create opportunities to inspect that writing. Annotation draws attention to features of the response. Self-assessment asks the student to compare. A structured feedback prompt supports the next decision.
Again, the intended endpoint is not “the computer has spoken.” It is a more useful question:
What will I change, and why?
That is a modest goal. It is also much closer to the work I want students doing.
VISIBLE APPLICATION EVIDENCE
What the student actually sees
These are real application states—not concept mockups. The tools keep the response, criteria, annotations, and next decision visible.
The two tools form one practice loop
I do not see these as two unrelated web experiments.
Together, they form the student side of TRACE:
- Try first: produce a response from memory and understanding.
- Reveal reasoning: make the thinking behind the response visible.
- Annotate: identify the argument, evidence, explanation, and gaps.
- Check: compare the visible response with the assessment criteria.
- Evolve: revise while the student retains authorship.
Underneath the acronym, the learning loop remains straightforward: retrieve → explain → compare → decide → revise.
The Response Studio slows down the construction and review of a response. The Exam Practice Studio makes criteria and annotation visible around an attempted response. In both cases, the tool is there to support attention and decision-making.
My interpretation is this:
These two IB tools are most useful when the interface makes the cognitive work—retrieving, explaining, comparing against criteria, and deciding what to revise—easier to see without replacing it.
This is a design and classroom-use interpretation. It is not a measured claim that the tools improve learning outcomes, and it should not be read as one.
That limitation is important. I can explain what the tools make visible and what I designed them to encourage. I cannot turn those observations into proof of impact without appropriate evidence.
Why I designed the practice loop this way
The research below supports the design principles—not a claim that my tools have already improved IB results. I kept coming back to three ideas.
1. Assisted performance is not the same as learning
OECD guidance distinguishes completing a task with generative AI from learning to complete it independently. A 2025 field experiment with nearly 1,000 high-school mathematics students found the same tension in practice: unrestricted AI improved work during practice but reduced later performance when the AI was removed, while a more carefully safeguarded tutor reduced that harm. Different subject, different tools, but a useful warning: the interface must preserve cognitive effort. (OECD, 2026; Bastani et al., 2025)
2. Retrieval should come before assistance
Roediger and Karpicke found that prior testing supported better delayed retention than restudying, and a later review of 50 classroom experiments found substantial benefits in many settings—with important limits and variation. Neither study tested my applications. They support the narrower choice to ask students to attempt, retrieve, and commit before receiving help. (Roediger & Karpicke, 2006; Agarwal, Nunes & Blunt, 2021)
3. Feedback should support a decision
Large reviews show that feedback is not one consistently effective treatment. Its value depends on the information it carries. Specific, task-focused feedback that helps explain what, how, or why is more useful than instant verdicts. That is why these interfaces put the response, annotation, checklist, and criteria together: the learner still has to decide what the evidence shows and what to revise. (Wisniewski, Zierer & Hattie, 2020; Shute, 2008)
Research notes and additional sources
These sources added useful nuance while I was designing and writing:
- UNESCO (2023) cautions against uses that remove opportunities for independent reasoning and discussion.
- Kestin et al. (2025) found positive immediate results from a carefully scaffolded, course-grounded AI tutor, while warning against broad transfer claims.
- Fütterer et al. (2026) found that adding reflective prompts did not automatically produce robust gains in strategy use or domain knowledge.
- Bisra et al. (2018) found an overall positive effect for prompted self-explanation, with meaningful variation across contexts.
- Panadero et al. (2026) found positive but varied effects from self- and peer-assessment. A checklist can structure reflection; it does not become an official IB mark.
What the finished tools actually do
The deployed applications do not call an AI model. They do not upload a student response, generate a mark, or issue live AI feedback. AI helped me plan, code, debug, and improve them; the finished tools run as ordinary browser applications.
What they do is simpler and more deliberate: keep the task, attempted response, annotation stamps, rubric language, and checklist visible together. Students retrieve, explain, compare, question, and revise. The interface organizes the practice; it does not do the practice for them.
How I would use them with students
I would ask students to attempt the response first, drag the annotation stamps onto the phrases that show their thinking, and then use the checklist to decide whether the evidence is actually visible. A useful discussion can stay focused on three questions:
- What does the response actually say?
- How does that compare with the visible criterion?
- What revision would make the reasoning clearer?
The tool holds the evidence in view. The student and teacher make the judgment.
The honest limits
I am not claiming measured learning gains. The research gives me reasons to design around retrieval, explanation, useful feedback, and self-assessment; proving that these particular applications improve learning would require direct evaluation with real students and suitable safeguards.
The DigSoc Response Studio also still needs a verified distinct public URL, so I am showing its interface here without offering a broken link. Both tools are practice aids, not official IB assessment systems.
A tool should leave something for the learner to do
That may be the simplest test I have found for educational technology: after the tool has helped, what meaningful work still belongs to the student?
The goal is not to prove that AI can produce an answer-shaped object with tremendous confidence. The goal is to use AI to help build better places for students to retrieve, explain, compare, question, and revise.
That is the point of TRACE. It is not a proven intervention, and the acronym has not secretly done the research. It is my practical reminder that the technology needs a bounded job and the learner needs meaningful work left to do.
If you try it, tell me where the workflow supports a genuine revision decision—and where it gets in the way.