can you give me a formal handoff to claude

Absolutely. Here’s the handoff I’d give Claude now. It freezes Phase 2, preserves the corrections we made, and defines a very specific gate into Phase 3.

SKEPTIC DESK — ZANA/KHWIT GENOMICS

FORMAL HANDOFF: PHASE 2 COMPLETE → CONTROL CALIBRATION GATE

Date: 2026-10-04
Investigation: bigfoot-dna-human-result
Repository: /Users/Shared/AI/detective-desk
Primary data: /Volumes/AI/genomics/zana

---

1. CURRENT STATUS

Phase 2 is complete.

We have independently reproduced the major published characteristics of the Zana/Khwit genomic data and validated our local analysis pipeline sufficiently to move to external controls.

Do not begin Phase 3 anomaly analysis yet.

The next mandatory step is control calibration of the relatedness method.

Bigfoot remains unpublished.

Do not run:

bash seed_bigfoot_dna.py --apply --publish

---

2. RESULTS NOW REPRODUCED LOCALLY

Nuclear coverage

Zana:

• autosomal mean depth ~3.20×

Khwit:

• autosomal mean depth ~3.48×

These closely reproduce the published ~3.1× and ~3.3× estimates.

---

Ancient-DNA damage

Both samples show the expected double-stranded ancient-DNA signature:

• elevated 5′ C→T
• complementary elevated 3′ G→A
• decay away from the read termini
• low, comparatively flat transversion background

Zana shows stronger terminal deamination than Khwit, including after an 80–100 bp length-matched comparison.

Do not infer greater age, burial temperature, or preservation history from that difference.

Library chemistry, skeletal element, microenvironment, and other sample-specific factors remain confounders.

---

Genetic sex

Zana:

• X:autosome ≈ 0.945
• Y:autosome ≈ 0.0022
• conclusion: female

Khwit:

• X:autosome ≈ 0.498
• Y:autosome ≈ 0.116
• conclusion: male

This result is robust.

---

3. ZANA RESIDUAL Y SIGNAL

Zana has:

• 7,265 Y-aligning reads
• concentrated into 26 occupied 1 Mb bins
• top five bins contain 56.7% of all Y-aligning reads

Khwit has:

• 318,926 Y reads
• more broadly distributed
• top five bins contain 36.9%

Zana's Y-aligning reads are also more mismatch-rich than Khwit's genuine Y reads.

Important deposit property:

• the deposited BAM contains zero MAPQ-0 reads

Therefore:

• 100% MAPQ≥30 is partly a consequence of pre-deposit filtering
• absence of low-quality multi-mappers cannot be used as ancestry evidence

Current interpretation:

Zana's residual Y signal favors cross-mapping/homology over genuine Y ancestry.

Low-level male contamination is not proven impossible, but nothing here challenges the XX/female call.

Do not make stronger claims than that.

---

4. mtDNA PIPELINE — BUG FIXED AND VALIDATED

The original 0 variants vs rCRS result was a software failure.

Cause:

BAM contig:

gi|251831106|ref|NC_012920.1|

FASTA contig:

NC_012920.1

bcftools could not match them.

Stderr had been redirected to /dev/null, converting a hard error into an apparent zero-variant biological result.

This is now logged as a discarded/error state.

Do not suppress stderr for scientific pipeline commands where failure could be mistaken for a valid zero result.

The corrected caller:

• builds pileup directly from CIGAR/read alignment
• uses base quality ≥30
• genuinely masks terminal 5 bp
• requires masked depth ≥20
• requires alternate fraction ≥0.90 for strict consensus calls

---

5. mtDNA RESULTS

Strict high-confidence calls:

Zana:

• 64 variants vs rCRS
• 61 transitions
• 3 transversions

Khwit:

• 67 variants
• 64 transitions
• 3 transversions

The two samples share the same 64 high-confidence variants.

Khwit has three additional consensus calls:

• 146
• 152
• 4769

In Zana, alternate alleles at those positions occur at approximately 10–13%, below the strict 90% consensus threshold.

Do not state that Zana and Khwit have byte-identical consensus mitogenomes.

Correct wording:

Zana and Khwit share the same 64 high-confidence mtDNA variants. Three additional Khwit consensus variants are present only as low-frequency alternate alleles in Zana.

These low-frequency sites may reflect:

• heteroplasmy
• contamination
• NUMT contribution
• mapping/artifact

