Self-described identity outranks system classification

What it is

Scoped use of self-described identity means that when an interface is permitted to refer to identity, it prefers the name, title, pronouns, or relationship wording a user supplied for that context over a system category or inference. Preference is not permission to distribute it everywhere: each self-description needs a source, purpose, audience, visibility scope, and current state. A classification retained for compliance, analysis, or operations does not automatically become a form of address and must not drive unrelated personalization.

Why it happens

Identity data often loses context through reuse: a legal name collected at registration enters a social notification, pronouns from a private profile appear on a shared card, or an analytical model's category becomes a template fact. Collapsing legal record, desired address, and inferred category into one field mixes write authority, display permission, and update cadence. Separating source and scope lets the presentation layer choose only a self-description authorized for the current audience. When a user edits or withdraws it, dependent templates, caches, and support views can expire together instead of continuing to propagate an obsolete identity.

Studying it

Map each identity field from collection and storage through synchronization into UI, notifications, support, exports, and sharing. At every use, record who supplied it, why it was collected, who can see it, when it updates, and how absence falls back. In contextual interviews, ask participants whether a specific output addresses them as expected and where its visibility boundary should be across audiences and channels; do not ask them to prove an identity or speak for an entire group. Audit logs and test accounts can verify correction, withdrawal, permission change, and cache invalidation, while checks look for undeclared inference from names, images, voice, location, or behavior.

Where it stops holding

Legal, medical, tax, or security processes may require authoritatively verified attributes. Keep those fields distinct from everyday self-description and explain each purpose rather than declaring either value universally “more real.” Free-text self-description still needs protection from injection, impersonation, and harassment, but security validation should not silently correct an uncommon name or map it to a preset gender. When a value is absent, unauthorized, or withdrawn, use a neutral fallback that does not reveal why it is missing. Lawful collection, retention, security, and data-subject rights belong to privacy governance; this leaf addresses how copy presentation consumes data already authorized for that context.

Applying it

• Store legal records, self-description, and system classification in separate fields. For self-description, retain the verbatim value, provider, purpose, allowed audiences and channels, update time, state, and withdrawal record; presentation must not infer address from a classification.
• At collection, show examples of where the field will appear and offer skip, preview, edit, and withdrawal. Obtain the necessary permission before adding an audience or channel instead of relying on vague global consent.
• Define presentation priority: a self-description authorized for the current context, then a name or neutral expression that reveals no attribute. Never fill identity gaps with a model, support note, or another person's input.
• Regress updates and withdrawal across UI, email, support, export, sharing, caches, and search indexes. Log access and propagation, enforce least privilege, and block unrelated recommendation or profiling uses.

Related

• Same group: T1.08.1 Avoid default assumptions about ability, gender, or age · T1.08.2 Avoid metaphors with exclusionary overtones
• Adjacent: S2.05.4 Titles and honorifics vary by locale · O1.03.1 Data must not be used for purposes undisclosed at collection
• Search terms: self-described identity · identity display scope · purpose limitation