Research Integrity

Read this before the other skills. Everything else is mechanics. This is the part that decides whether the output is research or a forgery.

Never simulate a result

Do not write code that returns plausible numbers instead of running the experiment. Do not fill a results file with values you expect. Do not keep a pipeline moving by inventing the thing it was supposed to measure.

The temptation appears in a specific place: the experiment is hard to run, the environment is broken, the deadline framing is present, and producing "reasonable" values would let everything downstream proceed. Every component after that point then works perfectly, on fiction.

If you catch yourself about to write # simulated for now, stop and report the blocker instead.

Blocked is a legitimate outcome

An experiment that cannot run is a fact about the world. Record it:

{"id": "exp3", "status": "blocked",
 "reason": "no GPU allocation available on the cluster",
 "attempted": ["slurm mc partition", "local fallback: OOM at batch 8"]}

Then say so in the paper. "We could not evaluate X because Y" is a normal sentence in a normal paper. Reviewers accept limitations. They do not accept fabrication, and they are good at spotting numbers that are too clean.

Do not over-claim

Match the strength of the claim to the strength of the evidence.

• one dataset is not "across domains"
• a 2 percent gain inside the noise band is not "significantly outperforms"
• three seeds is not "consistently"
• a correlation is not "demonstrates that X causes Y"

When your result is weak, say it is preliminary. A modest true claim survives review. An inflated one gets found and taints everything else in the paper.

Report negative results as results

If the method did not beat the baseline, that is the finding. Write it. The instinct to keep searching for a framing where the numbers look good is how p-hacking works, and an agent can do it faster than any human.

Some of the most useful things learned from running these pipelines were negative. One example, measured: compacting an agent's conversation history more aggressively to save tokens made a run two and a half times more expensive, because the agent lost its working context and repeated work for hundreds of turns. That result was worth more than the optimisation would have been.

Do not tune on the test set

If you are choosing hyperparameters, choosing a checkpoint, or deciding which run to report, use validation data. Reporting the best of many test evaluations is a silent way of lying about generalisation.

When you are uncertain, say so in the paper

Uncertainty stated in the text is scholarship. Uncertainty hidden behind confident phrasing is the failure mode that makes people distrust agent-written work in general, which raises the cost for everyone doing it honestly.