Project terminology collides with PeopleSoft's Project; disambiguation needed

[nate-layman]

Context

The UDM's Project table is currently described as "Research or training projects that may span multiple funding sources. A project can have multiple proposals and multiple awards." That is a research-administration / logical-effort definition.

PeopleSoft RAs use the word Project to mean something very different:

• A PeopleSoft Project is a financial sub-account / chartfield value used for grants accounting, billing, and budget tracking.
• A single award routinely has multiple PeopleSoft Projects, often one per fund, budget category, or PI.
• It's closer to what the UDM today calls a FinanceCode (or what one might call a sub-account or speed-type) than what the UDM calls Project.

When the same word means two structurally different things in the same room, every conversation about adopting the UDM with a PeopleSoft shop starts with a re-definition argument we can avoid.

Why this matters

• Adoption friction. A PeopleSoft RA reading the UDM cold sees "Project" and pattern-matches to their accounting concept. The next sentence reads wrong, the synonyms don't match, and trust in the model drops.
• AI assistants will get it wrong. Any LLM grounded on the schema will conflate the two unless we disambiguate explicitly.
• Documentation drift. Vignettes and the dashboard use "project" loosely, sometimes meaning the research effort and sometimes meaning the finance subdivision.

Possible fixes

1. Synonym work. Add PeopleSoft's Project to the FinanceCode (or relevant subaccount-shaped table) synonyms list explicitly. Add a negative synonym / cross-reference on UDM Project noting that PeopleSoft's Project is not this one.

2. Rename the UDM table. If "Project" is widely overloaded, consider renaming UDM's table to something less collision-prone (ResearchEffort, SponsoredEffort, Engagement, etc.). High cost; deserves discussion.

3. Documentation layer. Add a "Terminology" page that maps common source-system vocabularies (PeopleSoft, Banner, Workday, Cayuse, Kuali) to UDM tables, including known collisions. Even without renaming anything, naming the conflict in the docs would help.

4. Sub-account model clarity. Tighten the FinanceCode / Fund / Account model so it's obvious where institutional sub-accounting (speed types, project numbers, chartfield strings) actually lives. Related to Award lifetime, proposal UIDs, and the project/account boundary #43.

Open questions

• Is PeopleSoft Project ≈ UDM FinanceCode the right mapping, or does it need its own table?
• Are there other systems (Banner FRS, Workday Grants) with the same Project-overloaded vocabulary problem worth documenting at the same time?
• Do we need a "source-system glossary" reference doc separate from the ontology vignette?

Related issues

• Award lifetime, proposal UIDs, and the project/account boundary #43 (Award lifetime, proposal UIDs, project/account boundary)
• Deadline as a first-class concept across the UDM #44 (Deadlines / temporal events)