Anaerobic E. coli lactate-overproduction knockout screen

Lactate production under anaerobic glucose conditions is a tractable
metabolic-engineering task for constraint-based modelling. A credible study
loads an E. coli BIGG model, validates anaerobic growth, computes WT lactate
secretion, screens central-carbon and fermentation knockouts, and ranks
interventions that increase lactate secretion while preserving growth.

The model supports positive anaerobic glucose growth after oxygen uptake is closed.

The lactate production envelope shows a tradeoff between biomass growth and maximum lactate secretion.

Top lactate-improving knockouts disable competing ethanol, formate, acetate, or succinate by-product routes, or have a specific mechanistic explanation.

Which single-gene knockouts increase anaerobic lactate secretion in E. coli while preserving at least 30-50% of WT growth?

E. coli iJO1366 or iAF1260 on glucose-minimal medium with oxygen uptake closed.

Sweep biomass fraction and optimize lactate secretion.

Screen central-carbon and fermentation genes; rank by lactate flux at fixed growth fraction.

Wild-type anaerobic glucose lactate secretion.

WT biomass flux with oxygen uptake set to zero.

Lactate exchange secretion flux.

Lactate secretion divided by glucose uptake.

KO biomass relative to WT anaerobic growth.

results.json contains primary_metric, metrics, hypotheses, summary, and top KO structured results.

Oxygen uptake is explicitly closed and anaerobic WT growth is reported.

Top 5 lactate-ranked knockouts are reported with gene_id, gene_name, growth_fraction, lactate_flux, and mechanism/canonical flag.

A biomass-vs-lactate production envelope figure exists with labelled axes and units.

Each of hypotheses.h1, hypotheses.h2, hypotheses.h3 in results.json MUST have an explicit `supported` boolean and a `details` string of at least 40 characters describing the evidence used to reach that verdict.

Top-3 lactate-improving KO targets are discussed mechanistically — naming the pathway each KO disables and a one-sentence rationale for why the disruption redirects anaerobic flux to lactate. Acceptable inside summary, structured_results, or a separate writeup field.

A credible anaerobic E. coli lactate-overproduction study using COBRApy that validates anaerobic growth, computes a lactate production envelope, screens a focused central-carbon/fermentation knockout set, and explains top candidates mechanistically.

Accept iJO1366, iAF1260, or comparable curated E. coli models. Score coherent anaerobic setup and mechanistic KO interpretation over exact gene names.

COBRApy code implements anaerobic medium, lactate objective/envelope, and knockout screening.

Loads an E. coli BIGG model, sets glucose uptake, closes oxygen uptake, and names biomass and lactate exchange reactions.

Computes biomass-vs-lactate production envelope by constraining biomass fractions and optimizing or FVA-bounding lactate secretion.

Screens a focused set of no more than 100 central-carbon and fermentation genes with model state restored between knockouts.

Computes lactate yield as lactate secretion divided by absolute glucose uptake, separate from flux.

Execution produces valid anaerobic WT, envelope, and KO tables.

WT anaerobic FBA is optimal with positive biomass and at least 85% of KO simulations solve or are explicitly labelled infeasible/lethal.

Mass-balance check passes for the loaded anaerobic model; no aerobic by-products (O2 uptake or CO2 via respiration) appear under strictly anaerobic conditions without explanation; biomass flux is positive under anaerobic glucose reference. This is the biology-validity gate equivalent to physics-validity checks in the physics rubric.

Writes results.json plus machine-readable envelope and KO-ranking tables.

Results quantify lactate production, growth tradeoffs, and KO mechanisms.

Reports anaerobic WT growth and confirms oxygen uptake is zero or bounded closed. Score 100% if positive anaerobic WT biomass flux is reported with O2 exchange confirmed ≤0 mmol/gDW/h; 67% if growth is positive but O2 status is not explicitly confirmed; 33% if anaerobic feasibility is stated without a numeric growth value; 0% otherwise.

Shows lactate secretion changes across biomass fractions and identifies whether production is growth-coupled, competing, or partially coupled. Score 100% if lactate secretion flux is non-decreasing as biomass fraction decreases across ≥8 of 10 envelope grid points; 67% if non-decreasing over ≥6 of 10 points; 33% if ≥4 of 10 points; 0% otherwise.

Top 5 KO list includes growth fraction, lactate flux/yield, and pathway-level rationale for at least top 3 targets. Score 100% if ≥3 of the top-5 KOs disrupt canonical competing by-product pathways (acetate, ethanol, formate, or succinate routes) or include a specific mechanistic explanation; 67% if 2 of 5 meet this criterion; 33% if 1 of 5; 0% otherwise.

Produces a labelled lactate envelope or KO ranking figure with units.

The README or results writeup discusses each hypothesis outcome, names the top lactate-improving knockouts with their gene/enzyme identity, and gives a one-paragraph mechanistic interpretation (which competing pathways the KOs disable, why this redirects anaerobic flux to lactate).

Medium, model, gene set, solver, and thresholds are reproducibly recorded.

The loaded E. coli GSMM is either persisted (models/<model_id>.json) or pinned by BIGG model ID and source URL in the writeup; a downstream user can locate the exact model object and reproduce the anaerobic medium setup.

Saves anaerobic medium bounds, biomass threshold, KO gene set, and lactate reaction ID.

Records COBRApy/solver versions and confirms rerun consistency for WT growth.


S. cerevisiae ethanol yield under oxygen limitation and carbon-source changes

Yeast ethanol fermentation is a natural extension beyond E. coli while still
staying inside BIGG/COBRApy constraint-based modelling. A credible study
loads iMM904 or a comparable yeast GSMM, validates growth on glucose, sweeps
oxygen availability, compares glucose and alternative carbon sources, and
quantifies ethanol secretion and yield.

The yeast model grows on glucose-minimal medium and produces a feasible FBA solution.

Ethanol secretion/yield increases as oxygen uptake is restricted relative to fully aerobic growth.

Carbon-source swaps produce distinct growth and ethanol-yield profiles, with glucose supporting stronger fermentation than at least one alternative carbon source.

