Parameterised Research Scripts and Config Files

A script with lookback = 60 typed directly into the code works fine for one run. Testing a 90-day lookback means editing the file, and now there are two versions of the script differing by one number, easy to lose track of which produced which result. Parameterisation pulls every number and setting that a researcher might reasonably want to change — lookback windows, universe filters, rebalance frequency, which dataset version to use — out of the code itself and into a separate configuration that gets passed in at run time.

What a config-driven run looks like

Instead of constants buried in the logic, the script accepts a configuration object and a distinct run identifier, and every output — results, logs, plots — gets tagged with exactly which configuration produced it:

$$\text{output} = f(\text{data}, \ \theta), \quad \theta = \{\text{lookback}, \text{universe}, \text{rebalance freq}, \dots\}$$

In words: the same fixed function $f$ — the actual research logic — is run against a bundle of settings $\theta$ that changes from experiment to experiment, and every run's output is saved alongside the exact $\theta$ that generated it, so nothing is ever ambiguous about what produced which number.

Worked example

A researcher testing lookback windows of 20, 60 and 120 days for a momentum signal originally kept three near-duplicate copies of the same script, each with a different hard-coded window, and after two weeks could no longer confirm which copy had produced the results in her notes. Rewritten as one script reading lookback from a config file, the same three tests become three config files (lookback: 20, lookback: 60, lookback: 120) run against one unchanged script, with each run's output directory automatically named after its config. Re-running the 60-day case six months later to check a claim in a research note takes one command instead of reconstructing which of three near-identical scripts had been the right one.

What this means in practice

Keep configs in version control alongside the code, not as loose files on a researcher's laptop — a config is part of the experiment's record, and a result without its config attached cannot be reproduced or audited later.