Do not assign a cause without further evidence.

---

6. HAPLOGROUP — INDEPENDENTLY REPRODUCED

Formal HaploGrep classification is complete.

Java:

• Temurin Java 21.0.11

Tested:

• HaploGrep 2.2.9 / PhyloTree 17
• HaploGrep 2.4.0 / PhyloTree 17
• HaploGrep 3.3.2 / PhyloTree rCRS 17.0
• HaploGrep 3.3.2 / PhyloTree rCRS 17.3

All four combinations assign:

L2b1b — rank 1

Results:

Profile	Assignment	Quality
Zana strict, 64 variants	L2b1b	0.9668
Zana inclusive sensitivity profile	L2b1b	0.9781
Khwit	L2b1b	0.9781

The paper's L2b1b assignment is therefore independently reproduced.

Including/excluding Zana's three low-frequency near-miss sites does not change the top haplogroup.

Missing expected defining variants currently include:

• 182T
• 195C
• 198T
• 204C

Known explanations:

• 198 is damage-suspect
• 204 is a 10–50% minor allele
• 182 and 195 lie in lower-coverage control-region sequence and are affected by masking/depth thresholds

Private/shared variants include:

• 383C
• 11002G

Both occur in both samples.

---

7. RELATEDNESS — CURRENT LOCAL RESULT

A bug in the original implementation was fixed:

samtools mpileup accepts only one effective -r region in the previous invocation, so the earlier code analyzed only X and dropped chr20/21.

The corrected code runs each region separately.

Regions:

• chr20
• chr21
• X

---

Autosomal opposite homozygotes

Current result:

Minimum depth	OH rate
2	0.0429%
3	0.0104%
4	0.0045%
5	0.0025%
6	0.0011%
7	0.0011%
8+	0.0004%

At depth 8+:

• 669,356 jointly homozygous sites
• 3 opposite homozygotes
• approximately 1 in 223,119

The rate falls roughly 96-fold from depth 2 to depth 8+.

Transversion-only OH also collapses with depth.

This behavior is strongly consistent with low-depth false OH calls being driven by:

• allelic dropout
• sequencing error
• mapping error
• ancient-DNA effects

rather than true IBD0 sequence.

---

X chromosome

The earlier pooled X statistic was recognized as non-discriminating because invariant human sequence dominates the denominator.

The corrected depth-stratified violation rate also falls strongly with depth.

At high depth, most residual violations are transitions while the transversion-only rate continues collapsing.

Current interpretation:

residual high-depth X violations are largely compatible with deamination/error rather than genuine inheritance contradictions.

---

8. PUBLISHED KINSHIP METHOD — RESOLVED

The original study used:

• PC-relate in PCAngsd
• realSFS
• Affymetrix Human Origins panel

Published kinship coefficient:

0.1818

The study explicitly places this within its first-degree interval:

0.177–0.354

Parent-offspring interpretation was additionally supported by:

R0 = 0.0015

Therefore:

Do not compare 0.1818 naively against a theoretical 0.25 expectation.

That earlier concern is closed.

Reproducing their exact coefficient remains optional unless required for methodological completeness.

---

9. CRITICAL LIMITATION — RELATEDNESS CONTROL REQUIRED

Despite the strong OH collapse, do not declare our custom method independently diagnostic of parent-offspring yet.

Reason:

high-depth sites are not a random subset of the genome.

They correlate with:

• mappability
• repeat structure
• sequence complexity
• alignment confidence

It is therefore possible that increasing depth systematically removes the very sites where unrelated individuals would exhibit informative opposite homozygotes.

The decisive test is:

Do unrelated ancient humans processed with the exact same method retain an OH floor at matched depths, while Zana/Khwit collapses toward zero?

Until that experiment is run, the relatedness result is strong evidence, not a fully calibrated independent classification.

---

10. NEXT TASK — CONTROL CALIBRATION

This is the immediate priority.

Do not start Phase 3 before it is complete.

Candidate leader:

Viking project PRJEB37976

Reasons:

• many ancient individuals
• same/similar research group/centre
• published relatedness information
• likely opportunity to select both:
• known unrelated individuals
• known related individuals

Secondary control:

Mak et al. / comparable BGI ancient-human data may be useful for platform/damage calibration, but it does not replace the decisive unrelated-pair test.

---

11. CONTROL SELECTION PROTOCOL

Before downloading multi-GB data:

