Rosetta

highlighted-source-evidence
learning-notebook
rosetta-workbench
gpt-5.6-routing & harness-setup

Inspiration

We believe that one of the best ways to learn AI research is to try to reproduce it. Reproduction turns passive reading into active understanding: learners translate a paper's claims into code, predict what should happen, inspect failures, and compare a reported result with what they observe themselves.

In practice, that learning path is difficult to access. A learner can understand a paper and find its repository, then get stuck on unfamiliar code, missing dependencies, a huge dataset, unavailable GPUs, or an experiment that simply does not fit their machine. Too often, the only options are to read passively or run someone else's code without understanding why it works.

Rosetta began with a simple question: what if a learner could understand a difficult paper by tracing its evidence, adapting the experiment responsibly, and running the central idea on the hardware they already have? We wanted to make research reproduction more approachable without simplifying away the science or pretending that a small local run is the paper's full benchmark.

What it does

Rosetta is a learning workbench for AI engineers. A learner starts with a machine-learning paper and its implementation repository. Rosetta pins those sources, connects claims to the relevant PDF passages and code, and turns them into an editable lesson rather than a one-shot summary.

The lesson moves in a deliberate order: the paper's question and definitions, the key equations and architecture, a prediction about the method, an executable experiment, and an interpretation of the result. Learners can open a citation at the supporting passage, inspect the related code, edit a notebook cell, and see how each part connects to the paper's central idea.

Rosetta then plans an experiment for the learner's machine. It checks the available CPU, memory, disk, accelerators, dependencies, and execution budget. When the full experiment will not fit, it reduces only scale-related settings such as sample size, batch size, rank, width, layers, or steps. The goal is to preserve the mechanism being taught while clearly showing what was changed.

It also helps learners find a usable dataset. Rosetta extracts datasets mentioned by the paper, verifies candidate metadata and licenses, compares size with local hardware, and lets the learner approve a bounded local sample. Local experiments run in an isolated Docker environment. For work that needs more compute, Rosetta can prepare an approved Modal GPU plan, explain the expected cost, and wait for an explicit one-time approval before launching it.

When a learner is confused, they can drag a paper passage, equation, code selection, or generated figure into an annotation and ask the research agent about that exact context. Rosetta keeps the selected evidence with the question instead of opening an ungrounded side conversation.

Finally, Rosetta keeps the evidence with the result. It records the pinned sources, selected dataset, notebook version, code and runtime details, model route, generated figures, outputs, annotations, and any deviation from the original experiment. This helps learners see the difference between what the paper reported, what its repository implements, what was adapted for their hardware, and what their own run actually established.

How we built it

Rosetta is a TypeScript, React, and Electron desktop application with a local Node.js API and a pinned Python/PyTorch Docker runtime. We built it as five connected layers, each with a specific responsibility.

1. Source and evidence layer

The first layer receives a paper and repository. It downloads and hashes the PDF, extracts page-level text, pins the repository to a commit, and records the source identities before the agent is allowed to reason over them. The repository is inspected as evidence rather than executed as setup code. This gives the rest of the system a stable answer to a basic question: what paper and what implementation are we actually discussing?

2. Learning and planning layer

The second layer combines that evidence with the learner's machine profile. It builds an adaptation plan for CPU, memory, disk, accelerators, dependencies, dataset size, and execution budget. It also creates the learning structure: definitions before equations, equations before code, predictions before runs, and interpretation after results. This is where Rosetta decides how to create the smallest honest experiment that can teach the mechanism on the learner's machine.

3. Agent and model layer

The research orchestrator gives Codex the pinned source passages, repository snapshot, adaptation plan, selected dataset contract, and a structured output requirement. Prebuilt skills make recurring tasks consistent: extracting paper claims, authoring the concept notebook, adapting the environment, planning a resource-fit dataset, reproducing a figure, running isolated snippets, and packaging provenance. Hooks act as narrow gates around evidence grounding, safe execution, and artifact retention, while agents provide focused research roles.

This is also where we made our central GPT-5.6 design decision. We chose GPT-5.6 because its strengths match the hard parts of Rosetta: scientific synthesis across a paper and repository, long-horizon coding work, experimental diagnosis, and interpretation of observed results. But sending every request to the deepest reasoning setting would make interactive learning slower and less deliberate. We therefore created a versioned routing policy based on the quality required by each task.

