grind-lab-core/night_owl_research_agent/experiment-design

Experiment Design: Claim-Driven, Paper-Oriented Validation

Refine and concretize: $ARGUMENTS

Overview

Use this skill after the method is stable enough that the next question becomes: what exact experiments should we run, in what order, to defend the paper? If the user wants the full chain in one request, prefer /experiment-design-pipeline.

The skill is domain-general (AI / deep learning / ML research is fully supported) and must handle GIScience, remote sensing, and spatial data science research as a first-class case. The spatial-specific validation layer (MAUP sensitivity, alternative spatial weights, GWR/MGWR, residual Moran's I, spatial CV) is conditional, not automatic — add only the pieces the research question and chosen claims actually require, and document any spatial check that was considered and skipped (with a one-line reason). When uncertain whether to include a spatial check, honor `HUMAN_CHECKPOINT` and ask the user before either adding it (extra cost) or omitting it (review risk). See spatial-analysis/SKILL.md §5.3 for the same gating rule applied at execution time.

The goal is not to generate a giant benchmark wishlist. The goal is to turn a proposal into a claim -> evidence -> run order roadmap that supports four things:

1. the method actually solves the anchored problem
2. the dominant contribution is real and focused (not a confound of scale, data source, or setup choice)
3. the method is elegant enough that extra complexity is unnecessary
4. any frontier-model-era component (foundation model, VLM, diffusion, RL, geo/graph transformer, etc.) is genuinely useful, not decorative

Constants

• OUTPUT_DIR = `output/` — Default destination for experiment planning artifacts.
• MAX_PRIMARY_CLAIMS = 2 — Prefer one dominant claim plus one supporting claim.
• MAX_CORE_BLOCKS = 5 — Keep the must-run experimental story compact.
• MAX_BASELINE_FAMILIES = 3 — Prefer a few strong baselines over many weak ones.
• DEFAULT_SEEDS = 3 — Use 3 seeds when stochastic variance matters and budget allows.

Workflow

Phase 0: Load the Proposal Context

Read the most relevant existing files first if they exist (use Read; skip silently if missing):

• output/LIT_REVIEW_REPORT.md — consolidated literature review, thematic synthesis, ranked gaps
• output/IDEA_REPORT.md — ranked idea candidates with pilot scores
• output/refine-logs/FINAL_PROPOSAL.md — refined proposal the experiments must defend
• output/refine-logs/REFINE_REPORT.md — round-by-round resolution log and drift record

Extract:

• Problem Anchor (and, if spatial, the geographic / sensor / scale scope)
• Dominant contribution
• Optional supporting contribution
• Critical reviewer concerns (including any spatial-validity concerns: autocorrelation, MAUP, transferability, geographic bias)
• Data / compute / timeline constraints (including geospatial data licensing, AOI coverage, revisit cadence, compute for large rasters / graphs)
• Which frontier primitive is central, if any (e.g., geo-foundation model, SAM-style segmenter, VLM, diffusion, GNN, transformer)

If none of these files exist, focus on `$ARGUMENTS` and derive the same information directly from the user's prompt. Do not block on missing files; do not fabricate content from files that are not present.

Phase 1: Freeze the Paper Claims

Before proposing experiments, write down the claims that must be defended.

Use this structure:

• Primary claim: the main mechanism-level contribution
• Supporting claim: optional, only if it directly strengthens the main paper story
• Anti-claim to rule out: e.g. "the gain only comes from more parameters," "the gain only comes from a larger search space," or "the modern component is just decoration"
• Minimum convincing evidence: what would make each claim believable to a strong reviewer?

Do not exceed MAX_PRIMARY_CLAIMS unless the paper truly has multiple inseparable claims.

Phase 2: Build the Experimental Storyline

Design the paper around a compact set of experiment blocks. Default to the following blocks and delete any that are not needed:

1. Main anchor result — does the method solve the actual bottleneck?
2. Novelty isolation — does the dominant contribution itself matter?
3. Simplicity / elegance check — can a bigger or more fragmented version be avoided?
4. Frontier necessity check — if an LLM / VLM / Diffusion / RL-era component is central, is it actually the right tool?
5. Failure analysis or qualitative diagnosis — what does the method still miss?

For each block, decide whether it belongs in:

• Main paper — essential to defend the core claims
• Appendix — useful but non-blocking
• Cut — interesting, but not worth the paper budget

Prefer one strong baseline family over many weak baselines. If a stronger modern baseline exists, use it instead of padding the list.

Phase 3: Specify Each Experiment Block

For every kept block, fully specify:

• Claim tested
• Why this block exists
• Dataset / split / task
• Compared systems: strongest baselines, ablations, and variants only
• Metrics: decisive metrics first, secondary metrics second
• Setup details: backbone, frozen vs trainable parts, key hyperparameters, training budget, seeds
• Success criterion: what outcome would count as convincing evidence?
• Failure interpretation: if the result is negative, what does it mean?
• Table / figure target: where this result should appear in the paper

Special rules:

• A simplicity check should usually compare the final method against either an overbuilt variant or a tempting extra component that the paper intentionally rejects.
• A frontier necessity check should usually compare the chosen modern primitive against the strongest plausible simpler or older alternative.
• If the proposal is intentionally non-frontier, say so explicitly and skip the frontier block instead of forcing one.

Phase 4: Turn the Plan Into an Execution Order

Build a realistic run order so the user knows what to do first.

Use this milestone structure:

1. Sanity stage — data pipeline, metric correctness, one quick overfit or toy split
2. Baseline stage — reproduce the strongest baseline(s)
3. Main method stage — run the final method on the primary setting
4. Decision stage — run the decisive ablations for novelty, simplicity, and frontier necessity
5. Polish stage — robustness, qualitative figures, appendix extras

For each milestone, estimate:

• compute cost
• expected turnaround time
• stop / go decision gate
• risk and mitigation

Separate must-run from nice-to-have experiments.

Phase 4.5: Human Checkpoint — Data Synthesis

Honor the HUMAN_CHECKPOINT flag in CLAUDE.md (default: true). This skill is a planning skill, but the plan it writes commits the executor (/deploy-experiment) to specific data — and a few choices in this phase silently authorize generation of that data. When HUMAN_CHECKPOINT is true, PAUSE and request explicit user approval before writing any of the following into EXPERIMENT_PLAN.md; when false, log the choice to output/PROJ_NOTES.md and proceed.

Record approved synthesis decisions in the Risks and Mitigations section of EXPERIMENT_PLAN.md so the executor inherits the rationale.

Phase 5: Write the Outputs

Step 5.1: Write output/EXPERIMENT_PLAN.md

Use this structure:

# Experiment Plan
 
**Problem**: [problem]
**Method Thesis**: [one-sentence thesis]
**Date**: [today]
 
## Claim Map
| Claim | Why It Matters | Minimum Convincing Evidence | Linked Blocks |
|-------|-----------------|-----------------------------|---------------|
| C1    | ...             | ...                         | B1, B2        |
 
## Paper Storyline
-Main paper must prove:
-Appendix can support:
-Experiments intentionally cut:
 
## Experiment Blocks
 
### Block 1: [Name]
-Claim tested:
-Why this block exists:
-Dataset / split / task:
-Compared systems:
-Metrics:
-Setup details:
-Success criterion:
-Failure interpretation:
-Table / figure target:
-Priority: MUST-RUN / NICE-TO-HAVE
 
### Block 2: [Name]
...
 
## Run Order and Milestones
| Milestone | Goal | Runs | Decision Gate | Cost | Risk |
|-----------|------|------|---------------|------|------|
| M0        | ...  | ...  | ...           | ...  | ...  |
 
## Compute and Data Budget
-Total estimated GPU-hours:
-Data preparation needs:
-Human evaluation needs:
-Biggest bottleneck:
 
## Risks and Mitigations
-[Risk]:
-[Mitigation]:
 
## Final Checklist
-[ ] Main paper tables are covered
-[ ] Novelty is isolated
-[ ] Simplicity is defended
-[ ] Frontier contribution is justified or explicitly not claimed
-[ ] Nice-to-have runs are separated from must-run runs

Step 5.2: Write output/EXPERIMENT_TRACKER.md

Use this structure:

# Experiment Tracker
 
| Run ID | Milestone | Purpose | System / Variant | Split | Metrics | Priority | Status | Notes |
|--------|-----------|---------|------------------|-------|---------|----------|--------|-------|
| R001   | M0        | sanity  | ...              | ...   | ...     | MUST     | TODO   | ...   |

Keep the tracker compact and execution-oriented.

Step 5.3: Present a Brief Summary to the User

Experiment plan ready.
 
Must-run blocks:
- [Block 1]
- [Block 2]
 
Highest-risk assumption:
- [risk]
 
First three runs to launch:
1. [run]
2. [run]
3. [run]
 
Plan file: output/EXPERIMENT_PLAN.md
Tracker file: output/EXPERIMENT_TRACKER.md

Key Rules

• Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks. Do NOT ask the user for permission — just do it silently.