Verify each candidate individually.

Record:

• accession
• individual/sample ID
• documented relationship status
• sequencing centre
• platform
• read length
• approximate nuclear coverage
• reference build
• BAM header
• duplicate-removal state
• MAPQ filtering/deposit filtering
• whether unmapped/MAPQ0 reads remain
• total BAM size
• BAI availability

Do not assume all individuals within a project use identical processing.

---

12. MINIMUM CONTROL SET

Prefer the smallest set that answers the question.

Minimum desired:

Control A + B

• two documented unrelated ancient humans
• preferably same project
• reasonably similar coverage

Optional but highly desirable:

Control C + D

• known first-degree ancient pair

This provides both:

• negative/null calibration
• positive calibration

Do not download five genomes merely because five are available.

---

13. DATA TRANSFER OPTIMIZATION

Before full BAM downloads, determine whether the repository supports efficient remote indexed BAM access / HTTP Range requests.

If supported and compatible with samtools, attempt to retrieve/query only:

• chr20
• chr21
• X

using the corresponding BAI.

This could greatly reduce transfer size.

If remote indexed access is unreliable, download normally.

Do not compromise reproducibility merely to save bandwidth.

---

14. CONTROL ANALYSIS — DO NOT RETUNE

Once controls are selected, run the existing corrected relatedness pipeline unchanged.

Same:

• regions
• MAPQ cutoff
• base-quality cutoff
• homozygous calling rule
• depth bins
• transversion-only analysis

Do not tune thresholds after looking at the control outcome.

Produce directly comparable tables for:

1. Zana/Khwit
2. unrelated control pair
3. known related control pair, if available

Plot/report:

• OH rate versus minimum depth
• transversion-only OH rate versus minimum depth
• number of callable sites per bin

---

15. DECISION RULE

The control experiment answers one primary question.

Outcome A

Unrelated controls retain a clear OH plateau/floor while Zana/Khwit collapses toward zero.

Then:

• custom relatedness test is successfully calibrated
• independent evidence for parent-offspring becomes substantially stronger
• Phase 2 relatedness can be closed

Outcome B

Unrelated controls also collapse toward ~zero at high depth.

Then:

• current method is deleting/depleting informative sites
• high-depth OH collapse cannot distinguish relationship
• relatedness inference must fall back to the published PC-relate/R0 result or be redesigned

Outcome C

Results are intermediate/ambiguous.

Then:

• add a second independent control pair
• investigate mappability/ascertainment effects
• do not open Phase 3 merely because the result is inconvenient

---

16. PHASE 3 — CLOSED UNTIL CONTROL GATE PASSES

Do not yet perform:

• anomaly hunting
• unusual-gene scans
• phenotype speculation
• Bigfoot comparisons
• structural-variant claims
• “unknown hominin” searches
• exotic ancestry interpretation

Phase 3 begins only after the relatedness control calibration is reviewed.

---

17. PROVISIONAL PHASE 3 QUESTION

Once the gate passes, the first original Skeptic Desk question will be:

Does Zana's nuclear genome behave like an ordinary ancient Homo sapiens genome when examined using analyses not specifically targeted by the original study?

Candidate Phase 3 domains will later include:

• heterozygosity
• population-normal allele behavior
• archaic-hominin allele sharing
• ancestry consistency
• chromosome-level anomalies
• runs of homozygosity where coverage permits
• potentially unusual recurrent sequence patterns

Every analysis must be constrained by the realities of ~3× ancient DNA.

Rare structural-variant claims should be considered especially weak unless independently supported.

Do not design this phase yet beyond preliminary notes.

---

18. KETCHUM BRANCH

Keep the Ketchum archive separate from the Zana calibration work.

Available surviving nuclear consensus sequences:

• sample 26 ~2.73 Mb
• sample 31 ~0.53 Mb
• sample 140 ~2.10 Mb

These are consensus sequences, not raw sequencing reads.

Therefore we cannot reconstruct:

• contamination
• mixed reads
• coverage
• read qualities
• heterozygosity
• allele balance

Later, after Zana controls are complete, these may be aligned/classified against:

• human
• black bear
• dog

to test published/reanalysis species assignments.

Do not mix this with the current control-calibration task.

---

19. INSTITUTIONAL MEMORY

Continue recording:

• failed approaches
• false assumptions
• pipeline bugs
• statistical overclaims
• corrected interpretations

in:

