ADR 0003: Assignment Lifecycle Rules¶
Status¶
Accepted
Context¶
Assignment lifecycle behavior (initial assignment, reassignment, revocation, and historical traceability) appears across customer lifecycle and related workflows.
Inconsistent lifecycle handling can cause:
- Duplicate active assignments
- Lost historical lineage
- Ambiguous actor visibility and ownership
Decision¶
Use a temporal lifecycle model for assignment tables:
- Reassignment is modeled as "expire previous active row, create new active row."
- Revocation expires active membership and assignment state according to workflow rules.
- Historical rows are retained for audit and reconstruction.
Enforce the invariant: one active assignment per customer per Service Account at any point in time.
All writes that modify assignment state must be idempotent at the API/use-case layer to avoid duplicate active rows during retries.
Consequences¶
- Audit trails remain complete and queryable over time.
- Reassignment and revocation behavior becomes deterministic across workflows.
- Visibility calculations have a stable active-state input.
- Integrators can rely on temporal history instead of reconstructing state from partial events.