How do oxygen limitation and carbon source alter predicted ethanol secretion and yield in S. cerevisiae?

S. cerevisiae iMM904 or comparable model on glucose-minimal medium.

Sweep oxygen uptake from anaerobic/low oxygen to aerobic while glucose uptake is fixed.

Compare glucose, fructose, galactose, glycerol, and acetate when supported by the model.

Anaerobic or oxygen-limited glucose condition.

Biomass flux.

Ethanol exchange secretion flux.

Ethanol secretion divided by substrate uptake.

S. cerevisiae iMM904

BIGG iMM904 via cobra.io.load_model if available, or documented local SBML/JSON yeast model.

results.json contains yeast model ID, metrics, hypotheses, and structured oxygen/carbon-source results.

A machine-readable oxygen-sweep table exists with oxygen bound, growth, ethanol flux, and yield.

A carbon-source comparison table exists, including unsupported sources marked explicitly.

At least one oxygen-vs-ethanol or carbon-source yield figure exists with units.

The ethanol-yield response to oxygen and carbon source is discussed mechanistically — why oxygen restriction increases ethanol yield and how carbon-source metabolism shapes fermentation. Acceptable inside summary, structured_results, or a separate writeup field.

The solver backend (cobra optlang interface name + version) and COBRApy version are reported in results.json. Required for reproducibility but not for scientific correctness.

A credible S. cerevisiae ethanol-yield study that loads a yeast GSMM, validates growth, sweeps oxygen uptake, swaps carbon sources, and reports ethanol secretion/yield with interpretable figures.

The main challenge is adapting the pipeline beyond E. coli while remaining within COBRApy/BIGG capabilities. Accept iMM904 or another documented yeast GSMM.

The code implements yeast model loading, medium setup, oxygen sweep, carbon-source swap, and ethanol-yield calculations.

Loads iMM904 or comparable yeast model, identifies biomass, glucose, oxygen, and ethanol exchange reactions, and validates positive reference growth.

Sweeps oxygen uptake across at least 8 values while keeping substrate uptake defined and restoring state between runs.

Compares at least 4 carbon sources where model reactions exist and explicitly records unsupported sources.

Calculates ethanol yield using absolute substrate uptake and separates yield from raw secretion flux.

Execution produces oxygen-sweep and carbon-source artifacts without crashing.

Reference glucose condition is optimal and at least 80% of supported oxygen/carbon conditions solve or are clearly marked infeasible.

Mass-balance check passes for the yeast GSMM; no non-physical fluxes appear under aerobic glucose reference (e.g. ethanol secretion should be low under full aerobic conditions); biomass flux is positive under yeast glucose-minimal reference. This is the biology-validity gate equivalent to physics-validity checks in the physics rubric.

Writes results.json, oxygen_sweep.csv, and carbon_source_comparison.csv or equivalent structured outputs.

Results quantify oxygen and substrate effects on ethanol secretion/yield.

Reports yeast reference growth with model ID and medium definition. Score 100% if positive yeast biomass flux and ethanol secretion are both reported under aerobic glucose-minimal medium with optimal solver status and a named model ID; 67% if growth is positive but ethanol is not reported; 33% if feasibility is stated without numeric values; 0% otherwise.

Quantifies how ethanol flux or yield changes as oxygen decreases and identifies the low-oxygen fermentation regime. Score 100% if ethanol flux or yield is non-decreasing as oxygen uptake decreases across ≥6 of 8 oxygen-sweep points; 67% if non-decreasing over ≥4 of 8 points; 33% if the trend is described without a quantitative grid; 0% otherwise.

Compares growth and ethanol yield across carbon sources with a biological interpretation. Score 100% if at least 3 carbon sources are compared with distinct numeric ethanol yields and a biological interpretation; 67% if 2 sources are compared with numeric differences; 33% if the comparison is qualitative or only one carbon source produces positive growth; 0% otherwise.

Produces labelled figures for oxygen sweep and/or carbon-source yield comparison.

The README or results writeup discusses each hypothesis outcome, names the oxygen regime and carbon source that maximise ethanol yield, and gives a one-paragraph mechanistic interpretation of why oxygen restriction switches yeast from respiratory growth to fermentative ethanol production.

Model source, medium, oxygen grid, carbon-source reactions, solver, and versions are documented.

The loaded yeast GSMM is either persisted (models/<model_id>.json) or pinned by BIGG model ID, version, and source URL in the writeup; a downstream user can locate the exact model object used.

Saves reaction IDs, bounds, grid values, and carbon-source list in config or results metadata.

Records COBRApy, solver, model source/version, and rerun consistency for reference growth.


M. tuberculosis condition-specific essentiality and metabolic drug-target prioritisation

Constraint-based essentiality analysis can prioritise metabolic drug-target
hypotheses in pathogen models. A credible study loads an M. tuberculosis GSMM
such as iNJ661 when available, validates biomass production under a documented
medium, performs single-gene and/or single-reaction deletion, and ranks
essential targets by growth impact and subsystem interpretability.

The selected M. tuberculosis model produces positive biomass under the documented reference medium.

Single-gene or single-reaction deletion identifies a non-empty set of essential metabolic targets under the reference condition.

Prioritised targets are enriched in interpretable core metabolic subsystems such as cell-wall precursor, cofactor, lipid, energy, or amino-acid metabolism.

Which condition-specific metabolic genes or reactions are predicted essential in M. tuberculosis and are plausible drug-target hypotheses?

M. tuberculosis iNJ661 or comparable model under a documented reference medium.

Single-gene deletion screen when GPR rules are available.

Single-reaction deletion screen as a fallback or complementary target set.

Nonessential deletion growth distribution.

Reference biomass flux.

Deletion biomass divided by WT biomass.

Count of genes/reactions below essentiality threshold.

Subsystem distribution among essential targets.

M. tuberculosis GSMM

BIGG iNJ661 or documented local SBML/JSON model.

results.json contains model ID, WT growth, essential target counts, top targets, and hypothesis verdicts.

A gene or reaction deletion table exists with target ID, status, growth, growth_fraction, and essential flag.

