01 · What breaks
Design for the failure modes, not only the happy path.
Screening decides who gets a chance at an opportunity, so small design errors carry large consequences. These four failures tend to fall hardest on the applicants a scholarship exists to reach.
Proxy discrimination hidden in rules
A rule that looks neutral, such as a school-type requirement, a pincode list or a typed income certificate, can quietly exclude the poorest or most rural applicants. Run every new rule over past applications from different groups before the cycle opens, and compare who it would have excluded.
Poor scans treated as missing proof
A blurred phone photo of a marksheet is not the same as no marksheet. If the system marks it missing, an eligible student loses out because of a camera. Route unreadable or partial documents to a correction request with a clear deadline, and keep the application open while it is pending.
Conflicting documents resolved automatically
When the income on a certificate and the income stated in the form differ, the system should not pick one. Show both, with their sources, and send the case to a reviewer. Automatic resolution hides exactly the cases where a family's circumstances most need to be understood.
Eligibility conflated with merit selection
Meeting the rules only makes an applicant eligible to be considered. Selection, when eligible applicants outnumber awards, is a panel judgement about need, potential and context. If the screening result turns into the selection ranking, the panel stops exercising the judgement the scholarship depends on.
Many applicants are still at school. Under India's Digital Personal Data Protection Act, 2023, processing the personal data of anyone under 18 needs the verifiable consent of a parent or lawful guardian, with most duties applying from around May 2027. Collect it before any document is read. Ask only for documents the rules actually use, mask identity numbers the rules do not need, and have a legal adviser confirm the approach. The DPDP compliance guide covers the wider picture.
02 · Minimum viable model
Each application becomes a review case with its own evidence trail.
In a DozAI mission, each application is a case that runs until it is complete or needs a person. The case carries the rule version it was checked against, so the result can be explained to the applicant, the donor or an appeals panel months later.
| Rule in plain language (illustrative) | Checked against | Possible results |
|---|---|---|
| Enrolled in Class 11 or 12, or the first year of an undergraduate course, this academic year | Enrolment letter or fee receipt, and the stated class | Meets / Does not meet / Needs document |
| Annual family income at or below this cycle's limit | Income certificate, and the stated income | Meets / Does not meet / Figures conflict: send to reviewer |
| Marks in the last qualifying exam at or above this cycle's cut-off | Marksheet | Meets / Does not meet / Unreadable: correction request |
| Not a previous recipient of this scholarship | Programme's own award records | Meets / Possible duplicate: send to reviewer |
03 · Implementation sequence
Move through reviewable gates.
Order matters here: rules are written and tested before a single application is read, and the audit at the end feeds the next cycle's rules.
Translate policy into explicit rules
Rewrite the donor's or scheme's criteria as short, testable statements, each naming the document that proves it and the result when it is unclear. Give the set a version number and a start date. When a donor changes a cut-off mid-cycle, issue a new version rather than editing the old one.
Test rules on diverse historical examples
Before go-live, run the rules over a sample of past applications that spans rural and urban applicants, girls and boys, and different school types. Compare exclusion rates across these groups. A rule that excludes one group far more often needs a reason that stands up to scrutiny, or it changes.
Separate missing from ineligible
Use three results, not two: meets the rules, does not meet them, and needs a document or a review. Send correction requests in the applicant's language, through the channel they applied on, with a deadline. Track how many needs-document cases are later found eligible; that number shows what a yes-or-no rule would have cost.
Run extraction under review
DozAI reads marks, income, category and enrolment details and attaches a confidence score to each field. Low-confidence fields go to a person to confirm before any rule runs on them. Track extraction errors by document type, because income certificates and board marksheets vary in layout and some fail far more often.
Prepare evidence-linked packets
Each packet shows the applicant's answers, the document each was checked against, the rule result with a one-line reason, and anything flagged. Reviewers can accept the result, correct a field, request more evidence or overturn it, giving a reason each time. Every reason is added to the test set used before the next rule version ships.
Audit outcomes and appeals
After each cycle, compare automated results with reviewer decisions and appeal outcomes. If reviewers keep overturning one rule, or appeals from one group often succeed, fix the rule before the next cycle. Link the award record forward to disbursal tranches, mentoring and renewal, so screening is not the last time anyone looks at the case.
04 · Evidence
Measure whether the work became clearer.
Measure whether reviewers now spend their time on the cases that need them, and whether that saving comes without changing who gets through. The human escalation and override design mission explains how reviewer decisions feed back into the rules.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Checking each application for missing or unreadable documents
- Reading stated facts with a confidence score per field
- Applying a versioned rule set and explaining each result
- Assembling reviewer packets with linked evidence
People should decide
- Eligibility and selection
- Interpreting hardship or context
- Document fraud judgement
- Appeals and exceptions
06 · Common questions
Practical questions teams ask.
Questions scholarship teams and donors ask before letting AI near an application queue.
Can AI be used to screen scholarship applications fairly?
Yes, for the mechanical parts, if the rules are written down, tested on past applications from different groups and applied with a person reviewing anything unclear. AI can check completeness, read stated facts and apply rules consistently. It should not decide selection, judge hardship or conclude that a document is forged. Fairness comes from the rule testing and the review, not from the model.
What information does an AI scholarship screening mission need?
The cycle's eligibility rules in plain language with a version number, the application answers, the supporting documents, the applicant's consent for this purpose, and a list of who reviews which kind of exception. It also needs past applications with known outcomes, with personal details removed where possible, so the rules can be tested before go-live.
What should a person decide in scholarship screening?
A person should decide any case where evidence conflicts or is unclear, how to weigh hardship or unusual circumstances, whether a document may have been altered, who is selected when eligible applicants outnumber awards, and every appeal. The system's job is to make those decisions quicker to reach by putting the right evidence in front of the reviewer, not to make them.
What audit trail should scholarship screening produce?
For every application: the rule version applied, each extracted value with its source document and confidence, the result of each rule with its reason, every reviewer action with name, time and reason, and the appeal outcome where there was one. That trail lets the programme explain a rejection to an applicant or a donor long after the cycle has closed.
Where can AI scholarship screening go wrong?
Most often through rules that exclude groups without anyone intending it, poor scans treated as absent documents, conflicting figures settled automatically, and screening results reused as selection rankings. Less visibly, staff can stop reading packets closely once the system seems reliable. Sending a random sample of cases that met the rules to review every cycle catches that drift.