The high-reasoning route creates the canonical paper-to-code notebook and reconstructs important figures. Reasoning escalates only when there is concrete evidence of a problem: a grounding, schema, or curriculum gate can request a deeper structural repair, while the maximum setting is reserved for observed Docker errors or unsafe runtime warnings. A balanced route handles research chat and bounded cell explanations, where the learner needs a responsive answer tied to a selected passage or code region. A faster route proposes dataset candidates, but deterministic code remains responsible for checking live metadata, license, size, and hardware fit. This is how we applied GPT-5.6 deliberately rather than using it as a generic text generator.

4. Execution layer

The accepted notebook becomes a runnable experiment. Local cells run cumulatively inside a network-disabled, read-only Docker environment with bounded resources and a pinned runtime. The selected dataset is mounted read-only, so generated code cannot silently fetch or replace the learning data. When local hardware is not enough, Rosetta prepares a separate Modal plan with an allowlisted GPU, package list, timeout, network policy, and maximum estimated GPU cost. The learner sees and approves that plan before a paid run starts.

5. Proof and provenance layer

The final layer turns a run into an inspectable learning artifact. Rosetta retains the source hashes, dataset selection, notebook version, code and image digests, execution manifest, figures, outputs, annotations, and declared deviations. Every model-backed artifact also records the model, reasoning setting, policy version, prompt hash, duration, and Codex version. This lets the learner and reviewer trace an answer or result back to the evidence and the exact execution that produced it.

Codex also accelerated the development of these layers. We used it to investigate real interface and packaging failures, turn repeated review findings into reusable validation contracts, improve the Electron build, and operate a quality loop across linting, type checking, unit tests, production builds, desktop smoke tests, browser tests, and Docker checks. We kept the product decisions human-led: teach the mechanism rather than fake a benchmark, require explicit approval for remote spending, and never treat a model response as proof by itself.

Challenges we ran into

The most important challenge was honesty. A compact experiment can help someone understand a paper, but it cannot automatically reproduce a large benchmark. Rosetta therefore makes the boundary visible. It distinguishes the paper's reported result from the repository's implementation, the local adaptation, and the result the learner actually ran.

We also had to connect three very different things: the scientific story in a PDF, the practical details hidden in a repository, and the limits of a learner's machine. Solving that meant building a system that keeps citations, code, environment choices, datasets, and outputs connected instead of relying on a fluent answer alone.

The final challenge was making powerful automation feel safe and understandable. A learner should be able to ask a natural question, but the agent needs the relevant evidence. A GPU can make an experiment possible, but the learner should see the plan and cost before anything runs. A repair step can help, but it should respond to a real failure instead of changing an experiment blindly.

Accomplishments that we're proud of

We are proud that Rosetta creates a complete learning loop: learners can go from a source claim to an explanation, code, prediction, execution, interpretation, and a retained result without losing the connection between those steps.

We are proud that it makes research reproduction more honest. Rosetta adapts experiments to real hardware while making the adaptation visible, so a learner can gain intuition from a runnable experiment without mistaking it for the paper's full benchmark.

We are also proud that Codex and GPT-5.6 are meaningful parts of the product. They help create and explain the learning experience, but evidence checks, execution limits, approvals, and provenance stay visible and enforceable.

What we learned

We learned that AI education needs more than a capable model. Learners need a clear sequence, a chance to predict before they run, evidence they can inspect, feedback on the exact thing they do not understand, and an honest explanation of what an experiment does and does not prove.

We also learned that reproducibility is not binary. A mechanism demo, a partial rerun, and a full reproduced result are all useful outcomes, but they mean different things. Showing that difference is not a limitation of the product; it is part of the lesson.

Finally, we learned that model routing is product design. GPT-5.6 is most useful when its deeper reasoning is reserved for work that needs it, while structured checks and faster routes handle bounded tasks responsibly.

What's next for Rosetta

Next, we want to make the path from paper to experiment even more useful: richer dataset choices, more hardware-aware experiment plans, clearer views that compare reported and observed results, and easier sharing of reproducible learning bundles with classmates, mentors, and collaborators.

Our long-term goal is to make advanced ML research accessible to anyone willing to learn it—not by hiding its complexity, but by giving learners a trustworthy way to inspect, adapt, run, question, and explain it on the hardware they already have.