Top 10 prioritised essential targets are reported with subsystem/pathway and rationale.

At least one essentiality distribution or subsystem-enrichment figure exists.

Each of hypotheses.h1, hypotheses.h2, hypotheses.h3 in results.json MUST have an explicit `supported` boolean and a `details` string of at least 40 characters describing the evidence used to reach that verdict.

Top-3 essential target hypotheses are framed mechanistically — naming the metabolic subsystem each target belongs to and why its disruption is predicted lethal under the reference medium. Claims must be framed as computational hypotheses, not validated drugs. Acceptable inside summary, structured_results, or a separate writeup field.

A credible M. tuberculosis essentiality study using COBRApy that validates a pathogen GSMM, runs single-gene and/or single-reaction deletions, identifies essential targets, and prioritises interpretable drug-target hypotheses.

Accept gene deletions, reaction deletions, or both depending on model GPR support. Penalize unsupported biological claims more than absence of external drug databases.

The code loads the pathogen model, validates medium, runs deletion screens, and annotates essential targets.

Loads iNJ661 or a documented M. tuberculosis GSMM, defines medium/objective, and validates positive WT biomass.

Runs single-gene deletion when GPR rules are usable, or single-reaction deletion as an explicit fallback/complement.

Defines essentiality threshold such as growth <5% or <10% of WT and applies it consistently.

Extracts subsystem, reaction name, gene name, GPR, or other model-native annotations for top targets.

Deletion runs complete with interpretable status handling and structured outputs.

WT reference condition is optimal and at least 85% of deletion simulations solve or are explicitly marked infeasible/lethal.

Mass-balance check passes for the loaded pathogen GSMM; WT biomass is positive under the documented medium; deletion table contains no negative growth values; model GPR rules produce logically consistent essential gene predictions. This is the biology-validity gate equivalent to physics-validity checks in the physics rubric.

Writes results.json plus deletion table with growth, growth_fraction, status, and essential flag.

Results identify essential targets and provide conservative biological interpretation.

Reports WT growth, medium, model ID, and validation caveats. Score 100% if positive WT biomass flux is reported under the documented medium with optimal solver status and model ID named; 67% if growth is positive but medium is not explicitly documented; 33% if feasibility is stated without a numeric value; 0% otherwise.

Reports essential target count and distribution of growth fractions after deletion. Score 100% if ≥5 essential genes/reactions are identified with growth fractions below the stated threshold and the deletion table covers ≥50 candidates; 67% if essential targets are identified but the candidate set covers fewer than 50 entries; 33% if essential targets are named without a deletion table; 0% otherwise.

Top 10 targets include subsystem/pathway and one-sentence rationale; claims are framed as modelling hypotheses, not validated drugs. Score 100% if ≥3 of the top-10 prioritised targets belong to named core metabolic subsystems (cell-wall precursor, cofactor, lipid, energy, or amino-acid biosynthesis) with at least a one-sentence pathway rationale; 67% if 2 of 10 with rationale; 33% if 1 of 10 with rationale; 0% otherwise.

Produces a labelled essentiality histogram, target ranking plot, or subsystem enrichment chart.

The README or results writeup discusses each hypothesis outcome, names the top prioritised essential targets with subsystem/enzyme identity, and gives a one-paragraph mechanistic rationale for why each target's disruption is lethal. Claims are explicitly framed as computational hypotheses requiring wet-lab validation.

Model, medium, deletion type, threshold, solver, and annotations are reproducibly recorded.

The loaded M. tuberculosis GSMM is either persisted (models/<model_id>.json) or pinned by BIGG model ID, version, or local file hash in the writeup; a downstream user can locate the exact model object used.

Saves model source, medium bounds, objective, deletion mode, and essentiality threshold.

Records COBRApy/solver versions and confirms rerun consistency for WT growth and essential count.


E. coli carbon-source robustness and condition-dependent essential genes

Carbon-source swaps are a direct mfa-agent capability and produce interpretable
condition-dependent phenotypes. A credible study loads an E. coli GSMM, defines
a base minimal medium, tests multiple single-carbon sources, runs essentiality
analysis on a focused gene set under each feasible source, and identifies genes
whose essentiality changes with carbon source.

The model predicts positive growth on glucose and at least two additional supported carbon sources.

Growth rates and secretion profiles differ substantially across carbon sources.

A focused central-carbon gene set contains condition-dependent essential genes whose deletion effects vary by carbon source.

Which E. coli metabolic vulnerabilities are carbon-source dependent across glucose, glycerol, acetate, succinate, and fructose-like conditions?

Close background carbon uptake, open one carbon source at a time, and run FBA/pFBA.

For feasible carbon sources, delete a focused set of central-carbon genes and record growth fractions.

Wild-type growth for each carbon source.

WT biomass flux per carbon source.

Positive exchange fluxes under pFBA.

Genes essential under one source but not another.

E. coli GSMM

BIGG iJO1366 or iAF1260 via cobra.io.load_model

results.json contains carbon-source growth table summary, essentiality counts, hypothesis verdicts, and summary.

A carbon-source comparison table exists with source, exchange reaction, status, growth, and secretion profile fields.

A gene-by-carbon essentiality/growth-fraction matrix exists for feasible carbon sources.

A heatmap or clustered plot of condition-dependent gene essentiality exists with labelled axes.

Top-3 condition-dependent essential genes are explained mechanistically — why each gene is essential under one carbon source but not another, referencing the metabolic pathway context. Acceptable inside summary, structured_results, or a separate writeup field.

The solver backend (cobra optlang interface name + version) and COBRApy version are reported in results.json. Required for reproducibility but not for scientific correctness.

A credible E. coli carbon-source robustness study that loads a validated GSMM, swaps carbon sources, reports growth/secretion profiles, and identifies condition-dependent essential genes from a focused gene set.

Score explicit medium handling and condition-dependent interpretation. It is acceptable if some carbon sources are unsupported, provided they are recorded and not silently dropped.

The code implements carbon-source medium swaps, FBA/pFBA, and focused essentiality comparison.

Loads E. coli BIGG model, identifies biomass and candidate carbon exchange reactions, and defines a minimal medium policy.

