Generative Lab OS

Turn bounded computational learning goals into verified, interactive experiments—generated in one GPT-5.6 request, validated by trusted host code, and exportable as notebooks.

Comment

Inspiration

Most AI learning tools explain a concept and then stop. The learner receives an answer, but rarely gets a chance to test the idea, change a variable, observe a failure, or build an evidence-based understanding.

I wanted to create something closer to a small scientific laboratory.

Instead of asking an AI tutor to explain attention, recurrent memory, optimization, or convolution, the learner should be able to make a prediction, manipulate a bounded system, run an experiment, compare conditions, and explain what happened.

That idea became Generative Lab OS:

Turn a bounded computational learning goal into a verified, executable micro-course.

The central principle is simple:

Do not merely explain knowledge. Create a situation in which the learner can experience its cause-and-effect behavior.

What it does

A learner provides:

  • a one-sentence computational learning goal;
  • a learner level;
  • a time budget;
  • an experience preference.

The live compiler then makes exactly one GPT-5.6 Structured Outputs request.

GPT-5.6 proposes a complete micro-course containing:

  • a short orientation;
  • a worked example;
  • a prediction prompt;
  • bounded controls;
  • a restricted pure-Python experiment;
  • declared observations;
  • visualizations;
  • measurable checks;
  • a contrasting condition;
  • a transfer task;
  • a debrief;
  • a downloadable notebook.

The generated course is not launched immediately. Trusted host code first validates and normalizes the response, checks every control and observation reference, statically analyzes the generated Python, executes reference and contrast cases, and verifies the declared outputs and checks.

The live compiler uses:

  • one GPT-5.6 request;
  • zero retries;
  • zero repair calls;
  • zero fallback labs.

If the generated result fails bounded validation, the system rejects it instead of silently substituting a canned experience.

A successful lab follows an active learning sequence:

orientation
→ prediction
→ guided experiment
→ measured evidence
→ explanation
→ contrast
→ transfer
→ debrief

In the video demo, the system generates a lab comparing GPT-style causal attention with BERT-style bidirectional attention. The learner changes the query position and future-score boost, runs both mechanisms, and observes their attention distributions and future-attention mass.

How we built it

Generative Lab OS is built with:

  • Next.js and React;
  • TypeScript;
  • Zod;
  • the OpenAI Responses API;
  • GPT-5.6 Structured Outputs;
  • Python 3.11;
  • KaTeX;
  • SQLite;
  • Vitest;
  • Playwright;
  • Docker;
  • Railway.

The production pipeline is:

Learning goal
→ one GPT-5.6 structured response
→ trusted normalization
→ static Python preflight
→ reference and contrast execution
→ host validation
→ interactive micro-course
→ downloadable notebook

The learner-facing renderer is generic. It operates on reusable educational primitives such as:

  • explanation;
  • formula;
  • parameter;
  • execution;
  • observation;
  • visualization;
  • check;
  • comparison;
  • reflection;
  • transfer.

There are no production renderers hard-coded specifically for Attention, RNNs, JEPA, convolution, optimization, or red-black trees. These subjects use the same LabSpec, stage engine, restricted runner, evidence model, renderer, and notebook exporter.

Generated Python runs through a bounded capability system with:

  • restricted builtins;
  • approved runtime namespaces;
  • protected names;
  • type-aware container-method allowlists;
  • literal control bindings;
  • declared output contracts;
  • undefined-name and attribute checks;
  • source, execution-time, stdout, and output-size limits;
  • isolated Python mode;
  • no shell;
  • no network;
  • no arbitrary imports;
  • no eval, exec, subprocesses, or file access.

Every accepted lab can export a standard Jupyter notebook containing the lesson, editable controls, reusable experiment function, primary run, contrasting run, comparisons, transfer task, and reproducibility metadata.

Codex helped implement and test the typed contracts, generic LabSpec, restricted Python capability system, validation pipeline, learner interface, notebook exporter, automated tests, Docker packaging, and Railway deployment.

