Account merges resolve identity collisions with explicit precedence rules, move data under a surviving account, define an irreversible commit boundary, and support rollback or uncertain states until reconciliation completes.
Package status: AI-assisted reference package. Static package validation has passed; implementation scenarios remain not run and human domain review is required before stable adoption.
Decision
Run account merges as phased preview, staged intent, and commit with survivor selection based on trust signals; resolve identity collisions using documented rules in merge-plan.yaml; allow rollback only before the irreversible commit; and enter an uncertain operator-visible state when reconciliation jobs partially fail rather than pretending success.
Scope
- User-initiated merge of two accounts within one product tenant model.
- Identity attributes: email, username, OAuth identities, MFA factors.
- Data movement for user-generated content, preferences, and audit provenance.
- Blocking conditions when both accounts are organization owners or OAuth subjects conflict without manual review.
Outside this block
- Organization-to-organization acquisition merges across billing entities.
- Ownership transfer within a single organization.
- GDPR erasure after merge (deletion blocks may reference but not define erasure).
Contract
- Preview phase is read-only and lists every collision with proposed resolution; no data mutation occurs before user confirms preview.
- Staged phase records merge intent with TTL; user may abort rollback until commit begins.
- Commit phase is irreversible under normal operations; post-commit undo requests are rejected with pointer to exceptional support recovery only.
- Survivor account receives moved content; source account login is disabled after successful commit and sessions are revoked.
- Identity collisions follow merge plan strategies: email must match or be a verified alias; conflicting OAuth subjects block auto-merge until manual linking completes.
- When both accounts are sole owners of different organizations, merge is blocked until ownership transfer or demotion resolves conflict.
- Partial job failure during commit transitions to
uncertainimmediately; if uncertain persists beyond the profile maximum, escalation alerts operators and blocks automated completion until acknowledgement. - Survivor account receives moved content; source account login is disabled after successful commit, active source sessions are revoked, and authentication with source tokens fails.
- All historical audit events on moved content retain original actor IDs plus merge correlation identifier.
Implementation guidance
- Use idempotent job steps keyed by merge ID so retries do not duplicate moved rows.
- Store merge state machine separately from user rows; workers advance phases only through documented transitions in
merge-plan.yaml. - Present human-readable collision report during preview including billing impact when ledger merge requires manual review.
- Coordinate with authorization to prevent merged-away account tokens from authenticating after commit.
Failure handling and safeguards
- If commit transaction fails after irreversible boundary crossed, enter
uncertainrather than deleting source account. - If preview TTL expires, discard staged tokens and require fresh MFA verification.
- Never merge accounts based solely on similar display names or IP overlap.
- Support tooling must show merge phase prominently to reduce mistaken duplicate support actions.
Verification and operations
- Monitor counts of preview abandons, commits, uncertain merges, and mean time to resolve uncertain states.
- Table-test collision rules using fixtures derived from
merge-plan.yaml. - Run disaster recovery drill restoring survivor from backup without orphaning half-moved content identifiers.
Adoption assumptions
- Names and values in
example.yamlandmerge-plan.yamlare an adoption profile, not universal defaults. - Teams classify which data classes move automatically versus require manual review.