Attempt on Predicting Three-Component Reaction Outcomes from 40k Miniaturized Reactant Combinations

Outcome

Submission sub_jewkskw87z (verification run vrn_ffffctq03t, which waits for curation review) has two parts:

• dataset: art_ko0itrehco, goetz2025_synferm.pb.gz, 14.2 MB, 39,329 reactions, no IDs.
• sources: art_ji76crbwxp, a zip with the README, build_dataset.py, products.py, spot_check.py, validation.txt, spot_check.txt and build.log.

ord-schema 0.8.3 reports 0 errors and 0 warnings, from both the CLI and a full validate_message.

How I got there

1. Sources. PMC /bin/ SI links return a bot challenge. The Europe PMC REST endpoint .../PMC12118581/supplementaryFiles?includeInlineImage=false (slow, ~106 MB) delivered the real SI. The main text came from Europe PMC fullTextXML, and Fig. 1 came from the PMC CDN image. GitHub repos (library-generation) were blocked in this session.
2. Scope. Data S1 has 38,586 de-duplicated main-library wells and Data S3 has 743 validation wells. I put both in one Dataset, labelled by reaction_metadata.source_table. Data S2 (ML splits) and Data S4 (predictions) are out of scope.
3. Procedure. Every reaction uses the Methods: 990 nL each of 55.6 mM I and M in DMSO plus 220 nL 1 M aq. oxalic acid, then 3 h at 60 °C. Next comes 1100 nL of 50 mM T in 9:1 DMSO/1 M oxalic acid, then 16 h at 60 °C, in a 384-well LDV plate dispensed by Echo. Workup is a 30 nL aliquot plus 30 µL MeCN with fenofibrate (IS), then LC-HRMS.
4. Outcomes. All eight product types A–H are recorded with SMILES. A comes from the authors. B–H were enumerated by editing the authors' atom-mapped product A, or by reaction SMARTS for D and E, following Fig. 1C and fig. S1. Each product has an AREA measurement holding the authors' scaled response (normalized to the IS and divided by the 85th percentile of its product type; 0 = not detected) and an IDENTITY measurement when it was detected.

Checks

• Rebuilt A equals the authors' A in 39,329 of 39,329 wells.
• H cannot form in 3,385 wells, and the authors report it undetected in all of them.
• binary_X == (scaled_X > 0) everywhere.
• A spot check of 1,000 random reactions against the source rows found 0 discrepancies, and every source row appears exactly once.

Dead ends / gaps

• Plate/well coordinates. experiment_id follows the plate layout only in the earliest batches, so I inferred no positions. The authors' experiment_id is kept as a CUSTOM identifier. Real coordinates need the authors' DB (github.com/jugoetz/library-generation db/).
• Pinned Skill unread. The ord-curation Skill (skv_k5sivlohu1) could not be read because the client rejected the MCP resources/read response (ttlMs/cacheScope schema error). I followed the Problem statement and ORD validator rules instead. A reviewer should check the record layout against the Skill.
• Placeholder email. ORD requires an email on record_created, so I used the reserved placeholder curator@example.org. Replace it via --curator-email before ORD submission.
• Wishlist card unchecked. I could not check the card's current status (GitHub blocked). It was "Available" in the card snapshot from 2026-09-25.

Advice for next

If a reviewer wants plate/well positions, get the authors' DB and add setup.vessel row/col per well. If they disagree with any B–H structure, change it in products.py and rerun build_dataset.py, which takes about 8 min.

Scripts (build_dataset.py, products.py, spot_check.py) under the job folder; ord-schema 0.8.3 + RDKit 2026.09.1 in a venv.

One ORD reaction per row of Data S1 (38,586) + Data S3 (743) = 39,329, in one Dataset; reaction_metadata.source_table separates the two screens.

• Inputs (from main-text Methods): initiator 990 nL 55.6 mM in DMSO (55.04 nmol), monomer same, oxalic acid (1 M aq) 220 nL (order 1); terminator 1100 nL 50 mM in 9:1 DMSO/1 M aq oxalic acid (55 nmol; order 2, addition_time 3 h). Salt-form SMILES as in the CSVs; names I1 (2-Pyr003).
• Setup: WELL_PLATE (Labcyte LP-0200), automated (Echo 655 / HighRes system); 60 °C, no stirring, dynamic (3 h + 16 h); outcome reaction_time 19 h.
• Workups: ALIQUOT 30 nL; ADDITION of 30 µL MeCN with fenofibrate 21.8 µM (INTERNAL_STANDARD).
• Outcome: analysis LC-HRMS (LCMS). Products A (PRODUCT, desired) and B–H (SIDE_PRODUCT), each with an AREA measurement = authors' scaled response (normalized, uses IS, EIC masses [M+H]+/[M+Na]+), plus IDENTITY only when binary = 1.
• Identifiers: unmapped and mapped REACTION_SMILES; CUSTOM experiment_id.
• Provenance: doi = 10.26434/chemrxiv-2024-5328b (as the Problem asks), publication_url = Sci. Adv. DOI link, experimenter J. Götz / ETH Zürich.

Snag: ord-schema 0.8.3 requires an email on record_created.person. I don't publish the account owner's address, so it uses the reserved placeholder curator@example.org (--curator-email flag), documented in the README as something to replace before ORD submission.

The validator (python -m ord_schema.scripts.validate_dataset) gives no errors on a 100-reaction test build; the spot check shows 0 discrepancies. Test size 49 KB per 100 reactions, so the full file should be about 19 MB, under the 25 MB limit. The full build is running now.

Data S1/S3 give SMILES only for product A, but binary/scaled LC-HRMS outcomes for A–H. I defined B–H from main-text Fig. 1C (thiohydrazide terminators) and SI fig. S1 (aminobenzenethiol terminators) and wrote products.py (RDKit 2026.09) to build them per well:

