Check every application against the rules.
Before the funder does.
Grants PreFlight: Submission Assurance reads a scheme's guidelines once, under your supervision, and turns them into checks.
Point it at a draft application and it automates the scan against every rule it breaches, the clause, the page, and how to fix it.
Grants PreFlight
Submission Assurance
Be part of our current build design
Developing with Australian research offices.
Here's how we think grant compliance checking should work: read a scheme's guidelines once, under your supervision, turn them into checks your office signs off, then run any draft application against them, with the clause, the page and the fix for every breach.
Nothing should fail on a technicality.
The model reads the guidelines. It never reads your applications.
January to April, your team is a proofreading service.
Page limits. Word counts. Font sizes. Margins. Required sections. Certifications. Attachment naming.
Budget caps per year. Every scheme different, every round slightly changed, all of it buried in prose PDFs that run past a hundred pages.
Your officers check it by eye, under deadline, at volume. They're good at it — that's the problem. It's careful, skilled work that produces nothing except the absence of a disaster, and it eats the exact weeks when researchers most need help with the parts that are actually assessed.
And the failure mode is brutal. An application ruled ineligible for a missing statement. A section marked down for running a page long. Months of work undone by something a rule could have caught in seconds.
The mass tickbox work should be done by machines.
The work that wins grants is human effort.
We’ve heard this idea from every Research Office team we’ve worked with. But nobody automated this before because the rules live in prose, they differ across every scheme, and they change every round. Hand-coding them was never worth the effort. Now the calculation has changed.
The design is simple. An AI model reads a scheme's guideline documents and proposes a set of checks, each one quoting the exact sentence it came from. Your team reviews them, accepts, edits or rejects each one, and signs the ruleset off in their own name. From there, checking an application is arithmetic. No judgement, no guesswork, and every line of the report points back to a clause on a page.
The software doesn’t assess your applications. No score, no band, no ranking, no prediction. It checks rules; it doesn't judge research. That's a permanent boundary, not a phase-one limitation.
Grants PreFlight
Submission Assurance
This is our early prototype system. We designed the interface and recorded a walkthrough of it so there's something concrete to react to, the scheme content and the draft application in it are illustrative. This is in early development and testing stage, and what gets built depends partly on what research offices tell us in the next few months.
How it Works
Three steps.
Your team stays in charge of all of them.
01 Bring in the guidelines
Upload the Grants guideline documents for a round. The system proposes a set of checks, each quoting the sentence it came from. Anything it can't quote is discarded before anyone sees it. Anything ambiguous is flagged for a person, not guessed at.
02 Verify and sign off
Your team reviews each of the proposed rules beside its source clause and clicks to accept, edit or reject them. Nothing publishes until every rule carries a decision and a named officer signs it off. There's no bulk-accept button, by design, so the human still gets the final approval.
03 Check applications
Upload the Grant Application draft. Watch the dashboard: what breaches a rule, where is it in the document, which clause does it breach, including the page number, and what to do about it.
Blockers first. Send it to the CI, re-run it when the fix comes back.
That's the current design, built with real Research Office team members.
Let us know what you think and if it’s something that your team can use.
Why its being built
Most Research Software arrives finished, designed by people who have never submitted a round, and your team spends the next three years working around it. We know, we’ve seen it before.
We want to do this the right way, show you the thinking while it's still early and easy to change, and be told where it's wrong and where it’s right.
The recent AI developments make building simpler, easier, quicker, and smarter. Design it. Build it. Test it. Iterate. Use.
What we're after is a conversation with research offices willing to walk us through how their rounds actually runs, where the time goes, where the risk sits, what you've already tried and what you've already rejected.
Bring your worst scheme, the one with the formatting rules nobody can keep straight.
If it turns out this doesn't fit how you work, that's a useful answer and we'll tell you so. If it does, you'll have shaped it before a line of it was written.
Grants PreFlight: Submission Assurance is an inflight prototype build. The walkthrough on this page is a recorded demonstration of a the current interface using illustrative scheme and application content.
