By October 4, 2026, Grants.gov’s public XML index was listing daily opportunity extract files with names ending in `v2.zip`, and Grants.gov’s help documentation says that v2 is an enhanced XML format that includes grant forecast information (XML extract index, XML extract help). Set against NIH’s August 14, 2025 notice that, beginning in fiscal year 2026, Notices of Funding Opportunities, or NOFOs, would no longer be posted in the NIH Guide and that Grants.gov would be NIH’s single official source for grant and cooperative agreement opportunities, that is not just a formatting update. It is a feed-governance issue for research offices (NIH notice NOT-OD-25-143).
The first check is source-of-truth alignment. NIH’s notice is a 2025 policy statement written in future tense about FY2026, so by October 4, 2026 it is evidence of intended practice, not a direct measurement of every current outcome. Still, the notice is explicit that the NIH Guide would continue for policy and informational notices while official opportunity postings would move to Grants.gov, and that NIH NOFOs would no longer appear in the weekly NIH Guide Table of Contents emails (NIH notice NOT-OD-25-143). The practical implication is simple: an institution that still treats NIH Guide traffic as its main discovery input may be aligned to the wrong channel, even if staff still see NIH-related announcements.
The second check is schema behavior, not just file retrieval. Grants.gov says the v2 extract includes forecast information, and its field table identifies elements that appear only in Forecast records, including Close Date, Estimated Synopsis Post Date, Fiscal Year, Estimated Synopsis Close Date, Estimated Award Date, Estimated Project Start Date, Grantor Contact Name, and Version values such as Forecast X. The same help page also says that when a field is blank, the element will not appear in the extract at all (XML extract help). That combination can break rigid parsers in two directions at once: new forecast fields may be ignored, while omitted blank elements may be misread as malformed data. As analysis, that makes a parser test more important than a spot-check of one visible record.
A hypothetical example shows the distinction. If a campus database expects every record to carry the same closing-date element, a forecast record that follows Grants.gov’s documented rules could be mishandled even though the source file is valid. Research offices therefore need to confirm not only that `v2.zip` files download, but that forecast-only fields are mapped intentionally and absent elements are handled safely (XML extract help, XML extract index). The public index supports the urgency of that test because it showed v2-named files across the observed September 28 to October 4, 2026 window, but it does not establish the first production date of v2 or whether earlier naming patterns persisted elsewhere.
The third check is system-to-system behavior for offices or vendors that use Grants.gov web services beyond the daily extract. Both the applicant-side and grantor-side Get Application Zip pages say V2.0 supports large submissions, but they do not apply the same business rule. The applicant service ties valid tracking numbers to the current certificate or a linked previous certificate, while the grantor service requires a tracking number valid for the agency using that service (Applicant Get Application Zip, Grantor Get Application Zip). In operational terms, a failed test may reflect credential scope rather than a bad package.
For research administrators, the immediate task is to ask internal IT teams or vendors for written evidence that they tested four things: v2 filename handling, forecast-field mapping, omitted-element tolerance, and role-specific V2.0 web-service behavior. Until that evidence exists, a feed that still loads should not be treated as proof that NIH opportunity coverage is complete. The source record supports a narrow conclusion, but an important one: when an official posting venue shifts and the published extract format changes, institutions need to verify both changes together, not assume either one is backward compatible by default.
