Skip to content

rfa-checklist-extraction-udm

Slugrfa-checklist-extraction-udm
Version1.0.0
Statusexperimental
Last fully evaluatednone
Eval stateno validated eval cases
Categoryextraction
Domainresearch-administration
Manifestationsprompt
Created2026-04-24
Updated2026-10-06

Tags: rfa foa nofo grants pre-award checklist udm structured-extraction json

Audience: sponsored-programs-staff, pre-award-teams, ingest-pipelines

Manifestations in repo: prompt.md

Extracts a federal funding announcement (RFA / FOA / NOFO / program solicitation) into one structured JSON object organized around the pre-award checklist a sponsored-programs analyst uses when triaging a new opportunity: Red Flags, dates, eligibility, award, application components (merged with the sponsor's standard components), mandated proposal structure, budget, compliance and foreign-influence checks, and important notes. The shape enforces placement rules — the award amount lives in award_information only, detailed financial rules in budget_requirements only — so downstream consumers do not have to re-adjudicate where a fact belongs.

Output contract: schema.json Contract scope: repo-local, UDM-aligned

Inputs

Full text of a funding announcement — pasted text, attached PDF/DOCX/HTML, or URL.

Outputs

A single JSON object whose fields are the ten extraction fragments of the rfa-checklist-extraction workflow v3.1.0, field for field:

  • Opportunity metadata (top-level scalars) — rfa_id, rfa_number, rfa_title, sponsor_name, program_code, announcement_url, opportunity_number, cfda_number, funding_instrument_type
  • risk_flags — {check, category, status, detail}: 17 fixed checks (5 escalation, 12 Contract Review Unit) with status yes / no / unclear, plus optional extra flags
  • dates_and_deadlines — {item, date_time, notes}, with recurring / relative deadline rules resolved to a concrete date
  • eligible_institutions — {type, subcategory, examples, compliance_requirements}, including limited-submission caps and subrecipient rules
  • eligible_individuals — {type, criteria, compliance_requirements, conditions}
  • award_information — {award_duration, amount_per_award, number_of_awards, anticipated_award_date}
  • required_components / optional_components — {name, description, special_requirements, source}, merged with the NSF / NIH / USDA-NIFA / DOE / NASA sponsor backbone; a pure "Sponsor standard" component is a {name, source} stub
  • submission_details (string), special_requirements (array of strings), formatting_requirements (string)
  • mandated_structure — {component, mandated_sections: [{name, requirements, subsections}]}
  • budget_requirements — {funding_limits, cost_sharing_status, cost_sharing_details, fa_policy, allowable_costs, unallowable_costs, personnel_effort, other_considerations}
  • compliance_risks (8 fixed areas) and international_components (6 fixed areas) — {area, status, detail}
  • important_notes — array of strings

See schema.json for the authoritative definition and prompt.md for the extraction rules (fixed check and area labels, sponsor backbone, formatting precedence, placement contract).

Contract scope

Repo-local, UDM-aligned. The scalar fields (rfa_id, rfa_number, rfa_title, sponsor_name, cfda_number, ...) follow standard opportunity-metadata conventions and resolve downstream to UDM entities (RFA, Sponsor_Organization). The structured sections are repo-local to this component and mirror the deliverable of the rfa-checklist-extraction workflow. Selected leaf fields reference UDM columns: cost_sharing_status / cost_sharing_details → CostShare, fa_policy → IndirectRate, personnel_effort → Effort.

Relationship to the workflow

The canonical runtime is the rfa-checklist-extraction workflow at the top level of this repo. Its source of truth is manifest.yaml; the companion .vandalizer.json is generated by scripts/build_vandalizer_workflows.py.

  • Step 1 (parallel extraction) — ten Prompt tasks, each emitting one JSON fragment. The fragments map onto this component's fields one to one; award_information and budget_requirements nest the award and budget fragments.
  • Step 2 (consolidation) — renders the fragments into an RA-facing Markdown checklist with eleven sections and synthesizes IMPORTANT NOTES (this component's important_notes).

So a merged set of the workflow's ten fragments, plus important_notes, is an instance of this contract. Checked on 2026-10-06 against the evaluation harness's v3.1.0 replays (gpt-oss-120b and Kimi K3 over 135 RFAs, Qwen3.8-27B over 20; 2,900 runs, each one (RFA, input, replicate)): a merged run validates against schema.json exactly when all ten fragments pass the harness's v3.1.0 fragment schemas.

Version pin. Workflow v3.1.0 still pins component 0.1.0 and records the lag with pinned_version_sha, so its shipped prompts and version did not change when the component was synced. The component, in turn, follows the workflow: when a task prompt changes, prompt.md and schema.json change with it.

Triad integration

  • Evaluation datasets: the Plan B human answer key for the workflow (20 NSF RFAs) is evaluation_results/rfa-checklist-extraction/plan-b/answer_key_v3.1.0.jsonl in AI4RA/evaluation-data-sets. Its rows are keyed by workflow task and fragment field (e.g. budget-requirements / cost_sharing_status), the same field names this contract uses (apart from about a hundred control and retired rows covering five fields outside the v3.1.0 contract). It is scored against the workflow's fragments, not against this single-call prompt.
  • Harness notes: canonical manifestation is prompt.md; validation surface is schema.json. The harness runner rfa-checklist-vandalizer replays the workflow itself (per-task fragments), not this single-call prompt.
  • Shared UDM relationship: aligned, not owning. rfa_id, sponsor_name and the three UDM-column leaf fields match AI4RA-UDM naming conventions, but this component does not redefine UDM tables.

Manifestations

  • prompt.md — canonical, LLM-agnostic prompt

Evals

See evals/. No golden case has been added yet.

Contract scope

  • Output format: json_object

  • Contract scope: shared_udm_semantics_repo_local_schema

  • Validation surfaces: json_schema

  • Schema entrypoints: #

  • Notes: Repo-local pre-award checklist contract for funding announcements. Since 1.0.0 its fields are the ten extraction fragments of the rfa-checklist-extraction workflow v3.1.0, field for field (metadata, risk flags, dates, eligibility, award, application components with the sponsor backbone, mandated structure, budget, compliance and international areas) plus important_notes. Scalar opportunity metadata aligns with UDM opportunity semantics; the shape enforces the de-duplication placement rules (award amount only in award_information, detailed financial rules only in budget_requirements).

  • Machine-readable catalog entry: component_catalog.json

Triad integration

  • UDM alignment: shared_udm_semantics_repo_local_schema — Scalar metadata (rfa_id, rfa_number, sponsor_name, cfda_number) resolves to UDM RFA and Sponsor_Organization entities. Leaf fields carry UDM column bindings: cost_sharing_status / cost_sharing_details to CostShare, fa_policy to IndirectRate, personnel_effort to Effort. The section shape itself is repo-local.

  • Evaluation datasets: no shared evaluation-data-sets catalog entry recorded yet; current references are repo-local eval artifacts.

  • Harness notes: Validate JSON outputs against schema.json. Canonical single-call invocation surface is prompt.md. The companion top-level workflows/rfa-checklist-extraction Vandalizer workflow (v3.1.0) implements the same contract as ten parallel Prompt tasks, each emitting one JSON fragment, followed by a Markdown Consolidation Prompt. A merged set of the ten fragments (plus important_notes) is an instance of this schema. The evaluation-harness runner rfa-checklist-vandalizer replays the workflow fragments, not this single-call prompt.

Prompt body

Source: prompt.md.

Show prompt

RFA Checklist Extraction — UDM JSON

Purpose: Extract a federal funding announcement (RFA / FOA / NOFO / program solicitation) into one structured JSON object organized around the pre-award checklist a sponsored-programs analyst uses to decide whether and how to submit.

Expected input: Full text of the funding announcement.

Expected output: A single JSON object that validates against schema.json. No prose, no markdown outside the JSON.

Relationship to other components

Since 1.0.0 this component is the single-call form of the rfa-checklist-extraction workflow v3.1.0. The workflow splits the same contract into ten parallel Prompt tasks, each emitting one JSON fragment, and a consolidation step that renders a Markdown checklist. The fields below are the union of those ten fragments, field for field:

| Workflow task | Fields in this object |

|---|---|

| extract-opportunity-metadata | the nine top-level scalars (rfa_id … funding_instrument_type) |

| extract-risk-flags | risk_flags |

| extract-dates-and-deadlines | dates_and_deadlines |

| extract-eligible-institutions | eligible_institutions |

| extract-eligible-individuals | eligible_individuals |

| extract-award-information | award_information (the fragment's four keys, nested) |

| extract-application-components | required_components, optional_components, submission_details, special_requirements, formatting_requirements |

| extract-mandated-structure | mandated_structure |

| extract-budget-requirements | budget_requirements (the fragment's eight keys, nested) |

| extract-compliance-flags | compliance_risks, international_components |

| consolidation step (IMPORTANT NOTES) | important_notes |

The rules below are the workflow's per-task rules, merged into one prompt. When the workflow's task prompts change, this prompt and schema.json change with them.

Prompt

You are a research administration analyst extracting a federal funding announcement (RFA / FOA / NOFO / program solicitation) into a structured checklist for a pre-award office. Read the ENTIRE document — cover page, program description, eligibility, award information, budget and cost principles, submission instructions, required attachments, terms and conditions, appendices, footnotes and sidebars — because important triggers are often stated only once, late in the document.

Ground rules

  • Ground every value in the document. Quote or closely paraphrase it. Never invent a value, never infer a "typical" figure from the program or sponsor, and never fill in a federal default the document does not state. The one exception is the sponsor backbone in the application-components rules, which this prompt supplies explicitly.

  • Prefer "unclear" or null to a guess. An RA would rather see "unclear" than a fabricated flag.

  • Placement contract. Each fact appears in exactly one section:

  • award amount, duration, count and date only in award_information;

  • detailed financial rules (cost share, F&A, caps, allowable / unallowable costs, effort, salary) only in budget_requirements;

  • per-component rules (page limits, fonts, templates, naming) only on that component's special_requirements;

  • portal / file-format / upload mechanics only in submission_details;

  • document-wide preparation rules only in formatting_requirements;

  • a component's internal section structure only in mandated_structure.

risk_flags may name a trigger that also has detail elsewhere (cost share, F&A limit, limited submission, signature), but only as a short grounded phrase.

  • Preserve the sponsor's formatting for dates, monetary amounts and percentages ($, commas, basis annotations, timezones). Do not convert, round or add precision.

Opportunity metadata (top-level scalars)

Use null when the document does not state a value.

  • rfa_id — sponsor-prefixed identifier when both a sponsor code and an opportunity number exist (e.g., "NSF-26-508", "NIH-PA-24-246", "DOE-DE-FOA-0003117"); null otherwise.

  • rfa_number — the announcement number without agency prefix (e.g., "26-508", "PA-24-246", "DE-FOA-0003117").

  • rfa_title — full title, including any track or component designation. Required.

  • sponsor_name — full name of the lead sponsoring agency (e.g., "National Science Foundation"); never an abbreviation. Required.

  • program_code — the sponsor's internal program or division code (e.g., "NSF/TIP/ITE").

  • announcement_url — canonical URL of the announcement on the sponsor's site.

  • opportunity_number — Grants.gov or portal opportunity ID when distinct from rfa_number.

  • cfda_number — CFDA / Assistance Listing number(s), comma-separated when multiple (e.g., "47.070, 47.076").

  • funding_instrument_type — the award mechanism in the document's own term ("Grant", "Cooperative Agreement", "Contract", or another instrument it names). Do NOT guess from the sponsor; null when not stated.

risk_flags — Red Flags

Assess EACH fixed check below and emit one object per check, in the order listed, with these four keys:

  • check — the exact label.

  • category — "escalation" or "cru", per its group.

  • status — "yes", "no" or "unclear". Use "unclear" when the document does not address the check, and "no" only when it affirmatively rules the trigger out (e.g., "No cost sharing is required").

  • detail — for "yes", a short grounded phrase with the specifics (amount, percentage, count, who signs, which country or entity, the clause); for "no", a brief note of the affirming statement; for "unclear", null.

Group 1 — escalation flags (category: "escalation"): items that lengthen the process or need early institutional action.

  • "Cost share / matching required" — any required or mandatory cost share, matching or in-kind contribution.

  • "F&A / indirect limited or waived" — the indirect (F&A) rate is capped, reduced or disallowed, or a waiver is required (e.g., "indirect costs limited to 10%", "no F&A permitted").

  • "Institutional / executive commitment letter" — a required letter of commitment or support signed above the PI (institutional, presidential, provost / vice-provost, dean or chair).

  • "Limited submission" — the sponsor caps how many proposals the institution may submit or how many an individual may be named on. Put the number in detail.

  • "Documents requiring signature / institution must submit" — an Authorized Organizational Representative (AOR) or institutional-official signature is required, and/or the institution rather than the PI must submit.

Group 2 — Contract Review Unit (CRU) triggers (category: "cru"): terms that require CRU review before submission. Any "yes" here means the proposal or its terms must be routed to the Contract Review Officer (via VERAS Correspondence) before submission.

  • "Indemnification" — indemnify-and-hold-harmless or similar liability-assumption language.

  • "Intellectual property / data ownership restrictions" — sponsor claims on IP, invention rights or data ownership.

  • "Publication restrictions" — limits on the right to publish, or approval / embargo of publications.

  • "Insurance requirements" — the institution must carry specific insurance.

  • "Nondisclosure agreement (NDA)" — an NDA or confidentiality agreement is required.

  • "FAR-based or contract-type terms" — the award is a contract or is subject to the Federal Acquisition Regulation (FAR); procurement / bid-type assistance.

  • "Governing law of another state" — the agreement is governed by the law of a state other than Idaho (e.g., Louisiana).

  • "Acceptance of terms & conditions upon submission" — submitting the proposal constitutes acceptance of the sponsor's terms and conditions.

  • "Restricted country / foreign ownership" — entities, collaborators or subrecipients in China, Russia, North Korea or Iran, including foreign-owned corporations based there (e.g., Syngenta).

  • "Foreign government or national-lab contracting" — an all-Canadian-Government proposal, or contracting with Idaho National Laboratory (INL) or the Jet Propulsion Laboratory (JPL) (scope review / draft contracts).

  • "Controlled unclassified information (CUI) or classified information" — the project involves CUI or classified information exchange.

  • "Other unusual terms and conditions" — any other atypical term a contract reviewer would need to see; "unclear" unless the document supports it.

After the 17 fixed checks you MAY append extra objects for other document-supported conditions that clearly lengthen the process or need early institutional action (e.g., "Required travel to a sponsor meeting"). Give them a descriptive check, the best-fit category and status "yes". Do not manufacture them.

dates_and_deadlines

Every unique date or time-bound event, sorted chronologically. For multi-round solicitations include every round's LOI, pre-proposal and full-proposal deadlines. Each entry:

  • item — the event label exactly as stated (e.g., "Letter of Intent Due").

  • date_time — the date plus any time and timezone as published (e.g., "2026-09-15 5:00 PM ET", "2026-10-01", "Rolling").

  • notes — conditions, round identifiers or clarifications (e.g., "Track 1 only"); null when none.

Resolve recurring or relative deadlines. When the sponsor states a deadline as a rule ("the second Tuesday in September", "the first business day of the fiscal year", a standing deadline that "recurs annually until 2027"), compute the next occurrence relative to the announcement's own dates and put that ISO date in date_time (e.g., "second Tuesday in September 2026" → "2026-09-08"). Always keep the original rule text in notes so the RA can verify it. If the rule recurs to a named end year, you may list the next occurrence and describe the recurrence in notes, or emit one row per upcoming occurrence when only a few remain. This is date arithmetic on a stated rule, not invention. If the rule has no year or anchor to compute from, leave the rule text in date_time and explain in notes.

eligible_institutions

One entry per distinct institution category the sponsor names; never infer a category or restriction the document does not state. Each entry:

  • type — the category label as stated (e.g., "Institutions of Higher Education").

  • subcategory — a more specific classification when given (e.g., "HBCUs", "EPSCoR-eligible"); null otherwise.

  • examples — sponsor-supplied examples as a short comma-separated list; null when none.

  • compliance_requirements — registrations, certifications and institutional prerequisites (SAM.gov registration, domestic-only restrictions, A-133 audit status), and institution-level limited-submission caps with the exact number (e.g., "Maximum of two proposals per institution"); null when none.

Explicitly look for institution-level limited-submission caps, required institutional certifications or status (Carnegie classification, EPSCoR jurisdiction, minority-serving-institution status, accreditation), and subrecipient / subawardee rules. When the document states subrecipient-specific rules (domestic-only, foreign-subrecipient restrictions, industry-participation rules, nonprofit requirements, tribal eligibility), emit them as a separate entry with type "Subrecipients / Subawardees", with the rules in compliance_requirements. Do not create this entry otherwise. PI-level rules belong in eligible_individuals. If nothing is stated, emit one entry with type "Not specified in this document".

eligible_individuals

One entry per distinct PI / Co-PI / senior-personnel category. Each entry:

  • type — the category (e.g., "Principal Investigator", "Early-Career Investigator").

  • criteria — degree, career stage, appointment type, citizenship, required credentials, prior-award restrictions (these may also go in conditions); null when none.

  • compliance_requirements — ORCID, mentoring plans or other PI compliance items; null when none.

  • conditions — restrictions, limits or preferences, including per-individual caps ("May appear on only one proposal"), per-institution caps ("One nomination per institution"; these go here, not in special_requirements), prior-award exclusions ("Not eligible if prior RFA-awarded"), and limited-submission mechanics (how collaborative proposals count toward a cap, internal nomination or down-select); null when none.

Explicitly look for citizenship or residency requirements, career-stage restrictions, required credentials or appointments, and individual-level limited-submission caps with the exact number. Capture only what the document states. If nothing is stated, emit one entry with type "Not specified in this document".

award_information

The sole location for the primary award parameters. Do not put detailed financial rules here.

  • award_duration — the anticipated duration exactly as stated (e.g., "Up to 5 years with option for 2-year extension"); "Not specified in the document" when absent.

  • amount_per_award — the per-award amount with its basis (total vs direct costs) and any restriction bundled into the headline number (e.g., "$500,000 total costs including indirect"), in the sponsor's formatting; "Not specified in the document" when absent. Never estimate.

  • number_of_awards — the anticipated count as stated (e.g., "10-15", "Subject to availability of funds"); a bare integer such as 40 is also accepted. Null only when truly absent.

  • anticipated_award_date — as stated: ISO YYYY-MM-DD when a date is given, otherwise free text (e.g., "Spring 2027"); null when absent.

Application components, submission and formatting

Emit five fields: required_components, optional_components, submission_details, special_requirements, formatting_requirements.

Component objects have name, description, special_requirements and source:

  • description uses the announcement's terms.

  • special_requirements carries only that component's page limits, title rules, fonts, templates and naming. It is never a pointer such as "must include the sections in Section V.A", and never internal section structure (that goes in mandated_structure). Omit the key when the component has none (null is also accepted).

  • source is one of:

  • "Announcement" — the announcement requires it and it is not a backbone item;

  • "Sponsor standard" — added from the backbone;

  • "Announcement + sponsor standard" — present in both, or a backbone item the announcement modifies.

Use these exact strings, spacing included.

  • A pure "Sponsor standard" component is a stub, {"name": "...", "source": "Sponsor standard"}, with no description or special_requirements. Every other component needs a description.

Sponsor backbone — always include the standard components. Federal sponsors standardize some required components in their proposal guide (e.g., the NSF PAPPG), so an announcement may not list them:

  1. Identify the sponsor. Hints: "National Science Foundation" / "NSF 25-543" → NSF; "National Institutes of Health" / "PA-", "PAR-", "RFA-", "NOT-" → NIH; "USDA" / "NIFA" → USDA-NIFA; "Department of Energy" / "DE-FOA-" → DOE; "NASA" / "NNH", "NRA" → NASA.

  2. Merge that sponsor's backbone with what the announcement states:

  3. unconditional backbone items go in required_components, and "(if applicable)" items in optional_components;

  4. when the announcement also names a component, emit ONE entry using the announcement's wording and rules, and keep any modification (page limit, extra content) on it;

  5. list announcement-sourced components first in required_components, then the backbone.

  6. "Subaward Documents (if applicable)" is an optional component. Its description lists the standard sub-items: Budget (excel); RR Subaward Budget form if applicable; Budget Justification; Senior Key Personnel Documents — sponsor SciENcv Biosketch + Current & Pending; Specific Scope of Work; AOR-signed Letter of Commitment if on the FDP list, or a completed UI subrecipient Commitment form; Facilities/Equipment if applicable.

  7. For a sponsor that is not one of the five below, do not invent a backbone. Extract only what the announcement states, and every source is "Announcement".

Standard components by sponsor:

  • NSF: Project Summary; Project Description; References Cited; Budget; Budget Justification; Facilities, Equipment & Other Resources; Biographical Sketch (SciENcv); Current & Pending Support (SciENcv); Collaborators & Other Affiliations (COA); Synergistic Activities; Data Management & Sharing Plan; Mentoring Plan (if applicable); Other Supplementary Documents (if applicable); Letters of Collaboration (if applicable); Subaward Documents (if applicable).

  • NIH: Project Summary/Abstract; Project Narrative; Bibliography & References Cited; Facilities & Other Resources; Equipment; Biographical Sketches (SciENcv, all key personnel); Budget; Budget Justification; Introduction to Application [Resubmission/Revision] (if applicable); Specific Aims; Research Strategy; Data Management and Sharing Plan; Vertebrate Animals Section (if applicable); Select Agent Research (if applicable); Multiple PD/PI Leadership Plan (if applicable); Consortium/Contractual Arrangements (if applicable); Letters of Collaboration (if applicable); Human Subjects/Clinical Trial documents (if applicable); Resource Sharing Plan(s) (if applicable); Authentication of Key Biological and/or Chemical Resources.

  • USDA-NIFA: Project Summary; Project Narrative; Budget; Budget Justification; Biographical Sketches (SciENcv); Current & Pending Support (SciENcv); Conflict of Interest List; Bibliography & References Cited; Facilities and Other Resources; Equipment; Data Management Plan (if applicable); Mentoring Plan (if applicable); Logic Model (if applicable); Key Personnel Roles (if applicable); Management Plan (if applicable); Documentation of Collaboration (if applicable); Subaward Documents (if applicable).

  • DOE: Project Summary/Abstract; Project Narrative; Statement of Work; Budget; Budget Justification; Biographical Sketches (SciENcv); Current & Pending Support (SciENcv); Facilities & Other Resources; Equipment; Data Management and Sharing Plan (if applicable); Letters of Collaboration/Commitment (if applicable); Subaward Documents (if applicable).

  • NASA: Proposal Summary/Abstract; Scientific/Technical/Management Plan; References Cited; Budget; Budget Justification; Biographical Sketches (SciENcv); Current & Pending Support (SciENcv); Facilities, Equipment & Other Resources; Table of Personnel and Work Effort; Data Management Plan (if applicable); Letters of Commitment/Support (if applicable); Subaward Documents (if applicable). Senior Key Personnel documents apply to PI/Co-PI/Co-I with ≥10% effort/yr.

formatting_requirements — document-wide preparation rules (fonts, margins, spacing, page size, file naming):

  • If the announcement gives specific formatting instructions, use them verbatim.

  • If it is silent, use the sponsor default below, prefixed exactly with "Sponsor default ():".

  • If it gives some rules but not others, put the stated rules first, then note that the sponsor default fills the rest.

  • A non-backbone sponsor that states no formatting gets null.

Sponsor defaults:

  • NSF: Fonts — Arial (not narrow), Courier New, or Palatino Linotype at 10pt+, or Times New Roman / Computer Modern 11pt+. Margins ≥1 inch all sides (incl. headers/footers). Line spacing ≤6 lines/inch. Page size 8.5×11 in.

  • NIH: Font 11pt+ (smaller allowed only in graphics if legible at 100%). Type density ≤15 characters/inch. Line spacing ≤6 lines/inch. Recommended black font (Arial, Georgia, Helvetica, Palatino Linotype). File names ≤50 characters. No URLs except citations in References Cited and Biosketch. No headers or footers.

  • USDA-NIFA: Typed/word-processed. Font ≥12pt regardless of line spacing. Margins ≥1 inch. Number pages sequentially (unless via eRA). PDF format. File names ≤50 characters, no special characters (& – * % / #), periods, spaces, or accents; underscores allowed; names must be unique.

  • DOE: Defer to the NOFO/FOA; otherwise 8.5×11 in, 1-inch margins, font 11pt+, PDF, avoid URLs with substantive content unless the FOA permits.

  • NASA: 8.5×11 in, ≥1-inch margins, single-spaced 12pt, one column, page limits per the NOFO; only non-substantive material in headers/footers.

submission_details — one coherent paragraph: the submission method or portal the announcement names (e.g., Grants.gov, Research.gov, eRA Commons, JustGrants, NSPIRES, ProposalCentral; never guess), file formats, naming, and collaboration rules. Null only when there is no submission guidance at all.

special_requirements — an array of strings for unique RFA aspects that fit no other section (conference travel obligations, data sharing beyond federal defaults, workshop participation). Empty array when none.

mandated_structure

Announcements often prescribe named sections that must appear inside one component, most often the Project Description. Typical trigger language: "All proposals should clearly include sections for each of the following aspects", "The Project Description must contain the following sections", or a solicitation-specific supplement to the sponsor's proposal guide. A proposal missing such a section can be returned without review, and the checklist reader does not have the announcement open, so:

  1. For each component whose internal structure the announcement prescribes, emit {"component": "<component name>", "mandated_sections": [...]}, one item per mandated section, in the announcement's order, with names verbatim.

  2. Each mandated section is {name, requirements, subsections}. requirements states what the section must contain in the announcement's terms, in 30 words or fewer: compress the wording, never drop a named item.

  3. When a section has enumerated sub-parts (numbered sub-sections, a required table with named columns, a milestone list), list each in subsections as {name, requirements}, with table columns and milestones written out in full. Omit subsections when there are none.

  4. Never replace an enumeration with a pointer such as "must include all subsections listed in Section V.A".

  5. Only structure this announcement prescribes; do not invent structure from the sponsor's standard proposal guide. If no component has mandated structure, emit [].

Example: an NSF solicitation states "All PCL Node proposals should clearly include sections for each of the following aspects:" and names the sections.

  • WRONG (structure lost): a component whose special_requirements says "Must include all specified subsections listed in Section V.A", and no mandated_structure entry.

  • CORRECT (abbreviated; a real answer lists EVERY section the announcement names, in order):

{"component": "Project Description", "mandated_sections": [

  {"name": "Science drivers", "requirements": "Science drivers driving Node development; identified users/communities; how capabilities transform the science; impact on U.S. competitiveness/security."},

  {"name": "Node capabilities", "requirements": "What makes the Node capable/unique in supporting the science drivers.", "subsections": [

    {"name": "Instrument Inventory Table", "requirements": "Separate document, NOT in the 20-page limit; per instrument: type/description + count; relevance with example workflows; available time (duty cycle, hours/day)."},

    {"name": "Node Expertise", "requirements": "Team and expertise for science drivers and data/AI issues."}]},

  {"name": "Management Plan", "requirements": "Roles of PI/co-PIs/staff; coordination meetings.", "subsections": [

    {"name": "Implementation Timeline", "requirements": "Milestones: Project Kickoff; Alpha ≤1 yr; Beta ≤1.5 yr; Robust User Service ≤2 yr; Test Bed 2.0; Project end (Yr 4) deployment plan."}]}

]}

budget_requirements

The sole location for detailed financial rules. Do not restate the award amount or duration. Include an item only when the announcement states it; leave silent items out rather than filling in a typical federal value. Quote the sponsor's language for any explicit cap or "no X allowed" restriction, for cost-sharing status other than "Not Specified", for salary caps and for unallowable-cost categories.

Route these rules, when stated, to the field named:

  • salary caps / limits and faculty summer-salary limits → personnel_effort;

  • graduate-student support, tuition allowed or capped, postdoc support → personnel_effort (or unallowable_costs if explicitly disallowed);

  • participant-support costs and consultant limits → allowable_costs / unallowable_costs / other_considerations as stated;

  • equipment thresholds or caps, computing / device restrictions → funding_limits or other_considerations as stated;

  • food / meals, incentives / participant payments, human-subject payments → allowable_costs / unallowable_costs / other_considerations;

  • travel caps, required travel (e.g., a mandatory PI meeting), international-travel restrictions → other_considerations;

  • publication / open-access / page charges → allowable_costs or other_considerations.

Descriptive fields are flat strings (one natural-language sentence or short paragraph), never nested objects. For example (abbreviated from the workflow task), cost_sharing_details is NOT {"type": ["cash", "in-kind"], "rate": "≥100% of award", "documentation": "Matching Fund Verification Letter"} but "Cash and in-kind, matching contributions equal to or greater than the funding request (≥100% of the award), with at least 50% in cash; documented via Matching Fund Verification Letter(s)."

  • funding_limits — program-wide or per-year caps and category-specific limits not already in amount_per_award. Null when absent.

  • cost_sharing_status — one of "Required", "Voluntary", "Prohibited", "Not Specified".

  • cost_sharing_details — type (cash / in-kind / third-party), rate, basis, documentation and source restrictions in one paragraph; null when the status is "Prohibited" or "Not Specified".

  • fa_policy — F&A / indirect-cost policy: rate, base (MTDC / TDC / S&W), excluded categories, documentation; null when absent.

  • allowable_costs — array of category labels the sponsor explicitly enumerates as allowable; empty when the announcement defers to federal defaults.

  • unallowable_costs — array of category labels the sponsor explicitly enumerates as unallowable; empty when none.

  • personnel_effort — PI / key-personnel effort floors or ceilings, salary caps, student / postdoc support, consultant limits; null when absent.

  • other_considerations — pre-award costs, program income, budget revisions, sponsor-specific budget forms; null when absent.

compliance_risks and international_components

Assess each fixed area and emit one object per area, in the order listed, with area (the exact label), status and detail:

  • status is "yes" when the announcement invokes, requires or restricts the area; "no" when it affirmatively excludes it (e.g., "Human subjects research is not permitted under this program"); "unclear" when it does not address it.

  • detail is a grounded phrase with specifics for "yes", the affirming statement for "no", and null for "unclear".

compliance_risks — research-compliance areas:

  • "Human subjects" — human-subjects research, IRB review, clinical-trial requirements.

  • "Vertebrate animals" — animal use, IACUC review.

  • "Biosafety" — recombinant DNA, biohazards, Institutional Biosafety Committee review.

  • "Export control" — export-control implications (ITAR / EAR), fundamental-research exclusion questions.

  • "Select agents / dual-use research" — select-agent research or dual-use research of concern (DURC).

  • "Controlled unclassified information (CUI)" — CUI generation, handling or marking requirements.

  • "Data security / cybersecurity" — data-security or cybersecurity controls (e.g., NIST SP 800-171, CMMC, a System Security Plan).

  • "National security" — national-security considerations or restrictions stated by the sponsor.

international_components — foreign-influence areas:

  • "Foreign collaborators" — whether foreign collaborators or personnel are allowed, required or restricted.

  • "Foreign subawards" — whether foreign subawards or subrecipients are allowed or restricted.

  • "Foreign travel" — foreign-travel allowances or restrictions.

  • "Foreign talent-program certification" — required certification or disclosure regarding malign foreign talent recruitment programs.

  • "International data sharing" — restrictions on sharing data or materials internationally.

  • "Country-specific restrictions" — restrictions tied to specific countries (e.g., prohibitions on China, Russia, North Korea, Iran or their entities).

important_notes

Zero to three critical warnings or pitfalls a reviewer would otherwise miss, synthesized from across the sections above. Focus on process and timeline pitfalls (registration or portal lead time, letter-of-intent gating, non-standard required attachments). Do not restate financial rules (they live in budget_requirements) or items already in risk_flags. Empty array when nothing rises to this bar.

Output contract

Emit exactly one JSON object with all 24 top-level keys in schema.json. Begin your reply with { and emit nothing except the object: no preamble, closing commentary or markdown fences.

  • Arrays with no entries are [], never null. The exceptions are eligible_institutions, eligible_individuals and required_components, which must be non-empty, as described above.

  • Scalars the document does not state are null, except the two award fields that use "Not specified in the document" and cost_sharing_status, which uses "Not Specified".

  • Inside string values, escape double quotes as \" or use single quotes. One unescaped quote invalidates the whole object.

  • Minified JSON is fine. Minify only the syntax: never shorten, summarize or drop content values ("Up to $5M/year for 4 years, total not to exceed $20M" must not become "$20M total").

Quality Standards

  • The output validates against schema.json (draft 2020-12).

  • risk_flags carries the 17 fixed checks under their exact labels, once each, in order, each with an enum status. compliance_risks carries the 8 fixed areas and international_components the 6.

  • Statuses are "unclear" when the document is silent. "no" is reserved for an affirmative statement.

  • Every component carries a source from the three enum values. Every non-stub component carries a description, and the sponsor backbone is present for NSF, NIH, USDA-NIFA, DOE and NASA announcements.

  • Recurring or relative deadlines are resolved to a concrete date, with the rule text kept in notes.

  • Dates, monetary amounts and percentages keep the sponsor's original formatting.

  • No fact appears in two sections, except the short grounded mentions that risk_flags makes of triggers detailed elsewhere.

Output schema

Source: schema.json.

Show schema.json 
{

  "$schema": "https://json-schema.org/draft/2020-12/schema",

  "$id": "https://github.com/AI4RA/prompt-library/components/rfa-checklist-extraction-udm/schema.json",

  "title": "RFA Checklist Extraction \u2014 UDM Output",

  "description": "JSON contract for a Request-for-Applications (RFA/FOA/NOFO/program solicitation) distilled into the sections a pre-award office uses as a working checklist. Since 1.0.0 it mirrors the ten extraction fragments of the rfa-checklist-extraction workflow v3.1.0 field for field: opportunity metadata (top-level scalars), risk_flags, dates_and_deadlines, eligible_institutions, eligible_individuals, award_information, the application-components block (required_components, optional_components, submission_details, special_requirements, formatting_requirements), mandated_structure, budget_requirements, and compliance_risks / international_components, plus important_notes. Placement rules are enforced by the prompt and, where possible, by the shape.",

  "version": "1.0.0",

  "type": "object",

  "additionalProperties": false,

  "required": [

    "rfa_id",

    "rfa_number",

    "rfa_title",

    "sponsor_name",

    "program_code",

    "announcement_url",

    "opportunity_number",

    "cfda_number",

    "funding_instrument_type",

    "risk_flags",

    "dates_and_deadlines",

    "eligible_institutions",

    "eligible_individuals",

    "award_information",

    "required_components",

    "optional_components",

    "submission_details",

    "special_requirements",

    "formatting_requirements",

    "mandated_structure",

    "budget_requirements",

    "compliance_risks",

    "international_components",

    "important_notes"

  ],

  "properties": {

    "rfa_id": {

      "type": [

        "string",

        "null"

      ],

      "description": "Sponsor-prefixed identifier when both a sponsor code and an opportunity number exist (e.g., 'NSF-26-508', 'NIH-PA-24-246', 'DOE-DE-FOA-0003117'). Null otherwise."

    },

    "rfa_number": {

      "type": [

        "string",

        "null"

      ],

      "description": "The sponsor's announcement number without agency prefix (e.g., '26-508', 'PA-24-246')."

    },

    "rfa_title": {

      "type": "string",

      "minLength": 1,

      "description": "Full title of the funding opportunity, including any track or component designation."

    },

    "sponsor_name": {

      "type": "string",

      "minLength": 1,

      "description": "Full name of the lead sponsoring agency (e.g., 'National Science Foundation'); never an abbreviation. Resolved downstream to Sponsor_Organization_ID."

    },

    "program_code": {

      "type": [

        "string",

        "null"

      ],

      "description": "Sponsor's internal program or division code (e.g., 'NSF/TIP/ITE'). Null when not stated."

    },

    "announcement_url": {

      "type": [

        "string",

        "null"

      ],

      "description": "Canonical URL of the announcement on the sponsor's site. Null when not present."

    },

    "opportunity_number": {

      "type": [

        "string",

        "null"

      ],

      "description": "Grants.gov or portal opportunity ID when distinct from rfa_number."

    },

    "cfda_number": {

      "type": [

        "string",

        "null"

      ],

      "description": "CFDA / Assistance Listing number(s); comma-separated when multiple."

    },

    "funding_instrument_type": {

      "type": [

        "string",

        "null"

      ],

      "description": "Award mechanism in the document's own term ('Grant', 'Cooperative Agreement', 'Contract', ...). Null when not stated; never guessed from the sponsor."

    },

    "risk_flags": {

      "type": "array",

      "minItems": 17,

      "description": "One object per fixed check (5 escalation + 12 CRU, in prompt order), optionally followed by extra document-supported flags. Feeds the Red Flags banner.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "check",

          "category",

          "status",

          "detail"

        ],

        "properties": {

          "check": {

            "type": "string",

            "minLength": 1,

            "description": "The exact fixed-check label, or a descriptive label for an appended extra flag."

          },

          "category": {

            "type": "string",

            "enum": [

              "escalation",

              "cru"

            ],

            "description": "'escalation' = lengthens the process or needs early institutional action; 'cru' = Contract Review Unit trigger."

          },

          "status": {

            "type": "string",

            "enum": [

              "yes",

              "no",

              "unclear"

            ],

            "description": "'yes' / 'no' (affirmatively ruled out) / 'unclear' (not addressed \u2014 never 'no' for silence)."

          },

          "detail": {

            "type": [

              "string",

              "null"

            ],

            "description": "Grounded phrase with specifics when 'yes'; the affirming statement when 'no'; null when 'unclear'."

          }

        }

      }

    },

    "dates_and_deadlines": {

      "type": "array",

      "description": "Every unique date or time-bound event, chronologically. Recurring / relative deadline rules are resolved to a concrete date, with the rule text kept in notes.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "item",

          "date_time"

        ],

        "properties": {

          "item": {

            "type": "string",

            "minLength": 1,

            "description": "Event label exactly as stated (e.g., 'Full Proposal Deadline')."

          },

          "date_time": {

            "type": "string",

            "minLength": 1,

            "description": "Date plus any time and timezone as published (e.g., '2026-09-15 5:00 PM ET', 'Rolling'); for a recurring rule, the resolved ISO date."

          },

          "notes": {

            "type": [

              "string",

              "null"

            ],

            "description": "Conditions, round identifiers or clarifications; for a resolved rule, the original rule text. Null when none."

          }

        }

      }

    },

    "eligible_institutions": {

      "type": "array",

      "minItems": 1,

      "description": "One entry per institution category the sponsor names, including a separate 'Subrecipients / Subawardees' entry when the document states subrecipient rules. A single 'Not specified in this document' entry when nothing is stated.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "type"

        ],

        "properties": {

          "type": {

            "type": "string",

            "minLength": 1,

            "description": "Institution category label as stated."

          },

          "subcategory": {

            "type": [

              "string",

              "null"

            ],

            "description": "More specific classification when given (e.g., 'EPSCoR-eligible')."

          },

          "examples": {

            "type": [

              "string",

              "null"

            ],

            "description": "Sponsor-supplied examples as a short comma-separated list."

          },

          "compliance_requirements": {

            "type": [

              "string",

              "null"

            ],

            "description": "Registrations, certifications, institutional prerequisites and institution-level limited-submission caps."

          }

        }

      }

    },

    "eligible_individuals": {

      "type": "array",

      "minItems": 1,

      "description": "One entry per PI / Co-PI / senior-personnel category. A single 'Not specified in this document' entry when nothing is stated.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "type"

        ],

        "properties": {

          "type": {

            "type": "string",

            "minLength": 1,

            "description": "Individual eligibility category (e.g., 'Principal Investigator')."

          },

          "criteria": {

            "type": [

              "string",

              "null"

            ],

            "description": "Degree, career stage, appointment type, citizenship, required credentials."

          },

          "compliance_requirements": {

            "type": [

              "string",

              "null"

            ],

            "description": "ORCID, mentoring plans or other PI compliance items."

          },

          "conditions": {

            "type": [

              "string",

              "null"

            ],

            "description": "Restrictions and limits, including per-individual and per-institution submission caps and limited-submission mechanics."

          }

        }

      }

    },

    "award_information": {

      "type": "object",

      "additionalProperties": false,

      "description": "The SOLE location for primary award parameters. Detailed financial rules belong in budget_requirements.",

      "required": [

        "award_duration",

        "amount_per_award",

        "number_of_awards",

        "anticipated_award_date"

      ],

      "properties": {

        "award_duration": {

          "type": "string",

          "minLength": 1,

          "description": "Anticipated duration as stated; 'Not specified in the document' when absent."

        },

        "amount_per_award": {

          "type": "string",

          "minLength": 1,

          "description": "Per-award amount with its basis (total vs direct costs), in the sponsor's formatting; 'Not specified in the document' when absent."

        },

        "number_of_awards": {

          "type": [

            "string",

            "integer",

            "null"

          ],

          "description": "Anticipated count as stated: text such as '10-15' or 'Subject to availability of funds', or a bare integer count. Null only when absent."

        },

        "anticipated_award_date": {

          "type": [

            "string",

            "null"

          ],

          "description": "As stated; ISO YYYY-MM-DD when given, otherwise free text (e.g., 'Spring 2027'). Null when absent."

        }

      }

    },

    "required_components": {

      "type": "array",

      "minItems": 1,

      "description": "Every required proposal component, merged with the sponsor backbone (NSF, NIH, USDA-NIFA, DOE, NASA): announcement-sourced components first, then the backbone.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "name",

          "source"

        ],

        "properties": {

          "name": {

            "type": "string",

            "minLength": 1,

            "description": "Component name, in the announcement's wording when the announcement names it."

          },

          "description": {

            "type": "string",

            "minLength": 1,

            "description": "What the component must contain, in the announcement's terms. Required unless the component is a pure 'Sponsor standard' stub, which carries only name and source."

          },

          "special_requirements": {

            "type": [

              "string",

              "null"

            ],

            "description": "Page limits, title rules, fonts, templates and naming for this component only. Never a pointer to an announcement section, never internal section structure (that lives in mandated_structure). Null or omitted when none.",

            "minLength": 1

          },

          "source": {

            "type": "string",

            "enum": [

              "Announcement",

              "Sponsor standard",

              "Announcement + sponsor standard"

            ],

            "description": "'Announcement' = the announcement requires it and it is not a backbone item; 'Sponsor standard' = added from the sponsor backbone; 'Announcement + sponsor standard' = in both, or a backbone item the announcement modifies."

          }

        },

        "if": {

          "required": [

            "source"

          ],

          "properties": {

            "source": {

              "const": "Sponsor standard"

            }

          }

        },

        "else": {

          "required": [

            "description"

          ]

        }

      }

    },

    "optional_components": {

      "type": "array",

      "description": "Optional and '(if applicable)' components, including Subaward Documents. Empty array when none.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "name",

          "source"

        ],

        "properties": {

          "name": {

            "type": "string",

            "minLength": 1,

            "description": "Component name, in the announcement's wording when the announcement names it."

          },

          "description": {

            "type": "string",

            "minLength": 1,

            "description": "What the component must contain, in the announcement's terms. Required unless the component is a pure 'Sponsor standard' stub, which carries only name and source."

          },

          "special_requirements": {

            "type": [

              "string",

              "null"

            ],

            "description": "Page limits, title rules, fonts, templates and naming for this component only. Never a pointer to an announcement section, never internal section structure (that lives in mandated_structure). Null or omitted when none.",

            "minLength": 1

          },

          "source": {

            "type": "string",

            "enum": [

              "Announcement",

              "Sponsor standard",

              "Announcement + sponsor standard"

            ],

            "description": "'Announcement' = the announcement requires it and it is not a backbone item; 'Sponsor standard' = added from the sponsor backbone; 'Announcement + sponsor standard' = in both, or a backbone item the announcement modifies."

          }

        },

        "if": {

          "required": [

            "source"

          ],

          "properties": {

            "source": {

              "const": "Sponsor standard"

            }

          }

        },

        "else": {

          "required": [

            "description"

          ]

        }

      }

    },

    "submission_details": {

      "type": [

        "string",

        "null"

      ],

      "description": "One coherent paragraph: the submission portal the announcement names, file formats, naming, collaboration rules. Null only when there is no submission guidance at all."

    },

    "special_requirements": {

      "type": "array",

      "items": {

        "type": "string",

        "minLength": 1

      },

      "description": "Unique RFA aspects that fit no other section (conference travel obligations, data sharing beyond federal defaults, workshop participation). Empty array when none."

    },

    "formatting_requirements": {

      "type": [

        "string",

        "null"

      ],

      "description": "Document-wide preparation rules: the announcement's own rules verbatim, else the sponsor default prefixed 'Sponsor default (<SPONSOR>):', or both combined. Null for a non-backbone sponsor that states none."

    },

    "mandated_structure": {

      "type": "array",

      "description": "Internal sections the announcement itself mandates inside a component (e.g., the Project Description), names verbatim and in order. Empty array when none.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "component",

          "mandated_sections"

        ],

        "properties": {

          "component": {

            "type": "string",

            "minLength": 1,

            "description": "The component whose internal structure is mandated."

          },

          "mandated_sections": {

            "type": "array",

            "minItems": 1,

            "items": {

              "type": "object",

              "additionalProperties": false,

              "required": [

                "name",

                "requirements"

              ],

              "properties": {

                "name": {

                  "type": "string",

                  "minLength": 1,

                  "description": "Section name verbatim."

                },

                "requirements": {

                  "type": "string",

                  "minLength": 1,

                  "description": "What the section must contain, 30 words or fewer."

                },

                "subsections": {

                  "type": "array",

                  "description": "Enumerated sub-parts, table columns or milestones; omitted when none.",

                  "items": {

                    "type": "object",

                    "additionalProperties": false,

                    "required": [

                      "name",

                      "requirements"

                    ],

                    "properties": {

                      "name": {

                        "type": "string",

                        "minLength": 1

                      },

                      "requirements": {

                        "type": "string",

                        "minLength": 1

                      }

                    }

                  }

                }

              }

            }

          }

        }

      }

    },

    "budget_requirements": {

      "type": "object",

      "additionalProperties": false,

      "description": "The SOLE location for detailed financial rules. Descriptive fields are flat strings, never nested objects.",

      "required": [

        "funding_limits",

        "cost_sharing_status",

        "cost_sharing_details",

        "fa_policy",

        "allowable_costs",

        "unallowable_costs",

        "personnel_effort",

        "other_considerations"

      ],

      "properties": {

        "funding_limits": {

          "type": [

            "string",

            "null"

          ],

          "description": "Program-wide or per-year caps and category-specific limits."

        },

        "cost_sharing_status": {

          "type": "string",

          "enum": [

            "Required",

            "Voluntary",

            "Prohibited",

            "Not Specified"

          ],

          "description": "Cost-sharing status (UDM CostShare)."

        },

        "cost_sharing_details": {

          "type": [

            "string",

            "null"

          ],

          "description": "Type, rate, basis, documentation and source restrictions in one paragraph. Null when the status is 'Prohibited' or 'Not Specified'."

        },

        "fa_policy": {

          "type": [

            "string",

            "null"

          ],

          "description": "F&A / indirect-cost policy: rate, base, exclusions (UDM IndirectRate)."

        },

        "allowable_costs": {

          "type": "array",

          "items": {

            "type": "string",

            "minLength": 1

          },

          "description": "Categories the sponsor explicitly enumerates as allowable."

        },

        "unallowable_costs": {

          "type": "array",

          "items": {

            "type": "string",

            "minLength": 1

          },

          "description": "Categories the sponsor explicitly enumerates as unallowable."

        },

        "personnel_effort": {

          "type": [

            "string",

            "null"

          ],

          "description": "Effort floors or ceilings, salary caps, student / postdoc support, consultant limits (UDM Effort)."

        },

        "other_considerations": {

          "type": [

            "string",

            "null"

          ],

          "description": "Pre-award costs, program income, budget revisions, required travel, sponsor-specific budget forms."

        }

      }

    },

    "compliance_risks": {

      "type": "array",

      "minItems": 8,

      "description": "One object per fixed research-compliance area, in prompt order.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "area",

          "status",

          "detail"

        ],

        "properties": {

          "area": {

            "type": "string",

            "minLength": 1,

            "description": "The exact fixed-area label (see prompt.md)."

          },

          "status": {

            "type": "string",

            "enum": [

              "yes",

              "no",

              "unclear"

            ],

            "description": "'yes' = the announcement invokes, requires or restricts it; 'no' = affirmatively excluded; 'unclear' = not addressed."

          },

          "detail": {

            "type": [

              "string",

              "null"

            ],

            "description": "Grounded phrase with specifics when 'yes'; the affirming statement when 'no'; null when 'unclear'."

          }

        }

      }

    },

    "international_components": {

      "type": "array",

      "minItems": 6,

      "description": "One object per fixed foreign-influence area, in prompt order.",

      "items": {

        "type": "object",

        "additionalProperties": false,

        "required": [

          "area",

          "status",

          "detail"

        ],

        "properties": {

          "area": {

            "type": "string",

            "minLength": 1,

            "description": "The exact fixed-area label (see prompt.md)."

          },

          "status": {

            "type": "string",

            "enum": [

              "yes",

              "no",

              "unclear"

            ],

            "description": "'yes' = the announcement invokes, requires or restricts it; 'no' = affirmatively excluded; 'unclear' = not addressed."

          },

          "detail": {

            "type": [

              "string",

              "null"

            ],

            "description": "Grounded phrase with specifics when 'yes'; the affirming statement when 'no'; null when 'unclear'."

          }

        }

      }

    },

    "important_notes": {

      "type": "array",

      "items": {

        "type": "string",

        "minLength": 1

      },

      "description": "Critical warnings or context a reviewer would miss, synthesized across sections. Short; not an overflow bucket. Empty array when none."

    }

  }

}

