A research assistant has several jobs, not one
Finding a paper, proposing an explanation, running code, and writing a conclusion do not produce the same kind of evidence. Calling the whole sequence “research” makes it too easy for an idea to acquire the tone of a result before anything has been tested.
No workbench, model, database, dataset, code path, or experiment was run for this article. The example below is hand-authored and fictional. It illustrates artifact labels, not scientific findings.
Five jobs, with different outputs
- FindA dated source set and a record of where the search looked.
- ExtractClaims tied to exact source locations, with uncertainty preserved.
- ProposeA question or hypothesis labeled as an idea to test.
- ExecuteAuthorized code, data, environment, parameters, observations, and failures.
- ConcludeA bounded comparison between the proposal and observations.
This is a staircase of evidence, not an automatic pipeline. A missing citation sends extraction back to finding. A hypothesis that cannot be measured returns to proposal. A failed assumption or broken instrument sends execution backward. A conclusion that reaches beyond the observations returns to analysis rather than becoming polished prose.
One fictional question at five stages
Suppose the question is: “Does a shorter retrieval passage improve answer support on a tiny document set?” Nothing below was run.
| Stage | Artifact | What it does not establish |
|---|---|---|
| Find | A dated list of papers about retrieval chunking and citation support, plus search terms and exclusions. | That the list is complete or that its claims apply to this question. |
| Extract | A table linking each relevant claim to a page, section, method, and stated limitation. | That the claims are correct or comparable across studies. |
| Propose | “On this invented corpus, shorter passages may reduce unsupported context while retaining the cited sentence.” | That shorter is generally better, or that any effect exists. |
| Execute | A future record would need exact corpus bytes, passage rules, retrieval settings, questions, support rubric, environment, outputs, and failures. | No execution record exists here, so there is no observation. |
| Conclude | No conclusion. The only honest status is not run. | A plausible mechanism is not a result. |
Why interfaces should keep these jobs visible
The official OpenScience repository describes a workbench that gathers evidence, runs code and experiments, and returns inspectable results. The archived ML Intern repository historically described an agent spanning papers, datasets, code, compute, and Hub actions; Hugging Face now marks that project unmaintained and directs readers to HuggingChat. DeepTutor exposes distinct research, solve, quiz, and visualization capabilities. These are documented surfaces, not evidence that the tools produce valid science or current tool recommendations.
The useful design lesson is narrower: when one interface can move between reading, proposing, executing, and writing, the artifact should say which job produced it. A source list should not look like an observation. Generated code should not look like a completed experiment. A fluent synthesis should retain links to the material and execution record it depends on.
A practical handoff
At each transition, hand forward the artifact and its status: sources found, claims extracted, proposal awaiting test, execution record, or bounded conclusion. Keep return paths cheap. The goal is not to make research perfectly linear; it is to stop the label from outrunning the evidence.
Primary sources checked: OpenScience, the archived ML Intern repository, and DeepTutor. The evidence staircase, return-path model, and fictional example are original synthesis. No adoption, reliability, benchmark, learning-effectiveness, scientific-discovery, or current-product recommendation claim is made.