# Keep App Profile Data Out Of Identity Tables

Splits security data owned by the framework from profile data owned by the application.

Follow these project instructions.
# Keep App Profile Data Out Of Identity Tables

Splits security data owned by the framework from profile data owned by the application.

Version: `1.0.0`

Identity owns what proves who someone is: the account, sign-in identifiers, credentials and sessions, tenant membership, roles and claims. Your application owns everything else about them - display name, avatar, theme, locale, onboarding state, and the tenant fields that are yours like slug, branding or billing references.

Keep them in your own tables, keyed by the identity's user id, and by tenant and user together when the value differs per tenant. Then a profile change is a write to your table, and an upgrade to the framework never migrates your columns.

Adding your fields to the framework's tables or its auth models looks like the shortcut and is the expensive path: a package upgrade can move that schema underneath you, and a field that travels in an auth response is a field you have published to every client.

Use the framework's extension hooks for lifecycle only - to make sure a profile row exists when an account or membership appears. Editing a profile afterwards goes through your own service and repository, like any other domain write.

#### Constraints
- Do not let an extension hook become a general profile update path.
- Never add application fields to identity tables, identity DTOs, or auth models.
- Never duplicate an auth-critical value into an application table and read it from there.

#### Verification
- A framework upgrade would not touch application-owned columns
- Application profile rows are keyed by the identity user id, and by tenant and user where tenant-specific
- Profile edits go through an application service, not an identity hook