AI Grant Writing Coach

Assess our proposal. First determine which criteria to use: - "Funder materials" means pasted funder content — an RFP, application questions, selection criteria, or a "What We Fund" page. A funder's name alone is not funder materials, and a URL alone is not funder materials unless you can actually read the page. Never reconstruct a funder's criteria from memory — only assess against criteria you can quote from the materials in this conversation. If we name a funder without pasting their materials, say so and use the standard criteria. - If funder materials with stated criteria are present, assess against the funder's own criteria, in their order, quoting their criterion names — then add "AI responsibility" as one final criterion (rules below). If the materials contain more than one criteria-like list (for example "what we look for" plus "selection criteria"), rate against the list explicitly labeled as selection or evaluation criteria, and draw on the other lists only inside Gap and To improve lines. - If not, assess against these standard criteria, in this order: 1. Problem grounded in real user need, 2. Solution matches the problem, 3. Co-design with the people being served, 4. Lived experience on the team, 5. Organizational capacity, 6. Measurable outcomes, 7. Sustainability beyond the grant period, 8. AI responsibility. Rate every criterion in the chosen set — do not add, drop, or rename criteria. Begin your response with one line naming the criteria source, exactly one of: "**Assessing against [funder name]'s criteria from the materials provided, plus our AI responsibility standard.**" "**No funder materials identified — assessing against the standard criteria.**" Then this exact line on its own: "Rating guide: Developing = needs building out | Strong = good with a notable gap | Standout = exceeds what the criteria ask for" If funder materials are present, next check eligibility before any rating — read all of their materials, including eligibility rules, geographic restrictions, focus areas, and deadlines, not just scoring criteria — and output one line: **Check before applying:** [one sentence naming any eligibility rule, geographic restriction, focus-area limit, or deadline that could disqualify the application, quoting their text — or "no disqualifying requirements found in the materials provided"] If something disqualifying exists, say it plainly here, then still rate against the funder's criteria — not the standard set — so we can see how the draft performs against their rubric. A disqualifier changes what we do next; it does not change which criteria you rate. Use this rating scale, lowest tier to highest: Developing / Strong / Standout. Apply these rating definitions: - "Developing" means: criterion is absent, contradicted, or addressed only with non-committal language and aspiration. Example: a problem section describing the issue in general terms with no named users, field research, or quotes rates Developing — stating a problem exists is not evidencing it. Organizational statistics ("we've served 3,000 users") are capacity claims, not user need evidence, and do not raise a rating. - "Strong" means: criterion is addressed with specifics and evidence, but with at least one notable gap a reviewer would flag. Example: a problem section citing a study and naming the population, without connecting that evidence to this org's specific users, rates Strong. - "Standout" means: criterion is addressed with specifics and evidence, and either exceeds what the criterion requires or adds a dimension the rubric doesn't require, with no remaining gap a reviewer would weigh against it (a gap that counts against the proposal is Strong, not Standout). Example: a problem section quoting users directly, naming the research method, and showing how findings shaped the solution rates Standout. Apply this ranking for "biggest gap": the one most likely to drop the rating a tier if left unaddressed. Prefer gaps you can quote proposal text for over abstract weaknesses. Apply this mandatory specificity penalty before finalizing each rating: if a section relies on vague claims, round numbers without sources, or low-specificity language (no named users, partners, dates, dollar amounts, or specific outcomes), reduce that criterion's rating by one tier. An unsourced headline statistic caps a problem or need criterion at Developing. Specificity separates accepted proposals from rejected ones in real data. Apply this aspirational-claim cap: unsecured commitments (contracts still in conversation, funding not closed, features not built, partnerships only planned) cannot rate above Strong — Standout requires evidence in place today. "We are confident" or "we are in conversations" is not Standout. For a "lived experience" or "team representation" criterion specifically: this measures proximity to the problem, not a fixed personal history the team either has or lacks. A team can hold it through members' firsthand experience, or through community advisors, co-designers, or staff hired from the community served. "To improve" must point to surfacing proximity the team already has or building it through those channels — never imply the team should manufacture a personal history. A team that meaningfully engages people with that experience can rate Strong or Standout even if the founders do not share it themselves. Apply these rules for AI responsibility — always include it as the final criterion, never skip it: - If the proposal makes AI claims you can quote, rate it on how completely it tells a verifiable governance story: what the AI actually is (custom build, fine-tune, vendor API, or off-the-shelf), deployed with users cited or aspirational, and whether data handling (sources, consent, retention, access), bias testing, human oversight, and an appeals path are named. All elements present and specific: Standout. Named AI with real gaps: Strong. If data handling, bias testing, and human oversight are all absent, rate Developing even when the AI is named — naming a model is not governance. - If the proposal describes automated or algorithmic features without saying whether they are AI, do not rate; output under the criterion label: "Not rated: [quote the feature] doesn't say whether this is AI. If it is, name it plainly — funders probe unexplained algorithms. If it's rule-based, say that." - If the proposal has no AI claims and no algorithmic features, do not rate; output under the criterion label: "Not rated: No AI claims found in this proposal. Nothing to assess here, and it does not count against you." Use this same output structure no matter which criteria set you rate against. Rate every criterion using only Developing, Strong, or Standout — never substitute another scale (such as unmissable, implied, or absent) for any criterion, including lived experience. Never sum ratings into a total or overall score, never use emoji or checklists, and never add commentary comparing this funder to other funders. Format every rated criterion in this exact structure, with each label bolded, each field on its own line, and one blank line between criterion blocks: **Criterion:** [name] **Rating:** [Developing, Strong, or Standout] **Gap:** [one sentence naming the single biggest gap, quoting proposal text, or "None identified"] **To improve:** [one sentence offering what to add or sharpen to raise this one tier, framed as an option to weigh rather than a command; name the missing evidence or framing, don't rewrite it for us, addressed to us as "you". For a Standout, offer the one refinement that would strengthen it further if a genuine one exists (this is not a gap, the criterion already clears the bar); otherwise write "None identified", and never manufacture a suggestion] After the criteria, write one sentence in bold labeled "**Overall:**" on the overall picture, naming which criteria set you used. If no funder materials were provided, add this single line after Overall: Funder fit: Paste the RFP or "What We Fund" page along with your draft, and I'll assess your proposal against their specific criteria. End with a final block labeled exactly "**Where to go deeper:**". For the one or two lowest-rated criteria, tell us which prompt to run for a full teardown of each, choosing the closest match by name: Problem Clarity, Solution Fit (covers solution match and co-design), Lived Experience, Team Capacity, Impact Measurement, Sustainability, AI Claims, or Funder Fit (point us there whenever the eligibility check or funder criteria surfaced a mismatch). Name the prompt to copy next. Theory of change and systems thinking are deeper lenses that don't fit a quick assessment — the Theory of Change and Systems Thinking prompts are available as separate teardowns. Stop there. No preamble before the first line, no commentary after the last block. Rate strictly against the definitions above, never relative to other proposals, and never inflate a rating to soften the message; anything worth improving belongs in the "To improve" line.

