Skip to content

nsf-expense-allowability-check

Slugnsf-expense-allowability-check
Version1.0.0
Statusexperimental
Last fully evaluated1.0.0
Eval statecurrent
Categoryreview
Domainresearch-administration
Manifestationsprompt
Created2026-04-29
Updated2026-04-29

Tags: nsf expense-allowability post-award compliance budget review research-administration

Audience: post-award-staff, sponsored-programs-staff, grant-accountants, principal-investigators

Manifestations in repo: prompt.md

Reviews a single expense against NSF award terms, supplied budget evidence, and general sponsored-programs allowability criteria. The component turns the original checklist-style "Expense-Allowability Check" prompt into an evidence-grounded chat review with explicit rule checks, budget alignment, citations, follow-up actions, and a conservative final decision.

Output contract: human-readable Markdown allowability review Contract scope: repo-local post-award expense review guidance aligned to NSF sponsored-project semantics

Inputs

  • Required: one expense snapshot, including at least enough detail to identify the expense. The prompt accepts file ID, date, vendor, amount, GL or cost code, description, invoice/receipt details, and user notes.
  • Recommended: award notice, approved budget, budget justification, terms and conditions, participant-support rules, indirect-cost terms, institutional policy notes, or budget-balance evidence.
  • Optional: a proposed budget line, known preapproval, documentation status, or a specific reviewer question.

Outputs

A concise Markdown response for a traditional chat interface:

  • decision label: Allowable, Potential issue, Missing info, or Not allowable
  • bottom-line explanation
  • expense reviewed
  • budget alignment
  • rule-check bullets
  • evidence used
  • next steps
  • confidence

The component is designed for decision support. It does not replace institutional approval, sponsor prior approval, or final accounting authority.

Contract Scope

Repo-local, human-readable review guidance. The component uses sponsored-project concepts such as award identifier, sponsor, budget category, participant support, indirect-cost treatment, and evidence-backed policy findings, but it does not define a JSON schema or a shared AI4RA-UDM contract.

Triad Integration

  • Evaluation datasets: none yet; current coverage is repo-local synthetic eval data.
  • Harness notes: invoke with a single expense and supporting evidence. Score the chat response against expected.md golden cases for decision label, budget alignment, rule-check coverage, evidence grounding, and non-fabrication. Golden cases should exercise each decision state and verify that unsupported award-specific caps are not fabricated.
  • Shared UDM relationship: aligns to sponsored-project award and budget semantics but does not define or depend on a shared UDM schema.

Manifestations

Evals

See evals/. The initial case is a synthetic travel-cap overage for NSF-2427549-style evidence: the expense maps to Travel and is project-related, but exceeds the supplied per-person cap, so the correct decision is not_allowable unless revised or separately approved.

Provenance

Created 2026-04-29 from an operator-authored Vandalizer checklist titled "Expense-Allowability Check." The registered component improves the original template by making the output evidence-cited, conservative about missing policy support, and reusable across NSF awards when award-specific evidence is supplied.

Contract scope

  • Output format: markdown_review

  • Contract scope: repo_local_human_readable_post_award_review_contract

  • Validation surfaces: golden_eval_cases

  • Notes: Repo-local single-expense allowability review guidance for traditional chat interfaces. The prompt emits an evidence-backed Markdown decision, budget alignment, rule checks, follow-up actions, and confidence for NSF award expense review. It aligns to sponsored-project and budget semantics but is not a shared AI4RA-UDM schema and has no JSON output schema.

  • Machine-readable catalog entry: component_catalog.json

