Experiment Workflow

Philosophy

experiments.md is a living document, not a rigid specification. It captures ideas at various stages of development. The format can evolve as needs change.

The table is an index; the detailed sections are the documentation. The table lets you scan experiment labels and statuses at a glance. Each experiment should have a ## <label> section below the table that contains the actual content:

• The research question and any sub-questions it breaks into
• How this experiment connects to other experiments (dependencies, shared data, sequential logic)
• What the outcome implies for next steps (e.g., "if sys > 1 is rare, we need targeted search methods")
• Open questions and blockers
• Where the idea came from (conversation, paper, advisor discussion)

Don't compress ideas. When capturing a research idea, preserve the intellectual labor that went into articulating it. A one-line note in the table loses the nuance, connections, and decision points. Write the detailed section.

One experiment can have multiple variants. If an experiment explores multiple families or parameter settings (e.g., comparing "convex hull of random points" vs "intersection of random halfplanes"), keep it as one experiment entry. Each variant gets its own config file in config/<label>/ (e.g., convex-hull.json, halfplane-intersection.json). The set of commands to run for full reproduction must be obvious from the repo state — no mental recall or documentation lookup required (e.g., "run for each config file in the directory"). Local iteration (one stage, one config) may use CLI args. Don't create separate table rows for each variant.