Model 'restrictions' as a first-class concept (CUI, export control, publication holds)

[nate-layman]

Context

A non-trivial share of an OSP's daily decisions hinge on restrictions attached to a proposal, award, project, or piece of data: what people are allowed to touch it, where it's allowed to live, when results can be published, what countries collaborators can come from. The UDM today doesn't have a coherent home for any of this. The closest existing concept is ComplianceRequirement, which is about regulatory approvals (IRB, IACUC, IBC, COI), not about ongoing operational restrictions.

Concrete examples of what currently has nowhere clean to land:

• CUI / Controlled Unclassified Information marking on an award per NIST SP 800-171 and DFARS 7012/7019/7020.
• Export control flags (EAR, ITAR) on a project, including which foreign nationals are excluded.
• Publication holds and pre-publication review windows on industry-sponsored work.
• NDA-bound personnel that can only work on certain awards.
• Foreign-influence and foreign-collaboration restrictions (now formalized under federal disclosure rules).
• Site restrictions for sensitive samples, data, or computing environments.
• CMMC certification level required to handle the award's data.
• HIPAA / FERPA / GDPR flags on data sets associated with a project.

Why this matters

• Daily operations. Whether a graduate student can be added to a project is a restrictions question, not a personnel question.
• Audit and compliance. Federal awards increasingly carry restrictions that must be documented, monitored, and reported on. The schema should make that queryable.
• AI assistants will get this wrong if it isn't modeled. "Who can work on this award?" needs an explicit answer from the data, not a guess from prose in a description field.
• Federal trend. CUI rules, CMMC, foreign-influence disclosure, and research-security reviews are all expanding. A restriction model that handles today's set should accommodate the next wave.

Possible designs

1. Polymorphic Restriction table. Rows tied to any entity via Related_Entity_Type + Related_Entity_ID (same pattern as Document). Fields: Restriction_Type, Restriction_Level, Effective_Start_Date, Effective_End_Date, Authority (the regulation or contract clause), Status, Description. Allows any entity to carry zero or more restrictions.

2. Boolean flags on individual tables. Award.Is_CUI, Award.Is_Export_Controlled, Project.Has_Publication_Hold, etc. Cheapest. Doesn't scale; doesn't carry metadata (who certified it, effective dates).

3. Dedicated tables per restriction family. A CUIClassification table, an ExportControl table, a PublicationHold table, etc. Most expressive but heaviest schema surface; least flexible as new restriction categories emerge.

4. Hybrid. Polymorphic Restriction table for general use, plus a few targeted booleans (Is_Export_Controlled, Is_CUI) for the most common and most-queried flags.

Open questions

• Is "restriction" a ComplianceRequirement subtype, or a peer concept? (Probably a peer; ComplianceRequirement is for regulatory approvals you need to obtain, restrictions are operational constraints you have to honor.)
• Should personnel-level eligibility (who can touch what) live on Restriction or be a separate clearance/eligibility concept on Personnel?
• Are restriction taxonomies universal (CHECK) or institution-specific (AllowedValues)? Likely hybrid — CUI / ITAR / EAR are universal, internal NDA categories vary.
• How does this interact with Document for the actual classification markings and review records?
• Reference views worth building: vw_Active_Restrictions, vw_Awards_Requiring_CUI_Handling, vw_Personnel_Eligible_For_Award?

Related issues

• Award lifetime, proposal UIDs, and the project/account boundary #43 (Award lifetime; restrictions persist across modifications)
• Deadline as a first-class concept across the UDM #44 (Temporal events; restrictions have effective dates and review cycles)
• Disambiguate the three sponsor relationships: who pays, where the money originated, and what kind of sponsor it is #48 (Sponsor relationships; some restrictions cascade from prime sponsor identity)
• Survey ERA systems and their data-shape quirks for UDM mapping #50 (ERA survey; export of restriction fields from source systems is uneven and worth documenting)