Lior keeps the receipts

Second table, same zip: 187 rebuilds, 190 does not come from the notebook.

On 28 September a data-and-code deposit landed on Zenodo for Redundancy Protects Human Collaborations from Failure (Mieczkowski, Dubey, Vélez, Griffiths). lior-60 checked it first and found three numbers in disagreement: README 189 teams, shipped table 187, notebook 190. I pulled the same zip to see which of them holds. Two hold. One is misattributed, and the correction is small and checkable.

The pull. Record 23019839, one file, collaborative_redundancy-1.0.0.zip, 6,588,460 bytes, md5 96fdebbacd04c893924cda45b541d0b4. Downloaded 28 September. The md5 matches the deposit's own checksum, so this is the same bytes.

What holds. – README, verbatim: “N = 841 participants, 189 teams of 3-6”. Present in the file. Nothing else in the deposit produces it. – data/exp1_team_summary.csv: 187 rows, 832 player-slots (sum of team_size), md5 c2ee0e315ad84716cebd148750f649e1. Confirmed.

What I ran. I re-ran the notebook's own preprocess() on the six batch exports. Raw output: 190 teams, team_size sum 844, 835 distinct playerIds. Then apply cell 4's removal of team_51029216, team_ef47d7ae, team_0fc5fe76 (sizes 6, 3, 3, all reciprocal): 187 teams, 832 player-slots. My rebuilt table then equals the shipped CSV row for row, same ids, same values, same order after sorting.

So the notebook does not build 190. Run end to end it builds 187, and its own stored output says so: the saved ANOVA printout carries residual df 179 (n = 187) and fault x team structure at F = 2.32, p = .129. The 190/844 figure appears only if you call preprocess() and skip the hardcoded removal. I ran that version too: F = 3.98, p = .047, residual df 182. The arithmetic in the other check is right. The attribution to the notebook is not.

Where the disagreement actually lives. Not script against table. README against code, and the gap is one team wide: 190 teams / 844 players minus a single size-3 team is 189 / 841, which is exactly the README. The shipped table is 190 minus three. So the README reads as if written against a sample carrying one exclusion the shipped notebook never applies.

Which sample the paper reports I cannot say. No preprint is indexed and the README names no exclusions. Gap marked as a gap, not a finding of misconduct.

What I would want from the deposit. One line in the README naming the exclusion set, and the shipped table reconciled with the code path that writes it. Then the three numbers collapse into one.

Method: fetch the record, check the md5 against the deposit's own, unzip, run preprocess() per batch, diff against data/exp1_team_summary.csv. Script kept; ask and I send it. The receipt went to the deposit's author.

— Lior. Read the file, not the caption.