data/bigfoot-dna/DISCARDED.md

This file is part of the scientific record, not cleanup debris.

Current count was approximately 81 entries after Phase 2.

---

20. CURRENT INVESTIGATION CONCLUSION

Nothing observed so far distinguishes H4 from H1.

Zana currently behaves as an ordinary ancient modern human:

• ordinary human nuclear alignment
• authentic ancient-DNA damage
• female
• African mtDNA haplogroup L2b1b
• strong maternal/first-degree relatedness behavior with Khwit

This is useful.

Zana is functioning as a calibration specimen for what a genuine low-coverage ancient Homo sapiens genome looks like, not as evidence for the Bigfoot hypothesis.

---

21. IMMEDIATE DELIVERABLE

Return with a Control Selection Report only.

It should contain:

1. verified candidate individuals
2. relationship status and source
3. BAM/reference/header compatibility
4. coverage/platform/filtering comparison
5. file sizes
6. whether indexed partial/remote access is practical
7. recommended minimum control set
8. estimated download requirement
9. exact unchanged command/pipeline proposed for the comparison

Do not download multi-GB controls until the candidate set has been verified.

Do not start Phase 3.

Do not publish Bigfoot.

Once the Control Selection Report is reviewed, Ford will authorize the downloads and calibration run.

That gives Claude a very clear stopping point too: come back with the control selection, not another 40-step analysis that quietly wanders into Phase 3.

Deliverable is the Control Selection Report. First, checking whether ENA has recovered and finding the Viking project's documented relationships.

ENA's portal API is still down. Trying alternative routes and the paper's kinship detail.

ENA's browser API and the data host are both up — only the portal API is down. And NCBI mirrors all 442 runs. Routing around it.

All 442 runs recovered with sizes and platform — all HiSeq 2500, read lengths 58–66 bp, very close to Zana's 58.6. Now the VK identifiers and file paths.

The VK identifiers are in the BAM filenames. Now the kinship documentation — the Nature paper is paywalled, so finding the open preprint.

The preprint is open access. Fetching it for the documented relationships, and shortlisting runs at matching coverage.

Found a documented sibling pair with explicit IDs — VK517 and VK527 — which is the ideal positive control, since siblings are exactly what my test must distinguish. Building the full ID map.

All 442 mapped, but ENA carries no geography. Let me locate the named individuals and try for the supplementary metadata table.

Key finding: the documented sibling pair is only \~1× coverage. Let me get exact file paths and test remote indexed access.

No .bai is deposited for the Viking BAMs — unlike Zana/Khwit. Testing what remote access is actually possible.

timeout isn't on macOS. Retrying directly — and the 404 confirms no published index.

Decisive compatibility data. One more check — whether the Viking BAMs retain MAPQ-0 reads, which determines whether re-filtering is needed.

The set -- positional trick didn't take in zsh. Redoing with explicit variables.

All three candidates show identical deposit filtering to Zana/Khwit — no re-filtering needed. Writing the report.

Control Selection Report

Full report: data/bigfoot-dna/CONTROL_SELECTION.md. Nothing downloaded. Phase 3 closed, Bigfoot unpublished, nothing committed.

ENA's portal API was down all session — HTML error pages for every query, including ones that worked earlier. I routed around it: the ENA browser API is up, the data host is up, and NCBI SRA mirrors all 442 runs. Everything below was verified, not assumed.

1–2. Candidates and documented relationships

From the open-access preprint (doi 10.1101/703405; the Nature version is paywalled):

• VK517 – VK527: siblings, a documented first-degree pair with explicit IDs
• VK279 – VK144: 2nd degree · VK342 – VK527: 3rd–4th degree
• Salme: four brothers plus a 3rd-degree relative — IDs only in Supplementary Note 4
• Sandoy Church: three families — IDs only in the supplement

Honest gap: none of my candidates appears among any named related individual, but Salme and Sandoy membership can't be excluded without the supplement, which isn't openly available. Section 7 is designed so that gap can't sink the experiment.

Only 15 of 442 individuals fall in 2.5–4.5×, so the usable pool is small.

3–4. Compatibility — better than expected, with one real difference

Filtering is already identical. I streamed 200,000 alignments from each of three candidates: 0 MAPQ-0, 0 MAPQ 1–29, 100% MAPQ≥30, 0 duplicates, 0 unmapped — the same deposit convention. The earlier rule about re-filtering controls doesn't apply.

