Funding source as a first-class concept distinct from Sponsor

[nate-layman]

Context

The UDM today captures who you contract with (Sponsor_Organization_ID, Prime_Sponsor_Organization_ID) and which institutional fund pays the bills (Fund table). What it does not capture cleanly is where the money actually came from at the funding-mechanism level: the federal program, the foundation initiative, the corporate giving line, the internal pool of money that originated a seed grant.

"Sponsor" and "funding source" overlap but aren't the same:

Concept	Question it answers	UDM today
Sponsor	Who's the legal counterparty on the award?	Sponsor_Organization_ID
Prime sponsor	Who originally funded a pass-through?	Prime_Sponsor_Organization_ID (Organization)
Funding source	What program, mechanism, or pool of money is this?	not modeled
Fund	Which institutional accounting fund pays expenses?	Fund

Why this matters

• Federal reporting requires the federal Assistance Listing Number (formerly CFDA). It's not on the schema. Today there's nowhere to put it without inventing a column.
• Strategic reporting wants to slice by funding mechanism: "how much NIH R01 work do we have vs. NIH career-development awards?" The mechanism is a property of the funding source, not the sponsor.
• Pass-through accuracy. A subaward where the prime is federal money flowing through another university needs both the immediate sponsor (the university) and the original federal funding source preserved. Prime_Sponsor_Organization_ID carries the organization, not the program.
• Internal funds need a source too. When the institution funds a seed grant, the money came from somewhere (F&A returns, endowment, central admin). Capturing that source enables accurate institutional analytics.

Possible designs

1. Funding_Source field on Award / Proposal. A nullable FK or AllowedValue reference identifying the funding mechanism. Cheapest. Doesn't generalize well across federal / non-federal / internal.

2. New FundingSource table. Rows for each funding mechanism: federal Assistance Listing entries, named foundation initiatives, named industry giving lines, internal pools. Award / Proposal / RFA reference a row. Allows hierarchy (NIH > NIH/NIA > NIA R01).

3. Extend RFA to be the funding-source carrier. The RFA already identifies "the funding opportunity" — make it the authoritative source-of-funds record, add the federal Assistance Listing Number, federal agency CFDA code, etc., to it. Tightens RFA semantics; doesn't help internal funding or awards with no formal RFA.

4. Hybrid. Use RFA when one exists (formal solicitation), introduce a FundingSource table for everything else (foundation programs without formal RFAs, industry funding, internal funds).

Open questions

• Is the federal Assistance Listing Number (Assistance Listing / CFDA) a property of the RFA, the Award, or both?
• Should FundingSource be hierarchical (NIH > NIH/NIA > NIA/R01) or flat?
• Does this fold into the Sponsor Type discussion (Sponsor type needs a richer taxonomy than the current Organization_Type value #46), or is it orthogonal?
• For internal seed funding, do we model the source as just another FundingSource row, or does it need a different table?
• Where does CFDA-by-agency reporting (DATA Act, USAspending.gov, federal financial assistance reporting) hook in?

Related issues

• Award lifetime, proposal UIDs, and the project/account boundary #43 (Award lifetime, proposal UIDs)
• Deadline as a first-class concept across the UDM #44 (Deadlines / temporal events)
• Project terminology collides with PeopleSoft's Project; disambiguation needed #45 (Project terminology collision with PeopleSoft)
• Sponsor type needs a richer taxonomy than the current Organization_Type value #46 (Sponsor type taxonomy)