Monitor and steer an experiment

An experiment opens on Timeline, where you can follow the work without watching every step. The goal is not to supervise every tool call. It is to notice the moments that change what will be learned: a substituted dataset, a failed control, a surprising intermediate result, or a decision that needs your judgment.

Keep questions about research direction in the parent thread. Open the experiment when you need to understand or correct execution.

What a healthy run looks like

A healthy experiment leaves a readable trail. You should be able to see what it is doing now, how that follows from the plan, and whether any deviation changes the claim.

• Reports is the published answer. Use it for the headline, evidence, review, and export actions. See Review and synthesize results for a deeper pass through the result.
• Timeline is the durable research record: the original plan, checkpoints, decisions, deviations, results, and critic review.
• Worker is the execution conversation. Use it to understand what the worker is doing and to steer active work.
• Compute shows experiment usage and the jobs behind it, with filters for running, completed, and failed work.
• Metrics appears when the experiment links a training or evaluation run, such as a Weights & Biases run.
• Code shows files added, changed, or deleted in the experiment worktree. Open a file to inspect it, copy its path, download it, or chat about it.

Queued compute or a long evaluation is not necessarily a problem. Silence after a failed job, repeated work with no new evidence, or progress on the wrong input is. Timeline and Compute help you tell the difference.

Read Timeline first

Timeline is the experiment's narrative: the plan, meaningful progress, decisions, deviations, and reports. Read the newest entry first, then move backward only as far as needed to understand it.

When a finding surprises you, ask:

• What changed from the plan?
• Which decision or progress entry introduced the change?
• What evidence would separate a real finding from a data, metric, or implementation problem?

Compare the run with Plan when the method or scope appears to have shifted. A deviation is not automatically a failure; exploratory work often changes course. What matters is whether the change is visible and whether the resulting evidence still supports the intended claim.

When a durable output is ready, open Reports for the result rather than reconstructing the conclusion from individual progress entries.

Answer decisions precisely

Read the surrounding Timeline entries before answering. Usually, the most helpful response is the smallest clear constraint that lets the work continue without inventing a new experiment inside the old one.

Use the held-out templates for the comparison. Keep the training split only for debugging, and stop before the full sweep if the control fails.

Your answer becomes part of the record, so include the reason when it would not be obvious later. “Use split B” is operational; “Use split B because split A overlaps the probe-training data” preserves scientific intent.

Prefer thread-level steering

When an issue changes the question or how the evidence should be interpreted, bring it back to the thread and cite the relevant experiment or Timeline entry. The planner can then decide whether to revise the current direction, propose a follow-up, or reinterpret earlier work.

Open Worker only for an immediate execution correction or information only you have. Preserve valid completed work:

Keep the completed baseline. Before scaling the intervention arm, rerun 20 examples with the tokenizer fix and compare them with the saved outputs.

Avoid replacing the hypothesis mid-run. If the new question changes the comparison or claim, preserve the current work and ask for a follow-up plan. Separate experiments make later comparisons much easier to trust.

Inspect code, compute, and metrics

• Use Code when a result depends on preprocessing, evaluation logic, or an implementation change.
• Use Compute when work appears idle, expensive, queued, or failed.
• Use Metrics when you need the shape of a linked training or evaluation run, not just its final number.

Open Compute to check whether a run is still consuming compute, which jobs completed, and whether anything failed. Usage and job status answer operational questions; they do not explain whether the result is scientifically trustworthy.

Open Code when you need to trace a result to the files that produced it. Select a file to inspect its diff, open the worktree in the IDE, or use Chat about this file for a focused question.

Use the parent thread's code icon for the accumulated codebase. Use experiment Code for this run's changes.

Stop or follow up

It is worth stopping an experiment when it is using the wrong data, producing evidence you cannot trust, consuming resources after the decision is already clear, or answering a question that no longer matters. Record why so the partial work remains understandable later.

If the completed portion is valid, preserve it. A useful baseline does not become worthless because a later sweep failed. Let valid work finish when the remaining cost is reasonable, then launch a focused follow-up for the changed condition.

Before leaving a long run, you should be able to answer: what is running, what will make it stop, and where Silico will ask for help. That is enough oversight for most experiments.

Next step

When a report is available, continue with Review and share reports.