Case study · Public sector · Saudi Arabia
An AI that agrees with your experts most of the time can still be wrong in exactly the cases that matter.
Teaching an AI to say no
Screening research grant proposals with an LLM: a proof of concept for a Saudi government agency, tested against its own reviewers' past decisions.
Chapter 01 / The ask
Every proposal, read in full, at every stage.
The agency funds university and institute teams to turn a lab result into a working prototype. Each proposal arrives as a long PDF with budget tables and scanned pages, and reviewers read it at every stage it reaches, including proposals later rejected for a missing section or a budget over the limit.
The question they brought us: could an AI do the first pass of each stage, and explain itself well enough for staff to act on it?
Complete, and within budget and duration limits?
7 criterianext stage
Meets the programme's eligibility criteria?
6 criterianext stage
Feasibility, methodology, impact, relevance
4 criteriaWhat the system had to do
- A verdict and a reason for every criterion
- Staff decide when each stage runs
- Fixed rules in code like budget and duration limits
- Read the original PDF scanned pages and all
- Prove itself against reviewers' past decisions
Chapter 02 / First attempt
It sounded right. Often, it wasn't.
Version one used the standard recipe for long documents: cut each proposal into chunks of about a thousand characters, pull the chunks that look most relevant to each question, and answer from them.
The answers were polished and often wrong. A budget check needs the whole budget table, and chunking split it. The model answered confidently from half the evidence, which made the mistake hard for staff to spot.
Budget table, first half
Budget table, second half
“The budget is within the programme's limit.”
Confident. Based on half the table.Illustration of the failure the team found in testing.
Chapter 03 / Reading it properly
Give every question the whole evidence it needs.
The proposals follow the agency's template, so we stopped guessing. Each PDF is converted to text with its headings, tables and scanned pages intact, then split into 18 standard sections. Each criterion becomes one AI call that sees only its own sections and returns a verdict and a reason in a fixed format.
18 standard sections
- Principal investigator
- Title
- Abstract
- Budget and timeline
- Aims
- Research plan and methodology
- Impact
- Intellectual property
- Definition of success
- Risks
- Management plan
- + 7 more
Mandatory. If missing, the proposal stops with an error instead of the AI inventing it.
Each criterion gets only what it needs
Requested budget SAR 1,450,000
Duration 36 months
Compared with the programme's maximum budget and duration
Pass or fail, never a judgement call
Values from the sample proposal used in this case study.
Chapter 04 / The test
Agreement looked fine. Until we split it.
The agency's past proposals, and how far each one got, became stage-by-stage tests. Every version was scored against the reviewers' real decisions, and a crash counted as a rejection.
When we reported agreement separately for proposals the reviewers had passed and those they had rejected, the problem appeared: in most runs, the models agreed more often on the passes. The overall number had been hiding an AI that said yes too easily.
Illustration of the pattern, not project figures.
“The proposal describes how much water leaks waste, which shows a clear market need.”
Nothing in the proposal shows a building owner would pay for the sensor.
The sample proposal was written by our team in the agency's format, because real proposals are confidential. The AI's reason is paraphrased to show the pattern.
Chapter 05 / Teaching it to say no
Five versions, one test.
Rewording the instructions didn't remove the leniency, so we fine-tuned the model on examples of how the agency evaluates proposals. Each version was judged by the same stage tests, which is how every swing showed up.
- V1Chunked retrieval
An answer per criterion
Evidence missed by chunks
- V2Section routing
Whole sections, structured verdicts, rules in code
Too lenient
- V3First fine-tune
The agency's format and vocabulary
Agreed on fewer rejections
- V4Reasoning fine-tune
Reasoning trained with each answer
Recommended none of the funded proposals
- V5Balanced data + web search
Agreed on passes and rejections more evenly
Tested on a limited set of past proposals
A spreadsheet's 32,767-character cell limit silently trimmed long training examples before they reached training.
Asked what the programme's acronym stood for, one version confidently described a business analytics group at a Canadian university.
A dataset balanced between funded and rejected proposals, each with its reasoning, plus web search for facts a proposal can't prove about itself.
The final comparison is across development versions, not a controlled experiment.
Chapter 06 / Staff in charge
The AI proposes. Staff decide.
Staff see a board of proposals by stage. Opening one shows every criterion with its verdict and the AI's reason. Any answer can be corrected through a feedback form that stores the correction against the proposal, and nothing moves to the next stage until a member of staff starts it.
The portal also suggests five expert reviewers whose recorded expertise is closest to the proposal's title.
Pre-screening
Screening
Scientific review
Acoustic leak sensors · Screening
Team and track record
Market success: no evidence building owners would pay
Suggested experts: 5 matches
How it fits together
One proposal, end to end.
The live path runs from upload to the staff portal. Beside it, an offline loop tests every version against past decisions and trains the next one.
Chapter 07 / Road to production
An honest list of what production needs.
A proof of concept is built to answer one question, so parts of it stay deliberately simple. This one ended with a clear list, which makes the production budget something you can scope rather than guess.
- Sections by content
Recognise sections from what they say, not only their headings
- Arabic passages
Judge them instead of removing them, and test on Arabic proposals
- Visible sources
Show web results beside each verdict so staff can check them
- Bigger test sets
Measure agreement on more past decisions before real funding calls
- Durable pipeline
A job queue that survives restarts, behind authentication
What other teams can take from it
Convincing isn't correct. Test it on the decisions it should reject.
The proof of concept answered its question: an LLM can do a first pass that staff can check, if it reads the right evidence, leaves fixed rules to code and is tested against the agency's own decisions.
- Test against decisions you already made. Your history is a better judge than a demo.
- Score the noes separately. Overall agreement hides an AI that approves too much.
- Let the model read, and people decide. Fixed rules in code, every verdict visible and correctable.
Thinking about AI for reviews, approvals or screening?
Let's look at how you'd know it's right, before anyone builds it.
A conversation with the engineers who built this proof of concept. Bring a process, a pilot or a vendor's claims. We'll share how we'd test it against your own past decisions, and tell you honestly if a proof of concept isn't the right first step.