Additional course links
You leave with: A field-and-document plan with definitions, separate submission states and a tested correction path for one pilot program.
Where this fits: The field-role table in Lesson 1 says what each R-2 field is for. This deep dive answers the next question from that exercise: how should each field and upload be collected so its evidence survives review, correction and reporting? It follows A-44, which arrives without its fiscal-sponsor letter. Bring back a definition for every field, a set of submission states, and a correction path you have tested.
Watch · 0:00–1:14 · collect from any source, read on arrival
Unmesh describes the three parts of an AI-native intake: collect from any source, configure each field with a prompt so it is read on arrival, then ask questions of the result. Watch the workforce example, where barriers are drawn from applicants' own statements. That only works if each statement was collected in the applicant's words and attached to the right record. Watch on YouTube ↗
Jump to: 0:28 — barriers in applicants' own words · 0:47 — a prompt for each field
Collecting applications clean at the source means capturing each answer and document with a clear definition, a stable applicant ID and its submission history, so it can be read and reviewed without cleanup. Check required items before submission, keep every file attached to the right application, and hold completeness, eligibility and merit review as separate states. Clean collection removes the rework that usually sits between the deadline and the first review.
Pair structured answers with the documents behind them
Use fields for information that needs a consistent format or comparison across applicants. Use documents for evidence whose context matters. A-31's request of $24,000 belongs in a defined currency field; its budget upload explains how that money is spent. Its employer letter is a document; the form's question about which commitments are confirmed gives reviewers structured context for reading it. Neither should overwrite the other.
| Source | In R-2 | Keep with it |
|---|---|---|
| Form answers | Gates, amount requested, the four narrative answers | The field definition and instruction version |
| Uploads | Budget, employer or partner letter, Form 990 if the organization files one, fiscal-sponsor letter if needed | The file, its version and the date received |
| Clarification responses | A-44's fiscal-sponsor letter, sent after a request | The request it answers and the date |
| Existing records, where permitted | A returning applicant's profile from an earlier round | Confirmation that it is current and belongs to this applicant |
A record from an earlier round is not automatically part of this application. Confirm permission, currency and the right applicant before it enters review.
Define the field before configuring validation
A number without a unit, period or population can pass every validation rule and still be impossible to interpret. Write the definition first, then set the rule that enforces it.
| Information | Collection rule | Review check |
|---|---|---|
| Amount requested | A number in US dollars; the grant request, not total program cost | $25,000 or less; matches the request line in the budget |
| Young people to be served | Unique people aged 16–24 over the grant year | Counted as people, not registrations or sessions |
| How you will know it worked | A measure, its denominator and timing, such as job placements at 90 days | An outcome, not only an activity count |
| Budget upload | Accepted formats listed; the applicant's own workbook is fine | Totals reconcile with the form; unreadable files flagged |
| Employer or partner letter | Say what the letter should show: a confirmed placement role, or interest | Intention kept apart from a confirmed responsibility |
| Fiscal-sponsor letter | Required when the applicant is not a 501(c)(3) | Present, signed and naming the applicant |
Give "not applicable" and "unknown" their own answers where both are valid. A blank should not have to mean missing, zero and not applicable at once, and no applicant should have to invent a value to move to the next page. The outcome row is where intake meets reporting: if its definition is weak, the outcomes, not outputs deep dive shows how to tighten it before the round opens.
Make errors understandable and recoverable
Tell applicants before they start what is required: attachments, accepted formats, size limits, the deadline and its time zone. When something is wrong, the message should name the field and how to fix it. "Enter the amount requested in US dollars, as a number. The R-2 maximum is $25,000" helps; "Invalid" does not.
The W3C guidance on form validation recommends accepting different valid forms of input and giving accessible notifications, and its error-notification guidance stresses clear messages with correction instructions. Test the real form with a keyboard and with assistive technology; a red outline is not enough.
Test save-and-return and interrupted uploads too. A success message should mean a stored submission, not a button click, and the confirmation should say what happens next.
Keep completeness, eligibility and assessment in separate states
A submission can be received but incomplete, complete but ineligible, or eligible but not yet assessed. Give each its own state so everyone can see the next action and who owns it.
| State | What it means | Who acts next |
|---|---|---|
| Received | Submission and its sources recorded with the applicant ID | Intake check |
| Completeness checked | Each required item present, missing or unreadable | Program staff, if anything is missing |
| Held for clarification | One request sent under the published policy | The applicant, by the stated deadline |
| Eligibility reviewed | Each gate recorded as pass, fail or unresolved | Program staff |
| Ready for merit review | Evidence and the current rubric with the assigned reviewers | Reviewers |
Horizon example · fictional
A-44 applies through a fiscal sponsor but uploads no fiscal-sponsor letter. Completeness: missing. The second eligibility gate cannot be confirmed, so it is unresolved, not failed. A-44 is held and sent one clarification request naming the letter. The letter arrives within the window, the gate passes, and A-44 moves to merit review and is scored like every other application.
A-44 was never ineligible and never scored low. Had the states been merged, a missing file could have become a rejection nobody decided. An AI flag or a missing upload should never silently become an irreversible outcome.
Analyze on arrival without treating extraction as verification
With a prompt configured for each field, a new answer or document can be read the moment it arrives: text structured, a draft rubric score prepared, inconsistencies flagged. When A-31's employer letter lands, the draft feasibility finding says the letter expresses interest rather than confirming a placement role, and quotes the sentence. A reviewer opens the letter and confirms. The finding saved the reviewer the search; the reviewer still made the call.
When two sources disagree, for example the amount on the form and the request line in the budget, the useful finding names both values and where each came from. Do not let the system pick one silently or rewrite the applicant's file. Staff decide whether the difference is already explained or needs a question.
Document reading can also fail. A scanned table, a locked PDF or a photographed page may yield partial text. Keep the original, mark the extraction status, and route the exception to a person. A confident summary is not evidence that every page was read.
Handle corrections without losing the earlier submission
When A-44's letter arrives, it joins the same record as a new item, dated and linked to the request it answers. The original submission stays as it was, so a reviewer or auditor can see what arrived when. A corrected file works the same way: a new version on the same application, with a note on whether it replaces the earlier one for this assessment or adds context.
Do not merge applicants because their names look alike. One organization can have several contacts, and a fiscal sponsor may sponsor more than one applicant. Use stable IDs and a reviewed process for resolving duplicates.
Check permissions before adding more sources
Assign access by role and stage. R-2's community volunteer reviewers need the narratives, letters and rubric; they may not need contact details or the Form 990. Test access with a real account for each role. Collect and show only what has a stated purpose, and keep any consent with the source it covers.
In Sopact Sense, each applicant has a persistent unique ID, so A-44's late letter, A-31's draft scores and every later report attach to one record. An Intelligence Cell reads each field or upload as it arrives, with the prompt you configure, and its finding links back to the source. Whatever tool you use, the definitions and states above come first.
Put it into practice
Run one deliberately imperfect application
- Use your R-2 field-role table from step 1 of the workbook. Write a definition and a review check for every scored field and upload.
- Build a small test set from
horizon-r2-applications.csv: A-31 as a valid submission, A-44 with its missing letter, and one fictional test record with an unreadable budget scan and a form amount that disagrees with its budget. - Run each through your submission states and write down where it stops and who acts next.
- Add A-44's letter as a correction. Check that a reviewer can see the original submission and the letter, with dates, without guessing which is current.
- Record each failure, fix the rule or instruction, and rerun the affected test.
Download the workbook (PDF)
Practice data: horizon-r2-applications.csv · horizon-rubric.csv · calibration-scores.csv · eastgate-q1-update.csv
Check your reasoning before moving on
A-31 should pass completeness and every gate and reach merit review with its employer letter flagged as interest, not commitment. A-44 should stop at held for clarification with its fiscal-sponsor gate unresolved, then reach review once the letter arrives. The test record should stop at completeness twice: the budget is unreadable, and the amount mismatch needs a named question, not a guess. If any of the three landed in "ineligible" or received a low score instead, your states are merged somewhere. The pass condition is that the next reviewer can assess each submission without a separate folder or a call to whoever built the form.
Questions grant teams ask
What does clean-at-source application collection mean?
It means collecting understandable, consistently defined answers and documents under a stable applicant ID with their submission history, so they can be read and reviewed without cleanup. It removes avoidable rework. It does not verify that every claim in an application is true; reviewers still check the evidence against the source.
Should every answer be a structured field?
No. Use structured fields for information you compare across applicants, such as the amount requested or ages served, and narrative answers or documents where context matters, such as a delivery plan or an employer letter. Keep definitions, units and periods with the values, and keep the source behind any extracted finding.
Does a missing attachment mean the applicant is ineligible?
Not necessarily. Apply your published completeness and clarification rules. A missing document, confirmed ineligibility and a low merit score are different states with different recorded reasons. In the Horizon example, A-44's missing fiscal-sponsor letter held the application for one clarification; it was then scored like the rest.
Can AI analyze an uploaded application immediately?
Where configured, yes: each answer or document can be read as it arrives and given a draft finding or score with the sentence behind it. Staff still check extraction, evidence and uncertainty. A failed read of a scanned or locked file should show as a failure, not as a completed review.
How should a corrected file be handled?
Add it to the same application as a new, dated version, linked to the request it answers if there was one. Record whether it replaces the earlier file for the current review or adds context, and keep the earlier version available to authorized reviewers rather than overwriting it.
What should be tested before launch?
Test a valid submission, a missing attachment, an unreadable file, two values that disagree, a correction, the confirmation message and each role's access. Check both sides: the applicant can understand and fix errors without losing work, and the reviewer can trace every finding to its source.