Experiment Lifecycle
An experiment lifecycle describes how an idea becomes a run, how a run becomes evidence, and how evidence becomes a public claim. It connects Experiment design, Training run, Experiment tracking, and Reproducibility.
A compact lifecycle is:
where is a research question, is a hypothesis, is an experiment design, is a run, is an analysis, and is a claim.
Stages
- Question: define what decision the experiment should change.
- Hypothesis: state the expected direction before running.
- Design: choose data, split, baseline, metric, and smallest test.
- Run: execute with fixed code, config, seed policy, data version, and environment.
- Artifact: preserve logs, checkpoints, predictions, figures, and failure notes.
- Analysis: compare against baseline, ablation, confidence interval, or error analysis.
- Claim: write only what the evidence supports.
- Promotion: decide whether the result becomes a note, project milestone, paper reproduction, or Korean post.
Evidence Flow
The claim should become weaker when any upstream piece is missing. A result without split details is weaker than a result with a recorded Dataset split contract. A metric without predictions is weaker than a metric with saved Run artifacts. A public result should be summarized through a Claim evidence record before being promoted into a stronger statement.
Checks
- Is the decision question explicit before the run?
- Is the baseline or ablation chosen before seeing the result?
- Are train, validation, and test roles separated?
- Are code commit, config, data version, seed policy, environment, and scheduler assumptions recorded?
- Are artifacts sufficient for later metric checking?
- Does the analysis mention uncertainty, failure modes, or threats to validity?
- Is the public claim separated from private paths, internal task names, unpublished results, and collaborator details?