address SCHED-1-2-3

[decarlof]

Title: SCHED-1: APS does not move a beamtime window once users are on-site (pre-arrival shifts only); SCHED-2: local contact is a beamline-side internal assignment, NOT in the proposal user list (CORA's assumption needs revising); SCHED-3: each user has a unique facility badge number AND a required ORCID in the proposal system (two stable IDs available); PII / deletion-on-request classification still routes to APS data-management

SCHED-1 (does APS move the scheduled time window after users arrive on-site?)

No. Once a user group is on-site for their beamtime, APS does not move the scheduled window earlier or later. Schedule changes happen only before arrival.

CORA's provisional assumption ("time changes happen only before arrival") is confirmed.

Operational notes that are NOT schedule moves and should not be modeled as such:

• Beam dumps, storage-ring trips, mode switches, and other facility-side outages reduce the usable beam time inside an already-scheduled window. They do not shift the window in the APS scheduling system, and they are not communicated to users as "your beamtime moved".
• The local contact may negotiate a make-up slot informally if a long outage eats most of a shift, but that is a separate conversation, not a scheduling-system change.

So for CORA: the beam-api / DMagic scheduled window for an active beamtime can be treated as immutable for the duration of that beamtime. Any Run-level "beam was unavailable from T1 to T2" annotation belongs at the Run / facility-status layer, not as a schedule mutation.

SCHED-2 (is the local contact one of the proposal's users, or a beamline-side assignment?)

Beamline-side assignment, NOT in the proposal user list. The local contact is internal 2-BM staff assigned by the beamline scientist; they do not appear in the proposal's user roster in the APS scheduling system.

CORA's provisional assumption ("listed as one of the beamtime's people") is incorrect and should be revised to: the local contact is a separate field on the beamtime, populated from the 2-BM staff list, distinct from the proposal users.

CORA-side implications:

• The local-contact link for a Run must be sourced from the beamline-side assignment record, not by scanning the proposal's user list for staff.
• Notification routing ("notify the appropriate people") should therefore be modeled as two distinct sets: proposal users (from the proposal) and the assigned local contact (from the beamline-side assignment). The same human can in principle appear in both, but the data sources are separate.
• If a future feature wants the historical "who was the local contact for proposal X on date Y", that record lives in beamline-side assignment state, not in the proposal record.

SCHED-3 (APS badge-number reuse + personal-data classification under data governance)

This row bundles two separate questions. CORA originally routed both to the APS User Office / data-management contact, but the first has a clear beamline-side answer; only the second still needs to go to data-management.

Sub-question 3a: are badge numbers reused over time?

No. Each user is assigned a unique APS facility badge number, and that number stays with that person. Badge numbers are not recycled across users.

There is also a second stable identifier already in the APS proposal system: each user is required to provide an ORCID to access the proposal system. That means for every user CORA cares about, two stable per-person identifiers are available:

Identifier	Scope	Issuer	Notes
APS facility badge number	APS-internal	ANL badging office / APS User Office	Unique per person, stable across visits, present in beam-api / DMagic.
ORCID	Global / cross-institution	The user (via orcid.org), required by APS proposal system	Institution-independent, user-owned, ideal for cross-facility data sharing.

CORA implications:

• Either identifier alone is a sound join key for "all Runs by this human across their career". (badge_number, time_window) compounding is NOT needed because the badge does not recycle.
• ORCID is the stronger long-term identifier when CORA's scope extends beyond APS (cross-facility data sharing, publication linkage, persistent author attribution). It is also what the user themselves owns and updates.
• A reasonable model is to store both: ORCID as the primary cross-institution person key, and badge number as the APS-internal join key for beam-api / DMagic correlation. They are not redundant; they answer different questions.

Sub-question 3b: is a badge number (or ORCID) classified as deletable personal data?

This part still has to go to APS data-management. The 2-BM beamline scientist is not the authoritative source for data-classification decisions, which are owned by ANL records-management and the APS User Office.

What needs confirming from data-management:

• Is the APS badge number classified as Personally Identifiable Information (PII) subject to a user's deletion request?
• Same question for ORCID. (ORCID is a published, user-controlled identifier that often appears on publications, so it may be treated differently from an internal facility badge, but the formal classification is still a governance call.)

CORA-side implications, depending on the answer:

• If neither is classified as deletable PII, CORA can persist both freely on Runs, Datasets, and audit records, no special handling.
• If either or both is classified as deletable PII, CORA must support a deletion or anonymization path for that field: store it only where strictly necessary, and ensure every storage site is reachable from a delete-by-user request.

Pragmatic recommendation for CORA

Given the confirmed answer on 3a (both badge and ORCID are stable per person and available from APS scheduling), and pending the governance answer on 3b:

• Use ORCID as the primary cross-institution person identifier on CORA's User record. It is institution-independent, user-controlled, and already required by the APS proposal system.
• Use APS badge number as the APS-internal identifier alongside ORCID, for direct correlation with beam-api / DMagic feeds.
• Mint an internal opaque CORA-side user_id as the actual primary key on Runs / Datasets / audit rows, with ORCID and badge number as attributes on the User record rather than as foreign keys. This keeps the schema deletion-safe regardless of which way 3b resolves: if either identifier turns out to be deletable PII, the attribute can be nulled per request without breaking referential integrity elsewhere.

Summary of CORA-side actions

SCHED question	CORA assumption	Action
SCHED-1	time changes happen only before arrival	Confirmed. Treat the scheduled window as immutable once a beamtime is active.
SCHED-2	local contact listed as one of the beamtime's people	Revise. Local contact is a beamline-side assignment, separate from the proposal user list. Model it as a distinct field with its own data source.
SCHED-3 (3a, badge stability)	badge stable per person	Confirmed by 2-BM: each user has a unique, non-recycled APS facility badge number. ALSO available: each user's ORCID, required by the APS proposal system; use ORCID as the cross-institution person key and badge as the APS-internal join key.
SCHED-3 (3b, PII classification)	classified as deletable personal data	Still defer. ANL records-management and APS User Office must classify both badge number and ORCID. Mint an opaque internal user_id as the actual primary key so either field can be anonymized without breaking referential integrity.

Cross-references

• beam-api / DMagic: the APS scheduling-system feed already in use at 2-BM. Local contact is a separate field on the beamtime record there.
• APS User Office: confirmer for SCHED-3 (badge-number policy and personal-data classification).