Progressive Profiling: Update Verified Users Without Recreating Their Identity

Short answer: progressive profiling should update the record addressed by an immutable user ID, preserve verified identifiers as identities, and record each accepted change as a separately authorized, auditable state transition; it should never create a replacement user merely because a profile field or recovery address changes. For a healthtech sign-up flow, that rule matters more than collecting every field on day one. A patient may begin with an email and password, then add a display name, recovery method, or other application-owned attributes later. The authentication record answers “who is this?” while the profile answers “what do we currently know about this user?” Combining those questions makes recovery dangerous: a changed email can accidentally become a changed person. What does progressive profile retention actually cost? The useful cost model is not a vendor price table. It is the amount of state the team must retain, reconcile, authorize, and eventually delete. Let U be users, P the mutable profile fields stored per user, and E the accepted profile transitions. Current profile storage grows roughly with U x P ; the audit history grows with E . In a system where profiles change repeatedly, E becomes the dominant retention term. Provider calls and invoices still matter, but they aren't the hard part of explaining a patient's account history to a security reviewer. One current row plus one immutable audit event per accepted transition is a tractable design. The event needs the stable user ID, actor, time, operation, previous version, resulting version, and a correlation or idempotency key. Sensitive values need not be copied wholesale into the event. A field name, classification, and integrity-protected reference may provide the required evidence with less exposure; the exact retention period must come from the organization's legal and compliance analysis, not from a generic authentication recipe. This changes the dominant term by separating operational st