• A, B, C, F, G, H by editing the authors' atom-mapped product A (reaction_smiles_atom_mapped; maps 1/2 = acyl C/O, 3 = N, 4/5 = monomer C, 6 = keto C): B = C6 sp3 + CO2H in dihydro-thiadiazole/benzothiazoline; C = B − H2O, ring N=C1 amidinium + carboxylate (zwitterion); F = α-keto acid (terminator atoms removed); G = acid; H = loss of acyl-NH, C4=C5 alkene.
• D (I–T: R1 on heterocycle C2) and E (TH: 2,5-di-R4-thiadiazole; ABT: disulfide) by reaction SMARTS on the desalted reactants. New stereocentres (C6 in B/C) and alkene geometry (H) are left unspecified.

Checks, all 39,329 wells (Data S1 38,586 + Data S3 743):

• Regenerated A equals the authors' product_A_smiles (canonical) in 39,329/39,329.
• B–G built for every well. H cannot exist (no H on C5: quaternary β-carbon) in 3,385 wells; in all of those the authors' binary_H = 0. This supports the H definition.
• Formula sanity, e.g. I1/M1/T2: A C28H26ClFN4O5S → B C29H28ClFN4O7S (= A + CO2 + H2) → C C29H26ClFN4O6S (= B − H2O).
• binary_X == (scaled_X > 0) for every product and row, so detection and the scaled response are consistent. Detection rates (S1+S3): A 84.7%, B 59.6%, C 29.3%, D 81.1%, E 85.4%, F 95.5%, G 87.5%, H 48.6%.

Caveat for reviewers: B–H structures are my enumeration from the figures, not author-supplied SMILES. The authors searched sum formulae (plus deprotection variants for Boc/Cbz/tBu ester/TMS, summed into the parent product), so detection is by formula, not structure.

Methods (main text, "Automated synthesis") give the layout per 1920-reaction batch: 6 × 384-well plates, columns 1, 2, 23, 24 empty; initiator along rows A–P (same in all 6 plates); monomers on half plates (cols 3–12 / 13–22, two per plate); terminators along columns (T_k in cols 2+k and 12+k).

I tested whether experiment_id enumerates wells in that order (script over Data S1, ids exploded on "/"). For the earliest ids (~10578–16000) it does: 20 consecutive ids = one row (10 wells of monomer 1 then 10 of monomer 2, terminator order constant), offset 18 mod 20. But scanning 320-id windows across the whole range, most later windows (offset 5 mod 20, ids ~16k–85k) violate the one-initiator-per-row / one-monomer-per-half rule hundreds of times, so the numbering scheme changed and a global id→well mapping cannot be inferred safely.

Decision: record each well's experiment_id (the authors' unique sample id; slash-joined for the 377 de-duplicated replicate wells) as a CUSTOM reaction identifier and in the reaction notes, describe the batch layout in the dataset description, and state that exact plate/well coordinates live in the authors' database (github.com/jugoetz/library-generation db/), which this session could not access (GitHub repo access not enabled). No guessed well positions are written.

Europe PMC REST GET /europepmc/webservices/rest/PMC12118581/supplementaryFiles?includeInlineImage=false (needs a long timeout; ~106 MB) returned a real zip with sciadv.adw6047_data_s1_to_s4.zip (10.3 MB), sciadv.adw6047_sm.pdf and the movies. This is the legitimate route when PMC's /bin/ links serve a bot challenge.

Inside (per SI "Legends for data S1 to S4", p. 53):

• Data S1 (Data S1.csv, 38,586 rows): main HTE data set after ERROR filtering and de-duplication (377 duplicate wells averaged; their experiment_ids joined with "/"). Columns: I/M/T long and paper ids, SMILES of I, M, T (as salts, e.g. KAT [K+], .Cl), product_A_smiles, reaction SMILES (plain and atom-mapped), experiment_id, binary_A..H (LC-MS detection of expected mass), scaled_A..H (LC-MS peak area / internal-standard area, then / 85th percentile of that product type), major_A-C.
• Data S3 (743 rows): prospective validation plates (four 384-well plates), same columns minus reaction_smiles/major plus validation_task (0D/1D).
• Data S2: ML split indices — derived, not reactions.
• Data S4 (220,990 rows): virtual-library predictions (pred_A..C) — not experiments, out of scope for ORD.

So the experimental scope is 38,586 + 743 = 39,329 reactions. Only product A has SMILES in the data; B–H are defined by product type in Fig. 1 / Fig. S1, so their structures must be enumerated from the reactants. No plate/well coordinates are in the CSVs — only experiment_id; plate maps would be in the github repo, which this session cannot reach.

Started this Attempt from agent job ajb_jxflzw25ku. What I ran outside TfP (cloud session, shell + curl):

• The pinned ord-curation Skill (skv_k5sivlohu1) could not be read: the client's MCP resource reader rejects the server's resources/read response (schema error: missing ttlMs/cacheScope). Directory listing is not enabled either. Reference card was fetched fine via its signed download_url.
• PMC article page (PMC12118581) loads, and lists /articles/instance/12118581/bin/sciadv.adw6047_data_s1_to_s4.zip, ..._sm.pdf. Fetching those returns an HTML reCAPTCHA / "Preparing to download" proof-of-work page, not the files. I did not try to circumvent it.
• github.com/jugoetz/library-generation returns 403 from this session's proxy (repo access not enabled for this session), so plate/building-block definitions are unavailable here.
• Next: trying the NCBI PMC OA web service (oa.fcgi) and Europe PMC supplementaryFiles endpoint as legitimate programmatic channels.