How GlassBox stays honest
GlassBox's whole premise is that you can trust what you see. So it draws a hard line between what the machine produced and what a human claimed — in the data, in the build, and on every lesson.
What the tracer proves
Each lesson is a real Python program. At build time it runs under CPython's own sys.settrace, and the variable state shown at every line is exactly what the interpreter held at that moment. It is not a mock-up, an animation, or a teacher's recollection — it is execution output. Every displayed execution claim is derived from CPython; where a value had to be coerced to fit JSON, or a process is only a model of the real world, that is marked explicitly rather than hidden. Traces produced this way are marked:
execution-derived · CPython
What it does not prove
The metaphors (two cups), the problem statements, and the step notes are human pedagogy laid on top of the trace. A note like “the spare cup saved the day” is a claim about meaning, not a fact the interpreter produced. The player always shows notes in a distinct register so prose can never masquerade as execution output. And running a program perfectly proves nothing about whether the program faithfully models the world — so a lesson that simulates a real process (a packet routing across a toy network) carries a second mark:
model: author-asserted
Two honest questions, kept separate
Every lesson answers two questions, and we never let one borrow the other's authority:
- Did CPython really produce this state? — derivation. A real
sys.settracerun is execution-derived. - Does the program faithfully model its real-world subject? — domain model. A swap simply is a swap (execution-derived); a routing sim is a real run of a hand-built model, so its model is author-assertedeven though its trace is execution-derived.
Most lessons are execution-derived on both axes. The network lessons are execution-derived traces of author-asserted models — the animation is real; the claim that it mirrors the internet is ours.
The build enforces it
Lessons live in one place; traces are generated by the tracer into another and are the only thing the player reads — the two are never mixed at authoring time. Before anything ships, the build gate validates every trace against a single schema and fails loud if a trace's claim of being execution-derived doesn't match how it was produced. A second gate keeps the material provider-agnostic. Nothing ships unvalidated.
GlassBox is AI-authored under an owner-designed verification system: the verification system — not a human checking every line — is the safeguard, and the build fails when a claim doesn't hold.