I retained the core product and engineering decisions: one model request, no repair loop, no fallback lab, generic educational primitives, model generation separated from host authorization, and independent execution before launch.

Challenges we ran into

Keeping every runtime contract consistent

The compiler prompt, TypeScript validator, Python runner, notebook exporter, and developer evidence all had to agree on exactly which Python capabilities were available.

A real Railway compile exposed a mismatch where math.tanh passed attribute validation, but the math namespace itself was not recognized as a predefined runtime capability. The fix was not to loosen execution broadly. Instead, approved namespaces were derived from the same canonical capability manifest while reassignment and shadowing remained prohibited.

Supporting generated programs without allowing arbitrary execution

The generated experiments needed enough expressiveness for meaningful computational learning while remaining bounded.

We implemented AST preflight, protected runtime identifiers, typed method allowlists, literal control bindings, output contracts, execution limits, and independent reference runs. The current implementation is deliberately a bounded competition runner rather than a claim of a hardened public multi-tenant sandbox.

Validating dynamic generated outputs

Live generation exposed cases where an experiment changed a sequence length but its observation schema still expected one fixed matrix shape. This required clearer contracts between controls, runtime output dimensions, and validation cases.

Making failures honest and useful

A generated course can be syntactically valid but pedagogically or operationally invalid.

Rather than hiding these cases with automatic retries or fallback content, the host reports the validation failure and refuses to launch the lab. This made production debugging harder, but it also made the system more transparent and trustworthy.

Making generated courses pedagogically coherent

A technically valid Python program is not automatically a useful lesson.

The system needed to preserve orientation before prediction, visible cause-and-effect controls, interpretable observations, contrast, transfer, and debrief. Trusted normalization rules enforce this learning structure even though the course content is generated.

Deploying Node and Python together

The Railway deployment combines a Next.js standalone application and a restricted Python 3.11 runner in one service. This required careful Docker packaging, server-only secrets, health checks, access-code validation, quotas, and verification that runtime capability files were included in the production image.

Accomplishments that we're proud of

  • Deployed a real judge-accessible GPT-5.6 lab compiler.
  • Successfully generated and launched a production attention lab.
  • Preserved a one-request, zero-retry, zero-repair, zero-fallback contract.
  • Built one generic runtime for multiple computational subjects.
  • Separated model generation from trusted launch authorization.
  • Added independent primary and contrast execution before launch.
  • Built visualized evidence, measurable checks, transfer, and debrief stages.
  • Generated portable Jupyter notebooks from accepted labs.
  • Added committed examples that judges can open without credentials.
  • Deployed the mixed Next.js and Python system on Railway.
  • Passed the automated quality gates, including:
    • 309 unit tests;
    • 16 integration tests;
    • 21 Playwright browser tests;
    • lint;
    • type checking;
    • production build.

What we learned

The most important lesson was that generating educational software is fundamentally different from generating explanations.

The model must define not only what to say, but also:

  • what the learner can change;
  • what should be measured;
  • what evidence supports the concept;
  • which condition should fail;
  • which condition should succeed;
  • what should transfer to a new case;
  • how the host can independently validate the result.

We also learned that the critical boundary is not simply between AI and non-AI components. It is between proposal and authority.

GPT-5.6 proposes the learning experience. Trusted host code decides whether it is coherent, executable, bounded, and valid enough to launch.

Real deployment testing was also essential. Several important contract inconsistencies only appeared when newly generated programs exercised combinations that fixed local fixtures had not covered.

What's next for Generative Lab OS

The current version focuses on bounded computational experiments.

Future work could include:

  • isolated worker-level sandboxing;
  • persistent learner accounts;
  • instructor-authored constraints;
  • course-material ingestion;
  • reusable lab collections;
  • richer scientific visualizations;
  • classroom assignments;
  • teacher dashboards;
  • learning evidence across sessions;
  • LMS integration.

The long-term vision is an educational compiler that turns knowledge into something learners can manipulate, test, and understand through evidence.

Built With

Share this project:

Updates