Rockie began as the internal research system at Pebble ML. It was built to increase the rate at which the lab could turn a research question into an evaluated result and then into the next experiment.
Thesis
Rockie makes a research team's full experiment loop executable as software so the team can increase the velocity of useful experiments.
The loop begins with a research question and ends when a result informs the next experiment. Experiment velocity is the rate at which a team completes those iterations. A useful iteration has a result the team can evaluate, inputs and outputs it can trace, and a decision that moves the research forward. Rockie calls a result verified when it passes the checks chosen for that workflow. The experiment record names the rule used to judge it and preserves the information needed to review the decision later.
Once that loop is represented in a working environment, Rockie can increase its rate in several ways. Work that used to happen in sequence can overlap. Independent branches can move to additional workers. The output of one experiment can become a dataset, model, or tool that makes later experiments faster. Every path returns to the same research record.
Friction
In many research teams, the pieces of the loop live in different places. Data sits on a shared drive. Credentials live on one researcher's machine. A baseline is reproduced from an old notebook. The reason a senior researcher accepts or rejects a result may never have been written down. Reconstructing this context becomes part of every experiment.
Long-running compute creates another gap. A model launches a job, waits for it to finish, interprets the result, and only then prepares the next experiment. Planning, implementation, and write-up happen between runs while expensive compute sits idle.
Parallel work introduces a coordination problem. Workers can repeat a failed direction, claim the same experiment, change the metric, or produce results that cannot be compared. A larger worker pool becomes useful when every worker shares the experiment record and follows the same research contract.
These problems define the unit Rockie has to provide: a persistent research environment for one experimental workflow.
Environment
Rockie gives the team one persistent environment for the whole experiment loop. The workspace, credentials, experiment history, and evaluation rules live together. Jobs and results are written to a shared record. A run can begin from the state left by the last one, and additional workers can use the same context without changing how results are judged.
Each customer receives a dedicated CPU cloud runtime with persistent storage. The runtime holds the workspace and run history. Dataset and model registries identify the versions used by an experiment without mixing customer data into a shared store. A job record keeps the hardware request, status, resource use, and logs separate from the output that later experiments may need.
The model works inside that environment through the harness built for it. Claude runs in Claude Code and OpenAI models run in Codex. Research skills and customer tools are installed in the format each harness expects, so sessions and tool behavior remain native. Rockie Nugget gives API-based and open models a smaller versioned tool contract against the same environment. Its standalone runtime works today while the control-plane chat route is still being integrated.
Elastic compute is attached to the runtime for a specific job. Before launch, Rockie and the researcher can set the hardware, time limit, and spend policy. Rockie reserves credits against that policy, monitors provider-reported spend, and shuts the compute down at the enforced limit.
Researchers can reach the same environment through the web lab, the Rockie CLI, or a local-to-cloud handoff. MCP lets a local model use Rockie tools. A2A hands longer work to the cloud environment and returns a task identifier. Each surface authenticates to the same tenant and operates on the same workspace.
Loop
Within that environment, installation establishes the research contract through a first accepted run. Rockie connects the real workflow, reproduces a baseline the team trusts, and records the metric, allowed changes, acceptance rule, and limits on time and compute. Later experiments inherit that contract.
fig. 1 — the experiment loop and what feeds each stage.
After the first run, each worker claims a bounded experiment from the shared queue. While that experiment runs, the worker finishes the preceding write-up and prepares likely successors. A positive, neutral, or negative result may each lead to different code or configuration. Preparing those branches before the result arrives removes the handoff gap between experiments.
When the result arrives, Rockie applies the workflow's checks, records the outcome, and selects the matching prepared branch. Independent experiments can run on separate workers at the same time. Atomic claims prevent duplicate work, and shared lineage keeps every result attached to the question that produced it.
Some outcomes still require researcher judgment. A change to the metric, acceptance rule, mutation boundary, credentials, safety policy, or approved spend stops the queue at a decision gate. More compute and more workers remain inside the research contract established by the team.
Compounding
An experiment can improve the system that runs the next experiment. A useful dataset remains in the registry. A model can become a callable endpoint. Code written to launch, evaluate, or visualize a workflow can become a tool available to later runs. This lowers the cost of returning to the same class of question.
Simulation provides a concrete example. A reference simulator may be too slow for a broad search. Rockie can save each simulation input with its output, build a versioned dataset from those pairs, and train an emulator. The emulator screens the larger search space. Cases with high uncertainty return to the reference simulator and add new training data. Public resources such as the SPICE dataset can provide initial molecular data and benchmarks while customer simulations define the domain that matters to the workflow.
Reviewed experiment histories can eventually serve another purpose. The same tools, tasks, and evaluation rules form an environment for post-training a customer-specific open model. That model can be served through Rockie, evaluated inside the same workflow, and improved with later research decisions.
Deployment
Rockie is installed around one valuable recurring workflow. The workflow is customer-specific, while the system used to run it carries across installations. A domain expert identifies the trusted baseline and the conditions for a useful result. Rockie connects the tools, reproduces the baseline, and encodes the parts of the process that can run repeatedly. Customers that want hands-on installation pay for that work, and the engagement gives Rockie detailed product feedback.
The customer's scientific code, data, and decision rules stay in its environment. Job controls, run storage, model routing, compute orchestration, registries, serving, and access tools stay in Rockie when they can support the next deployment. Each installation starts from the product already built and adds software that can be separated from the customer's private research.
The strongest first customer already has a valuable digital workflow and a painful execution bottleneck. The team runs the workflow often enough that throughput limits what it can explore, and it already knows how to recognize a useful result. A one-off analysis, or a task a notebook and an off-the-shelf coding tool handle well, does not need a dedicated environment.
Evidence
The Chronotope and Agteria Biotech engagements show how reusable code and methods reduce the marginal effort of a new deployment. Their physics and molecular workflows require different simulation code, data, and acceptance rules. Both use the same job controls, persistent run state, model-serving path, and simulation-to-emulator method. The domain work remains specific to each customer, while the reusable layer reduces the platform work required to put that workflow into Rockie.
Scope
The first installation still depends on a domain expert who can identify a trusted baseline and explain how results should be judged. Rockie currently focuses on narrow computational workflows whose outputs the customer already knows how to evaluate. That boundary is what allows the experiment loop to be encoded, scaled, and reviewed.
Conclusion
Rockie treats experimentation as a system that can be scaled. A research question is connected to the data, tools, model harness, compute, acceptance rules, and history required to act on it. Once connected, work can overlap, independent branches can run together, and their outputs can make the next search cheaper. Across customer workflows, the scientific work changes while more of the execution system carries forward. Rockie's value is the increase in useful experiment velocity that follows.