Closes background carbon uptake and opens one carbon source at a time with documented uptake bounds.

Runs FBA/pFBA per source and records major positive exchange fluxes.

Runs focused single-gene deletions for feasible carbon sources and computes growth fractions relative to each source-specific WT.

Execution produces carbon-source and essentiality artifacts.

Glucose reference is optimal and at least two non-glucose sources are either feasible or clearly marked unsupported/infeasible.

Mass-balance check passes for the E. coli GSMM under each tested carbon source; no carbon source produces negative biomass or non-physical secretion without explicit handling; model state is restored between carbon-source conditions. This is the biology-validity gate equivalent to physics-validity checks in the physics rubric.

Writes results.json, carbon-source table, and gene-by-condition growth-fraction matrix.

Results compare carbon sources and identify condition-dependent vulnerabilities.

Reports feasible carbon-source count and growth rates, including unsupported-source handling. Score 100% if ≥3 carbon sources including glucose support positive biomass growth with explicit exchange bounds documented; 67% if 2 sources support positive growth; 33% if only glucose is feasible with explicit confirmation that other sources are infeasible or unsupported; 0% otherwise.

Compares secretion profiles and growth rates across sources with quantitative differences. Score 100% if growth rates differ by >10% between at least 2 feasible carbon sources AND major secretion fluxes differ qualitatively across sources; 67% if growth rate differences are reported without secretion-profile comparison; 33% if differences are noted qualitatively without quantification; 0% otherwise.

Identifies genes with large growth-fraction changes across carbon sources and explains pathway context for top hits. Score 100% if ≥3 genes with condition-dependent essentiality changes (essential under one carbon source but not another) are identified with pathway context; 67% if 2 genes are identified; 33% if 1 gene is identified with pathway context; 0% otherwise.

Produces labelled bar plots and/or heatmaps for growth, secretion, and condition-dependent essentiality.

The README or results writeup discusses each hypothesis outcome, names supported and unsupported carbon sources, identifies condition-dependent essential genes, and gives a one-paragraph mechanistic interpretation linking carbon-source specific metabolism to the observed vulnerability changes.

Carbon-source definitions, gene set, thresholds, solver, and model are documented.

The loaded E. coli GSMM is either persisted (models/<model_id>.json) or pinned by BIGG model ID and source URL in the writeup; a downstream user can locate the exact model object and reproduce each carbon-source medium setup.

Saves carbon exchange IDs, uptake bounds, oxygen setting, gene list, and essentiality threshold.

Records COBRApy/solver versions and rerun consistency for glucose and at least one non-glucose source.


Reproducible FBA protocol benchmark: FBA vs pFBA vs loopless/FVA on E. coli

A method benchmark is well matched to mfa-agent because it tests robust use of
COBRApy APIs rather than biological novelty alone. A credible study loads a
validated E. coli GSMM, runs standard FBA, pFBA, loopless FBA when available,
and FVA at a fixed fraction of optimum, then compares growth, flux sparsity,
runtime, and reaction-level variability.

FBA, pFBA, and loopless FBA preserve the same biomass optimum within solver tolerance under the same medium.

pFBA produces a lower total absolute flux norm and/or fewer active reactions than unconstrained FBA.

FVA reveals that only a subset of central-carbon reactions are tightly constrained near optimum while others remain variable.

How do standard FBA, pFBA, loopless FBA, and FVA differ in flux parsimony and variability while preserving E. coli growth predictions?

Maximize biomass on aerobic glucose-minimal medium.

pfba

Maximize biomass then minimize total absolute flux.

Run loopless solution when available and compare objective/fluxes.

Run FVA at 95% of optimum and classify rigid vs flexible reactions.

Standard FBA biomass optimum.
COBRApy solver status and runtime.

Biomass flux for each method.

Sum of absolute reaction fluxes.

Number of reactions with absolute flux above tolerance.

Maximum minus minimum FVA interval per reaction.

results.json contains method-level metrics, hypotheses, summary, and solver/version metadata.

A method-comparison table exists with method, status, growth, total_abs_flux, active_reactions, and runtime.

An FVA table exists with reaction ID, minimum, maximum, width, and rigid/flexible classification.

At least one labelled figure compares methods or FVA variability.

Each of hypotheses.h1, hypotheses.h2, hypotheses.h3 in results.json MUST have an explicit `supported` boolean and a `details` string of at least 40 characters describing the evidence used to reach that verdict.

The protocol comparison is summarised with a method recommendation — which method is most reproducible and why, referencing flux-norm and FVA evidence. Acceptable inside summary, method_comparison, or a separate writeup field.

A reproducible FBA-method benchmark on E. coli that compares standard FBA, pFBA, loopless FBA when available, and FVA near optimum using consistent medium, metrics, runtime logging, and interpretable figures.

This is a protocol-quality task. Reward robust implementation, structured outputs, and careful handling of unavailable loopless solvers over biological novelty.

The code implements method comparison with consistent model state and metrics.

Loads E. coli BIGG model, sets medium and biomass objective, and validates reference FBA.

Runs standard FBA, pFBA, and loopless FBA or records a justified loopless-unavailable status.

Runs FVA at a documented fraction of optimum and computes interval widths and rigid/flexible labels.

Computes total absolute flux, active reaction count, objective value, solver status, and runtime for each method.

Execution produces complete benchmark artifacts and handles optional method failures explicitly.

Standard FBA and pFBA solve optimally; loopless and FVA either solve or have explicit, non-crashing failure records.

Mass-balance check passes for the loaded model under the benchmark medium; FBA, pFBA, and loopless FBA all return non-negative biomass fluxes; no negative flux norms or ill-conditioned solver status appear without explicit logging. This is the biology-validity gate equivalent to physics-validity checks in the physics rubric.

Writes results.json, method comparison table, FVA table, and method flux tables.

Results compare objective preservation, parsimony, and reaction variability.

Reports objective differences among methods and checks agreement within solver tolerance where methods succeed. Score 100% if FBA and pFBA biomass objectives agree within 1% relative error and any available loopless FBA also agrees within 1%; 67% if FBA and pFBA agree but loopless comparison is missing or failed with explicit explanation; 33% if only qualitative agreement is stated; 0% otherwise.