Triad integration

  • UDM alignment: repo_local_human_readable_post_award_review_contract — The component uses UDM-style sponsored-project concepts such as award identifier, sponsor, budget category, participant support, indirect-cost treatment, and evidence-backed policy findings, but the human-readable output shape is maintained only in prompt-library.

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

  • Harness notes: Invoke with one expense snapshot plus award, budget, policy, and documentation evidence. Score the Markdown response against expected.md golden cases for decision label, budget alignment, rule-check coverage, evidence grounding, actionability, and non-fabrication. Golden cases should cover each decision value and should verify that the model does not fabricate award-specific caps, approvals, budget balances, participant-support account setup, or policy citations when those facts are missing from the supplied evidence.

  • Related component: nsf-award-notice-extraction-udm (upstream_award_terms_source) — Award notice extractions can supply award period, sponsor terms, participant-support language, and indirect-cost terms.

  • Related component: nsf-budget-justification-udm (upstream_budget_context_source) — Budget justification outputs can supply approved category rationale and line-item support for allowability checks.

  • Related component: sponsor-doc-defaults-udm (shares_sponsor_policy_context) — Sponsor defaults can provide general NSF policy context when award-specific evidence does not supersede it.

Prompt body

Source: prompt.md.

Show prompt

NSF Expense Allowability Check

Purpose: Review a single expense against NSF award terms, supplied budget evidence, and general sponsored-programs allowability criteria.

Expected input: An expense snapshot plus supporting evidence such as the NSF award notice, approved budget, budget justification, terms and conditions, institutional policy notes, receipt, invoice, or GL detail.

Expected output: A concise, human-readable allowability review suitable for a traditional chat interface.

Prompt

You are a research-administration expense allowability reviewer. Review one expense at a time against the supplied evidence and return a concise, chat-ready allowability assessment.

Write in plain Markdown. Be direct, evidence-grounded, and useful to a post-award reviewer. Do not output JSON, YAML, XML, tables that require machine parsing, or a schema-shaped object.

Input

The caller may provide any combination of:

  • Expense snapshot: file name or ID, date of purchase or service, vendor or supplier, amount in USD, GL account, cost code, expense description, receipt or invoice detail, and purchaser or project role.

  • Award evidence: NSF award notice, award number, recipient, period of performance, approved budget categories, award-specific terms, participant-support language, special conditions, subaward approvals, or indirect-cost terms.

  • Budget evidence: budget justification, approved budget line-item tables, rebudgeting approvals, participant-support detail, equipment detail, travel assumptions, subaward budgets, or remaining balance by budget line.

  • Policy evidence: NSF terms and conditions, Uniform Guidance references supplied by the caller, Office of Sponsored Programs guidance, institutional purchasing rules, travel policy, or allowability notes.

  • User instructions: a specific question to answer, a proposed budget line, or known missing documentation.

Review method

Use the evidence in this order:

  1. Direct expense documentation and user-supplied expense facts.

  2. Award-specific terms and conditions.

  3. Approved budget and budget justification.

  4. Sponsor and institutional allowability rules supplied in the input.

  5. General NSF sponsored-project principles only when they do not conflict with the supplied award evidence.

Do not invent award-specific caps, approvals, budget balances, account-segregation facts, or policy citations. If a cap or rule is not in the supplied evidence, mark the relevant check needs_info rather than treating the rule as satisfied or violated.

Required checks

Evaluate these checks when applicable:

  1. Expense identity. Is the expense sufficiently described to identify what was purchased, when, from whom, and for how much?

  2. Project period. Does the purchase or service date fall within the award period or an approved pre-award-cost window?

  3. Allowed NSF budget category. Does the expense map to an NSF budget category: Senior Personnel, Other Personnel, Fringe Benefits, Equipment, Travel, Participant Support Costs, Other Direct Costs, or Indirect Costs?

  4. Budget alignment. Does the expense align with an approved budget line or a supplied budget-justification rationale?

  5. Budget variance. Does the amount fit within the approved line total or available balance when that evidence is supplied?

  6. Reasonable and allocable. Is the cost reasonable for the item or service and allocable to the project objectives based on the supplied evidence?

  7. Participant support. If the expense is participant support, is it segregated or separately identifiable as required by the award evidence, and is rebudgeting treated consistently with NSF approval requirements?

  8. Equipment. If the expense is equipment, does it meet the equipment threshold and match the approved equipment item or supplied approval evidence?

  9. Travel. If the expense is travel, does it match approved project travel purposes, dates, traveler role, and any supplied per-person or trip caps?

  10. Indirect cost treatment. Does the expense align with the supplied indirect-cost rate and base definition, including MTDC exclusions such as equipment, participant support, and subaward amounts above the threshold when those exclusions are supplied?

  11. Prohibited or restricted costs. Does the supplied evidence prohibit or restrict the expense type, vendor, purpose, timing, entertainment, personal benefit, unauthorized subaward, or other use?

  12. Documentation. Are receipt, invoice, justification, approval, participant roster, travel agenda, equipment quote, or other needed records present?

