Math With Purpose - Learning to think through mathematics

Inspiration

Most mathematics applications begin with a familiar instruction:

Solve for (x).

But children are rarely shown why (x) exists, what it represents or how changing it affects the rest of a system.

We wanted to change the question.

Instead of asking only:

What is the answer?

Math With Purpose asks:

What changed, what caused it, and what relationship did you discover?

The project is based on a simple educational idea: mathematics is the language of relationships. Numbers and equations become meaningful when learners can connect them to visible changes in a world they can explore.

Our goal was not to build another calculator, worksheet or answer-generating chatbot. We wanted to create an interactive thinking laboratory where children learn through experimentation, prediction and reflection.

We don’t solve for X. We understand why X exists.

What it does

Math With Purpose is an interactive Relationship Lab built around one carefully developed world: a delivery robot carrying packages.

The learner changes the number of packages from 0 to 10. The entire system responds immediately:

packages appear on the robot;
energy consumption changes;
trip time changes;
delivery cost changes;
the relationship map reacts;
the graph moves;
the equation updates.

The prepared mathematical relationships are:

$$ E = 4 + 2p $$

$$ T = 3 + p $$

$$ C = 5 + 1.5p $$

where (p) is the number of packages.

The fixed values also have visible meaning. Even with zero packages, the robot must power on, prepare its route and start the delivery service. This helps learners understand that an intercept is not simply an arbitrary number inside a formula.

Four views of one relationship

The lab presents the same system through four synchronized representations:

Robot World — visible packages, energy, time and cost.
Relationship Map — connections between the input and each output.
Graph View — how a relationship changes across 0–10 packages.
Math Lens — the symbolic equation and its substituted values.

The equation is deliberately not the first representation. Learners experience the relationship before encountering its formal notation.

For four packages, the learner can connect:

$$ E = 4 + 2p $$

with:

$$ E = 4 + 2 \times 4 = 12 $$

The 4 represents the robot’s starting energy, 2 represents the additional energy for each package, and (p) represents the package control the learner has already manipulated.

Learning missions

The prototype includes three missions using the same mathematical world.

Flow

The learner explores:

What changes when the number of packages changes?

The application compares the previous and current states and shows how each output responded.

Cause & Effect

The learner investigates:

Which change caused the energy increase?

Instead of displaying a punitive red “wrong” state, the system points to experimental evidence and asks the smallest useful next question.

Prediction

The learner predicts the energy, time or cost for eight packages before the result is revealed.

The prediction is preserved and then compared with the experiment. A difference is treated as an opportunity to investigate—not as failure.

Reasoning Review Engine

Math With Purpose includes a deterministic local Reasoning Review Engine inspired by the architecture of our AI Review Engine.

It does not only check whether a selected result matches an expected answer. It responds with:

what the learner noticed;
evidence from the experiment;
the relationship to inspect;
the smallest next question;
a suggested experiment.

For example:

You noticed that energy increased when packages were added. Compare two packages with three packages. How much energy was added? Does the same change happen again?

The engine does not assess intelligence, diagnose learning difficulties or create learner profiles. Its output is a learning prompt, not a judgement of ability.

How we built it

We built the prototype as a standalone React and TypeScript application.

The deterministic calculation and reasoning engines are separated from the interface, making the mathematical behavior inspectable and testable. The application uses no accounts, database, API keys, external model calls or cloud persistence.

The experience includes:

synchronized mathematical representations;
accessible package controls;
three mission workflows;
prediction-before-reveal logic;
an in-memory experiment notebook;
comparison of recorded states;
keyboard navigation;
screen-reader announcements;
graph and relationship-map text alternatives;
reduced-motion support;
responsive layouts for desktop and mobile.

The complete implementation was verified with 22 automated tests, linting, a production build and browser checks at multiple viewport sizes.

How we used GPT-5.6

GPT-5.6 helped us turn a broad educational philosophy into a focused and demonstrable product.

We used it to:

redefine mathematics as relationship exploration rather than answer production;
select one deeply developed world instead of many shallow exercises;
design the synchronized visual, graphical and symbolic representations;
structure the Flow, Cause & Effect and Prediction missions;
design Socratic reasoning prompts;
establish age-appropriate language and educational boundaries;
make key product, learning and interface decisions.

GPT-5.6 was used during product development. The submitted prototype does not make runtime model calls.

How we used Codex

Codex accelerated the complete engineering workflow.

We used Codex to:

scaffold and implement the standalone application;
separate the deterministic TypeScript engine from React components;
implement the synchronized Robot World, Relationship Map, Graph View and Math Lens;
implement mission switching and prediction-before-reveal behavior;
build the Reasoning Review Engine;
add the experiment notebook and state comparison;
create and expand automated tests;
improve keyboard access, screen-reader support and reduced-motion behavior;
verify responsiveness at desktop and mobile sizes;
run linting, all tests and the production build;
document key engineering and product decisions;
clearly distinguish previous KidsPiggy work from the new Build Week contribution.

Final educational, product, architecture and safety decisions remained human-led.

Build Week contribution

Before Build Week, the broader KidsPiggy platform already included:

educational experiences;
collecting notes and transforming them into study materials;
transforming children’s doodles into developed illustrations;
a wider philosophy of learning through creativity;
earlier research into reviewing reasoning and AI-generated outputs.

During Build Week, we created:

Math With Purpose as a new standalone module;
the Robot Delivery Relationship Lab;
four synchronized representations of one mathematical system;
Flow, Cause & Effect and Prediction missions;
prediction-before-reveal interaction;
the deterministic Reasoning Review Engine;
Socratic next-step prompts;
an experiment notebook and state comparison;
an accessible responsive interface;
a tested standalone repository and demonstration.

This separation is documented in the project README and Build Week changelog.

Challenges we faced

Showing one system instead of four widgets

The Robot World, relationship map, graph and equation could easily have felt like unrelated interface panels. We had to ensure that one learner action visibly affected every representation and that colours, labels and values remained consistent.

Making equations meaningful

A symbolic expression such as (E = 4 + 2p) can be technically correct but educationally empty. We connected every part of the equation to the visible world: the powered-on robot, each additional package and the live energy result.

Supporting different ages

The interface needed to remain understandable to a young learner without appearing childish to a teenager. We used large controls, objects and icons for immediate understanding, with graphs, equations and experiment comparisons available as deeper layers.

Reviewing reasoning without judging the learner

Binary feedback is simple to implement but often teaches learners to chase approval instead of investigating relationships. We designed the review engine to reflect observations, cite experimental evidence and ask a productive next question.

Preserving prediction

It was essential that the system did not reveal the result before the learner committed to a prediction. The interface and tests explicitly protect the prediction-before-reveal sequence.

What we learned

We learned that the same mathematical idea can become much easier to understand when represented as a world, a connection, a graph and an equation at the same time.

We also learned that educational feedback does not need to begin with “correct” or “incorrect.” A carefully chosen question can reveal more about reasoning than a verdict.

Most importantly, we learned that visual design is part of the teaching system. When one colour, object and connection consistently represent the same variable, the interface itself helps explain the mathematics.