# Draft Note: Instructor & Researcher — NeutronOS for Prague Summer Class

**To:** the instructor, a nuclear engineering researcher
**From:** Ben Booth
**Date:** 2026-04-13
**Subject:** Prague class platform — what we're building and what I need from you

---

Hi all —

Big update. Over the past few weeks the classroom architecture has expanded significantly — we've gone from "a chat interface with tracing" to something I genuinely think is publishable as a paper about how AI-assisted learning *should* work, not just how it *can* work. Let me walk you through it.

## The Shape of the Thing

For the Prague class, each of your 12 students will get:

- **A browser-based chat interface** (no install) with full mobile support. Start a conversation on a laptop in the classroom, continue on a phone walking to the dorm. Sessions are server-side, so device switching is seamless.
- **A curated domain knowledge base** — our nuclear engineering corpus plus whatever course materials you provide — so every answer is grounded in real sources with citations, not generic LLM training data.
- **A terminal interface** (`neut chat`) for students who prefer it. Same backend, same sessions. Students comfortable with Claude Code will feel at home.
- **An iterative research tool** that's fundamentally different from "ask a question, get a report" (more on this below — it's the most important feature).
- **Structured interviews** at the start and end of the course, conducted conversationally but producing research-grade structured data.

For the two of you:

- **A per-student dashboard** showing activity, topic coverage, objective mastery, quiz scores, any automated alerts.
- **Daily briefings** — our signal-detection agent (SCAN) watches for stuck students, misconception patterns, engagement drops, and surfaces them to you.
- **Automated evals** that prove (to you, to students, and to paper reviewers) that our system gives more accurate domain-specific answers than raw ChatGPT.
- **Clean research data export** — parquet/CSV, anonymized, ready for pandas.

## What's Genuinely New

This isn't just "ChatGPT with tracing." Here's what's structurally different:

### 1. Iterative Research (not "auto-research")

The most important feature, and the one I'd like you to push students to use heavily.

When a student says `/research "accident-tolerant fuel cladding materials"`, our research agent (CURIO) doesn't just dump a report. It runs an **iterative research loop**:

1. **Formulate** a hypothesis and sub-questions
2. **Search** the corpus for evidence
3. **Evaluate** what the evidence supports, what it contradicts, what's missing
4. **Refine** the hypothesis based on what it found
5. **Repeat** for multiple iterations until it converges

The student sees the hypothesis evolve across iterations. They see contradictions surfaced explicitly ("Source A says X, Source B says Y — investigating"). They can intervene: `@curio focus on the neutronics penalty, deprioritize manufacturing`. The loop is resumable across days.

The pedagogical claim: **this teaches students how experts actually investigate** — hypothesis formation, contradiction resolution, iterative refinement. The process is the learning outcome, not just the final synthesis. The loop state itself is a deliverable: "submit your research loop alongside your paper" means students submit the evolution of their understanding, not just their conclusions.

This is Karpathy's ML-training-loop insight applied to knowledge research. I think it's the feature that makes the paper interesting.

### 2. Agent Team with @Addressing

We don't have one chatbot — we have a team of agents, each with a distinct role:

| Agent | Role |
|-------|------|
| **Neut** (AXI internally) | Default conversational partner, orchestrator |
| **CURIO** | Research agent — runs the iterative research loops |
| **SCAN** | Signal/alert agent — watches for patterns, surfaces signals to you |
| **PRESS** | Publisher — handles document lifecycle, report generation |
| **TIDY** | Infrastructure steward |
| **TRIAGE** | Diagnostics |

Students can direct-address any agent: `@curio research this topic`, `@scan what have I been stuck on?`, etc. When Neut delegates to another agent behind the scenes, the student sees the delegation explicitly — this teaches them the agent topology by showing it in action.

### 3. Structured Q&A Engine

Your begin-of-course and end-of-course interviews are conducted via a structured Q&A engine — fixed questions (critical for research validity), typed responses (likert, free-text, yes/no, numeric), optional branching logic, conversational tone provided by the LLM wrapper. Same questions for every student, same interpretation. Export as structured CSV, ready for analysis.

This is reusable beyond the classroom — any time you want research-grade data gathered through conversation, you use the same engine.

### 4. Evals as First-Class

We have an eval framework that lets us prove quality claims with numbers. Before the class starts, we'll build a domain-accuracy eval suite — ~50 questions where we know the expected answers — and run it against both our system and baseline GPT-4o. If we can't show our system is measurably more accurate on domain questions, we shouldn't ship it. And if we can, that comparison is your Figure 1 in the paper.

### 5. LMS Integration via LTI 1.3

Rather than building custom Canvas integration, we're building against the LTI 1.3 standard, which works with Canvas, Moodle, Blackboard, Brightspace — all major LMS platforms. Students launch from their LMS course shell, arrive pre-authenticated. Grades push back to the LMS gradebook. Roster syncs automatically.

For Prague, if the Czech institution uses Moodle (common in Europe), this should work out of the box.

### 6. Cross-Student Research Cross-Pollination *(v2 feature, fall 2026)*