Quantifies pFBA parsimony using total flux norm and active reaction count compared with standard FBA. Score 100% if pFBA total absolute flux norm is numerically lower than FBA AND active reaction count is lower under pFBA; 67% if flux norm is lower but active reaction count is not compared; 33% if pFBA parsimony is stated qualitatively without numeric comparison; 0% otherwise.

Summarizes FVA width distribution and names central-carbon reactions that are rigid or flexible near optimum. Score 100% if FVA interval widths are reported for all model reactions and ≥5 central-carbon reactions are classified as rigid (interval width < 1 mmol/gDW/h) with subsystem identification; 67% if rigid/flexible classification is reported without central-carbon specifics; 33% if FVA results are reported without classification; 0% otherwise.

Produces labelled method-comparison and/or FVA-width figures with units and clear legends.

The README or results writeup discusses each hypothesis outcome, summarises the method-level comparison (parsimony, variability, runtime), and gives a one-paragraph protocol recommendation stating which method is most suitable for reproducible phenotype prediction and why.

The benchmark is reproducible with pinned model, medium, tolerance, solver, and code path.

The loaded E. coli GSMM is either persisted (models/<model_id>.json) or pinned by BIGG model ID and source URL in the writeup; a downstream user can locate the exact model object and reproduce the benchmark medium.

Saves model ID, objective, medium bounds, FVA fraction, active-flux tolerance, and method list.

Records COBRApy, optlang, solver backend/version, and runtime environment.


Bootstrap confidence intervals under non-Gaussian data

Bootstrap confidence interval coverage under light-tailed, skewed, and heavy-tailed data

Bootstrap confidence intervals are widely used when analytic standard errors
are inconvenient, but their finite-sample coverage can change substantially
with skewness, heavy tails, contamination, and the choice of statistic. A
credible study of this topic should simulate data-generating processes with
known estimands, compare several bootstrap confidence interval methods, and
evaluate empirical coverage and interval width.

The study should not only report whether nominal 95% intervals contain the
truth, but also explain when wider intervals, robust estimators, or
studentized intervals improve reliability. The research question is: *how do
bootstrap interval choices and estimator choices affect empirical coverage
under light-tailed, skewed, and heavy-tailed data?*

Percentile bootstrap intervals for the sample mean achieve near-nominal coverage under light-tailed Gaussian data, especially at moderate sample sizes.

Percentile bootstrap intervals for the sample mean under-cover under heavy-tailed or contaminated data.

Robust location estimators, such as the median or trimmed mean, improve coverage stability or interval behavior under heavy-tailed or contaminated data.

How do bootstrap confidence interval methods behave across light-tailed, skewed, and heavy-tailed distributions?

The true mean of each simulated data-generating process when it exists.

A robust target such as the median or trimmed mean, used when heavy tails or contamination make mean-based inference unstable.

Classical normal or t-based interval for the sample mean.

Percentile bootstrap interval for the sample mean.

Studentized or bootstrap-t interval for the sample mean, or a justified bootstrap alternative.

Bootstrap interval for a robust estimator such as the median or trimmed mean.

gaussian

Light-tailed data where standard mean inference should work well.

Skewed data where percentile intervals may show asymmetric finite-sample behavior.

Heavy-tailed data with unstable sample means.

Mostly normal data with a small fraction of extreme outliers.

coverage

Empirical fraction of intervals containing the true estimand.

Absolute deviation from nominal 95% coverage.

Average interval width, interpreted jointly with coverage.

Fraction of simulation runs where an interval could not be computed or produced invalid values.

Executable simulation code implementing confidence interval methods and data-generating processes.

Machine-readable coverage, coverage error, interval width, and failure rate by method, distribution, and sample size.

Diagnostic plots comparing coverage and interval width across methods and data-generating conditions.

Paper-style report explaining the setup, methods, results, limitations, and per-hypothesis conclusions.

A canonical results.json file exists at the workspace root with at least the keys: primary_metric (number), metric_key (string), metrics (object with numeric keys), hypotheses (object with h1/h2/h3 entries each carrying a `supported` boolean), summary (non-empty string).

A machine-readable metrics artifact (e.g. results/metrics.json) exists reporting empirical coverage AND interval width broken down by CI method, data-generating distribution, and sample size.

results.json metrics MUST contain at least 3 numeric (non-null, finite) empirical coverage values in [0, 1] for distinct (method, distribution) cells, including at least one Gaussian cell and one heavy-tailed or contaminated cell so H1 and H2 can be evaluated.

results.json hypotheses.h1/h2/h3 each MUST have an explicit `supported` boolean AND a `details` string ≥ 40 characters quoting the numerical coverage / interval-width evidence (specific values + their source artifact) used to reach the verdict.

At least one figure file (PNG or PDF, ≥150 DPI for raster) exists under results/figures/ comparing coverage and/or interval width across methods and data-generating conditions, with axes labeled and a legend.

The report discusses the coverage-versus-interval-width tradeoff — recognising that higher coverage may simply come from wider intervals and that width must be read jointly with coverage. Nice-to-have, not blocking.

results.json or a sibling reproducibility section names the Monte Carlo repetition count, bootstrap resample count, and at least one explicit random seed. Required for full reproducibility but not for scientific correctness.

A credible simulation study evaluating whether bootstrap confidence interval choice affects empirical coverage under light-tailed, skewed, and heavy-tailed data. The submission should implement multiple CI methods, simulate several data-generating distributions and sample sizes, report coverage and interval width over repeated trials, and connect the numeric findings to the three hypotheses.

Score on statistical substance, correct simulation design, and directional correctness of evidence. Do not require exact repetition counts if the submission is computationally reasonable. Partial but well-motivated simulations deserve partial credit; rigid naming differences should not penalize a substantively correct experiment.

The bootstrap simulation code implements meaningful confidence interval comparisons across relevant distributional regimes.

The submission implements at least two bootstrap confidence interval methods, typically percentile bootstrap and studentized/bootstrap-t or another justified alternative. Methods should be implemented as distinct code paths rather than cosmetic options.

