Skip to content

award-modification-intake-udm

Slugaward-modification-intake-udm
Version0.1.0
Statusexperimental
Last fully evaluatednone
Eval stateno validated eval cases
Categoryextraction
Domainresearch-administration
Manifestationsprompt
Created2026-05-20
Updated2026-05-20

Tags: 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:

  • identificationaward_number, amendment_number, modification_type (seven-value enum), execution_status (three-value enum), and personnel / date / sponsor identifiers
  • financialmodification_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 changes
  • complianceprior_approval_required (boolean), approval_date, sponsor_conditions[], regulatory_references[], end_date_change (boolean), requires_financial_unit (boolean), and ibc_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 is schema.json. Vendored into runners via harness prompts vendor --source-ref=<sha>; pinned in prompts.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_type and execution_status enums, and enforces the four cross-field rules (CFR-01..CFR-04 from the source Cross_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-sets catalog 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 UDM Award.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 ISO YYYY-MM-DD form when the document is unambiguous; otherwise quote the document. null when absent.

  • sponsor_name — string. Full name of the sponsoring agency. null when absent. Resolves to UDM Organization.Organization_Name.

  • pi_name — string. Current Principal Investigator on the award. null when absent. Resolves to UDM Personnel.First_Name / Personnel.Last_Name.

  • old_pi, new_pi — strings. Populate both only when modification_type is "PI Change" or "Combined (multiple types)" and the document identifies the swap; otherwise null.

  • new_end_date — string in ISO YYYY-MM-DD form. Populate only when modification_type is "No-Cost Extension" or "Combined (multiple types)"; otherwise null.

  • pms_code — string. Payment Management System code if the document states it; null otherwise.

  • point_of_contact_changes — string. Any changes to sponsor point-of-contact information; null when 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 or null. The dollar amount of the modification itself (additional funds added or rebudget amount). Resolves to UDM Modification.Funding_Amount_Change.

  • current_award_amount — number or null. Current total award amount before this modification. Resolves to UDM Award.Current_Total_Funded.

  • total_obligated_amount — number or null. Total obligated amount after this modification.

  • fa_rate — string or null. 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 UDM IndirectRate.Rate_Percentage.

  • fa_amount — number or null. F&A (overhead) dollar amount attributable to this modification.

  • budget_breakdown — array of {category, approved_amount} objects. category is the sponsor's category label exactly as stated (e.g., "Salaries", "Fringe", "Equipment", "F&A"). approved_amount is a number. Empty array when the document does not break down the modification by category. Resolves to UDM AwardBudget.

  • rebudget_source_account — string or null. Source budget account for rebudget (e.g., "OE/Account 30"). Populate only when modification_type is "Rebudget" or "Combined (multiple types)".

  • rebudget_destination_account — string or null. Destination budget account for rebudget. Same applicability as rebudget_source_account.

  • cost_share_changes — string or null. Any sponsor-imposed changes to cost-share commitments. Resolves to UDM CostShare.Committed_Amount.

Compliance block

  • prior_approval_required — boolean. Whether the modification required (or grants) sponsor prior approval. Required. Resolves to UDM Modification.Requires_Prior_Approval.

  • approval_date — string in ISO YYYY-MM-DD form. Date the sponsor approved the modification; null when 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 UDM Terms.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: true for additional funds and NCE; false for rebudgets and most administrative changes. Decide from the document and the modification type, not from a default.

  • ibc_protocols_required — boolean or null. Whether Institutional Biosafety Committee protocols must be complete before processing this modification. null when 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:

  1. If modification_type is "Additional Funds", modification_amount must be a positive number (> 0).

  2. If modification_type is "No-Cost Extension", new_end_date must be populated.

  3. If modification_type is "PI Change", both old_pi and new_pi must be populated.

  4. If modification_type is "Additional Funds", total_obligated_amount should equal current_award_amount + modification_amount when 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 in compliance.sponsor_conditions as a flag (e.g., "Stated totals do not reconcile: $X current + $Y modification != $Z obligated").

Encoding rules

  1. Monetary values are JSON numbers, not strings. "$1,234,567"1234567. "$0.5M" → do not invent precision; emit the document's stated number, or null if the document only gives a rounded summary without a specific amount.

  2. Dates use ISO YYYY-MM-DD whenever 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.

  3. Booleans are JSON booleans, not the strings "true" / "false".

  4. 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.

  5. Do not duplicate facts across blocks. Award identifiers live in identification; monetary values live in financial; compliance / approval terms live in compliance.

  6. No invention. When the document does not state a value, emit null (scalars) or [] (arrays). For the three optional Not_Found_Value strings in the source workflow ("Not specified in the document", "Not applicable", "No changes indicated"), emit null instead — the schema accepts null for these fields. The exception is execution_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-intake v1 Vandalizer workflow in ui-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 in prompt.md.
  • modification_type exposed 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_status exposed 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's Decimal field type. fa_rate typed as a string because the rate carries a base-type annotation (e.g., "30% MTDC").
  • Source Is_Required: true fields (award_number, amendment_number, modification_type, execution_status, prior_approval_required, end_date_change, requires_financial_unit) mirrored into required lists at the block level.
  • UDM column bindings preserved: award_numberAward.Award_Number / Award.Federal_Award_ID; sponsor_name / pi_nameOrganization.Organization_Name / Personnel; modification_amountModification.Funding_Amount_Change; current_award_amountAward.Current_Total_Funded; fa_rateIndirectRate.Rate_Percentage; budget_breakdownAwardBudget; cost_share_changesCostShare.Committed_Amount; sponsor_conditionsTerms.Special_Conditions; prior_approval_requiredModification.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 experimental until at least one golden extraction is added under evals/cases/.