Teaching An Open Model To Do Science
Captured source
source ↗Teaching an Open Model to Do Science | Arcee AI | Building Open Intelligence Trinity Large Thinking: Available on OpenRouter. Try Now
Teaching an Open Model to Do Science
Teaching an Open Model to Do Science
B + 2 Bojan Jakimovski, Sara Kovachovska, Maziyar Panahi
25 min read • Jul 30, 2026
Case Studies Post-training an open model for tool use, biological reasoning, and auditable research workflows
The next scientific question Our earlier work with Trinity Mini produced a model that could read a biomedical abstract and classify the relation between a drug and a protein. That was a deliberately narrow job with one piece of evidence, two named entities, and thirteen possible relations. The Trinity-Mini-DrugProt-Think adapter showed us that verifiable reinforcement learning could give a compact open model a useful scientific specialty. It also made the limitation obvious. Scientific work rarely arrives as a clean multiple-choice question. A researcher might begin with a target and a disease, not an answer set. The first literature query may return nothing. The protein may appear under several identifiers. A pathway result may be relevant but not decisive. One source may support the hypothesis while another weakens it. A confident paragraph is cheap. What's useful is a system that knows what evidence to seek next, tells missing evidence apart from a negative finding, and leaves a trail another scientist can actually follow. So the next question became much harder. Could we teach the same open model to carry out the kind of evidence-driven work we expect from an AI scientist: investigate a question, reason across sources, recover when the evidence is incomplete, and produce an auditable conclusion? This is not an isolated direction. The frontier of scientific AI is moving from models that answer questions toward systems that can participate in research workflows. OpenAI's GeneBench-Pro makes that shift visible in evaluation. Its 129 computational-biology problems ask agents to work with realistic, messy data, decide which analyses the data can support, revise an initial plan when diagnostics disagree, and determine when a result is ready to inform a downstream decision. OpenAI has also introduced GPT-Rosalind , a purpose-built life-sciences model designed to reason across biology, scientific evidence, data, and tools. Its target workflows include literature synthesis, genomics interpretation, pathway analysis, target discovery, and hypothesis generation. Anthropic's Claude Science approaches the same transition as a workbench. It brings together the databases, code, compute, and packages scientists already use, then asks agents to produce auditable artifacts rather than answers that disappear into a chat transcript. NVIDIA's BioNeMo Agent Toolkit supplies another critical layer by packaging structure prediction, molecular generation, docking, sequence analysis, and genomics as discoverable skills an agent can invoke and interpret. The products and benchmarks are different, but the direction is consistent. Scientific AI is becoming less about generating convincing scientific language and more about gathering evidence, operating specialist tools, running analyses, revising decisions, and leaving work that can be checked. This work is a collaboration between Loka, AWS, Arcee, and Prime Intellect around a shared idea. Scientific AI should not be a black box that an organization can only query. It should be a system the organization can inspect, evaluate, specialize, operate, and improve. The open stack makes that possible. Arcee's Trinity Mini provides an adaptable open-weight policy. Prime Intellect's open-source prime-rl turns domain feedback into repeatable policy updates. Loka translates scientific work into biomedical datasets, environments, verifiers, and an auto-research process, then carries the trained behavior into a working agentic harness. AWS provides the enterprise infrastructure that connects accelerated training, durable artifacts, security, model serving, application services, and observability. Together, those layers give research teams and regulated enterprises a practical path to building scientific AI around their own evidence, workflows, and standards. The model can be changed, the reward inspected, the evaluation shaped around the real task. Deployment can stay inside an approved operating boundary, and failures become inputs to the next training run instead of disappearing behind an API response. This report follows that stack in motion, from scientific questions and verifiable feedback through specialized open-model training and 21 rounds of evidence-led iteration, to a working agentic harness on AWS. Together, these layers turn scientific AI from a promising capability into a system an organization can build, govern, and keep improving on its own terms. Why specialize an open model? Because a prompt can describe a procedure, but it cannot make that procedure reliable. We can tell a model to prefer primary evidence, resolve identifiers, and return strict JSON. On an easy example, that may be enough. Over a long trajectory, the instruction competes with partial evidence, conflicting sources, formatting constraints, and the model's instinct to produce a helpful-looking answer even when the evidence is weak. That failure mode is especially dangerous in science. A malformed JSON object fails loudly. A polished synthesis built on the wrong protein can pass quietly into the next step of a workflow. The difference is not eloquence. It is learned judgment about evidence, uncertainty, and the next scientific action. Thinking Machines and Bridgewater found the same pattern in financial-information work. Expert-written prompts helped substantially, but task-specific training was needed to capture judgments experts could demonstrate more easily than explain. The shared lesson is that repeated expert judgment can become model behavior when a team turns it into examples, feedback, and evaluation. Specialization also has to be operationally practical. A compact open model can run within an organization's cloud boundary, be adapted through a small LoRA artifact, and be pinned to a specific policy version. The organization controls the data path, reward, evaluation, serving cost, and incident response. It can improve the model for its own workflow without waiting for a provider to prioritize the same niche behavior. Frontier systems...
Excerpt shown — open the source for the full document.
Notability
notability 6.0/10Substantive post on open model for science