NIH Grant Strategy for Computational and AI Research

Why Computational Grants Face Unique Review Challenges

Most NIH study sections are mixed. Even panels designed for computational biology — GCAT, BDMA, and several integrated review groups in the ZRG1 cluster — include reviewers who spend most of their time at the bench. Your three assigned reviewers might be strong computational scientists, or two might be experimentalists who are skeptical of any aim that produces a model instead of a western blot. You often won't know which until you see the summary statement.

This creates a specific writing problem. When you write "we will train a transformer-based classifier on single-cell RNA sequencing data from 10,000 patient samples," an experimentalist reviewer hears vague methodology, not a concrete aim. The benchmark you're trying to beat, the held-out test set you've pre-specified, the biological question that the model actually answers — none of that is implied to a reviewer who doesn't work in this space. Your job is to make it explicit.

The second challenge is the perception that computational projects can run indefinitely without a clear deliverable. Reviewers worry about scope. If Aim 1 is building a tool and Aim 2 is applying it, what happens to Aim 2 if the tool doesn't work well enough? That sequential dependency is one of the most common reasons computational R01s score poorly on Approach. The fix is structural, and it has to happen before you open a word processor.

Choosing the Right NIH Institute and Study Section

The right institute depends almost entirely on the biological question, not the method. An AI project that predicts cancer drug response belongs at NCI. One that parses clinical notes for psychiatric diagnoses belongs at NIMH or possibly NLM. A genomics algorithm identifying structural variants belongs at NHGRI. Method-first framing — "this is a machine learning project" — is one of the most reliable ways to get routed to the wrong panel, or to land in front of a study section where your application sits awkwardly between computer science and biology without landing in either.

For study section assignment, email the program officer before you submit and ask whether your project is a good fit for a specific integrated review group. A brief message — two sentences on the biological question, two on the computational approach — usually gets useful guidance within a week. The cover letter is your formal assignment request, but that conversation often shapes where you land more than the letter does. Program officers have seen dozens of applications like yours and can flag reassignment risks you won't find in the FOA text.

How to Write Aims That Work for Computational Projects

The most common mistake in computational aim-writing is confusing a task with a hypothesis. "Train a deep learning model to predict protein-ligand binding" is a task. "We will test whether incorporating molecular dynamics features into a graph neural network improves binding affinity prediction by at least 15% over state-of-the-art benchmarks on the PDBbind dataset, and we will identify which feature classes drive that improvement" is a hypothesis with a pre-specified success criterion. Reviewers can tell immediately whether the project would be falsifiable, and whether they'd be able to evaluate whether it succeeded at the annual progress report stage.

The independence problem is harder to solve. Computational projects often genuinely are sequential: you need the tool before you can apply it. One approach that works is anchoring each aim to a distinct biological question rather than to a stage in the pipeline. Aim 1 tests an established computational approach on a new biological context and generates interpretable findings. Aim 2 introduces a novel methodological innovation and tests whether it outperforms Aim 1. Aim 3 validates in an orthogonal dataset or biological system. The pipeline still exists underneath, but each aim produces something publishable on its own. Reviewers can follow a credible path to partial success even if Aim 2 doesn't deliver the hoped-for improvement.

One more thing: the FORMS-I application changes in 2026 didn't touch the one-page limit on Specific Aims. If your aims don't fit on one page, you're probably explaining methods rather than science. Trim the how and sharpen the what.

Rigor and Reproducibility When Your Lab Is a Laptop

NIH's rigor and reproducibility requirements were written with wet-lab science in mind, but they apply to computational projects too. Reviewers are increasingly flagging computational grants that don't address these criteria — not because the requirements are new, but because reviewers are getting more comfortable asking the question. The good news is that computational labs often already have the practices that satisfy these requirements. The problem is that most applicants don't say so in the grant.

The NIH Data Management and Sharing Plan is required for any project generating scientific data, including computational projects. If you're using publicly available data but generating new derived datasets, model weights, or analysis outputs, you need a plan for those outputs. If you're using only existing public data and generating only code, say so clearly and describe what you will share and where. Ambiguity on data sharing is a reviewer flag that's easy to avoid.

Preliminary Data Strategy Without Bench Experiments

Reviewers expect preliminary data that shows the signal you're chasing is real and that your approach is feasible. For computational projects, that doesn't require wet-lab experiments. The most effective preliminary data for an AI or ML application usually includes three things: evidence that the biological signal exists in real data (even from a public dataset), a pilot benchmark showing your approach outperforms a simple baseline, and some indication that you can move between computational results and biological interpretation.

That last point deserves emphasis. Reviewers who are skeptical of purely computational projects tend to ask: "What does this tell us biologically?" If your preliminary data answers that question even briefly, you've addressed the most common axis of skepticism before the reviewer writes their critique. A sentence like "pilot analysis on 500 samples identified three metabolic pathways with consistent signals across two independent cohorts, consistent with published findings in tissue X" is worth more to most reviewers than a 90% cross-validation accuracy reported without biological context.

Don't apologize for not having wet-lab data. Some applicants write as though the absence of a gel image is a weakness to explain away. It isn't. Strong computational preliminary results from well-characterized public cohorts can be entirely sufficient. What reviewers are checking is whether your approach is feasible and whether the science is credible, not whether you generated the underlying data yourself.

Budget and Personnel: What Reviewers Expect to See

Computational R01 budgets get flagged for two opposite problems: too little personnel and too much computing. The sweet spot for most R01-scale computational projects is roughly 70 to 80 percent personnel costs, with computing justified as a specific line item rather than an open allocation. If your budget runs 40 percent computing costs, reviewers will wonder whether the money is going to science or infrastructure. Reviewers also notice when there's no one on the team who can interpret the outputs biologically — budget allocations communicate your team's expertise before the Investigator section does.

Cloud computing is generally acceptable under current NIH policy, and most institutes have moved away from funding dedicated server hardware. Be specific in the budget justification: list the platform, estimate compute hours for the analyses in each aim, and attach a cost per hour. "AWS GPU compute for model training in Aim 2: approximately 1,400 GPU-hours at $3.20/hour, totaling $4,500/year" is a justification reviewers can evaluate. A lump sum labeled "cloud computing costs" is not.

For personnel, computational projects typically need a mix of domain and methods expertise. A bioinformatics postdoc who moves between genomics and machine learning is more fundable than one who exclusively does ML. If your team is all methods, add a collaborator with biological expertise and describe their specific role. Reviewers are checking whether anyone on the team can put a computational result in front of a biologist and explain what it means.

Frequently Asked Questions