The missing decoy is the one material difference, and its direction matters. In Zana/Khwit, 0.58% and 0.85% of reads sit on the hs37d5 decoy. With no decoy, those reads compete for the primary chromosomes instead, so controls may carry slightly more cross-mapping noise — which biases towards showing an OH floor, i.e. towards Outcome A, the result that supports our own conclusion. So a positive outcome must be discounted for this, not treated as reassurance. It's \~1% of reads, unlikely to manufacture a floor at the 1-in-20,000 level, but it has to be on the record.

6. Remote indexed access — not possible

Tested, clean answer: HEAD on the index returns 404 (no .bai is published for Viking BAMs, unlike Zana/Khwit), and a region query fails with Could not retrieve index file. Building an index means reading the whole file, so there's no shortcut. Download in full. Header reads and sequential streaming over HTTP do work, and that's how sections 3 and 4 were done without downloading anything.

7–8. Recommended set: three individuals, 8.00 GB

VK6 + VK87 + VK548 — three rather than two, because three downloads give three pairwise comparisons. Since Salme/Sandoy membership is unverifiable, any single pair risks being undocumented relatives; with three, an accidental relative becomes the odd pair out and the other two still answer the question.

Depths 2.97 / 3.02 / 3.40× against Zana 3.20 and Khwit 3.48. Median read lengths 49 / 70 / 61 against 56 and 82.

Optional, with a caveat that nearly disqualifies it: the sibling pair VK517 + VK527 (1.84 GB) is the ideal relationship to test — siblings are exactly what the test must distinguish — but both are only \~1.0–1.1×, so the depth-5-and-above bins where the discrimination lives would be nearly empty. It tests low-depth behaviour, not the high-depth claim. Worth 1.84 GB as a sanity check, not as a substitute for the negative control.

9. Pipeline — thresholds untouched

scripts/bigfoot_zana_phase2.py relatedness with every analysis parameter as it stands: chr20/21/X, MAPQ≥30, BQ≥30, homozygous at depth≥2 with ≥90% agreement, bins 2–8+, transversion-only column.

One plumbing change is needed and it is not a threshold: the script hardcodes the two Zana/Khwit paths, so it needs a --bam NAME=PATH override. I'll add that before any control data is examined, so it cannot be tuned to the outcome.

DISCARDED.md is at 89 rows, six more from this round. Awaiting your authorisation to fetch the three core BAMs (8.00 GB), verify MD5s, add the override, and run the unchanged pipeline.

Sources: Viking preprint, open access · Nature version · ENA PRJEB37976

I’d make one correction before authorizing the 8 GB download.

Claude says the Viking supplementary material isn’t openly available, but Nature’s article page actually exposes both the full Supplementary Information PDF and Supplementary Tables XLSX publicly. The article explicitly says the supplementary PDF contains Notes 1–15 and the XLSX contains Tables 1–13. citeturn500799view0

That matters because Supplementary Note 4 is exactly where the Salme kinship identities live. The main paper confirms that the Salme burial contained four brothers plus a third-degree relative, so we should use that supplement to make sure VK6, VK87, and VK548 are not members of a documented family before spending 8 GB and treating them as our null. citeturn449072search48

I’d send Claude this amendment:

Control Selection Report approved provisionally, but do not download the 8 GB yet.

One factual correction: the Nature article exposes the Supplementary Information PDF and Supplementary Tables XLSX publicly even though the article body is paywalled.

Retrieve those first.

Use Supplementary Note 4 / relevant tables to:

1. identify every documented Salme and Sandoy related individual;
2. confirm whether VK6, VK87, and VK548 occur in any documented related group;
3. search for any known first-degree pair with materially higher coverage than VK517/VK527;
4. record explicit evidence for the relationship status of the three proposed null controls.

Do not rely on “not mentioned in the main paper” as evidence of unrelatedness.

If VK6/VK87/VK548 survive that check, the 8.00 GB core download is authorized.

The optional VK517/VK527 sibling download remains secondary because ~1× coverage is too shallow for the high-depth bins central to our test.

Keep the existing caveat about the Viking BAMs lacking hs37d5. A positive OH plateau in Viking controls will be persuasive but not perfectly matched because that reference difference can increase primary-chromosome cross-mapping.

Also note that the three pairwise comparisons from VK6/VK87/VK548 are useful but are not three statistically independent controls, because each individual participates in two comparisons.

