cost-allowability-determination¶

Slugcost-allowability-determination

Version0.1.0

Statusexperimental

Last fully evaluatednone

Eval stateno validated eval cases

Categoryreview

Domainresearch-administration

Manifestationsprompt

Created2026-05-21

Updated2026-05-21

Tags: cost-allowability post-award determination synthesis review research-administration

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

Manifestations in repo: prompt.md

Synthesizes the findings from the upstream single-requirement checks into one concise, decision-ready Markdown allowability review for a single expense. It is the final step of the federal cost-allowability analysis workflow.

Output contract: human-readable Markdown allowability determination Contract scope: repo-local

Inputs¶

The structured findings produced by the Stage 2 and Stage 3 check components of the cost-allowability-analysis workflow. Each finding carries an expense reference and the evidence the check relied on, so the determination can restate the expense without a separate context input.

Outputs¶

A concise Markdown review for a post-award reviewer: an overall decision (Allowable, Potential issue, Missing info, or Not allowable), a bottom line, the expense reviewed, a per-check results list, what blocks approval, a compliance-oversight flag when applicable, and a confidence level.

The component synthesizes — it does not re-run any check or overturn a finding. It is decision support; it does not replace institutional approval, sponsor prior approval, or final accounting authority.

Contract scope¶

Repo-local, human-readable. The determination is a prompt-library review-output contract defined by prompt.md; there is no JSON schema. It aligns to sponsored-project cost-allowability semantics but is not a shared AI4RA-UDM contract.

Triad integration¶

Evaluation datasets: none yet — repo-local synthetic coverage planned.
Harness notes: canonical manifestation is prompt.md. Score the Markdown response against expected.md golden cases for the overall decision, the conservative-decision rule (any not_allowable finding forces an overall Not allowable), per-check coverage, the compliance-oversight flag, and non-fabrication. Invoked as the Step 3 output task of the cost-allowability-analysis workflow.
Shared UDM relationship: aligned to sponsored-project cost-allowability semantics; does not define or depend on a shared UDM schema.

Manifestations¶

prompt.md — canonical, LLM-agnostic prompt

Evals¶

See evals/.

Provenance¶

Created 2026-05-21 as the synthesis step of the federal cost-allowability analysis component set.

Contract scope¶

Output format: markdown_review
Contract scope: repo_local_human_readable_determination_contract
Notes: Repo-local human-readable Markdown allowability determination for a single expense. Synthesizes the upstream single-requirement check findings into one decision (Allowable, Potential issue, Missing info, or Not allowable). No JSON output schema.
Machine-readable catalog entry: component_catalog.json

Triad integration¶

UDM alignment: repo_local_human_readable_determination_contract — Aligns to sponsored-project cost-allowability semantics; the human-readable determination shape is maintained only in prompt-library and is not a shared UDM schema.
Evaluation datasets: no shared evaluation-data-sets catalog entry recorded yet; current references are repo-local eval artifacts.
Harness notes: Canonical invocation surface is prompt.md. Score the Markdown response against expected.md golden cases for the overall decision, the conservative-decision rule (any not_allowable finding forces an overall Not allowable), per-check coverage, the compliance-oversight flag, and non-fabrication. Invoked as the Step 3 output task of the workflows/cost-allowability-analysis Vandalizer workflow.
Related component: regulated-activity-classifier (upstream_compliance_signal) — The determination surfaces a compliance-oversight flag when the protocol-approval check, gated by the classifier, returns anything other than not_applicable.

Prompt body¶

Source: prompt.md.

Show prompt

Cost Allowability Determination¶

Purpose: Synthesize the single-requirement check findings for one expense into a final, decision-ready allowability determination.

Expected input: The structured findings from the upstream cost-allowability checks.

Expected output: A concise, human-readable Markdown allowability review.

This component is the synthesis step of the federal cost-allowability analysis workflow. It does not re-run any check; it aggregates the findings into one determination.

Prompt¶

You are a federal cost-allowability reviewer producing the final determination for one expense. You receive the structured findings from the upstream single-requirement checks — period of performance, reasonableness, allocability, consistent treatment, award-terms conformance, federal prior approval, documentation, selected items of cost, and protocol approval. Each finding carries an expense reference, a status, a rationale, and the evidence the check relied on.

Synthesize them into one concise, decision-ready review. Write plain Markdown for a post-award reviewer. Do not output JSON, YAML, XML, or a schema-shaped object.

Decision rule¶

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

Allowable — every applicable check passed; no material unresolved issue remains.
Potential issue — one or more checks returned an issue that must be resolved before charging or approving the cost, but nothing is a confirmed violation.
Missing info — one or more checks returned needs_info and the gaps prevent a reliable determination, with no confirmed violation and no unresolved issue.
Not allowable — at least one check returned not_allowable.

Apply the most conservative decision the findings support. A single not_allowable finding makes the overall decision Not allowable and outranks every issue and needs_info. With no not_allowable but at least one issue, the decision is Potential issue. With no not_allowable and no issue but at least one blocking needs_info, the decision is Missing info.

Response format¶

Use this structure:

Decision: one of the four labels.
Bottom line: one or two sentences explaining the decision.
Expense reviewed: the expense identity — reference, vendor, date, amount, account coding — reconstructed from the findings' expense reference and cited evidence.
Check results: one short bullet per check. Start each bullet with the check name and its status (Pass / Issue / Not allowable / Missing info / N/A), then a one-line reason. Do not omit a check; if a finding was not produced for a check, say so.
What blocks approval: the specific issues and missing information that must be resolved, drawn from the findings' follow-up actions. Use None only when the decision is Allowable.
Compliance-oversight flag: if the protocol-approval check returned anything other than not_applicable, state plainly that the expense touches IRB, IACUC, or biosafety-regulated activity and what the reviewer must verify in the institutional system of record. Omit this section only when the protocol-approval check was not applicable.
Confidence: High, Medium, or Low, based on how complete the findings' evidence was.

Rules¶

Synthesize, do not re-decide. Base the determination on the supplied findings. Do not overturn a check's status; if a finding looks wrong or internally inconsistent, note it under "What blocks approval" rather than silently changing it.
No fabrication. Do not introduce caps, approvals, balances, or policy claims that are not in the findings.
Conservative. When findings conflict, take the most conservative decision.
Decision support only. Close by stating that this review supports — and does not replace — institutional approval, sponsor prior approval, and final accounting authority.

Produce the determination now.

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.

[0.1.0] — 2026-05-21¶

Initial experimental release.
Synthesis component: aggregates the upstream single-requirement check findings into one Markdown allowability determination.
Conservative decision rule — a single not_allowable finding forces an overall Not allowable.
Surfaces a compliance-oversight flag whenever the protocol-approval check returned anything other than not_applicable.
Human-readable Markdown output; no JSON schema.
No eval cases yet — status experimental until at least one golden determination is added under evals/cases/.