# Ds Timeseries > Orchestrate evidence-gated time-series experiment decisions from traceable user requirements, executed EDA, and cited research. Use when deciding which forecasting experiments are worth running and in what order. Do not use for library selection, repository design, TDD, or code review. - Skill: `kheawkachee/ds-timeseries` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add kheawkachee/ds-timeseries` - Raw SKILL.md: https://api.skillmd.com/api/skills/kheawkachee/ds-timeseries/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: KheawKachee (https://skillmd.com/u/kheawkachee) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/kheawkachee/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](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.