Grant diagnostics · NIH F31

A machine that explains why the grant didn't get funded

Feed it a rejected NIH F31 fellowship application and its reviewer critique. It names the failure mode that sank the application and cites the exact lines that prove it. Plain text and one shell script, verifiable end to end.

Names the failure mode Cites the source line Refuses to guess 78-check verified

01First, what is an F31?

The F31 is a fellowship from the National Institutes of Health that pays for a PhD student's dissertation research, usually two to three years of stipend and tuition support. Around 1,800 of them are active at any time, and the top ten universities hold about 30% of those awards.

Applying is a paperwork gauntlet with strict page limits, and a panel of reviewers scores the result. Most applications are not funded. When yours isn't, you get back a critique document and a score, and it is on you to figure out what actually went wrong. That gap is what this project attacks.

Wide editorial illustration: stack of grant application pages with gold magnifying glass highlighting the primary cause card
Why it mattersMost F31s are not funded, and the critique document is the only feedback that comes back. Decoding it correctly is the entire next move.

02What the diagnostician does

You hand it an application plus its critique. It runs five stages, each a folder with a written contract for what comes in and what goes out:

Five-stage pipeline: 01 Intake, 02 Extract, 03 Match, 04 Verify, 05 Diagnose, forking to Named Cause or No Diagnosis
  1. Intake. A questionnaire pins down the basics: which institute, first submission or resubmission, what score came back.
  2. Extract. Pulls the claims, aims, and reviewer complaints out of the documents into structured records.
  3. Match. Compares those complaints against a table of known F31 failure modes.
  4. Verify. Checks every match against the source text. No citation, no match.
  5. Diagnose. Writes the verdict in plain language. If the critique matches nothing in the table, it says so and refuses to invent a cause. That refusal path has its own test case.
Why it mattersA dense critique becomes a named, cited cause instead of a guess. Every claim traces back to a line you can check.

03The paperwork it has to understand

Part of why diagnosis is even possible: the F31 is rigidly structured. Every component has a hard length limit, so complaints can be traced to a specific, bounded document. The bars show each limit relative to the largest.

F31 Application Components spec sheet showing length limits for Abstract, Biosketches, Research Strategy, and Reference Letters
Why it mattersHard limits mean every reviewer complaint points at a specific, bounded document. That is what makes automated diagnosis tractable at all.

04How reviewers score it

Since January 2025, fellowship review uses a three-factor rubric. The diagnostician encodes this rubric as a schema-checked JSON file, and its verification gate validates the encoding on every run.

Scorecard set for F1 Candidate Preparedness, F2 Research Plan, and F3 Sponsor Commitment leading to Impact Score percentile payline decision
From scores to a decision: discussed applications get an overall impact score from 10 (best) to 90, which converts to a percentile against the study section's recent history. Each NIH institute funds applications inside its payline, which for fellowships has typically run somewhere in the 15th to 25th percentile band. Outside the payline is the outcome this tool exists to explain.
Why it mattersThe rubric is encoded and machine-validated, so the diagnosis speaks in the same three factors the reviewers scored.

05Where this carries over

Nothing in the pipeline is F31-specific except two data files: the failure-mode table and the rubric. The rubric file already declares itself valid for the F30, F31, F32, and F33, because NIH moved all four fellowship types onto the same three-factor review in 2025. Swapping the two data files retargets the whole system.

NIH funds an entire research career as a relay of awards, stage by stage. Each handoff is its own application, its own review, its own way to be rejected with a critique in hand. That makes the whole pathway addressable:

NIH Research Career Pathway Relay timeline showing Undergraduate through Faculty award mechanisms

Where it helps most: med school students

The medical-school column is the busiest handoff on that map, and the one this system is built closest to. If you're an MD or MD/PhD student, the awards that fund you are:

Medical school timeline detailing T35 summer research block, F30 dual degree, and F31 PhD phase timing
  • T35 pays for the summer research block, usually after first year. Your school holds the grant; you apply internally.
  • F30 funds the full MD/PhD dual degree, both phases. Applied for directly, reviewed on the same three-factor rubric this tool already encodes.
  • F31 covers the PhD phase for dual-degree students outside a formal MSTP slot. This is the award the diagnostician is proven on.

A rejected F30 or F31 costs a med student a resubmission cycle, which can mean a full extra year against a fixed curriculum calendar. Reading the critique correctly the first time is the whole game, and that is the exact job this pipeline does. F30 support is a rubric-file swap away.

The nearby pivots, in rough order of distance: the other fellowships (F30, F32, F33) are a config change, since they share the 2025 rubric. The K series and training grants (T32, T35, K12) need a new failure-mode table but keep the same diagnosis shape: bounded documents, a written critique, a payline. Past NIH, any scored funding application fits, from NSF proposals to foundation grants to SBIR submissions. Wherever a rejection arrives with a written critique and a rubric, the intake-extract-match-verify-diagnose chain applies, and the refusal path matters more, since new failure-mode tables start out thin.

That's the value anchor: not an F31 gadget, but a grant-diagnostics pattern, proven first at the F31 handoff and pointed at the rest of the relay.

Why it mattersOne diagnostic pattern covers every scored funding mechanism. The F31 is the first instance, not the ceiling.

06Why I think the build is interesting

There is no framework here. The whole system is markdown contracts, JSON with a self-declared schema, and one verification gate in shell. A fresh agent dropped into the repo reads a 42-line entry file and knows where it is and what to do next. That was tested cold, and the transcript is in the repo.

The gate runs 78 checks, and it has a selftest that injects four deliberate defects to prove the gate can still fail. During the build, that selftest caught a real bug in the gate itself: a grep flag that BSD grep silently ignores, which had one check passing on a tree that should have failed. A gate that polices itself earned some trust that day.

Why it mattersYou do not have to trust the diagnosis. You can run the gate and watch it try to fail.
Read the source on GitHub