Every report of Ancient Ancestry, our qpAdm analysis, comes with the numbers needed to argue with it: the p-value, every source's weight, standard error, z-score and 95% confidence interval, the complete right set, and the model record (chi-square, degrees of freedom, SNP counts, every panel label), see The model record explained. The Ancestry Workbench is the next step: the ability to run the argument yourself, on your own merged genome, with real ADMIXTOOLS 2, with or without a report. This guide explains what it is, how to use it well, and what to expect, which is mostly rejections.
What the Workbench is#
The Ancestry Workbench is a self-serve service on a prepaid balance. You top up once, from €9.99, and the balance stays yours: it never expires and never renews. Every completed run draws its own small price from it, and failed runs are never charged. It replaced the earlier per-report unlock on 10 September 2026; if you had bought that, your merged sample is already attached as a kit and your balance carries a credit for it.
It runs three tools on your own merged genome:
- qpAdm, direct. Your sample is always the target; you choose the sources and the outgroups
from the merged panel, and the model runs as
qpadm()from ADMIXTOOLS 2 on the genotypes directly, the same code the published reports use. About €0.004 a run. - Rotation, as a batch of real fits. A pool of candidate sources, two to four sources per model, any population you want pinned into every model, and a right set. Every combination is fitted as its own genotype-direct qpAdm run and ranked passing first. About €0.004 a model, with a €0.04 minimum, up to 1,600 models in one batch.
- Fst distance. Hudson's Fst between your genotypes and every population in the panel, ranked closest first; the closest 500 are listed, each with the number of samples behind its figure. It needs no merge, so it is usable seconds after the kit is received. About €0.004 a scan.
Every Ready kit also includes the merged dataset itself, the exact EIGENSTRAT bundle (.geno,
.snp, .ind) your genome was merged into, so everything can be reproduced on your own machine.
What the Workbench is not: a way to change the result Ancestrify published. A report keeps opening
on Ancestrify's version; the Workbench is a bench beside it. If you want one of your own models in
the report, you can add it as a separate Customer model version for €5 from your balance, sealed as
yours.
Preparing a kit#
A kit is one raw-data export from 23andMe, AncestryDNA, FamilyTreeDNA, MyHeritage or LivingDNA. The Workbench converts it, filters it of indels and strand-ambiguous markers, and merges it into AADR v66 with Poseidon's trident; the kit card shows each stage as it happens, Received, Converting, Merging and Ready, and preparing a kit holds about €0.49 of the balance when you add it and draws it only when the kit is Ready. If you already have a completed Ancient Ancestry report, its sample attaches as a kit for free: the merge was done for the report and the bundle is archived. Whole-genome sequencing VCFs are not accepted as kits yet.
Why it exists#
Two reasons. The first is verifiability: a qpAdm result you cannot re-run is a claim, and one you can is a finding. The second is education: nothing teaches how a model works like watching it fail. Run a model with an outgroup that is too close to a source and watch the p-value collapse; swap one steppe proxy for another and watch the weights move; remove a source with a small z-score and see the nested model pass. An hour on the bench does more for your reading of the report than any explainer, including How to read qpAdm results, which you should nonetheless read first.
Before your first run#
If you have a published model, read it. Note its sources, its right set and its p-value. That model cleared the publish bar and was approved by a person; your first job is not to beat it but to understand it. Then read Understanding qpAdm for what the right set does, because that is where most of your runs will go wrong. If you have no report, start with the Fst scan: the closest populations are a sensible first pool of candidate sources.
Choosing sources#
Sources are the populations you propose the target descends from. Rules that save runs:
- Stay in one era. A model mixing a Mesolithic source with a Roman-period one asks the method to treat a later, already-mixed population as an ancestor of an earlier structure, and it will usually, correctly, reject it.
- Keep sources distinct. Two closely related sources produce two large standard errors and weights that trade off arbitrarily. If you want to know whether a finer split is resolvable, try it, but expect the answer to be no on most files.
- Start with two or three. Adding sources improves fit mechanically. A three-way model that passes is not evidence that a four-way model is needed.
- Respect chronology. A source that postdates the target cannot be its ancestor, however good the fit.
The curated source populations, each with its own page, are in the ancestry population directory.
Choosing outgroups#
The right set gives the method its power to tell sources apart, and it is where a model is won or lost. A good right set is distant from every source, diverse enough to distinguish them, and large enough to have power; a dozen populations is typical in the literature. If you have a published model, start from its right set: it was chosen to make its sources distinguishable and is a sound base for variations.
Two failure modes to recognise in your results. A right set that is too small or too close to the sources lets almost anything pass; a p-value of 0.9 against six weak outgroups is not a strong result. A right set containing a population that shares recent drift with one source rejects good models as readily as it accepts bad ones.
Reading a run#
Read in this order, every time: p-value, then standard errors, then z-scores, then weights.
- p below 0.05: rejected. Do not read the weights. Check the right set and chronology first, then try a simpler model.
- p above 0.05: admissible, meaning not refuted. Now the standard errors: a weight smaller than twice its SE is not a percentage you can repeat. Then z-scores: a source with |Z| below about 2 is not measurably contributing.
- Only then the weights, as properties of this model against this right set.
Then run the nested model, the same sources minus the weakest one. If it passes, the weakest source was not earning its place. This is the single most useful habit the bench teaches.
What a rotation is for, and what it is not#
A rotation fits every combination of a candidate pool and ranks the rows passing first (p above 0.05 and every weight above zero), then by p-value. Every row is a genotype-direct qpAdm run, so there is no screening step to confirm afterwards. What it is not is an answer. Trying combinations until one passes is the practice that Harney and colleagues (2021) showed produces confident wrong answers. In the paid analysis an automated search can propose candidate models, but it cannot publish one: a person reviews the candidates and approves every published model. The audit literature's lesson is that a search's error rate depends mostly on how plausible its candidates were before testing, not on whether a script or a person ran it, so the paid analysis chooses its candidate sources for the customer's declared origins before any model runs, and the same habit serves you here: choose the pool before you run it. The Workbench gives you the rotation anyway and labels the results as what they are: your own hypotheses, not our published finding. Read the grid as a map of what the data tolerate. Then take the two or three rows that survive your own scrutiny, chronology, distinct sources, a defensible right set, and run their nested models one at a time. If you find a model that clears the bar and seems better than a published one, that is genuinely interesting, and it is the kind of thing that, when we find it ourselves on revisiting a report, is published as a second version for €15 with the original left exactly as it was.
Working offline with the EIGENSTRAT bundle#
The download gives you the merged panel itself: your genotypes and the ancient reference at the same positions, in the format ADMIXTOOLS 2 reads natively. With it you can run anything the package offers, qpWave, f3, f4, qpGraph, on your own hardware, with no run limit and no dependence on us. Installing ADMIXTOOLS 2 is an R package install; Maier and colleagues (2023) describe the package. The bundle is the strongest form of verifiability we can offer: not "trust the report", but "here is everything needed to check it". Its lightweight companion is a report's own model record, which needs no Workbench at all: every panel label, outgroup and count of the published model on one screen, so the bundle and the record together reproduce the model exactly.
What the Workbench is not#
It does not run qpWave, f3 or f4 against your sample on our servers; those remain part of the operator's published workflow. It does not change Ancestrify's version of a published report; your own model joins one only as a separate Customer model version you choose to add. And it does not make any population your ancestor: a source in your best model is a statistical proxy, and a passing model is one the data did not refute. The free AdmixTools 2 Lab offers the same methods over the public reference panel without a purchase, if you want to learn the workflow before preparing a kit of your own. The Ancient Ancestry page covers the person-approved report the bench sits beside; the terms are in the glossary.
References#
- Flegontova, O. et al. (2025). Performance of qpAdm-based screens for genetic admixture on graph-shaped histories and stepping stone landscapes. Genetics, 230(1), iyaf047.
- Harney, É., Patterson, N., Reich, D. & Wakeley, J. (2021). Assessing the performance of qpAdm: a statistical tool for studying population admixture. Genetics, 217(4), iyaa045.
- Maier, R. et al. (2023). On the limits of fitting complex models of population history to f-statistics. eLife, 12, e85492.
- Patterson, N. et al. (2012). Ancient admixture in human history. Genetics, 192(3), 1065–1093.