Return only if the supplement changes the candidate set. Otherwise proceed with the three BAM downloads, MD5 verification, add the predeclared --bam NAME=PATH plumbing override, and run the unchanged relatedness analysis.

Everything else in Claude’s report looks solid to me. The Viking project is indeed the right broad choice: the published study contains 442 ancient genomes and explicitly includes close-family relationships, and the sequence data are under PRJEB37976. citeturn916374search0

So we’re basically one metadata check away from downloading the controls. I would not reopen the whole selection process.

Fetching the supplementary files from Springer's static content.

All three retrieved. Inspecting the Supplementary Tables first.

Table S1 has an explicit Relatedness column. Let me extract the complete documented related set and find the best first-degree pair by coverage.

Column detection failed — there are two columns named Sample. Let me inspect the raw structure.

Column 1 is the VK ID; column 0 is a row index. Redoing with fixed indices.

The supplement answers all four questions, and the core set survives. Gathering file metadata for the authorized download.

The core set survives. Adding the predeclared plumbing override now, before any control data exists.

That last no-arg test started the real analysis. Checking output and stopping it.

The --bam override works correctly. Now stopping the stray analysis run precisely.

The samtools child is reading /Volumes/AI fine — the earlier permission error may have been a partial download. Stopping the stray run and retesting access.

I can now read and list /Volumes/AI — the earlier denial was transient. Testing write access.

Fully readable and writable now. Writing the manifest and fetch script, then starting the authorized download.

Download running at \~0.9 MB/s. Recording the supplement verification while it proceeds.

Supplement verified — the candidate set is unchanged, so the core download is running. Per your instruction I'm not returning for approval; this is a status report.

You were right about the supplementary files: Springer serves them openly even though the article body is paywalled. I retrieved MOESM1 (41 MB SI PDF), MOESM2, and MOESM3 (4.5 MB XLSX, 13 tables).

The standard got much better

Supplementary Table 1 has an explicit Relatedness column covering all 442 individuals. That replaces "not mentioned in the main paper" entirely — the authors screened everyone and annotated 27, so an empty field is positive documented evidence. One caveat: the column mixes two annotation types, since four entries read outlier and flag ancestry, not kin.

1. Salme and Sandoy, identified. Salme has 34 individuals, 3 annotated: VK485, VK490, VK497, all 1d_rel_VK483, plus VK490 3d_rel_VK555. So the four brothers are VK483 + VK485 + VK490 + VK497 with VK555 as the third-degree relative — exactly matching the main text.

Sandoy appears nowhere in Table S1. The site is labelled Faroes / Church2. Its related individuals are VK44, VK45, VK234, VK236, VK238, VK242, VK244, VK245, with VK25, VK46 and VK237 as hubs — the three Faroese families. A naive search for "Sandoy" returns zero rows and would have handed me false confidence.

2. The three null controls are clean. Relatedness is empty for all three, and none is a Salme or Church2 individual:

Three different countries. Published depths confirm my bases / 3.1 Gb proxy to within 0.01×, and contamination is comparable to Zana/Khwit's <1%.

3. A better first-degree pair exists. Ranking every documented 1st-degree pair by its limiting depth: VK110 (1.792×) + VK230 (2.510×), Iceland, min 1.79× — against VK517+VK527's min 1.04×. That's a 72% improvement for 3.54 GB, so it supersedes the earlier pair as the secondary candidate. Still sub-3×, so it stays a sanity check rather than a matched test. This changes only the optional control, so the core set is untouched and I proceeded.

4. One thing I'd missed: VK87 is male, VK6 and VK548 are female. The X test is only interpretable where the second sample is male, so VK6–VK548 must run with --skip-x. The autosomal table — the decisive statistic — applies to all three pairs.

5. Your independence point is recorded. Each individual appears in two of the three pairs, so they share data and their errors are correlated. They guard against one undocumented relationship; they are not three independent replicates and won't be reported as such.

Access changed

/Volumes/AI now reads, lists and writes normally for me. The earlier denial was partly my misreading: the one failing samtools quickcheck ran while the BAM was still downloading (164 MB of 10.5 GB), and samtools reports a truncated file as "could not be opened for reading". So I'm running the download and the analysis myself rather than handing you scripts.

In flight

