Verification

Every module begins by checking the project against the record the pipeline left beside the results, and refuses before any compute if the two disagree.

What it refuses

The results on disk were produced under a configuration, and the pipeline recorded that configuration beside them. A module reads the tables and the settings together — pool sizes, ploidy and the filter thresholds all decide what a frequency means — so a project that has moved on since is refused, naming what moved:

• parameters.config has changed. The report lists each parameter, what was recorded and what it says now, and points at run_parameters.txt beside your results for the values that produced them. Paths and resources are not compared; they cannot change a number.
• The run table has changed. Which runs share a directory is decided by that table, so an edit can move a run onto results belonging to somebody else.
• The results came from another release. What a table holds and what its columns mean belong to the release that wrote it. Install that release's analysis layer, or produce the results again.

Restoring the values, or PoolSeqFlow reset and a fresh run, are the two ways forward. Nothing is deleted for you.

The pools your results were filtered against

A frequency in a published table is read against how many chromosomes the pool holds, so the report states that before any module reads one:

POOL SIZES:            Output
POOL SIZES:                ploidy 2, 6 pools of 100 individuals - 200 chromosomes, frequencies above 0.0025

Those are the pipeline's own poolSize and ploidy, per pool: a pool whose rows set param_poolSize holds that many individuals and every other pool holds poolSize of them. The chromosome count is ploidy × poolSize, and the detection limit is 1 / (2 × ploidy × poolSize) — the frequency below which step 7's false-positive filter took a call to be error rather than a rare allele, explained in The Filter Chain. Pools of one size share a line; a pool of its own size gets one, because its chromosome count and its detection limit both move with it.

Runs that hold a pool to different sizes never share a results directory. poolSize, param_poolSize and ploidy are all part of what decides whether two runs share step 7's work (Multi-run), so each run's tables are filtered against its own sizes and land under its own name. The analysis layer checks the sizes across a directory's runs regardless, and stops if it ever finds two: a directory whose tables were filtered against two different pool sizes has no answer to what a frequency in it means.