award-modification-intake-udm¶
award-modification-intake-udm0.1.0noneTags: award-modification post-award intake classification ncne rebudget pi-change additional-funds udm structured-extraction json
Audience: sponsored-programs-staff, post-award-teams, ingest-pipelines
Manifestations in repo: prompt.md
Classifies an incoming federal award amendment / modification document and extracts the type-specific fields a Post-Award Specialist needs to enter the modification into Banner. Covers the four mapped modification processes — additional funds, no-cost extension (NCE), PI change, rebudget — plus scope change, administrative change, and combined modifications. The structured JSON output drives Banner setup; the source process-mapping workflow's human-review (ApprovalNode) step is a runtime concern handled by Vandalizer's UI and is not part of this extraction contract.
Output contract: schema.json
Contract scope: repo-local, UDM-aligned
Inputs¶
A single award amendment / modification document — federal notice of award modification, sponsor correspondence describing the change, or an executed bilateral modification — typically one to twenty pages with possible attachments. Accepted file types in the source workflow: .pdf, .docx, .msg.
Outputs¶
A single JSON object with three structured blocks:
identification—award_number,amendment_number,modification_type(seven-value enum),execution_status(three-value enum), and personnel / date / sponsor identifiersfinancial—modification_amount,current_award_amount,total_obligated_amount,fa_rate,fa_amount,budget_breakdown(array of{category, approved_amount}objects), rebudget source / destination accounts, and cost-share changescompliance—prior_approval_required(boolean),approval_date,sponsor_conditions[],regulatory_references[],end_date_change(boolean),requires_financial_unit(boolean), andibc_protocols_required(boolean | null)
See schema.json for the authoritative definition and prompt.md for encoding rules (number vs string, ISO date handling, enum-classification rules, cross-field rules).
Contract scope¶
Repo-local, UDM-aligned. Scalar identifiers (award_number, pi_name, sponsor_name) and leaf fields resolve downstream to UDM entities (Award, Personnel, Organization, Modification, AwardBudget, IndirectRate, CostShare, Terms). The three-block shape itself is repo-local and mirrors the source ui-insight/ProcessMapping workflow.
Relationship to other components¶
| Concern | Source of truth |
|---|---|
| Modification intake / Banner setup | award-modification-intake-udm (this component) |
| Prior-approval procedural mechanics (threshold / authority / documentation / timeline / consequences per approval type) | prior-approval-extraction-udm |
| FFR / SF-425 post-award financial-reporting cadence | ffr-management-extraction-udm |
| Broader compliance framework (high-risk conditions, audit thresholds, deliverable schedules) | award-compliance-extraction-udm |
The four components are versioned independently and a single modification document may be extracted through more than one when the document covers multiple concerns.
Triad integration¶
- Evaluation datasets: none yet — planned: an authorized, de-identified federal modification (ideally one each of: additional-funds with reconciling totals, no-cost extension with a new end date, PI change with old/new pair, rebudget with source / destination accounts).
- Harness notes: canonical manifestation is
prompt.md. Validation surface isschema.json. Vendored into runners viaharness prompts vendor --source-ref=<sha>; pinned inprompts.lock.json. - Shared UDM relationship: aligned, not owning. Field names and leaf bindings follow the UDM conventions established by sibling award components but the three-block intake shape is repo-local.
Runtime topology — the Vandalizer workflow¶
The canonical runtime for this component is the award-modification-intake workflow shipped at the top level of this repo. The single source of truth is workflows/award-modification-intake/manifest.yaml; the companion .vandalizer.json envelope is generated by scripts/build_vandalizer_workflows.py and committed alongside. The runtime mirrors the source ui-insight/ProcessMapping/workflows/award-modification-intake/ workflow:
- Step 1 (parallel Extraction) — three Extraction tasks mirror the source workflow one-for-one: modification-type identification (12 fields, enum classification), financial-impact extraction (9 fields incl. budget-breakdown table), and compliance-requirements extraction (7 fields).
- Step 2 (Consolidation Prompt) — assembles the three JSON fragments into the schema-conformant three-block object, normalizes the
modification_typeandexecution_statusenums, and enforces the four cross-field rules (CFR-01..CFR-04 from the sourceCross_Field_Rules). - Source ApprovalNode — the source workflow's STEP-03 ApprovalNode (Post-Award Specialist review before Banner entry) is omitted from this Vandalizer manifestation. Operator review is handled by Vandalizer's UI and is not a contract concern. Re-introduce the review at the operator level if your Vandalizer instance is configured for it.
Regenerate the workflow JSON whenever this component bumps MINOR or MAJOR (or whenever the workflow manifest changes); CI fails if the committed .vandalizer.json drifts from a fresh build.
Manifestations¶
prompt.md— canonical, LLM-agnostic prompt
Evals¶
See evals/ for reference inputs and known-good outputs. Initial cases pending: representative additional-funds, NCE, PI-change, and rebudget modifications validated by a Post-Award Specialist to exercise the four cross-field rules and the seven-value classification enum.
Provenance¶
Authored 2026-05-20 against the award-modification-intake (Workflow_ID: WF-AWARD-MODIFICATION-INTAKE) process-mapping workflow in ui-insight/ProcessMapping at commit 2c1f47f46474130743af5aee44d074bcd21787e9, which was built from the four mapped post-award modification processes (more-money-processing, nce-processing, pi-change-processing, rebudget-processing). Created to make the modification intake step a harness-evaluatable, versioned artifact rather than a Vandalizer-internal configuration.
Contract scope¶
-
Output format:
json_object -
Contract scope:
shared_udm_semantics_repo_local_schema -
Validation surfaces:
json_schema -
Schema entrypoints:
# -
Notes: Repo-local post-award modification intake & classification contract. Three structured blocks (identification, financial, compliance) covering the seven-value modification_type classification, monetary impact with rebudget routing, and prior-approval / sponsor-conditions / Financial-Unit routing flags that a Post-Award Specialist uses to enter the modification into Banner. Source workflow's STEP-03 ApprovalNode is intentionally omitted (handled by Vandalizer's UI as a runtime concern).
-
Machine-readable catalog entry:
component_catalog.json
Triad integration¶
-
UDM alignment:
shared_udm_semantics_repo_local_schema— award_number resolves to UDM Award.Award_Number or Award.Federal_Award_ID; sponsor_name to Organization.Organization_Name; pi_name to UDM Personnel; modification_amount to Modification.Funding_Amount_Change; current_award_amount to Award.Current_Total_Funded; fa_rate to IndirectRate.Rate_Percentage; budget_breakdown rows to AwardBudget; cost_share_changes to CostShare.Committed_Amount; sponsor_conditions to Terms.Special_Conditions; prior_approval_required to Modification.Requires_Prior_Approval. The three-block intake shape itself is repo-local. -
Evaluation datasets: no shared
evaluation-data-setscatalog 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/award-modification-intake Vandalizer workflow at v0.1.0 implements the contract as three parallel Extraction tasks plus a Consolidation Prompt that assembles the three fragments and enforces the four source cross-field rules (CFR-01..CFR-04) as flag emissions on compliance.sponsor_conditions when the source document is internally inconsistent. Campaign authors should record both single-call and post-consolidation signals when both are available.
-
Related component:
prior-approval-extraction-udm(complementary_drilldown) — award-modification-intake-udm captures the prior-approval STATUS (boolean) and approval date on a single modification; prior-approval-extraction-udm captures the procedural MECHANICS (threshold / authority / documentation / timeline / consequences) for each prior-approval CATEGORY across the award lifecycle. -
Related component:
ffr-management-extraction-udm(complementary_focus) — ffr-management-extraction-udm covers post-award FFR / SF-425 submission cadence on the parent award; this component covers modification intake on a specific amendment. -
Related component:
award-compliance-extraction-udm(complementary_focus) — award-compliance-extraction-udm captures the broader compliance framework (high-risk conditions, audit thresholds, deliverable schedules) on the parent award; this component captures the modification-specific compliance fields and routing flags needed to enter the modification into Banner.
Prompt body¶
Source: prompt.md.
Show prompt
Award Modification Intake & Classification — UDM JSON¶
Purpose: Classify an incoming award amendment document and extract the type-specific fields a Post-Award Specialist needs to enter the modification into Banner. Covers four post-award modification processes — additional funds, no-cost extension (NCE), PI change, rebudget — plus scope change, administrative change, and combined modifications.
Expected input: A single award amendment / modification document (federal notice, sponsor correspondence, executed modification) ranging from one to twenty pages with optional attachments.
Expected output: A single JSON object that validates against
schema.json. No prose, no markdown outside the JSON.
When to use this contract¶
This is the post-award modification intake cut of an award document. It produces three structured blocks a Post-Award Specialist uses to set up the modification in Banner: the identification block classifies the modification type and captures core identifiers, the financial block captures monetary impact and rebudget routing, and the compliance block captures sponsor conditions, prior-approval status, and Financial-Unit routing flags.
This component does not cover broader post-award compliance monitoring (high-risk conditions, audit thresholds, deliverable schedules) — that lives in award-compliance-extraction-udm. It does not cover FFR submission cadence — that lives in ffr-management-extraction-udm. It does not cover prior-approval procedural mechanics (threshold / authority / documentation / timeline / consequences) — that lives in prior-approval-extraction-udm.
The source process-mapping workflow includes a human-review ApprovalNode step that pauses for Post-Award Specialist sign-off before Banner entry. That review is a runtime workflow concern (Vandalizer's UI handles operator approval) and is not part of this extraction contract.
Prompt¶
You are extracting the contents of a federal award modification / amendment document for a Post-Award Specialist's Banner intake.
Be 100% accurate. Quote the document for any amount, date, identifier, or sponsor-imposed condition; never paraphrase a monetary value or deadline. When the document does not specify a value, set the field to null (or, for required string fields where the source workflow specified a Not_Found_Value, use that exact string). Do not invent values.
Search the entire document with attention to sections titled Cover Page, Amendment Information, Modification Details, Award Information, Personnel Changes, Budget Information, Financial Details, Cost Sharing, Terms and Conditions, Special Conditions, Approval Information, and Regulatory Requirements. Keywords to follow: amendment, modification, no-cost extension, additional funds, PI change, rebudget, FAIN, effective date, principal investigator, budget, funding, obligated, indirect, F&A, cost share, prior approval, 2 CFR, IBC, biosafety.
Return a single JSON object that validates against schema.json with these top-level keys:
-
identification— object covering core identifiers and modification-type classification. -
financial— object covering monetary impact, F&A, cost share, and rebudget routing. -
compliance— object covering prior-approval status, sponsor conditions, regulatory references, and operational routing flags.
Identification block¶
-
award_number— string. Federal Award Identification Number (FAIN) or sponsor award number. Required. Resolves to UDMAward.Award_Number/Award.Federal_Award_ID. -
amendment_number— string. Amendment or modification number (e.g.,"Amendment 17","Mod 003"). Required. -
modification_type— one of"Additional Funds","No-Cost Extension","PI Change","Rebudget","Scope Change","Administrative Change","Combined (multiple types)". Required. Use"Combined (multiple types)"only when the document genuinely modifies multiple categories; otherwise pick the single primary type. -
execution_status— one of"Unilateral (fully executed)","Bilateral (requires signature)","Not specified in the document". Required. -
effective_date— string in ISOYYYY-MM-DDform when the document is unambiguous; otherwise quote the document.nullwhen absent. -
sponsor_name— string. Full name of the sponsoring agency.nullwhen absent. Resolves to UDMOrganization.Organization_Name. -
pi_name— string. Current Principal Investigator on the award.nullwhen absent. Resolves to UDMPersonnel.First_Name/Personnel.Last_Name. -
old_pi,new_pi— strings. Populate both only whenmodification_typeis"PI Change"or"Combined (multiple types)"and the document identifies the swap; otherwisenull. -
new_end_date— string in ISOYYYY-MM-DDform. Populate only whenmodification_typeis"No-Cost Extension"or"Combined (multiple types)"; otherwisenull. -
pms_code— string. Payment Management System code if the document states it;nullotherwise. -
point_of_contact_changes— string. Any changes to sponsor point-of-contact information;nullwhen none.
Financial block¶
All monetary fields below are JSON numbers, not quoted strings. Convert document language verbatim to a numeric value: "$1,234,567.89" → 1234567.89. null when the document does not state a value. Do not invent numeric values from context.
-
modification_amount— number ornull. The dollar amount of the modification itself (additional funds added or rebudget amount). Resolves to UDMModification.Funding_Amount_Change. -
current_award_amount— number ornull. Current total award amount before this modification. Resolves to UDMAward.Current_Total_Funded. -
total_obligated_amount— number ornull. Total obligated amount after this modification. -
fa_rate— string ornull. F&A (indirect cost) rate. Preserve the sponsor's format ("30% MTDC","56.5%"). String, not a number, because the rate often carries the base annotation. Resolves to UDMIndirectRate.Rate_Percentage. -
fa_amount— number ornull. F&A (overhead) dollar amount attributable to this modification. -
budget_breakdown— array of{category, approved_amount}objects.categoryis the sponsor's category label exactly as stated (e.g.,"Salaries","Fringe","Equipment","F&A").approved_amountis a number. Empty array when the document does not break down the modification by category. Resolves to UDMAwardBudget. -
rebudget_source_account— string ornull. Source budget account for rebudget (e.g.,"OE/Account 30"). Populate only whenmodification_typeis"Rebudget"or"Combined (multiple types)". -
rebudget_destination_account— string ornull. Destination budget account for rebudget. Same applicability asrebudget_source_account. -
cost_share_changes— string ornull. Any sponsor-imposed changes to cost-share commitments. Resolves to UDMCostShare.Committed_Amount.
Compliance block¶
-
prior_approval_required— boolean. Whether the modification required (or grants) sponsor prior approval. Required. Resolves to UDMModification.Requires_Prior_Approval. -
approval_date— string in ISOYYYY-MM-DDform. Date the sponsor approved the modification;nullwhen absent. -
sponsor_conditions— array of strings. Conditions, restrictions, or requirements imposed by the sponsor as part of the modification. Empty array when none. Resolves to UDMTerms.Special_Conditions. -
regulatory_references— array of strings. References to regulatory requirements ("2 CFR 200.308","Research Terms and Conditions","NSF PAPPG VI.D"). Empty array when none. -
end_date_change— boolean. Whether the modification changes the project end date. Required. -
requires_financial_unit— boolean. Whether the modification requires Financial Unit processing. Required. Source workflow rule:truefor additional funds and NCE;falsefor rebudgets and most administrative changes. Decide from the document and the modification type, not from a default. -
ibc_protocols_required— boolean ornull. Whether Institutional Biosafety Committee protocols must be complete before processing this modification.nullwhen the document does not address biosafety.
Cross-field rules¶
Mirror the source workflow's cross-field rules — apply them when assembling the JSON, do not violate them silently:
-
If
modification_typeis"Additional Funds",modification_amountmust be a positive number (> 0). -
If
modification_typeis"No-Cost Extension",new_end_datemust be populated. -
If
modification_typeis"PI Change", bothold_piandnew_pimust be populated. -
If
modification_typeis"Additional Funds",total_obligated_amountshould equalcurrent_award_amount + modification_amountwhen all three are present. If the document's stated totals do not satisfy this identity, do not adjust the values — emit the document's numbers as stated and capture the discrepancy incompliance.sponsor_conditionsas a flag (e.g.,"Stated totals do not reconcile: $X current + $Y modification != $Z obligated").
Encoding rules¶
-
Monetary values are JSON numbers, not strings.
"$1,234,567"→1234567."$0.5M"→ do not invent precision; emit the document's stated number, ornullif the document only gives a rounded summary without a specific amount. -
Dates use ISO
YYYY-MM-DDwhenever the document is unambiguous. When the document gives a granular qualifier the schema cannot capture (e.g.,"30 days after PO issuance"), keep the value as a string and place it where the schema allows a string, never invent a date. -
Booleans are JSON booleans, not the strings
"true"/"false". -
Enum values must match exactly. The classification, execution-status, and other enums are case-sensitive. Pick the closest enum; only use catch-all values (
"Combined (multiple types)","Administrative Change") when no better fit exists. -
Do not duplicate facts across blocks. Award identifiers live in
identification; monetary values live infinancial; compliance / approval terms live incompliance. -
No invention. When the document does not state a value, emit
null(scalars) or[](arrays). For the three optionalNot_Found_Valuestrings in the source workflow ("Not specified in the document","Not applicable","No changes indicated"), emitnullinstead — the schema acceptsnullfor these fields. The exception isexecution_status, which has"Not specified in the document"as an explicit enum value.
Output¶
A single JSON object. No surrounding markdown.
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/award-modification-intake-udm/schema.json",
"title": "Award Modification Intake & Classification \u2014 UDM Output",
"description": "JSON contract for an incoming federal award amendment / modification document, classified by type (additional funds, no-cost extension, PI change, rebudget, scope change, administrative change, combined) and broken into three structured blocks a Post-Award Specialist uses to enter the modification into Banner: identification, financial impact, and compliance. Mirrors the source ui-insight/ProcessMapping award-modification-intake workflow.",
"version": "0.1.0",
"type": "object",
"additionalProperties": false,
"required": [
"identification",
"financial",
"compliance"
],
"properties": {
"identification": {
"type": "object",
"additionalProperties": false,
"required": [
"award_number",
"amendment_number",
"modification_type",
"execution_status"
],
"properties": {
"award_number": {
"type": "string",
"minLength": 1,
"description": "Federal Award Identification Number (FAIN) or sponsor award number. Required by source workflow. Resolves to UDM Award.Award_Number or Award.Federal_Award_ID."
},
"amendment_number": {
"type": "string",
"minLength": 1,
"description": "Amendment or modification number as stated (e.g., 'Amendment 17', 'Mod 003'). Required by source workflow."
},
"modification_type": {
"type": "string",
"enum": [
"Additional Funds",
"No-Cost Extension",
"PI Change",
"Rebudget",
"Scope Change",
"Administrative Change",
"Combined (multiple types)"
],
"description": "Classification of the modification type. Required by source workflow. Use 'Combined (multiple types)' only when the modification genuinely spans multiple categories."
},
"execution_status": {
"type": "string",
"enum": [
"Unilateral (fully executed)",
"Bilateral (requires signature)",
"Not specified in the document"
],
"description": "Whether the modification is already fully executed by the sponsor or requires university signature. Required by source workflow."
},
"effective_date": {
"type": [
"string",
"null"
],
"description": "Effective date of the modification, ISO YYYY-MM-DD when unambiguous; otherwise the document's stated form. Null when not specified."
},
"sponsor_name": {
"type": [
"string",
"null"
],
"description": "Name of the sponsoring agency. Null when not specified. Resolves to UDM Organization.Organization_Name."
},
"pi_name": {
"type": [
"string",
"null"
],
"description": "Current Principal Investigator on the award. Null when not specified. Resolves to UDM Personnel.First_Name / Personnel.Last_Name."
},
"old_pi": {
"type": [
"string",
"null"
],
"description": "Previous PI name. Populate only when modification_type is 'PI Change' or 'Combined (multiple types)'. Null otherwise."
},
"new_pi": {
"type": [
"string",
"null"
],
"description": "New PI name. Populate only when modification_type is 'PI Change' or 'Combined (multiple types)'. Null otherwise."
},
"new_end_date": {
"type": [
"string",
"null"
],
"description": "New project end date, ISO YYYY-MM-DD when unambiguous. Populate only when modification_type is 'No-Cost Extension' or 'Combined (multiple types)'. Null otherwise."
},
"pms_code": {
"type": [
"string",
"null"
],
"description": "Payment Management System code if stated in the document. Null when not specified."
},
"point_of_contact_changes": {
"type": [
"string",
"null"
],
"description": "Any changes to sponsor point-of-contact information. Null when no changes are indicated."
}
}
},
"financial": {
"type": "object",
"additionalProperties": false,
"required": [
"budget_breakdown"
],
"properties": {
"modification_amount": {
"type": [
"number",
"null"
],
"description": "Dollar amount of the modification (additional funds or rebudget amount). JSON number, not a quoted string. Null for non-financial modifications. Resolves to UDM Modification.Funding_Amount_Change."
},
"current_award_amount": {
"type": [
"number",
"null"
],
"description": "Current total award amount before this modification. JSON number. Null when not specified. Resolves to UDM Award.Current_Total_Funded."
},
"total_obligated_amount": {
"type": [
"number",
"null"
],
"description": "Total obligated amount after this modification. JSON number. Null when not specified."
},
"fa_rate": {
"type": [
"string",
"null"
],
"description": "F&A (indirect cost) rate including the base annotation when stated (e.g., '30% MTDC', '56.5%'). String because the rate often carries a base type; preserve the document's form. Resolves to UDM IndirectRate.Rate_Percentage."
},
"fa_amount": {
"type": [
"number",
"null"
],
"description": "F&A (overhead) dollar amount attributable to this modification. JSON number. Null when not specified."
},
"budget_breakdown": {
"type": "array",
"description": "Budget breakdown by sponsor-stated category. Empty array when the document does not provide a category-by-category breakdown. Resolves to UDM AwardBudget.",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"category",
"approved_amount"
],
"properties": {
"category": {
"type": "string",
"minLength": 1,
"description": "Sponsor category label exactly as stated (e.g., 'Salaries', 'Fringe', 'Equipment', 'F&A')."
},
"approved_amount": {
"type": "number",
"description": "Approved category amount. JSON number, not a quoted string."
}
}
}
},
"rebudget_source_account": {
"type": [
"string",
"null"
],
"description": "Source budget account for a rebudget (e.g., 'OE/Account 30'). Null when modification_type is not a rebudget."
},
"rebudget_destination_account": {
"type": [
"string",
"null"
],
"description": "Destination budget account for a rebudget (e.g., 'Temporary Help/Account 12'). Null when modification_type is not a rebudget."
},
"cost_share_changes": {
"type": [
"string",
"null"
],
"description": "Sponsor-imposed changes to cost-share commitments as stated. Null when no cost-share changes apply. Resolves to UDM CostShare.Committed_Amount."
}
}
},
"compliance": {
"type": "object",
"additionalProperties": false,
"required": [
"prior_approval_required",
"sponsor_conditions",
"regulatory_references",
"end_date_change",
"requires_financial_unit"
],
"properties": {
"prior_approval_required": {
"type": "boolean",
"description": "Whether this modification required (or grants) sponsor prior approval. Required by source workflow. Resolves to UDM Modification.Requires_Prior_Approval."
},
"approval_date": {
"type": [
"string",
"null"
],
"description": "Date the sponsor approved the modification (ISO YYYY-MM-DD when unambiguous). Null when not specified."
},
"sponsor_conditions": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"description": "Conditions, restrictions, or requirements imposed by the sponsor as part of this modification. Empty array when none. Resolves to UDM Terms.Special_Conditions."
},
"regulatory_references": {
"type": "array",
"items": {
"type": "string",
"minLength": 1
},
"description": "References to regulatory requirements (e.g., '2 CFR 200.308', 'Research Terms and Conditions', 'NSF PAPPG VI.D'). Empty array when none."
},
"end_date_change": {
"type": "boolean",
"description": "Whether the modification changes the project end date. Required by source workflow."
},
"requires_financial_unit": {
"type": "boolean",
"description": "Whether this modification requires Financial Unit processing. Required by source workflow (true for additional funds and NCE; false for most rebudgets and administrative changes)."
},
"ibc_protocols_required": {
"type": [
"boolean",
"null"
],
"description": "Whether Institutional Biosafety Committee protocols must be complete before processing this modification. Null when biosafety is not addressed."
}
}
}
}
}
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-20¶
- Initial experimental release.
- Schema derived from the
award-modification-intakev1 Vandalizer workflow inui-insight/ProcessMapping(three parallel extraction tasks, 28 source fields, four cross-field rules, five validation-plan checks). - Three-block shape (
identification+financial+compliance) preserves source extraction-task separation; flat fields collapse into the relevant block per the placement contract inprompt.md. modification_typeexposed as the seven-value enum from the source workflow (Additional Funds,No-Cost Extension,PI Change,Rebudget,Scope Change,Administrative Change,Combined (multiple types)).execution_statusexposed as the three-value enum from the source workflow (Unilateral (fully executed),Bilateral (requires signature),Not specified in the document).- Monetary fields (
modification_amount,current_award_amount,total_obligated_amount,fa_amount,budget_breakdown[].approved_amount) typed as JSON numbers, not quoted strings, per the source workflow'sDecimalfield type.fa_ratetyped as a string because the rate carries a base-type annotation (e.g.,"30% MTDC"). - Source
Is_Required: truefields (award_number,amendment_number,modification_type,execution_status,prior_approval_required,end_date_change,requires_financial_unit) mirrored intorequiredlists at the block level. - UDM column bindings preserved:
award_number→Award.Award_Number/Award.Federal_Award_ID;sponsor_name/pi_name→Organization.Organization_Name/Personnel;modification_amount→Modification.Funding_Amount_Change;current_award_amount→Award.Current_Total_Funded;fa_rate→IndirectRate.Rate_Percentage;budget_breakdown→AwardBudget;cost_share_changes→CostShare.Committed_Amount;sponsor_conditions→Terms.Special_Conditions;prior_approval_required→Modification.Requires_Prior_Approval. - Source STEP-03 ApprovalNode (Post-Award Specialist review) omitted from the extraction contract — it is a runtime UI concern of Vandalizer's import surface, not a part of the JSON contract.
- No eval cases yet — status
experimentaluntil at least one golden extraction is added underevals/cases/.