project-asma · ovarian cancer research · a reproduction study
Project Asma
A 2023 study reported a set of 64 proteins that marks the ovarian cancers most resistant to first treatment. This project rebuilds that result from the public data, step by step, and reports what holds.
Research only. Not clinical advice, not a diagnostic service, and not peer reviewed. No scientific result has been reproduced yet. By Ahraz Arifuddin, Aska Digital. Assisted by an array of digital intelligences.
- proteins in the published panel
- 64
- cohorts in the study
- 3
- printed result under test
- AUC 0.83
- results reproduced so far
- 0
00//The question
Chowdhury et al., Cell 2023One published result, rebuilt from scratch.
High-grade serous ovarian cancer (HGSOC) is the most common and most lethal form of ovarian cancer. First treatment is usually platinum chemotherapy. The study behind this project compares two deliberately extreme groups. Refractory tumours showed persistent or growing disease on imaging after six cycles of first platinum/taxane chemotherapy. Sensitive tumours did not progress for at least two years. This is primary platinum-refractory disease, and it is not the same as cancer that responds first and resists later.
In 2023, Chowdhury and colleagues published a proteogenomic study of HGSOC. Among its results was a signature: levels of 64 proteins, measured in tumour tissue, that separated refractory from sensitive cancers in the study's own data. The headline measure was an AUC of 0.83. AUC is a ranking score: 1.0 ranks every refractory tumour above every sensitive one, and 0.5 is no better than chance. At the study's strictest operating point it caught about a third of refractory tumours (sensitivity 0.35) while almost never flagging a sensitive one (specificity 98%).
A result like that matters only if it survives outside the data it was built on. Project Asma's first pilot takes the published panel exactly as printed and asks whether the reported numbers can be recovered from the public data, and whether the patients counted as a separate validation group really are separate. It does not build a new test, and it makes no claim about patient care.
01//What has been checked
status on main · 2026-10-29Audits and tests are on main. No result is reproduced.
Status on 29 October 2026, counting only work merged into the main branch. These are internal checks. None has had external scientific review, so every result below is preliminary. The data audits work in memory on public files and keep only counts and fingerprints. The pipeline and source adapter were tested on made-up inputs only. No patient records, scores or linkage tables are stored in the repository.
-
On main · #1
Research scaffold and pilot protocol
The workspace, evidence map, registries and the pilot design. Defines the target (one printed result, Figure 3D), the cohorts and the stop rules.
-
On main · #2Preliminary · awaits review
Feasibility and patient-linkage audit
Recovers the 64-protein panel from the published supplements and rebuilds the discovery, frozen and FFPE score cohorts. It also checks patient membership between the frozen sheet labelled non-overlapping and the discovery score set. These results await external scientific review, so this page does not report them.
-
On main · #3Preliminary · awaits review
Published-score check
Recomputes the discovery AUC from the released scores and labels alone, under a specification fixed before the run. It refits no model. The result is recorded in the repository as a preliminary internal check. It awaits external scientific review, so this page does not report a value.
-
On main · #4, #14Preliminary · awaits review
Discovery input linkage
Links the author-released discovery matrix to the clinical records by exact name match, checks the file's integrity, and checks how often each panel protein occurs among its feature rows. A later check asks whether R's name cleaning, which the authors' scripts apply, would alter any panel symbol. These results await external scientific review, so this page does not report them.
-
On main · #7, #20, #25Preliminary · awaits reviewStatic · not run
Code audit of the published analysis
A static reading of the authors' Figure 3D R code at a pinned commit, with package sources read at named versions. It records which saved objects can feed the plotted cross-validation, how labels and operating points are set, and where package versions matter. The code was read, never run, and no data were accessed. A consolidated request to the authors is authorized as a draft only, and an owner handoff record now prepares its final text review, sending evidence and later answers. It is unsent, and only the owner decides whether to send it.
-
On main · #10Declared · not executed
Reconstruction decisions and data-use route
Fixes, before any fit, how a new discovery-only reconstruction would run: input assembly, new patient-stratified folds, seeds, model settings and score averaging. It is a new method on the released inputs, not a recovery of the original runs. A separate record selects a conditional, noncommercial research-use route for the data. It is not a licence, and the actual execution context must support it before any fit.
-
On main · #11, #13, #17, #20, #23Fixtures only · no study data
Synthetic pipeline and direction test
An original R implementation of those decisions, tested on artificial fixtures only. In a pinned container it passed 149 assertions and a complete 100-repeat run with the pinned model packages. Later tests check that each model gives higher probabilities to the class coded as refractory, pin the fold assignment to fixed reference vectors, and read each fitted model's own settings back against the declaration. On 27 October the whole suite, now 179 assertions, and the full 100-repeat run passed again in a rebuilt pinned container. No fixture result is compared with the paper.
-
On main · #12, #16, #22, #23Not run on study files
Source adapter
Code that would check the pinned workbooks and matrix member against their recorded hashes and turn the selected values into the pipeline's input. It was tested on generated files in the same formats, through the full model path, with network access mocked. A probe of the first combined Python and R container passed all 40 of its technical checks; the container rebuilt on 27 October passed the same fixture checks but still needs its own probe. The adapter refuses to download or parse the study files unless the call names a current entry in an attestation file that only the owner creates. The refusal to parse and the expiry dates on entries were added after the 27 October run, so the fixture checks need another run in the pinned container. The adapter has never been run on study files.
-
On main · #15Proposed · owner decision
Proposed protocol amendment
Proposes three additions to the declared reconstruction: a per-repetition AUROC distribution as a descriptive output, options for the sensitivity check, and a policy for warnings and messages during fitting. It is merged as a proposal only. Nothing in it takes effect until the owner records a dated decision.
-
On main · #21Preliminary · awaits review
Open-questions report
Narrows five open questions using public sources, static reading and bounded in-memory checks: the likely origin of the missing fold helper, the scope of the 2024 correction, panel coverage in the validation cohorts' published feature lists, what "non-overlapping" means for the frozen cohort, and whether a 2025 follow-up study could serve as a fallback. It computed no performance result, and none of the questions is closed. Its findings await external scientific review.
-
On main · #26Preliminary · awaits reviewArtificial tests only
Validation capacity and held-out evaluation tools
An offline calculation from existing aggregate counts shows what the available candidate cohort can establish about high specificity, and gives best-case minimum independent patient numbers for a high-specificity lower bound. These are design calculations, not measured model results or a powered recruitment target. A separate evaluation library prepares keyed patient checks, paired comparisons and bootstrap intervals for future independent patients, tested on artificial cases only. Neither result is a measured model performance, and neither resolves whether the candidate patients are independent. Counts and bounds are in the capacity report, not on this page, which withholds preliminary cohort counts until external review. Even perfect classification of the candidate sensitive patients could not establish 98% specificity; that needs at least 149 independent sensitive patients with no false positives.
-
Not done
Reconstruction fit on study data
Fitting the declared reconstruction's models on the released study data and comparing the result with the printed AUC. No model has been fitted on study data. A fit waits on the owner's dated attestation of the execution context and a new explicit instruction. It also waits on an actual execution host whose location, terms and applicable obligations support the selected data-use route, with the combined Python and R container rechecked on that host. It further waits on the owner's dated decision on the proposed amendment. Work in open pull requests is not counted until it is merged. Section 02 lists the key gaps recorded on main.
This list is dated and will age. The roadmap holds the current state and the next gates.
02//Still missing
recorded on main · 2026-10-29Gaps recorded before any fit on study data.
The fold helper
The authors' scripts call a helper file, balanced_folds.R, that decides how patients were split into folds. The searches so far did not find it: the authors' repository at the commit checked, its reachable history and three public forks. A later public repository from the same GitHub account defines a helper of the same kind. It is a likely stand-in, not proof: its 2023 version, shuffle details and the original label order remain unknown. The main branch declares a replacement fold rule. A rerun with it would be a new reconstruction, not a faithful rerun of the printed cross-validation.
The workspaces and processing history
The figure scripts load saved R workspaces (RData files) that the same searches did not find. Which objects they held, and in what order, decides what the printed figure actually averaged. The declared reconstruction starts from the released matrix instead and does not recover them. How that matrix was itself processed (normalisation, filtering, batch correction, imputation) is only partly documented. So even the declared reconstruction cannot claim that every processing step was fitted only inside training folds.
The corrected legends
A 2024 correction fixes the supplemental figure legends only; Figure 3D is outside its stated scope. The supplement copy pinned here predates the correction, and its legends disagree with the figure images at several points. The corrected legends have not been pinned yet, because the publisher's hosts were unreachable from the research environment.
People and permissions
No gynaecologic oncologist or proteomics/biostatistics collaborator has been recruited. Recruiting needs a new explicit instruction. The repository licence is undecided, and external scientific review is pending. Downloading study files for a research run, a real-source input check or any fit on study values needs the owner's dated attestation of the execution context and a new explicit instruction. Clinical interpretation and validation need domain review first.
03//Rules of the workspace
how claims are kept honestSmall rules, applied every time.
Aggregates only. Audits read public files in memory and publish counts, hashes and provenance. Patient-level records, scores and linkage maps never enter the repository.
Labels before numbers. Anything not independently verified is labelled as such, in the registries and on this page. A reproduced number and a printed reference value are never presented as the same kind of fact.
Fixed before run. Numerical checks are specified, with their tolerance, before they are executed. A disappointing result is recorded unchanged, not tuned away.
Offline checks. python3 tools/validate.py and python3 -m unittest discover -s tests run on the Python standard library, plus git in a checkout, without network access. They check the repository's records, recompute the validation-capacity calculation from committed counts, and test the audit code, the source adapter, the evaluation library and the runtime tooling on small made-up inputs. They do not rerun any audit or the published-score check, and passing them is not a scientific reproduction. The R pipeline tests run separately, on artificial fixtures in a pinned Docker container with networking off; the synthetic validation lists the commands. That container has not yet been checked on an actual research host. Separate network commands, listed in the README, rerun the audits. They follow the bounded-inspection rule: in memory, aggregates only, with a record of what was read and why. Neither the R tests nor the network commands are part of the offline checks. The published-score check ran under a recorded instruction, described in its protocol.