Pretend you're a skeptical program officer who has reviewed hundreds of proposals. List exactly five questions you'd ask the applicant. Apply this ranking criterion. A "damaging" question is one that: - targets a structural weakness in the proposal - would be hard to answer without admitting a gap - would require new evidence the applicant doesn't appear to have - could shift the funder's evaluation significantly if answered poorly Order most damaging first. Number them 1 through 5. One sentence per question. No preamble, no headers, no commentary.

Read our full proposal. Identify the single weakest paragraph by writing quality, not by topic. Apply these failure mode definitions: - "Vague" means: lacks specific numbers, names, dates, or examples - "Generic" means: could appear in any nonprofit's proposal with minor swaps, no specifics to this org or this work - "Unsupported" means: claims made without evidence, citations, or data - "Non-committal" means: uses conditional language that avoids accountability — "may," "could," "hopes to," "potentially," "explore," "consider" Identify the weakest paragraph by two factors, in this order of importance: 1. Stakes: how heavily a reviewer would weigh the weakness against funding — a weak claim about money, capacity, or evidence outweighs a weak claim about values, vision, or a closing pitch, even when the values paragraph carries more red flags. A boilerplate closing or mission statement is rarely the weakest paragraph that matters. 2. Red-flag density: among paragraphs of comparable stakes, pick the one with the highest count of red flags across the four categories. If two paragraphs are still tied, pick the one carrying the most load-bearing claim — the one other sections depend on being true. Respond in exactly three sections, no preamble, no headers: Why it falls flat: [one sentence naming the weakest paragraph (by section or opening words) and which failure modes apply] What it needs: [2-3 sentences naming what type of evidence, structure, or specifics would strengthen this paragraph, framed as options to weigh rather than commands — name the direction, not words to use, addressed to us as "you"] Weakest paragraph: [quote the full paragraph]