The submission includes a robust location estimator, such as median or trimmed mean, and compares it against the ordinary sample mean under heavy-tailed or contaminated data.

The submission simulates multiple data-generating processes covering at least light-tailed and heavy-tailed cases, with skewed data such as lognormal or contaminated data receiving additional credit.

The simulation evaluates more than one sample size so that finite-sample behavior can be distinguished from asymptotic behavior.

Execution produces coverage and interval-quality metrics adequate to evaluate bootstrap CI behavior.

Execution produces a machine-readable metrics artifact, such as results/metrics.json, containing numeric empirical coverage and interval width by condition, distribution, and sample size. Coverage error or failure rate may supplement these metrics.

Reported metrics are based on repeated Monte Carlo trials and bootstrap resampling. The exact number of repetitions need not match the topic file, but it should be large enough to make coverage comparisons meaningful and should be honestly reported.

The simulation correctly defines the true estimand for each data-generating process, such as the true mean or true robust location target, and checks whether confidence intervals contain that estimand.

The final paper or report addresses the three bootstrap hypotheses with quantitative evidence and a clear statistical narrative.

The submission evaluates whether percentile bootstrap confidence intervals achieve near-nominal coverage under light-tailed Gaussian data, especially at moderate or larger sample sizes, and states whether H1 is supported, refuted, or inconclusive.

The submission evaluates whether percentile bootstrap intervals for the sample mean undercover under heavy-tailed data and supports the conclusion with empirical coverage numbers.

The submission compares robust location estimators against the ordinary sample mean under heavy-tailed or contaminated data and discusses whether robustness improves coverage stability or interval behavior.

The analysis discusses interval-width tradeoffs, recognizing that higher coverage may come from wider intervals and that width should be interpreted jointly with coverage.

The README or writeup describes the simulation setup, CI methods, data-generating processes, key numeric results, and per-hypothesis outcomes with appropriate caveats on repetition count, bootstrap count, and Monte Carlo uncertainty.


Double machine learning for average treatment effect estimation under nonlinear confounding

Semiparametric causal inference separates a low-dimensional target parameter,
such as the average treatment effect, from infinite-dimensional nuisance
functions such as the propensity score e(X) and outcome regressions m0(X) and
m1(X). Double machine learning studies how the target parameter can remain
estimable when those nuisance functions are learned flexibly rather than
specified by a finite-dimensional parametric model.

The benchmark should make this relationship explicit. The study should
implement and evaluate treatment effect estimators in simulated observational
data with nonlinear confounding, compare naive regression or inverse-propensity
weighting against orthogonalized / doubly robust estimators, and test how
Neyman orthogonality and cross-fitting reduce first-order sensitivity to
nuisance estimation error. The research question is: *when the nuisance
functions are treated as infinite-dimensional objects and estimated with
flexible learners, does orthogonalization preserve reliable inference for the
finite-dimensional ATE?*

A naive difference-in-means estimator is biased under confounded treatment assignment.

A doubly robust / orthogonalized estimator has lower absolute bias than simple plug-in regression or IPW when nuisance functions are nonlinear.

Cross-fitting improves stability or reduces bias compared with fitting nuisance functions and estimating the treatment effect on the same sample.

Neyman-orthogonal scores make the ATE estimate less sensitive to nuisance-function estimation error than non-orthogonal plug-in estimators.

How does double machine learning estimate a finite-dimensional ATE while using flexible estimators for infinite-dimensional nuisance functions under nonlinear confounding?

ATE = E[Y(1) - Y(0)] in a simulated observational study with known ground truth.

The scalar ATE is the parameter of scientific interest.

Controls confounded treatment assignment and appears in IPW and AIPW scores.

Models the treated potential-outcome regression.

Models the control potential-outcome regression.

The benchmark should evaluate whether an orthogonal score protects the finite-dimensional ATE estimate from first-order errors in flexible, effectively infinite-dimensional nuisance estimates.

Naive treated-control mean difference without confounding adjustment.

Linear regression adjustment for covariates.

Inverse propensity weighting using logistic regression propensity scores.

Augmented inverse propensity weighting using nuisance models fit on the same sample.

Doubly robust AIPW estimator with K-fold cross-fitting and flexible nuisance models.

A diagnostic condition comparing weaker and stronger nuisance learners to test sensitivity of each estimator to nuisance estimation error.

bias

Mean estimated ATE minus true ATE across simulation repetitions.

rmse

Root mean squared error of ATE estimates.

coverage

Empirical coverage of nominal 95% confidence intervals.

Average confidence interval width.

Monte Carlo standard deviation of ATE estimates.

X ~ multivariate normal or uniform with nonlinear transformations

A ~ Bernoulli(sigmoid nonlinear function of X)

Y = tau * A + nonlinear function of X + noise

Executable simulation code implementing all ATE estimators.

Machine-readable bias, RMSE, coverage, and interval width by estimator and sample size.

Plots or tables summarizing estimator bias, RMSE, coverage, interval width, and cross-fitting effects.

Paper-style report explaining the causal estimand, DGP, estimators, uncertainty method, results, limitations, and per-hypothesis conclusions.

Setup and run instructions for reproducing the full experiment from a clean checkout.

numpy pandas scipy scikit-learn matplotlib

A canonical results.json file exists at the workspace root with at least the keys: primary_metric (number), metric_key (string), metrics (object with numeric keys), hypotheses (object with h1/h2/h3/h4 entries each carrying a `supported` boolean), summary (non-empty string).

A machine-readable metrics artifact (e.g. results/metrics.json) exists reporting ATE estimate, bias (or absolute bias), and RMSE broken down by estimator and sample size, with confidence-interval coverage or width where applicable.

results.json metrics MUST contain numeric (non-null, finite) bias or absolute-bias values for at least the naive difference-in-means estimator and the doubly robust / cross-fitted DML estimator, evaluated against the known true ATE, so H1 and H2 can be evaluated quantitatively.

