Membership Lifecycle: Gaps, Departures, and Backfilled Dates

Real membership isn't a clean start-and-end pair — model it as dated intervals, deactivate instead of delete, and be honest about the dates you inherited.

Ask most research offices "when did Dr. Rivera become a member of the immunology program?" and you'll get a confident answer. Ask "and were they ever not a member between then and now?" and the room goes quiet. The truth is that membership is rarely a single tidy line from a start date to an end date. People leave for a sabbatical and come back. They move from one program to another. They retire, and then return as an emeritus collaborator two years later.

This is the part of the researcher repository that quietly breaks reporting. A membership model that can only hold one start and one end date will force every messy reality into a shape it doesn't fit — and the cost shows up later, when a renewal narrative needs to credit someone for the years they were actually active and the system can't reconstruct them.

Why a single start/end pair isn't enough

The instinct is understandable: a person is either a member or they're not, so store a start_date and an end_date and move on. The problem is that membership is not monotonic.

Consider the common cases a single pair can't represent:

• The returner. A faculty member leaves for a position elsewhere, then is recruited back three years later. With one start/end pair you either erase the original tenure (and lose the publications from it) or pretend they never left.
• The program-switcher. Someone moves from the population sciences program to the prevention program mid-cycle. Their membership never lapsed, but their program did — and intra-/inter-programmatic collaboration counts are computed against where each person sat at the time.
• The on-and-off affiliate. A clinician participates during active trials, steps back, then re-engages. Each interval is real and reportable.

The fix is to model membership as a set of dated intervals, not a single field pair. One person owns many membership records, each with its own start, its own end (or an open end for current members), and its own program and role.

End-date, don't overwrite

When a member changes programs, the temptation is to edit the program field in place. Resist it. Overwriting destroys the only record that the person was ever in the prior program, and that record is exactly what a point-in-time collaboration calculation needs.

The clean pattern is: end-date the old appointment the day before the new one begins, then open a new interval. If someone moves to the prevention program effective July 1, their population-sciences interval ends June 30 and a new prevention interval starts July 1. No gap, no overlap, and a paper published in May still attributes to the program they were actually in that month.

The through-line: history is append-mostly. You close intervals and open new ones; you almost never rewrite or remove one.

Inactivate, never delete

A departed member is not a deleted member. Deleting the record might feel like good hygiene, but it strips out every publication, grant, and collaboration tie that person earned while they were active.

So the rule is to inactivate, not delete:

• Set an inactive flag (or status) and an end date; preserve the full profile, publications, funding, and membership intervals untouched.
• Keep inactivated members in time-bound reports for the dates they were active, and out of "current roster" views by default.
• Filter on the reporting window, not on current status.

The grace period for in-press work

Publications lag the work that produced them, often by many months. Someone who leaves in March may have two papers appear in print in September that were entirely a product of their time at your center. If their appointment ended cleanly in March, those papers fall outside the window and silently drop.

The practical control is a configurable grace period — effectively "extend the appointment by N days" past the formal end date — so in-press output from a member's tenure still attributes to them and their program. A buffer of one to two years is a common starting point.

Be honest about migrated dates

Here's the uncomfortable truth most offices discover a year after a system change: a large share of your "start dates" aren't real. When data is migrated from a legacy system or a spreadsheet, the load process frequently stamps everyone with a single placeholder date.

The defensible posture has three parts:

1. Treat pre-migration history as approximate. Mark it, document the placeholder convention, and don't build precision claims on dates you know were synthesized.
2. Capture true dates going forward. From the migration date onward, record actual start and end dates at the moment they happen.
3. Define a fallback rule for nulls. Some records will have no date at all. Decide explicitly what a null start date means in a time-ranged report — because the dangerous default is that the record vanishes from every date-bounded query.

The bottom line

Membership is a timeline, not a flag. Model it as dated intervals, deactivate instead of delete, give in-press work a grace period to land, and be candid about which dates you actually observed versus inherited.