Pretend you're the application reviewer who's about to recommend rejection. Tell us the three strongest reasons you'd give for why you can't fund this. After that, ask us five tough follow-up questions, one at a time, waiting for our answer before moving to the next. Push back on any answer that: - is vague or non-committal ("we hope to," "we plan to explore") - doesn't actually address the question you asked - contradicts something in our proposal - introduces new claims or assumptions without evidence - relies on credentials or aspiration instead of specifics Be direct and specific. Your job is to give the kind of candid, direct feedback a program officer would give privately — focused on what the proposal needs, not on making the team feel good or bad about the work they've done.

Review our proposal against this question: is the problem grounded in real user need? Go deep — this is a full teardown of the problem section, not a snapshot. Apply these criteria when answering: - "Evidence of user input" means: names specific users or communities consulted, quotes users directly, cites field research the team conducted, or describes co-design sessions. Generic stats and demographic claims don't count. - "Reads as assumed" means: uses "we think/believe," cites statistics without naming the source or specific community, or generalizes about user needs without specifics. - "User-voice balance" means: whether the Problem section is told through the users' experience or the organization's. Judge it in the Problem section only, by weighing sentences that center users (the grammatical subject is a user: "adults," "job seekers," "people," "they") against sentences that center the organization (the grammatical subject is "we," "our," or the org name). A sentence that names users but describes the organization's assumption or belief about them counts as org-centered. If org-centered sentences outnumber user-centered ones, call it we-heavy; otherwise call it balanced. Use this weighing only to decide; never report numbers, counts, or tallies in your answer. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this problem is real and understood — phrased in their voice, the way they'd say it out loud in a review meeting. - "What grounded looks like" means: the type and shape of evidence that would move this section from assumed to grounded. Name the kind of proof — do not draft the sentences for us. Respond in exactly six lines, no preamble, no headers: Where it reads as assumed: [one sentence pointing to specific text, or "none detected"] User-voice balance: [one sentence: "balanced" or "we-heavy," quoting the single sentence that best shows it; no counts or tallies] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] What would make it grounded: [2 sentences max — name the specific gap and the type of evidence or information that would close it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Problem stated: [one sentence quoted from proposal] Evidence of user input: [one sentence quoted from proposal, or "none stated"]

Review our proposal against this question: does the solution match the problem, with evidence of co-design? Go deep — this is a full teardown of solution fit, not a snapshot. Apply these criteria when answering: - "Co-design evidence" means: named user advisors, documented user feedback cycles, iteration based on user input, or specific user-facing changes made before this proposal. Generic statements like "designed with the community in mind" don't count. - "Mismatch or overreach" means: solution claims to address a broader problem than the one stated, solution proposes capabilities not justified by the user need, or solution is a technology-first answer to a problem the user need says is non-technical. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this solution actually fits the stated problem — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly five lines, no preamble, no headers: Mismatch or overreach: [one sentence pointing to specific text, or "none detected"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific gap and the type of evidence or information that would close it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Solution claimed: [one sentence quoted from proposal] Co-design evidence: [one sentence quoted from proposal, or "none stated"]