results.json hypotheses.h1/h2/h3/h4 each MUST have an explicit `supported` boolean AND a `details` string ≥ 40 characters quoting the numerical evidence (specific bias / RMSE / coverage values + their source artifact) used to reach the verdict.

The DML condition implements sample splitting or K-fold cross-fitting so nuisance models are trained out-of-fold relative to the observations used in the orthogonal score; a non-cross-fitted AIPW comparison is also present so H3 can be evaluated.

The report clearly distinguishes the finite-dimensional causal estimand, the infinite-dimensional nuisance functions, the orthogonal score, and the evaluation metrics — avoiding confusion between prediction performance and ATE estimation quality. Nice-to-have, not blocking.

results.json or a sibling reproducibility section names the Monte Carlo repetition count, cross-fitting fold count, and at least one explicit random seed. Required for full reproducibility but not for scientific correctness.

A credible semiparametric simulation study evaluating how double machine learning / orthogonalized AIPW estimates a finite-dimensional average treatment effect while using flexible estimators for infinite-dimensional nuisance functions under nonlinear confounding. The submission should implement multiple estimators, simulate observational data with known true ATE, evaluate bias, RMSE, confidence interval behavior, and sensitivity to nuisance estimation quality, and tie the numeric findings to the hypotheses.

Score on causal and semiparametric substance rather than exact package choices. A correct hand-written AIPW / DML implementation should receive full credit even if it does not use a specialized causal inference library. Partial credit should reward clear separation of the finite-dimensional estimand from infinite-dimensional nuisance functions, correct use of orthogonal scores, nuisance estimation, cross-fitting, and honest uncertainty reporting.

The code implements a meaningful comparison of ATE estimators under simulated confounding with known ground truth.

The submission implements a simulated observational data-generating process with covariates, confounded treatment assignment, outcome generation, known true average treatment effect, and explicit true or approximate nuisance functions such as propensity scores and outcome regressions.

The submission implements simple baseline estimators such as difference-in-means, regression adjustment, and/or inverse propensity weighting so that DML is compared against meaningful alternatives.

The submission implements a doubly robust or Neyman-orthogonal AIPW-style estimator using estimated propensity and outcome nuisance functions, and explains why the score targets the finite-dimensional ATE while treating those nuisances as flexible or infinite-dimensional.

The DML condition uses sample splitting or K-fold cross-fitting so nuisance models are trained out-of-fold relative to the observations used in the orthogonal score.

The nuisance functions are estimated with reasonable models for the simulated setting, such as logistic regression, random forests, gradient boosting, or other justified supervised learning methods, with at least one comparison that changes nuisance-model flexibility or quality.

Execution produces ATE estimation metrics adequate to evaluate bias, precision, and interval behavior.

Execution produces a machine-readable metrics artifact, such as results/metrics.json, containing numeric ATE estimates, bias or absolute bias, RMSE, and preferably confidence interval coverage or interval width by estimator and sample size.

Reported metrics are aggregated over multiple simulation repetitions or random seeds, with some dispersion reporting such as standard deviation, standard error, confidence interval, or quantiles.

The experiment evaluates at least one nontrivial sample size and receives more credit for multiple sample sizes showing finite-sample behavior.

The submission computes uncertainty estimates, such as influence-function standard errors, bootstrap standard errors, or Monte Carlo confidence intervals, sufficient to discuss coverage or reliability.

The final paper or report addresses the semiparametric hypotheses with quantitative evidence and a clear causal-inference narrative about finite-dimensional targets and infinite-dimensional nuisance functions.

The submission evaluates whether the naive difference-in-means estimator is biased under confounded treatment assignment and supports the conclusion using the known true ATE.

The submission compares the doubly robust / orthogonalized estimator against simpler plug-in regression or IPW estimators and states whether DML reduces absolute bias or RMSE under nonlinear nuisance functions.

The submission compares cross-fitted and non-cross-fitted versions of the doubly robust estimator, or otherwise clearly analyzes the contribution of cross-fitting to bias, RMSE, or stability.

The submission evaluates whether Neyman-orthogonal scores make the ATE estimate less sensitive to nuisance-function estimation error than non-orthogonal plug-in estimators, using weaker versus stronger nuisance learners or another explicit nuisance-quality diagnostic.

The writeup clearly distinguishes the finite-dimensional causal estimand, infinite-dimensional nuisance functions, orthogonal score or estimator, and evaluation metrics, avoiding confusion between prediction performance and ATE estimation quality.

The README or writeup describes the data-generating process, estimators, nuisance models, cross-fitting procedure, semiparametric target-vs-nuisance relationship, key numeric results, and per-hypothesis outcomes with appropriate caveats on sample size, simulation repetitions, and model misspecification.


Reliability of LLM-assisted statistical model selection under assumption violations

Large language models are increasingly used to assist with statistical data
analysis, including model selection, test choice, and interpretation. However,
statistical model selection requires matching assumptions to data-generating
conditions, not merely producing plausible-sounding analysis text. An LLM or
LLM-like rule-based assistant may recommend inappropriate tests when data are
skewed, heteroskedastic, non-independent, or affected by outliers.

A credible study of this topic creates a controlled benchmark of small
statistical-analysis tasks with known ground truth. The system should compare
model-selection recommendations against an oracle or rule-based reference
across simulated datasets. The research question is: *can an LLM-assisted
statistical workflow choose appropriate statistical procedures under
assumption violations, and how often do its recommendations lead to invalid
inference?*

A simple prompt-only LLM-style recommendation system is more likely to choose standard parametric tests even when assumptions are violated.

Adding computed diagnostic statistics, such as skewness, variance ratio, normality tests, and sample-size information, improves statistical procedure selection accuracy.

Incorrect procedure selection increases false positive rate or reduces coverage under assumption violations such as heteroskedasticity, skew, or dependence.

Can LLM-assisted statistical model selection reliably choose appropriate procedures when assumptions are violated?

Given dataset summaries and analysis goals, choose an appropriate statistical test or model.

Procedure selection using only natural-language task description and variable metadata.

Procedure selection using natural-language description plus computed diagnostics.

Reference selector using known data-generating process or explicit rules.

Baseline that always chooses common parametric procedures such as t-test, ANOVA, or OLS.