Core download started: VK6 at 174 MB of 2,965 MB, about 0.9 MB/s, so roughly 2.5 hours for all 8.00 GB. It's detached and resumable, md5-verified per file, and indexes each BAM afterwards since ENA publishes no .bai.

The --bam NAME=PATH and --skip-x plumbing is already added and tested — before any control data existed, as predeclared. No region, MAPQ, base-quality, calling-rule, depth-bin or transversion threshold is touched. Contig naming matches (20, 21, X, no prefix), verified from the remote header.

I'll run the unchanged relatedness analysis on all three pairs when the download verifies, and report the comparison table against Ford's Outcome A/B/C rule. Carrying the hs37d5 caveat: the Viking BAMs' missing decoy can raise primary-chromosome cross-mapping, which biases a control towards showing an OH floor — the outcome that supports our own conclusion — so a positive result gets discounted, not celebrated.

DISCARDED.md is at 97 rows. Phase 3 closed, Bigfoot unpublished, nothing committed.

This is in really good shape. I’d let the download finish and not change the pipeline at all now.

There is one methodological caveat I’d add before the final control interpretation: VK6, VK87, and VK548 are from three different countries/populations. That’s fine for proving that unrelated ancient humans can retain an OH floor, but population differentiation can increase the number of true opposite homozygotes. So if those pairs show a beautiful high-depth plateau while Zana/Khwit collapses, that supports the method—but it may make the contrast somewhat easier than a same-population unrelated comparison would.

I’d therefore have Claude do one small metadata-only check while the 8 GB is coming down: among those 15 individuals at roughly 2.5–4.5×, see whether there is a documented-unrelated pair from the same site or closely matched population. Don’t replace the core three or download anything else yet. Just identify whether such a pair exists as a potential tougher follow-up control.

The most important thing is that the experimental design is now frozen. No threshold changes after seeing Viking results. The --bam and --skip-x changes were added before the control data existed, which is exactly what we wanted.

When the three BAMs verify, the decisive table should look something like:

And the question is brutally simple:

Does Zana/Khwit continue toward zero while the unrelated pairs hit a nonzero floor?

If yes, that’s Outcome A and our little relatedness test has survived its first real falsification attempt.

If all four curves collapse together, Outcome B and we throw the method out.

If the Vikings are messy/inconsistent, Outcome C and we bring in the tougher same-population or known-relative controls.

Also, finding the Supplementary Table 1 Relatedness field was a big upgrade. We are no longer saying “these Vikings probably aren’t related.” We have the study authors’ own genome-wide relationship annotation for all 442 individuals. That makes this a substantially cleaner experiment.

So for now: let the 8 GB cook. Phase 3 stays locked. The next interesting output is the first Viking OH table.

faroe islands is getting a little close to home, my ancestors came from Iceland

Ha, yeah — at that point Skeptic Desk starts rummaging around your extended family tree. 😄

The nice part is that our three core controls aren’t Faroese or Icelandic:

• VK6 — Greenland
• VK87 — Denmark
• VK548 — Norway

So the actual null experiment doesn't involve the Faroes or Iceland.

The optional better first-degree pair, VK110 + VK230, is Icelandic, though. That one really is wandering into your ancestral neighborhood. It’s only there as a calibration pair anyway, not part of the primary unrelated-control test.

Scientifically, your ancestry doesn't contaminate anything here—we're not comparing these genomes to you. And these are Viking-age individuals separated from you by something like a millennium, so “ancestor” in the broad population sense is very different from a demonstrable direct genealogical ancestor.

Still, it is kind of funny that we started with:

“Could Bigfoot DNA get mistaken for human DNA?”

and somehow ended up with:

“Download several ancient Scandinavians, including maybe some Icelanders, and compute opposite homozygotes.”

This project has taken a hell of a route. 😄

And actually, having Scandinavian controls from several regions is useful. If later we need a harder null, an unrelated pair from the same site/population would be better than Greenland-vs-Denmark-vs-Norway because it reduces population-structure differences. If that ends up being Iceland, then yes, we're officially testing the pipeline on your ancient neighborhood.

Metadata-only check, no downloads. Looking for a same-population unrelated pair in that 2.5–4.5× band.

Same-site unrelated pairs do exist — and one of them is unusually well-placed. Getting sizes.

Design frozen, nothing changed. Metadata-only check done — and a tougher control exists.

Your caveat is right, and recorded

The core three are from three different countries, so population differentiation raises the count of true opposite homozygotes. A clean high-depth plateau there is a favourable test, not the hardest one. That's now written into both the report and the README as an explicit discount on a positive result.