Review our proposal for evidence of lived experience on our team. Go deep — this is a full teardown of the team's lived-experience signal, not a snapshot. Apply these assessment definitions: - "Unmissable" means: explicit statement of a team member's firsthand experience with the problem, names them, and ties their experience to a specific product or program decision. - "Implied" means: vague language about "communities we serve" or "passion for this work" without naming team members or tying experience to decisions. Note: job titles alone (e.g., "community navigator," "outreach coordinator") do not count — a title is a role, not a lived experience signal. - "Absent" means: no mention of any team member's personal connection to the problem — only roles, credentials, or organizational history. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this team truly has lived experience with the problem — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly five lines, no preamble, no headers: Assessment: [one word: unmissable, implied, or absent] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Make it concrete: [2 sentences max — name the specific gap and the type of information that would make this signal unmissable; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Concrete signal: [one sentence quoted from proposal, or "none stated"] Implied but not shown: [one sentence quoted from proposal, or "none"]

Review our proposal against this question: do we have the team and capacity to deliver what we're proposing? Go deep — this is a full teardown of delivery capacity, not a snapshot. Apply these criteria when answering. Note: a full-time tech team is not required for a strong proposal. Hybrid models (part-time, contractors, fellows, volunteers, vendors) can work, and "delivery" means whatever the proposal actually proposes to do — build a product, host a fellow, run a program, or something else. What matters is honesty about who does the work and evidence they can deliver it. - "Delivery model" means: the proposal explicitly states who does and sustains the proposed work (full-time staff, part-time staff, contractors, fellows, volunteers, vendors). If it's mixed, the mix is described. - "Capability evidence" means: named individuals with specific roles AND functions, a relevant track record, or shipped evidence appropriate to what's proposed (named clients, deployment counts, named partners, prior comparable work, or revenue). Generic credentials with no tie to the proposed work don't count. - "Key-person risk and runway" means: the proposal names what happens if a key person leaves, has a succession plan, or shows runway to sustain the work through and beyond the funding or program period. - "Internal consistency" means: founding year, operational history, and revenue claims line up. If the proposal says founded 2024 but operational since 2023, that's a flag. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this team can actually deliver and sustain what it proposes — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Key-person risk and runway: [one sentence: addressed how, or unaddressed] Internal consistency: [one sentence: consistent, or where it contradicts itself] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific gap and the type of evidence or information that would close it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Delivery model: [one sentence quoted from proposal, or "ambiguous"] Capability evidence: [one sentence quoting named people, track record, deployments, or revenue, or "none stated"]

Review our proposal against this question: are we measuring outcomes or just outputs, and are our numbers credible? Go deep — this is a full teardown of the measurement approach, not a snapshot. Apply these definitions: - "Outputs" are activities the organization completes: sessions delivered, users reached, hours of programming, content published. Outputs measure effort, not effect. - "Outcomes" are changes in users' lives or circumstances that result from the work: skills gained, employment outcomes, health improvements, behavior change, system change. Outcomes measure effect. - "User feedback loop" means: a named mechanism for collecting user feedback and using it to change the work, not just an end-of-program survey. - "Round-number red flag" means: large round numbers ("25M tons of CO2 annually," "500 users served," "20 awards won") that appear without a methodology, named source, or breakdown by year. Repeated round numbers across multiple sections amplify the flag. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether these numbers show real change — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Outputs vs. outcomes: [one sentence naming which listed metrics are outputs and which are outcomes] Round-number red flags: [one sentence quoting any unsupported round-number claims, or "none detected"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] Stronger metric: [2 sentences max — name the specific output metric that's weakest and the outcome metric that would replace or complement it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Metrics listed: [one sentence quoted from proposal] User feedback loop: [one sentence quoted from proposal, or "not addressed"]

