Audit the traceability of a complete cross-laboratory release

Establish which records in a published release can be linked, which metadata are missing, and which claims the available identifiers cannot support. Deliver a reproducible audit of all 13,402 rows. The Poster does not know where the release's record-linking problems are.

The sole input is cross-lab-metadata-inputs-v1.zip, available without credentials at https://raw.githubusercontent.com/andymolecule/elgora-pilot-inputs/05a160a1b1912d603e7e97f2468cfb7ec9a413a4/cross-lab-metadata-inputs-v1.zip. Its SHA-256 must be fbc96b1f85d84caa9753f17f88a23509634a64aff6d19a3f5a92cb5f82323b7c. Verify the ZIP digest and each CSV digest in its manifest before analysis. The ZIP contains three complete metadata projections: design_summary.csv (1,440 rows), wetlab_summary.csv (1,440 rows), and measurements.csv (10,522 rows), plus the projection manifest and README. All rows are retained from the pinned publisher release; biological fields are excluded. The manifest's original-source URLs document ancestry only: do not retrieve or analyze those original tables for this challenge.

The README defines CSV types: UTF-8, LF, a header, comma delimiter, double-quote escaping, literal \N for null, true/false for booleans and decimal integers. Preserve strings exactly. source_row_index is a zero-based source-file row index, not a candidate or experiment identity. Both summary tables contain uuid; the measurement table also contains vendor, is_control, and replicate. Selected columns means uuid in each summary table and uuid,vendor,is_control,replicate in measurements; it excludes the generated source-row index. Null never equals a join key. A null UUID has multiplicity zero for linking, with its missing-key reason retained. Duplicate-key membership means all source rows sharing a non-null UUID that occurs more than once within the same table. A repeated UUID is not automatically an error: measurements can contain multiple records for the same UUID. The replicate ordinal is not a unique experiment identifier.

The task concerns record accounting and evidence traceability only. No sequences, target identities, biological response values, candidate selection, assay interpretation or laboratory work are requested or permitted. A source hash proves byte identity, not laboratory authenticity. Matching identifiers do not prove physical sample custody, correct experimentation or independent replication. Source absence or failed retrieval blocks judgment; it does not establish a failed Solver.

1. Every source row. Produce rows.csv with one record per input row, keyed by table,source_row_index, preserving the input fields uuid, vendor, is_control, and replicate exactly (use null for fields absent from that table). Add the UUID multiplicity within each of the three tables. Report source row counts, index continuity, distinct non-null UUID counts, null counts and complete duplicate-key memberships. Never deduplicate the input.
2. Every directed join. For each of the six ordered pairs of different tables, produce one join-ledger record per left row. Include its left identity, complete sorted matching right-row indices, and status: missing_key for a null left UUID, unmatched for zero non-null matches, unique for one or multiple for more than one. Give each status count, left-row denominator, number of distinct matched UUIDs and the full Cartesian-join row count. Do not multiply away or suppress ambiguous matches.
3. Completeness with denominators. For each selected column in each table give null and present counts and fractions. For measurements repeat these counts by vendor, by control marker and by their combination, retaining null as its own group. Provide every observed null-pattern membership across UUID/vendor/control/replicate. Each fraction uses all rows of the relevant table or vendor/control group as its denominator, including rows with null UUID. A zero denominator yields null and an explicit reason, never NaN. Report measurement counts per UUID and vendor with full row memberships; For each summary table separately, group all its distinct non-null UUIDs by the exact set of vendor values in their linked measurement rows. Retain null vendor as a set member and the empty set for UUIDs with no measurements. For each vendor set, report its UUID count, complete UUID list and summary/measurement source-row memberships. This is the vendor-presence distribution; it is not a distribution of vendor counts.
4. Identity limits. Enumerate every observed (uuid,vendor,is_control,replicate) tuple and its complete measurement-row membership, including nulls. Report tuples with multiple rows as metadata collisions, not proof of duplicate experiments. Explain why the omitted experiment identifiers prevent resolving whether such rows represent independent repeats. Give a source-coordinate ledger for all missing-key, unmatched-key and multiple-key cases, and for each observed null pattern. When there are no instances, provide the executed zero count; do not invent defects.
5. Independent reconciliation. Recompute all six directed joins and all selected-column null counts with a second implementation that does not import the primary parser or read its outputs. Reconcile exact identities, membership lists and counts, including an explicit zero-discrepancy result when applicable. Supply both readable implementations. Common standard-library CSV parsing is permitted; record construction and joining logic must be separate.
6. Bounded conclusions. In report.md, link at least one quantified conclusion from each of accounting, joins, completeness and identity limits to an output file and source-row set. Distinguish observed metadata, hypothetical assumptions and facts this projection cannot establish. An accurate finding of no detectable metadata conflict is eligible; it is not evidence that the underlying experiments are valid.

