Additional course links
You leave with: A documented batch boundary, a source-backed barrier count for Horizon's 64 R-2 applications and a one-page decision brief.
Where this fits: Lesson 2 has the AI Assistant read Horizon's whole R-2 round and propose the 10 strongest applications. Before your committee trusts that shortlist brief, someone has to ask whether the numbers in it hold up: how many applications, which ones, and where each claim came from. This deep dive answers that. You bring back a checked batch summary for step 2 of the workbook.
Watch · 2:13–3:51 · the batch, read and questioned
Unmesh's 80 applications are each read as they arrive, then he asks questions across the pool: the total, the barriers each person faces, who is on top. Watch for his emphasis on reliable answers. This page is about what makes a batch answer reliable: a declared unit, a clear boundary and the source behind every count. Watch on YouTube ↗
Jump to: 2:13 — 80 applications, read on arrival · 2:42 — ask questions across the pool · 3:25 — "which 10 are the best"
Analyze a batch of grant applications by defining the round and the records included, checking that the sources are readable, then looking at individual assessments and cross-application patterns separately. Count distinct applications, allow overlapping categories and keep the source passages behind each one. Keep rare but important issues visible, and never treat the most common topic as an automatic funding priority.
Decide which question the batch is answering
A batch can answer several different questions. What work is being proposed? Which applications meet the gates? How do the proposals score against the rubric? Where is evidence thin across the round? Decide which output you need before you ask an assistant for a summary.
A topic overview describes the applications received. A scored review assesses each proposal against the calibrated criteria. A funding decision adds budget, eligibility and the round's selection rules. These inform one another, but they are not interchangeable, and a common topic is not a reason to change the rubric mid-round. If the batch raises a new strategic question, record it for the next round.
Define the batch before counting anything
For R-2 the batch is the 64 applications submitted by the deadline. Write down the choices that make that number reproducible.
| Boundary decision | Horizon R-2 · fictional |
|---|---|
| Round and cutoff | R-2, applications submitted by the deadline |
| Counting unit | Distinct applications, by application ID; not organizations, not young people, not mentions |
| Versions | One analysis version per application; earlier versions kept. A-44's clarification is added to A-44, not counted as a new application |
| Fields included | The four narrative answers, budget, employer or partner letter, Form 990 where filed |
| Different boundaries | The topic overview uses all 64; the shortlist uses eligible, scored applications only. Label which is which |
| Exclusions | Any withdrawn or duplicate submission is listed with the reason, not silently dropped |
One organization may submit more than one application. One application may mention transportation five times. Those are different counting choices, and without a declared unit a confident-looking total can mislead.
Make sure the source material is usable
Check that required files open and that text extraction kept the headings, tables and footnotes that matter. A scanned budget with a table read as a jumble of numbers is an exception, not data. Keep unreadable or missing material on an exception list instead of letting the assistant fill in the blanks.
Before analyzing all 64, compare a sample of extracted values with the originals, including a difficult file as well as a clean one.
Keep the records connected. In Sopact Sense each application has a persistent unique ID that holds its answers, uploads, clarifications and Intelligence Cell readings, so the same context supports both a criterion score and a question across the round. What the assistant can answer still depends on the sources actually supplied.
Use topics for an operational overview
For a working overview, define a few categories such as proposed activity, delivery area or the barriers applicants describe for the young people they serve. Write a short inclusion rule for each, allow several categories per application, and keep ambiguous cases in view.
A list of frequent words is not a thematic analysis. Braun and Clarke's explanation of thematic analysis describes themes as patterns of meaning that answer a research question, and their methodological guidance distinguishes a theme's value from its frequency. What this page describes is a descriptive, coded overview for running a round, not a full qualitative study.
Separate what an applicant says from what you interpret. "Transportation barrier" needs evidence about young people's access or travel, not the word "bus" in a description of a site.
Worked example: barrier counts overlap
Horizon's inclusion rule for a barrier: the application describes it as something that keeps participants from enrolling, attending or holding a job. Across the 64 R-2 applications, the reading returns these counts.
| Barrier described | Applications | Share of 64 | Read it as |
|---|---|---|---|
| Transportation | 24 | 38% | Common in this round; check delivery plans |
| Childcare | 16 | 25% | Overlaps with transportation; not a separate group |
| Both | 8 | 13% | Already inside the two rows above |
| Either | 32 | 50% | 24 + 16 − 8 = 32 distinct applications |
| Accessibility for participants with a disability | 1 | 2% | Rare here; not therefore unimportant |
Horizon example · fictional. Shares are rounded; they do not sum to 100% because an application can carry several labels.
These are application counts, not counts of young people affected. They describe the organizations that applied to this round, with the questions and selection effects that come with it, so they do not measure the prevalence of these barriers in Lake County.
The single accessibility application stays in view. Decide the response from what it says and the program's responsibilities, not from a minimum-mention threshold.
Keep the evidence behind each category
For each category, keep the definition, the included application IDs and the passage that placed each one there. One illustrative quote helps a reviewer see what the category means, but it does not verify the count. Check the full inclusion list, or a sample large enough for the decision.
Look at the exclusions too. If the reading missed a transportation barrier described as "the last bus leaves before the shift ends", the count is too low. If it counted a site description as a barrier, it is too high. Review what lands in "other" rather than letting it stand as an explanation, and record any change to the coding so the count can be reproduced.
A batch instruction you can check
Supply the batch boundary and your category definitions with the request. A usable instruction for the AI Assistant, or for Claude or ChatGPT connected through MCP, looks like this:
Analyze the 64 R-2 applications submitted by the deadline, one version per application. Count distinct application IDs. Apply the attached barrier definitions and allow more than one per application. For each barrier, return the count, the included application IDs and the passage behind each. Report overlaps and the number of distinct applications with any barrier. List ambiguous and unreadable records separately. Keep single mentions visible. Do not invent quotations, infer demographics or change the rubric. End with the limits a reviewer should know before using these counts.
Check the answer against the records. If it cannot supply the included IDs and the passages, treat the count as unverified and ask again, or calculate it from the reviewed coding table.
Compare the batch without losing the individual application
Once the overview is checked, return to individual assessments. Keep eligibility, held-for-evidence and merit scores separate, and check a sample of AI readings, including applications that were not flagged.
When you compare groups, state the denominator for each. A group of two applications cannot carry the same confidence as a group of 24. A difference in scores may come from the proposals, the criteria or the reviewers; the table alone does not say which. If portfolio balance is part of selection, apply the documented rule. Do not introduce a new geographic or topic preference after scoring.
Write a short decision brief
The brief starts with the decision it supports, then gives the boundary, the findings, the limits and the questions the committee has to resolve. Keep the source table one click away for anyone who wants to check a line.
Decision brief · R-2 batch overview · fictional
Scope: all 64 applications submitted to R-2, one version each; A-44 includes its clarification.
Finding: 32 applications describe a transportation or childcare barrier for participants; 8 describe both. One describes an accessibility need.
Source: coding table with application IDs and passages, attached.
Limits: application counts, not young people; applicants are not a sample of Lake County; scanned budgets were checked against the originals by hand.
For the committee: do the shortlisted delivery plans address the barriers most applicants describe, and how should the accessibility application be read against the rubric?
Do not share a public link by default. Applications can hold confidential organizational and personal information. Prepare the view for its audience and confirm access before sending it.
Put it into practice
Reproduce the headline count
- Write the R-2 batch boundary: round, cutoff, unit, versions, fields and how exclusions are recorded.
- In
horizon-r2-applications.csv, list the application IDs coded for transportation and for childcare, with the passage behind each. - Have a colleague reproduce the 32-application union from the two lists without looking at your summary.
- Add a duplicate version of one application and one ambiguous statement. Confirm the duplicate does not create a new application and the ambiguity stays visible.
- Check that the single accessibility application still appears in your decision brief, then carry the brief into step 2 of the workbook.
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
The union is 24 + 16 − 8 = 32, which is half of the 64. If your colleague got 40, they added the two lists without removing the 8 applications in both. A duplicate version belongs to its original application ID, so the unit count stays at 64. An ambiguous statement goes on its own list with its passage rather than into either category. The accessibility application stays in the brief because its meaning, not its frequency, decides its weight. If any count in your brief has no list of IDs behind it, mark it unverified.
Questions grant teams ask
How do you analyze a batch of grant applications?
Define the round, the included applications and the version of each. Check that the sources are readable. Then look at individual assessments and cross-application patterns separately, using a declared counting unit, overlapping categories where they apply and the passage behind each count. Write a short brief with the boundary, findings, limits and the questions the decision-makers need to resolve.
Should themes determine which applications are funded?
No. Themes help you understand the round you received, and they can inform the next round's design. Funding follows the round's published criteria and decision process. Rewarding the most common topic after scoring changes the rules for applicants who had no way to know, so record the insight for later rather than applying it now.
Why can category percentages add up to more than 100%?
Because one application can belong to several categories. In Horizon's round, 24 applications describe transportation and 16 describe childcare, but 8 describe both, so the distinct total is 32, not 40. State whether categories overlap and calculate totals from distinct application IDs so nothing is double-counted.
Should a single mention be excluded?
No. Keep it visible with its source and its frequency. A rare issue can still matter, such as an accessibility need that affects how a program is delivered. Assess what it says and how it relates to the program's responsibilities, rather than dropping it because it did not reach a threshold.
Does the batch represent community need?
Not by itself. It represents the organizations that applied to this round, answering these questions under these conditions. Some organizations never apply, and the questions shape what applicants write about. Use the counts to understand your applicant pool and do not present them as a measure of need in the wider community without other evidence.
Can AI produce the batch summary?
AI can do the reading and the first coding across every application, which is what makes a round-wide view practical. Before anyone relies on it, check category membership, the passages and the counts, including missed and ambiguous cases. A summary that cannot list the application IDs behind each number is a draft, not a finding.