Phase 1.4 Deliverable C: Effective-Dating Behavior Confirmation
Runbook Guidance (Quoted)
Fromdocs/runbooks/phase1_3_prod_population.md:131, 151:
effective_start_date = "2024-01-01" for PEPM mappings because identity resolution is effective-dated but does not change payout math; mappings must apply historically.
API Logic (Quoted)
Fromapi/routes/admin_identity.py:179-222:
The endpoint accepts effective_start_date and effective_end_date from the request body without modification. The validation happens in api/bigquery/admin_identity_queries.py.
From api/bigquery/admin_identity_queries.py:352-358:
api/bigquery/admin_identity_queries.py:78-136):
The overlap check uses end-exclusive window logic:
- Window is active when:
effective_start_date <= as_of_date AND (effective_end_date IS NULL OR as_of_date < effective_end_date) - NULL
effective_end_datemeans “currently active” - Overlap detection checks for any existing active rows with overlapping windows
- Rows are identified by
override_id(stable UUID) - No
exclude_override_idparameter incheck_overlap_pepm_map(unlikecheck_overlap_identity_admin) - This means overlap checks apply to ALL active rows for the same
(pepm_agent_name_norm, pepm_business_name_norm)pair
Confirmation Statement
Effective Start Date Policy: Use"2024-01-01" as effective_start_date for all initial PEPM mappings. This ensures:
- Historical coverage: mappings apply to all periods from 2024-01-01 forward
- No payout math changes: identity resolution is metadata-only
- Append-only semantics: close rows via
effective_end_dateonly, never delete
400 Bad Request with error message “Overlapping effective date window detected”.