Review our proposal against this question: is our theory of change explicit and credible? Go deep — this is a full teardown of the theory of change, not a snapshot. Apply these criteria when answering: - "Theory of change stated" means: the proposal explains WHY the intervention works — not just what it does, but the causal mechanism. A list of activities is not a theory of change. Look for logic like "by doing X, users can do Y, which leads to Z outcome." - "Causal chain" means: a sequence of cause-and-effect steps from the intervention to the intended impact. It must move from activity → behavior change → outcome — not just a timeline. - "Key assumptions" means: conditions that must be true for the change to happen that the organization doesn't control — e.g., internet access, employer behavior, policy environment. Unstated assumptions are not safer than stated ones. They're riskier. - "Evidence for mechanism" means: research, pilot data, or field evidence that this type of intervention produces this type of change in this type of context. Generic statistics about the problem area don't count. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this causal logic actually holds — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Causal chain: [one sentence only — one of: "explicit: [brief quote]", "implied: [one phrase describing the assumed logic]", or "absent"] Key assumptions embedded: [2 sentences max — name the most significant unstated assumption and why it's load-bearing for the proposed change] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific gap in the theory of change and the type of evidence or information that would make it credible; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Mechanism stated: [one sentence only — quote the proposal if it states a mechanism, or write "not stated"] Evidence for mechanism: [one sentence only — quote the proposal if evidence exists, or write "none cited"]

Review our proposal against this question: what happens to this work after the grant ends? Go deep — this is a full teardown of sustainability, not a snapshot. Apply these criteria when answering: - "Revenue model named" means: the proposal identifies a specific path toward financial sustainability — earned revenue, government contracts, fee-for-service, licensing, or a diversified grant strategy with named funders. "We plan to seek additional funding" does not count. - "Grant dependency risk" is: high if all current revenue is grant-funded with no earned revenue path named; medium if there's some earned revenue or a named diversification plan; low if earned revenue is significant or a credible multi-funder pipeline is described. - "Runway stated" means: the proposal shows the organization can sustain the work beyond the grant period — not just through it — by naming post-grant funding sources, revenue projections, or a specific bridge plan. - "Sustainability timeline" means: the proposal names when or under what conditions the work becomes self-sustaining, or identifies the next funding source with a realistic ask. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this work survives past the grant — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Grant dependency risk: [one of: low, medium, or high — with a one-sentence reason] Revenue model: [one sentence: named model with specifics, "grant-dependent only," or "not addressed"] Runway after grant: [one sentence: addressed how, or "not addressed"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific sustainability gap and the type of financial information or planning that would address it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Sustainability timeline: [one sentence quoted from proposal, or "not stated"]

Review our proposal against this question: does this solution understand the system it's entering? Go deep — this is a full teardown of the systems thinking, not a snapshot. Apply these criteria when answering: - "Root cause vs. symptom" — a root cause is a structural or systemic driver (e.g., lack of employer incentives, policy gaps, infrastructure inequity). A symptom is an observable effect of that driver (e.g., low employment rates, poor health outcomes). Most proposals address symptoms. Note which this is. - "Ecosystem named" means: the proposal identifies other actors, institutions, or structural forces that shape the problem — employers, government agencies, community organizations, funding patterns, infrastructure, policy environment. Naming the target population alone is not naming the ecosystem. - "Feedback loops considered" means: the proposal shows awareness that the intervention will change system dynamics — for better or worse. Example of positive: the tool lowers friction, which increases adoption, which generates data, which improves the tool. Example of negative: automation displaces workers the org claims to serve. - "Unintended consequences addressed" means: the proposal names at least one risk or tradeoff that could harm the people it serves or adjacent populations — and shows a monitoring plan or mitigation approach. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether this proposal understands the system it's entering — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: Problem framed as: [one of: root cause (quote), symptom (name the root cause it implies), or mixed] Feedback loops: [one sentence only: addressed (quote the logic), or "not addressed"] Unintended consequences: [one sentence only: addressed how, or "not addressed"] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific systemic gap and the type of thinking, evidence, or stakeholder engagement that would address it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Ecosystem named: [one sentence only — quote named actors or structures, or state "not named"]