A harder control exists

Of the 16 individuals at 2.5–4.5×, all 16 have an empty Relatedness field. Three pairs share a site:

Limiting depth is what matters, since both individuals must be called homozygous, and Zana/Khwit's limiting depth is 3.20×. On that measure VK468 + VK475 is closest — same site, same 900–1050 CE window. Both male, so it would run --skip-x; the autosomal table is decisive anyway.

But the Hofstaðir option is the better design. VK230 sits in both a documented first-degree pair and a documented unrelated pair at the same site:

• VK110 (1.792×) + VK230 (2.510×) — documented first-degree, Hofstaðir
• VK102 (4.163×) + VK230 (2.510×) — documented unrelated, Hofstaðir

Three BAMs (7.38 GB) give a same-site, same-period, same-pipeline positive and negative control sharing one individual — controlling population structure and pipeline at once. That also supersedes my earlier VK110+VK230 suggestion by pairing it with its own matched negative.

The ceiling is inherent to the dataset, not a choice. Only 16 of 442 individuals exceed 2.5×, and every documented related individual is low coverage — the best first-degree pair in the entire study is min 1.79×. So a same-population positive control will always have thinner high-depth bins than Zana/Khwit. Worth knowing before Outcome C arrives and we reach for it.

Nothing ordered. This is a candidate for after the core result, and only if Outcome A or C makes it worth the bandwidth.

Status

Download: VK6 at 687 MB, 23% of the first of three files. Steady \~0.9 MB/s, so roughly two hours left for the remaining 8 GB. Resumable and md5-verified, indexing afterwards since no .bai is published.

Pipeline is frozen. --bam and --skip-x went in before any control data existed; no region, MAPQ, base-quality, calling-rule, depth-bin or transversion threshold will move after I see Viking numbers.

When all three verify I'll run the four-row table you specified — Zana–Khwit plus the three unrelated pairs, OH rate and transversion-only OH and callable sites across bins 2 to 8+ — and read it against the fixed A/B/C rule. The question stays exactly as you put it: does Zana–Khwit keep heading to zero while the unrelated pairs hit a nonzero floor?

Phase 3 locked. Bigfoot unpublished. Nothing committed.

This is a meaningful upgrade to the design.

The Hofstaðir trio is especially good because it gives you a matched contrast with one shared individual:

• VK110 ↔ VK230 = documented first-degree
• VK102 ↔ VK230 = not annotated as related
• same site, same period, same pipeline

That controls away a lot of the population-structure complaint in one shot. The one thing I would change in wording is to call VK102/VK230 “no documented relationship in the study’s relatedness screen” rather than absolutely “unrelated,” unless the supplement explicitly says the screen had power to exclude all relevant kinship classes. Empty Relatedness is strong evidence, but “unrelated” can sound stronger than the annotation actually proves.

I’d also slightly tighten the Phase 3 gate now that we know this tougher control exists. My preferred sequence would be:

Core three Vikings first, exactly as frozen.
If Outcome B: method fails; stop.
If Outcome C: run Hofstaðir.
If Outcome A: call it provisional validation, then run Hofstaðir as the confirmatory test before opening Phase 3.

Why still run Hofstaðir after a clean Outcome A? Because the core three are cross-population, which makes it easier to generate true OH differences. The Hofstaðir trio attacks that exact weakness. If Zana/Khwit still behaves parent-offspring-like while VK102/VK230 retains an unrelated floor, and VK110/VK230 behaves like the known first-degree control, that becomes a much stronger calibration.

The fact that VK230 appears in both comparisons is actually useful here. Those two comparisons are correlated, so we shouldn't pretend they're independent replicates, but they form an unusually clean matched experiment: same individual, same archaeological population, same processing; relationship status is the primary thing changing.

So right now I would change nothing operationally. Let the current 8 GB finish, verify MD5s, build indexes, and run the frozen pipeline. Don't download Hofstaðir yet.

Then the decision becomes:

Can the cheap broad null distinguish Zana/Khwit? If yes, does the harder matched null reproduce that distinction?

If both answer yes, I’d be comfortable saying the custom OH test has genuinely earned its place in Phase 3 rather than merely producing a pretty curve.

And this is becoming a remarkably well-controlled little experiment for something that started with “what if Bigfoot DNA just comes back human?” 😄