2026-09-21 — Enveda CASMI26: G1 ablation, baseline lock, PubChem rebuild, Phase 4 launch

G1 Ablation (300 identities) — COMPLETE

16 settings tested (4 mass windows × 4 candidate caps), dev folds 1-4

Best: 20 ppm uncapped — MRR@25 = 0.8708, top1 = 0.8467, coverage = 0.90

Paired bootstrap 10 vs 20 ppm: +0.0283 MRR, 95% CI [+0.010, +0.050], p = 0.0016 — significant

cap=100 consistently harmful (~0.09 MRR loss at every window); caps ≥1000 never bind

30 ppm marginally better (0.8797) but 50% more candidate rows — not worth it

Runtime: 1316s, exit 0

Report: reports/g1-ablation-mass-window-cap-20260921-scale300/results.json

Retrieval Baseline Locked

Manifest: manifests/retrieval-baseline-locked-20260921.json

Config: 20 ppm, uncapped, cosine_similarity (tolerance 0.01 Da), top-1000 candidates

Peak cleaning: min_intensity 1e-4, top_n 200, precursor exclusion 1.5 Da

10 bound files, all 10 SHA-256 hashes verified

Fold policy: dev folds 1-4 for tuning, fold 0 frozen as report partition

PubChem Provenance Recovery

Archive SHA-256 verified (re-hashed SDF, matches e025a0d2...)

Recovered: upstream URL (ftp.ncbi.nlm.nih.gov CURRENT-Full), CC0 license, download date 2026-09-16

Gap 1 FIXED: derivation scripts committed to git (commit 8020971, 6 files)

Gap 2 FIXED: production index rebuilt from full 444,792-row pool → 424,291 unique identities (was 231,749)

Output: artifacts/phase3a/pubchem-structure-index-rebuilt-20260921.sqlite (131MB)

CC's Strategic Call: Kill the Lookup Path

CC said: "I don't want to keep going on lookup table way, it seems not realistic"

Evidence backed this up: CID 1-500k = 0.42% of PubChem's 120M compounds; only 4.5% of training identities found in slice

Decision: pivot to spectrum→SMILES generation (Phase 4), stop investing in structure databases

Retrieval baseline kept for Class 1 (spectral analogues) — MRR 0.87 is genuinely strong

Phase 4: Spectrum→SMILES Transformer — LAUNCHED ON KAGGLE

Read the official de novo tutorial (915 lines): PeakEmbedder + SpectrumEncoder + SmilesDecoder

Wrote kaggle-kernel/phase4-denovo/phase4_train.py (~27KB)

Key improvements over tutorial:

- Molecule-grouped 5-fold split (fold 0 held out) instead of random split

- Beam search (width 25) instead of temperature sampling — better for MRR@25

- In-script fold computation via blake2b (verified: 275,810/275,810 identities match local manifest)

- Filters out enveda-180 ingest lib (same as tutorial)

- 512-dim model (vs tutorial's 768) to fit T4 comfortably

First push failed: root path resolved to / on Kaggle, fold manifest not found

Fixed: replaced load_folds() with in-script compute_fold() using same blake2b algorithm as src/split_manifest.py

Second push succeeded: kernel v2, jamesl8/enveda-casmi26-phase-4-de-novo-train

Kernel status: RUNNING on Kaggle GPU at time of writing

CC explicitly said: do not run training locally (ARM CPU-only host)

Status check automation

Created: "Phase 4 Kaggle kernel status check" (every 20 min)

Job ID: 27497326-4080-46be-aba8-ca88cda2cc89

Will download output on COMPLETE, diagnose on ERROR, report to CC

Notes

Gateway restarted multiple times during this session (~23:12, ~23:14)

Got stuck in a status-check loop during restarts — broke out, verified all work intact

Two stale child delivery failures (from much earlier sessions) are not relevant

The .gz "quarantined original" in manifests/ is not actually gzipped — byte-identical copy of plain TSV

Build script has hardcoded source_total_rows: 240536 for progress display — stale for the 444k source, cosmetic only

📑 Contents