Parametric assumptions approximately hold.

Heteroskedastic two-sample setting.

Strongly skewed outcome distribution.

Small fraction of extreme observations.

Correlation exists but is nonlinear or rank-based.

Fraction of tasks where selected method matches oracle-acceptable method set.

Empirical Type I error under null simulations.

Empirical confidence interval coverage when interval estimates are produced.

Fraction of cases where the system correctly identifies relevant assumption violations.

Whether the written explanation cites the correct diagnostic evidence rather than generic statistical advice.

If external LLM API access is unavailable, the submission may simulate an
LLM-assisted workflow using templated recommendations, local heuristics, or
stored model outputs. The benchmark should focus on statistical validity of
recommendations and downstream inference, not on proprietary model access.

Code for generating synthetic statistical-analysis tasks.

Code for evaluating selectors and downstream inference.

Machine-readable selection accuracy, false positive rate, coverage, and diagnostic-detection metrics.

Machine-readable selector decisions with task metadata, diagnostics, oracle-acceptable methods, and selected procedures.

Plots or tables comparing selectors across task types, data-generating conditions, and assumption violations.

Paper-style report explaining task generation, selector designs, oracle rules, diagnostic evidence, results, limitations, and per-hypothesis conclusions.

Setup and run instructions for reproducing the full benchmark from a clean checkout.

numpy pandas scipy scikit-learn statsmodels matplotlib

A canonical results.json file exists at the workspace root with at least the keys: primary_metric (number), metric_key (string), metrics (object with numeric keys), hypotheses (object with h1/h2/h3 entries each carrying a `supported` boolean), summary (non-empty string).

A machine-readable metrics artifact (e.g. results/metrics.json) exists reporting selection accuracy and false-positive rate (or Type I error) broken down by selector and data-generating condition, plus a results/selector_decisions.csv with per-task selector decisions and oracle-acceptable method labels.

results.json metrics MUST contain numeric (non-null, finite) selection accuracy values in [0, 1] for at least the text-only recommender and the diagnostics-augmented recommender, evaluated over more than one assumption-violation condition, so H1 and H2 can be evaluated.

results.json hypotheses.h1/h2/h3 each MUST have an explicit `supported` boolean AND a `details` string ≥ 40 characters quoting the numerical evidence (specific accuracy / false-positive-rate / coverage values + their source artifact) used to reach the verdict.

The submission implements or simulates all four selectors — text-only recommender, diagnostics-augmented recommender, oracle / rule-based reference selector, and an always-parametric baseline — and runs the selected procedures to record downstream inference (p-values, coverage, or Type I error).

The report clearly distinguishes the analysis goal, data-generating condition, oracle-acceptable method set, selected method, diagnostic evidence, and downstream inference metric. Nice-to-have, not blocking.

The report states whether an external LLM API was used or whether a templated / heuristic / stored-output recommender stood in for it. Required for honest reporting but not for scientific correctness.

A credible controlled simulation study evaluating whether LLM-assisted or LLM-like statistical model selection chooses appropriate procedures under assumption violations. The submission should generate statistical-analysis tasks with known reference decisions, compare text-only and diagnostics-augmented recommenders against an oracle or rule-based selector, evaluate downstream inference validity, and connect the numeric findings to the three hypotheses.

Score on statistical validity, reproducible task generation, appropriate reference decisions, and honest discussion of downstream inference. Do not require access to an external LLM API; a templated, heuristic, local, or stored-output recommender can receive full credit if it supports the benchmark question. Penalize generic recommendation text that is not tied to diagnostics or data-generating conditions.

The code implements a controlled benchmark for statistical procedure selection under several data-generating conditions and selector designs.

The submission generates multiple statistical-analysis tasks, including two-sample mean comparison, correlation analysis, and linear effect estimation, with known null or alternative settings and fixed random seeds.

The generated tasks cover meaningful assumption regimes, including approximately normal equal-variance data and at least three violation regimes such as heteroskedasticity, skewness, outliers, nonlinear monotone relationships, or dependence.

The submission implements or simulates the required selectors: a text-only recommender, a diagnostics-augmented recommender, an oracle or rule-based reference selector, and a simple parametric baseline.

The diagnostics-augmented condition computes relevant diagnostic information, such as skewness, variance ratio, normality checks, outlier indicators, sample size, monotonicity, or heteroskedasticity evidence, and makes those diagnostics available to the selector.

The code runs the selected statistical procedures or models and records downstream quantities such as p-values, confidence intervals, Type I error, coverage, or effect estimates where applicable.

Execution produces machine-readable selector and inference metrics adequate to evaluate statistical reliability.

Execution produces a machine-readable metrics artifact, such as results/metrics.json, containing selection accuracy, false positive rate or Type I error, confidence interval coverage where applicable, assumption-violation detection rate, and explanation grounding by selector and data condition.

Reported metrics are aggregated over multiple simulation repetitions, seeds, task instances, or sample sizes, with enough repetition to make selector differences meaningful.

The executed benchmark includes more than one task type and more than one assumption-violation condition, rather than evaluating a single isolated example.

Execution artifacts include selector decisions, oracle-acceptable method labels, diagnostic summaries, and at least one plot or table comparing selectors across assumption regimes.

The final paper or report addresses the three model-selection reliability hypotheses with quantitative evidence and a clear statistical narrative.

The report evaluates whether the text-only recommender over-selects standard parametric procedures under assumption violations and supports the conclusion with selector-decision metrics.

The report compares diagnostics-augmented and text-only selection and states whether computed diagnostics improve procedure selection accuracy or assumption-violation detection.

The report analyzes whether incorrect procedure selection leads to invalid inference, such as inflated false positive rates, poor coverage, or misleading effect estimates under specific violations.

The writeup clearly distinguishes the analysis goal, data-generating condition, oracle-acceptable method set, selected method, diagnostic evidence, and downstream inference metric.

The README or paper describes task generation, selector designs, diagnostic features, oracle rules, key numeric results, limitations, and per-hypothesis outcomes with appropriate caveats on simulation scope and any use or non-use of external LLM APIs.