Funder rule packs

A rule pack is a declarative YAML file describing sourced rules and metadata the engine can use to lint and scaffold a grant for one funder: its sections and limits, formatting guidance (each with a citation), budget caps, portal quirks, spelling locale, and review rubric. Some formatting guidance requires generated-artifact or manual review rather than a Markdown check. Packs live under grantkit/data/funders/; the stem of the filename is the pack id (nsf-pappg.yaml → nsf-pappg).

Packs that ship today¶

Using a pack¶

grantkit init --funder <id> scaffolds from a pack. At runtime a grant is matched to a pack by its pack: field, then by funder name.

Schema¶

The full schema is documented in grantkit/packs/schema.py. Top-level keys:

Inheritance¶

Use extends: <pack-id> when a solicitation modifies a broader funder policy. Mappings merge recursively. A value in the child wins; lists and scalars are replaced, not appended. A program pack that supplies sections or review_rubric must therefore include the complete program-specific list. Inherited values are resolved and schema-validated when the pack is loaded.

proposal_rules enforce constraints on the proposal as a whole, currently a required title prefix and maximum duration. attachment_groups enforce the number of files matched by a project-relative glob and, for PDFs, an optional per-file page limit. For example, the PESOSE Track 2 pack checks the exact Track 2 title prefix, a 24-month maximum, and 3-5 collaboration letters of no more than two pages each.

PESOSE submission-readiness evidence¶

The PESOSE engine requires a pesose.compliance mapping in grant.yaml. GrantKit derives prose and file facts itself where it can: actual letter files and PDF page counts, the personnel table, DMSP fields, Senior/Key document existence and Synergistic Activities page counts, and a declared Mentoring Plan upload. It does not turn keyword matches into eligibility or substantive compliance. Facts available only to the proposer or AOR must be explicit attestations.

The mapping is organized into these evidence groups:

Place every declared letter PDF directly under letters/—the checker scans letters/*.pdf, not nested directories—and key letters.manifest by the project-relative path (for example, letters/state-user.pdf). A fresh PESOSE scaffold includes copyable entry shapes plus letters/README.md and senior-key/README.md with these file conventions.

Use the literal not_applicable only when the matching scope declaration makes a field inapplicable. false, omission, and not_applicable are intentionally different. Run grantkit check after adding the mapping; each finding names the specific missing or contradictory declaration and cites its rule family.

PESOSE budget-preparation evidence¶

The PESOSE Track 2 pack encodes NSF’s March 9, 2026 budget-preparation update under budget_rules.preparation. The pack owns the sourced values: the BLS 75th percentile, two-person-month, 10%, $50,000, and 15% thresholds; the affected organization/payment types; and the Track 2 subaward rules. The August 12, 2026 I-Corps update supplies manual-review context for the virtual format and expected maximum of three training-team members.

For grantkit check to verify them, budget.yaml uses these evidence fields:

Every funded line must also provide year_N amounts (covering the applicable years) or funds_per_year. Total-only sidecar fields such as funding_amount do not participate in the legacy calculator’s cap arithmetic and therefore produce an error instead of a potentially false pass.

Document paths are checked for existence and cannot escape the grant directory. Signature, execution, statement contents, employee status, salary-policy compliance, current-rate comparisons, narrative inclusion, and ownership are explicit attestations because GrantKit cannot establish those facts from the budget arithmetic or narrative alone. Missing cumulative NSF-support data is a manual-review warning; a declared over-threshold value without its required explanation is an error. Financial values used in cap arithmetic must be finite and non-negative.

Contributing a pack¶

1. Copy an existing pack and rename it to <funder>.yaml.

2. Only encode what you can source. Leave a limit null if the funder does not publish one — never invent a number. Absence of a limit is unknown, not unlimited.

3. Record provenance. Add a provenance: field and inline comments citing where each value came from (URL, solicitation, or a reference application).

4. Set the essentials: locale and portal.accepts_markdown drive the spelling and plain-text checks.

5. Cite formatting rules. Every formatting_rules entry should carry a citation (and ideally a url and verbatim quote).

6. Validate and test:

   python -c "from grantkit.packs import load_pack; load_pack('your-pack')"

   load_pack validates against the schema and raises on any error. Add a case to tests/test_packs.py asserting your sourced values.

Content engines¶

Most formatting rules are sourced pack guidance and cannot be verified from Markdown (font size and margins are PDF-level). Builders and PDF validation enforce or report the subset they can establish. A pack can opt into a content engine — a named programmatic checker — via content_engine. nsf_pappg runs the NSF-wide content checks; the nsf_pesose_26_506_track_2 engine adds Track 2 checks for summary keywords, I-Corps waiver disclosure, personnel-list guidance, letters, eligibility, supplementary documents, DMSP structure, and explicit human-review attestations for substantive proposal coverage.