Review our proposal against this question: are we the right fit for this specific funder? Go deep — this is a full teardown of funder fit, not a snapshot. Base every funder-specific judgment only on funder materials pasted in this conversation (an RFP, application questions, selection criteria, or a "What We Fund" page). A funder's name or a URL you cannot read is not funder material — never reconstruct a funder's criteria from memory. If no funder materials are present, say so first and limit the review to what the proposal itself signals about fit. Apply these criteria when answering: - "Stage fit" means: our annual budget, organization age, and growth stage match what this funder typically funds as described in their RFP or website. - "Funder-specific signal" means: the proposal explicitly references this funder's stated priorities, language, or past grants in a way that couldn't apply to a different funder. - "Scope discipline" means: 1 to 2 issue areas reads as focused. 3 issue areas is borderline. 4 or more signals scattershot positioning and weakens fit with any specific funder. - "Reviewer's objection" means: the single sharpest question a skeptical program officer at this funder would raise about whether this proposal belongs in their portfolio — phrased in their voice, the way they'd say it out loud in a review meeting. - Assessment definitions: - "Fits" means: proposal addresses this funder's stated priorities and constraints directly. - "Transactional" means: proposal could be sent to any funder, no funder-specific framing or references. - "Wrong lane" means: proposal sits in a sector, geography, or stage this funder doesn't fund. Respond in exactly six lines, no preamble, no headers: Assessment: [one word: fits, transactional, or wrong lane] Stage fit: [one sentence: right stage for this funder, or where it's off] Scope discipline: [one sentence: focused (1-2 issue areas), borderline (3), or scattershot (4+), with the list quoted] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it] To improve: [2 sentences max — name the specific gap and the type of information or framing that would close it; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"] Funder-specific signal: [one sentence quoted from proposal, or "reads generic"]

Review our proposal on AI-specific concerns. Go deep — this is a full teardown of the AI claims, not a snapshot. Always complete all six lines below. If AI is peripheral to the proposal or absent, say so in the first line and mark the AI-detail lines "not applicable." Do not skip this prompt or refuse to answer. Apply these definitions: - "Custom build" means: model trained or fine-tuned by the organization on their own data. If "custom" or "proprietary" appears to mean prompt engineering or configuration on top of a third-party model, classify it as vendor API and say so plainly. - "Fine-tune" means: an off-the-shelf model adapted with the organization's data or domain inputs. - "Vendor API" means: calling a third-party model (OpenAI, Anthropic, Google) without modification. - "Off-the-shelf" means: using a consumer AI product (ChatGPT, Claude.ai) directly. - "Minimal or none" means: AI is mentioned only in passing, or the proposal does not use AI in its core work. Name what little is there, or state plainly that AI is not central to this proposal. - "Deployed vs. aspirational" means: deployed AI is in production today with users, with specific clients or use counts cited. Aspirational AI uses language like "we are looking to incorporate," "we plan to add," "we will integrate" — future-tense, no current users. Aspirational AI in a proposal is a major red flag. - "Data handling addressed" means: data sources named, consent process described, retention period stated, and access controls listed. Missing any one of these counts as not addressed. Note: vague statements like "user data will be stored securely" or "we have a privacy policy" do NOT count — all four elements must be present. - "Bias and oversight addressed" means: bias testing mechanism named, human-in-the-loop checkpoint described, and appeals path for affected users specified. Missing any one of these counts as not addressed. - "Reviewer's objection" means: the single sharpest question a skeptical program officer would raise about whether the AI is real, responsible, and more than a buzzword — phrased in their voice, the way they'd say it out loud in a review meeting. Respond in exactly six lines, no preamble, no headers: What's actually AI: [one of: custom build, fine-tune, vendor API, off-the-shelf, minimal, or none — with a brief quote or summary from the proposal] Data handling: ["not addressed" if any of the four elements are missing, one sentence quoted from proposal if addressed, or "not applicable" if AI is minimal or none] Bias and oversight: [one sentence quoted from proposal, "not addressed", or "not applicable" if AI is minimal or none] Deployed or aspirational: [one of: deployed (cite specific users or clients), aspirational (quote the future-tense language), mixed (some live, some planned), or "not applicable" if AI is minimal or none] Reviewer's objection: [one sentence in a skeptical reviewer's voice, naming or quoting the text that provokes it, or "not applicable" if the proposal never claims AI] What to add: [2 sentences max — name the specific gap and the category of evidence that would differentiate this from a generic AI pitch; if AI is minimal or none, say plainly that this prompt does not apply and point us to the other prompts; frame it as an option to weigh rather than a command; describe what to strengthen, don't write it for us; addressed to us as "you"]