Not in the Prague MVP, but designed in. Students running related research loops can share findings automatically through classroom federation. Student A's discovery about regulatory pathways informs Student B's economic viability analysis. Neither student coordinates this — it happens through the research agents.

For Prague, each student works individually. But the architecture supports the collaborative version, and we'll deploy it for a larger cohort in the fall.

## The Student Learning Toolkit

Students shouldn't just be handed a chatbot. They should be taught a set of AI-powered learning tools as foundational skills. Onboarding includes guided training on:

1. **Chat** — effective questioning, evaluating answers, recognizing citations vs. generation
2. **Iterative research** — launch a loop, watch it iterate, identify contradictions, verify citations (this is the big one)
3. **Session management** — named sessions for different purposes, not one long conversation
4. **Help requests** — formal escalation when the AI can't help, de-stigmatizing asking
5. **Structured Q&A** — the interview format (they'll experience it in the pre-course interview)
6. **Publishing** (optional, for writing-heavy courses) — draft, review, submit reports

We track completion of each onboarding step. Students who complete the full toolkit are hypothesized to learn more effectively — and we'll measure this.

## Platform & Deployment

- **Chat UI:** Open WebUI (open-source, MIT-licensed, mobile-responsive, 124K GitHub stars). We don't build a chat UI from scratch — we build the intelligence behind it.
- **Tracing:** Langfuse (self-hosted, Apache 2.0) — every LLM call, every retrieval, every tool call is traced.
- **Learning records:** Ralph LRS for xAPI — standard format for learning analytics data.
- **Backend:** Our Axiom/NeutronOS stack on Rascal (UT campus tower), exposed via Cloudflare Tunnel for public HTTPS.
- **LLM provider:** Our choice — no student data goes to OpenAI or Anthropic without our control.

## Timeline

- **Phase 0 (now → Apr 27):** Foundation — trace provider, OpenAI-compatible endpoint, Open WebUI deployed on Rascal, eval harness, research loop engine. Dogfoodable by the three of us.
- **Phase 1 (Apr 28 → May 10):** Classroom features — course/classroom manifests, cohort enrollment, instructor dashboard, begin/end interview questionnaires.
- **Phase 2 (May 11 → May 25):** Intelligence — batch classification, objective tracking, SCAN alerts, load testing with simulated students.
- **Phase 3 (May 25 → class start):** Hardening only. Bug fixes, corpus curation, instructor training. No new features.
- **Phase 4 (during class):** Monitoring, daily data verification. Stability only.
- **Phase 5 (after class):** Data export, analysis, paper writing.

Aggressive but doable. Phases may compress.

## What I Need From You

### From both of you:

1. **Start using it this week.** I'll have the web chat deployed on Rascal by [target]. Use it for your own work for 1-2 weeks. Break it. Tell me what's frustrating, what's missing, what's genuinely useful. This is the single most important input I can get.

2. **Draft learning objectives** for the Prague course. Even rough is fine — 8-15 objectives with keywords. I need these to build the objective-tracking system.

3. **Identify course materials** — PDFs, textbooks, problem sets, lecture notes. Send them to me; I'll index them into the course-specific RAG corpus.

4. **IRB/ethics approval** — we're collecting human subjects data. Does the Czech institution have its own ethics board? What does UT require? This needs to start now, not in June.

### For the researcher specifically:

I want your unfiltered comparison with Claude Code. Where does NeutronOS fall short? Where is it better? What would make you reach for our tool instead of Claude Code during real work? If you can articulate "Claude Code does X better because Y," that's the feedback that makes the classroom product stronger. You're skeptical and that's valuable — please keep being skeptical.

The research loop (CURIO) is the feature I'd most like your assessment on. Try `/research` on a few topics you care about. Does the iterative structure actually produce better outcomes than a single Claude query? Be honest.

### For the instructor specifically:

Your experience running actual classes is the thing I have least of. Where does this design break down in real teaching? What would you do differently? The workflow catalog (enrollment, onboarding, quizzes, check-ins, help requests, grading, presentations) is in the PRD — look it over and tell me what's missing or wrong.

Also: how does your institution handle AI use policy today? The system lets us encode a policy in the course manifest ("AI may help with calculations but not written analysis") and enforce it via the grading workflow's integrity check. What would a reasonable policy look like for Prague?

---

## Key Documents to Read

- PRD: `axiom/docs/prds/prd-classroom.md` — what we're building and why
- Evals PRD: `axiom/docs/prds/prd-evals.md` — how we prove quality
- Tech spec: `axiom/docs/specs/spec-classroom.md` — implementation detail + the full set of end-to-end scenarios across v1/v2/v3
- Research loop: `axiom/docs/working/curio-research-loop.md` — the iterative research primitive
- Agent framework: `axiom/docs/working/axiom-repl-agent-framework.md` — the agent team design

Let me know when you want to sync — happy to walk through any of this.

Ben
_Copyright (c) 2026 The University of Texas at Austin and B-Tree Labs. Apache-2.0 licensed._