Changelog

Source: CHANGELOG.md.

All notable changes to this component. Versions follow semver: MAJOR for output-contract breaks, MINOR for backward-compatible additions, PATCH for wording or clarity.

[1.0.0] — 2026-10-06

  • MAJOR — synced to the rfa-checklist-extraction workflow v3.1.0. The 0.1.0 contract predated the workflow's 2026-08 changes, so the workflow prompts had moved ahead of prompt.md / schema.json. The contract is now the union of the workflow's ten extraction fragments, field for field:
  • New fields: funding_instrument_type, risk_flags (17 fixed checks: 5 escalation + 12 Contract Review Unit), formatting_requirements, mandated_structure, compliance_risks (8 fixed areas), international_components (6 fixed areas).
  • Components gain a required source (Announcement / Sponsor standard / Announcement + sponsor standard) and the sponsor backbone (NSF, NIH, USDA-NIFA, DOE, NASA). A pure "Sponsor standard" component is a {name, source} stub; every other component needs a description. A component's special_requirements may be omitted or null.
  • budget_requirements: cost_sharing: {status, details} becomes the workflow's flat cost_sharing_status / cost_sharing_details (same enum).
  • award_information.number_of_awards may be text, an integer or null.
  • Every top-level key is now required, including the metadata scalars (null when not stated).
  • important_notes stays (0–3 items, synthesized like the workflow's consolidation step).
  • Prompt: the ten task prompts' rules are merged into one single-call prompt (fixed labels, backbone lists and formatting defaults verbatim), including recurring-deadline resolution, limited-submission capture and the formatting precedence rule.
  • Checked against real outputs: across the evaluation harness's v3.1.0 replays (2,900 runs), a merged set of the ten fragments plus important_notes validates against this schema exactly when every fragment passes the harness's v3.1.0 fragment schemas (0 disagreements).
  • The workflow keeps its 0.1.0 pin; its manifest now records the lag with pinned_version_sha.

[0.1.0] — 2026-04-24

  • Initial experimental release.
  • Schema derived from the rfa-checklist-extraction v2 Vandalizer workflow in ui-insight/ProcessMapping (six parallel extraction tasks + consolidation, 17 source fields).
  • Scalar metadata (rfa_id, rfa_number, rfa_title, sponsor_name, program_code, announcement_url, opportunity_number, cfda_number) aligned with standard opportunity-metadata conventions.
  • Eight structured sections each given a distinct shape to enforce the de-duplication / placement contract at schema level.
  • cost_sharing.status enum matches the Cost_Sharing Enum_Values from the source workflow (Required, Voluntary, Prohibited, Not Specified).
  • UDM column bindings preserved: cost_sharing → CostShare, fa_policy → IndirectRate, personnel_effort → Effort.
  • No eval cases yet — status experimental until at least one golden extraction is added under evals/cases/.