Ds Timeseries

Time-Series Experiment Decisions

Decide the experiment program, not the software stack. Own the iterative path from the user's decision to a traceable experiment decision record. A new model, feature, fine-tuning run, ensemble, or MoE is not justified merely because it is available.

Read references/artifact-contracts.md before creating or evaluating any workflow artifact.

Required Artifacts

Use repository conventions when they already define authoritative locations. Otherwise use these files at the repository root:

1. user_requirements.md
2. eda_findings.md
3. research_findings.md
4. experiment_decision_record.md

The first three are gates. Never create or update experiment_decision_record.md unless all three declare status: ready and actually satisfy their quality gates. A status label without supporting content does not pass.

If a gate fails, state the failed gate and work only on the missing or stale prerequisite. Refuse requests to skip a gate or speculate about the experiment portfolio early.

Non-Linear Workflow

Start by reading repository instructions, existing requirements, notebooks, findings, research, and decision records. Then take the next valid action; do not force a fixed pass through all stages.

1. Requirements gate

Clarify the user's intended decision and save it in user_requirements.md. Build the chain evidence -> observed problem -> user need -> requirement -> validation with stable IDs and source references.

The gate is ready only when the intended decision, target, prediction grain, time boundary or forecast origin, horizon, success measures, error asymmetry, and material constraints are confirmed. User needs must remain solution-agnostic. Requirements must be measurable. Keep assumptions separate from validated evidence, and leave no blocking question that could change the contract.

Do not start research directions or EDA objectives whose meaning depends on an unresolved blocking requirement.

2. EDA gate

After the requirements gate is ready, invoke $ds-eda to derive EDA objectives from requirement IDs. Each objective must state the decision it can change, grain, population, metric, and intended evidence.

Request only the investigation families the requirements need: semantic and target EDA, panel and modeling-readiness EDA, or diagnosis of completed experiments. Completed-experiment EDA may establish the observed winner under a declared comparison and locate its failure mechanism. It must not choose the next experiment; that decision remains behind this skill's final gate.

When Plan mode is active, inspect the repository and produce a decision-complete notebook implementation and execution plan. Do not write or run the notebook until execution is allowed. Outside Plan mode, reuse the repository's existing notebook source and execution conventions, implement the agreed investigations, run the notebook, and extract the resulting evidence into eda_findings.md.

The EDA gate is ready only after a clean execution covers every relevant risk among semantics, time, demand shape, sparsity or cold start, feature availability, events, population coverage, and leakage. Trace REQ-* -> EDA-OBJ-* -> EDA-F-*. A notebook outline, profile report, or unexecuted notebook does not pass.

When completed experiments are analyzed, the EDA gate also requires comparable targets, grains, cutoffs, horizons, entity populations, and split roles. Use held-out evidence for headline findings, keep selection or all-fold evidence diagnostic, compare methods on a common grid, report native coverage separately, and label oracle, replay, optimistic, and post-hoc evidence as non-deployable.

3. Research gate

Once requirements are ready, derive RES-Q-* questions from requirement IDs and, when available, EDA gaps. Route those questions to /deep-research; this skill does not perform or silently substitute its own literature review.

Save the cited results in research_findings.md. Each RES-F-* finding must state applicability to the observed task and data shape, limitations, maturity, cost constraints, and its model-family implication. If /deep-research is not available, report the research gate as blocked rather than inventing current method claims.

Research may begin while EDA is incomplete, but later EDA evidence can make a research direction stale. Reopen only the affected questions.

4. Experiment decision gate

Only after the requirements, EDA, and research gates pass, write experiment_decision_record.md.

Start with the cheapest valid baseline, then add family-level challengers whose eligibility follows from the evidence. Examples of family-level choices include local statistical, global recursive tree, zero-shot time-series foundation model, fine-tuned foundation model, covariate ablation, ensemble, or MoE. These are examples, not a mandatory ladder.

For every proposed experiment record:

• supporting REQ-*, EDA-F-*, and RES-F-* IDs;
• hypothesis and why the experiment is worth its cost;
• conceptual data flow and fair comparison contract;
• expected learning even if it loses;
• promotion criterion and stop rule;
• important risks or prerequisites.

Also record rejected and deferred ideas with evidence. Recommend a conceptual experimental pipeline, not packages, modules, APIs, or repository refactors.

Invalidation Rules

The workflow is a loop, not a waterfall:

• A material change to target, grain, population, origin, horizon, metric, or constraints makes affected EDA, research, and experiment decisions stale.
• New EDA evidence may add or revise requirements. Preserve the old item and record the reason; do not silently rewrite history.
• New EDA evidence invalidates only the research questions and experiment decisions it affects.
• Research may request another targeted EDA check. Return to the EDA gate and rerun the relevant notebook section before proceeding.
• Never call a downstream artifact ready while one of its cited inputs is missing, stale, or blocked.

Scope Boundary

Reject a request whose primary job is package or library selection, production pipeline design, repository refactoring, performance engineering, TDD, or code review. State the mismatch and the appropriate handoff. For a mixed request, complete only the experiment-decision portion and identify the excluded work.

Do not browse package documentation, prescribe execution commands, or own implementation mechanics merely because an experiment will eventually require them.