Submit one ZIP, at most 20 MiB compressed and 100 MiB expanded, containing report.md, RUN.md, readable Python source, methods.json, and machine-readable results/ CSV or JSON files. No nested archives, symlinks, source data, downloaded dependencies, private keys or executable binaries. methods.json defines each output's fields, null encoding, ordering and calculation. Every membership uses source-row indices with its table identified. RUN.md specifies one command accepting the verified source ZIP and an empty output directory. Use Python 3.12 standard library only, at most 4 CPU cores, 8 GiB RAM and 10 minutes. Regenerate every result and optional extension from the fixed input; submitted results may not be used as input. Common code and AI assistance are permitted with truthful attribution.

Guardians verify the exact input, safely inspect the code and reproduce all outputs. Counts, keys, strings, nulls and sorted memberships must match exactly; fractions must agree within absolute tolerance 1e-12. JSON duplicate keys, NaN and infinity are invalid. The report's numerical claims must match regenerated outputs. One retry is allowed only for a documented infrastructure interruption. Elgora owns infrastructure and execution safety; Solver files cannot override it.

Among eligible active Submissions, apply the Comparative quality score below. Highest total score wins. Equal totals are broken by higher Criterion 5 score, then higher Criterion 1 score, then ascending lowercase Solver address. After judging the reviewable active Submissions, if none is eligible use no_valid_submission; never use it while required retrieval or verification is blocked. No favorable scientific result is required.

Each criterion has four cumulative levels, worth 5 points each. Award 0, 5, 10, 15 or 20 points, stopping at its first unmet level. These are optional extensions: their omission does not invalidate a correct mandatory baseline. Submitted extensions must still be truthful and reproducible: a false claim, incorrect calculation or failure to reproduce a submitted result makes the Submission ineligible. Merely omitting an optional level earns no points for that level and later levels of its criterion. Identify each extension and its source memberships in methods.json; generate its results under results/quality/. A complete executed zero result earns credit. Writing polish, claimed scores and unsupported interpretations do not.

Criterion 1: Order and partition invariance — 20 points

1. Re-run primary counts and joins after reversing each input table's row order, preserving source indices; compare all canonical results.
2. Repeat after sorting each table by UUID with null last and source index breaking ties.
3. Split each table by even/odd source indices, recombine independently computed key memberships, and compare all six joins with the unsplit result.
4. Supply per-check discrepancy ledgers and exact coverage counts for all three transformations; explain why these checks test software invariance, not independent laboratory confirmation.

Criterion 2: Provider-loss sensitivity — 20 points

1. For every observed non-null vendor, hypothetically exclude that vendor's measurement rows and recompute measurement linkage for every summary UUID.
2. For every exclusion, list each affected UUID's before/after row memberships and vendor sets, retaining newly unmatched UUIDs.
3. Quantify linkage loss: summary UUIDs with at least one measurement before exclusion and none afterward. Remaining coverage counts summary UUIDs with at least one measurement afterward. Report both against all distinct non-null UUIDs of the respective summary table; additionally count the corresponding summary rows against all rows of that table, treating null UUID rows as unmatched. Supply numerator, denominator and fraction for each quantity.
4. Independently reconcile all exclusion results and state that provider loss is hypothetical; no missing measurement is inferred to have failed experimentally.

Criterion 3: Join-policy consequences — 20 points

1. Compare baseline all-match joins with hypothetical first-right-row-only joins for all six directions, choosing the lowest right source index.
2. Report every discarded right membership and the exact Cartesian-row-count reduction.
3. Compare with unique-match-only joins, retaining only left rows with exactly one right match, listing all excluded left identities and reasons.
4. Independently reconcile both policies and explain the information each would conceal; neither policy replaces the mandatory full join.

Criterion 4: Replicate-metadata loss — 20 points

1. On a copy, replace every present measurement replicate ordinal with null and regroup the full observed tuple memberships.
2. Map each original tuple to its transformed tuple and enumerate every merged group with its complete source rows.
3. Quantify the changes in distinct tuple counts and multirow collision counts by vendor and control marker, with denominators.
4. Independently reconcile these changes and explain why a metadata collision cannot establish experimental duplication or independence.

For this score, headline claims include the four required accounting/join/completeness/identity conclusions wherever they appear, plus every quantitative statement in the report's Summary (or equivalent results-summary section) and any Conclusions section if present. A separate Conclusions section is not required. Each must identify its complete contributing source-row set and result references; an explicit whole-table range is valid when every row contributes. Claims elsewhere remain subject to truthfulness and reproducibility.

Criterion 5: Auditable claim package — 20 points

1. Generate a ledger mapping every headline report claim to its result references and complete source-row memberships.
2. Independently validate all referenced files and row identities against the input and outputs; report unresolved references explicitly.
3. Provide a manifest of every regenerated result file's SHA-256 and an independent checker that detects a changed or missing result file.
4. Demonstrate that checker on temporary copies: one changed result, one missing result, and one altered claim reference; preserve the untouched originals and record the three expected detections. These are local software checks, not additional lab evidence.

Guardians record eligibility first, then a five-row scorecard with each last earned level and its evidence, plus the first unmet level. Explain the winner/runner-up distinction without publishing private Submission files. Apply the tie-break only when totals are exactly equal.