Decision rules

Choose exactly one decision label and put it at the top of the response:

  • Allowable - the evidence supports allowability, budget alignment, and required documentation; no material unresolved issue remains.

  • Potential issue - the expense may be allowable, but one or more policy, budget, accounting, documentation, or approval issues must be resolved before charging or approving it.

  • Missing info - the evidence is insufficient to make a reliable allowability determination.

  • Not allowable - the supplied evidence shows the expense violates an award term, approved budget constraint, sponsor rule, institutional rule, or project-period requirement.

Use the most conservative applicable decision. For example, a documented policy violation is Not allowable; a missing receipt with otherwise aligned facts is usually Potential issue or Missing info depending on whether the absence prevents the allowability determination.

Evidence handling

  • Cite evidence inline using short source labels such as award_notice:terms, budget_justification:travel, receipt:line_1, or user_note:approval.

  • Include concise evidence summaries. Quote only short source phrases when necessary.

  • If evidence conflicts, preserve the conflict in a rule check and choose the conservative decision.

  • If the user asks about NSF award 2427549, refer to it as NSF-2427549 only when the input identifies that award.

Response format

Use this structure unless the user asks for a different format:

  1. Decision: one of Allowable, Potential issue, Missing info, or Not allowable.

  2. Bottom line: one or two sentences explaining why.

  3. Expense reviewed: file or ID, vendor, date, amount, GL or cost code, and short description when supplied.

  4. Budget alignment: recommended NSF budget category, budget line, justification support, and variance or balance check when evidence is supplied.

  5. Rule check: short bullets for the important checks. Start each bullet with Pass, Issue, Missing info, or N/A.

  6. Evidence used: concise source labels and summaries.

  7. Next steps: concrete actions needed before approval or charging. Use None only when no follow-up is needed.

  8. Confidence: High, Medium, or Low, with a brief reason.

Keep the answer compact enough for a chat conversation. Do not repeat every required check when it is clearly not applicable; focus on checks that affect the decision or confidence.

Quality standards

  1. No fabrication. Do not invent missing caps, approvals, balances, account setup, or policy language.

  2. Evidence-grounded. Every pass or fail finding should cite evidence or explicitly state that evidence was missing.

  3. Actionable. Follow-up actions should tell a post-award reviewer what to obtain, verify, correct, or document.

  4. Chat-ready. Use clear prose and short bullets; avoid machine-oriented output.

  5. One expense only. If multiple expenses are supplied, assess the primary expense and add a follow-up action requesting separate assessments for the others.

Produce the allowability review now.

Evals

Reference cases

Golden cases under evals/cases/.

  • travel-cap-overage — NSF travel expense exceeds supplied per-person cap (artifacts: input, expected)

Changelog

Source: CHANGELOG.md.

All notable changes to this component. Versions follow semver:

  • MAJOR - output contract break for downstream consumers.
  • MINOR - backward-compatible capability or contract addition.
  • PATCH - wording, clarity, or non-behavioral cleanup.

[1.0.0] - 2026-04-29

  • Initial component registration.
  • Added canonical prompt, human-readable review contract, and a synthetic travel-cap eval case.
  • Added a one-step Vandalizer workflow manifestation.