Seeded repo with initial and secondary research

terminology/TerminologyConflictMap.md

@@ -0,0 +1,152 @@
+# Terminology Conflict Map
+
+Status: draft. This map records high-risk terms whose meanings differ across
+source families. It should be revised after each source-note backfill.
+
+## Conflict: User
+
+Problem: `user` can mean a person, account, login credential holder,
+application profile, authorization subject, or product-facing actor.
+
+Canonical stance: do not use `user` as a root concept. Require the writer to
+choose among Natural Person, Account, Actor, Authenticated Subject, Principal,
+Profile, or Persona.
+
+Current mapping rule:
+
+- If the system stores login state, map to Account.
+- If the system renders a public or local display surface, map to Profile.
+- If the system evaluates access, map to Principal or Authenticated Subject.
+- If the text means a human being, map to Natural Person.
+
+## Conflict: Identity
+
+Problem: `identity` can mean selfhood, a directory record, an issuer-bound
+subject, a set of claims, a DID, a credential, a profile, or an account.
+
+Canonical stance: avoid bare `identity`. Prefer Identity Record, Identifier,
+Claim, Credential, Profile, Persona, or Synonymity Assertion.
+
+Current mapping rule:
+
+- A persistent record about an actor maps to Identity Record.
+- A value used to refer maps to Identifier.
+- A statement made by an issuer maps to Claim.
+- Proof material maps to Credential.
+
+## Conflict: Account
+
+Problem: account can mean login account, customer billing account, social
+account, service account, or account profile.
+
+Canonical stance: Account is an operational access record in a scope. Billing
+or customer accounts need explicit relationship and commercial-role modeling.
+
+Current mapping rule:
+
+- Login-capable operational record maps to Account.
+- Non-human login-capable record maps to Service Account.
+- Commercial customer record maps to Customer relationship or Customer Account
+  only if a later source analysis justifies the separate concept.
+
+## Conflict: Subject, Principal, Actor
+
+Problem: protocols, authorization engines, and application models use these
+terms differently. OIDC and SAML focus on subject identifiers; Cedar and IAM
+often decide over principals; social and conceptual models talk about actors.
+
+Canonical stance:
+
+- Actor is the conceptual participant.
+- Authenticated Subject is the issuer/protocol view after identification.
+- Authorization Principal is the decision-engine projection.
+
+The same natural person or account may appear as all three in different
+contexts, but the concepts should not be merged.
+
+## Conflict: Tenant, Realm, Organization, Customer
+
+Problem: multi-tenant products often use tenant, organization, realm, customer,
+workspace, project, and account as partial synonyms. Some are isolation
+boundaries, some are legal or commercial actors, and some are administrative
+containers.
+
+Canonical stance:
+
+- Tenant is an administrative or isolation scope.
+- Realm is an issuer or administrative namespace unless source analysis proves
+  stronger tenant semantics.
+- Organization is a collective actor or organizational structure.
+- Customer is a commercial relationship role.
+
+Model the relationships among these concepts instead of choosing one term to
+stand for all of them.
+
+## Conflict: Group, Role, Team, Community
+
+Problem: IAM systems often use groups for role assignment, collaboration tools
+use teams for work coordination, and social platforms use groups or communities
+for participation.
+
+Canonical stance:
+
+- Group is a named collection or collective actor with membership.
+- Role is a capability bundle or relationship label.
+- Team is a domain-specific group or organization unit.
+- Community is a participation-oriented collective actor.
+
+Avoid modeling all four as generic `group`.
+
+## Conflict: Member, Follower, Affiliate
+
+Problem: membership, following, affiliation, employment, subscription, and
+moderation relationships are often hidden behind `member`.
+
+Canonical stance: relationship type matters. Represent each relationship with
+source, target, scope, role or relation kind, evidence, lifecycle state, and
+authorization implications if any.
+
+## Conflict: Profile And Persona
+
+Problem: profiles are sometimes account records, public pages, social
+identities, or collections of claims. Personas are sometimes aliases,
+pseudonyms, or UX-specific presentations.
+
+Canonical stance:
+
+- Profile is a presentation or attribute surface in a scope.
+- Persona is a deliberate contextual presentation of an actor, often separate
+  from other presentations for privacy or role clarity.
+
+## Conflict: Identifier, Credential, Claim
+
+Problem: identifiers, credentials, and claims are often conflated because all
+can appear in tokens, profiles, or identity documents.
+
+Canonical stance:
+
+- Identifier refers.
+- Credential proves or supports.
+- Claim states.
+
+A token may contain all three, but the conceptual model should keep them apart.
+
+## Conflict: Synonymity, Linking, Matching, Merge
+
+Problem: identity systems often collapse weak matches, verified account links,
+same-as claims, and destructive record merges into a single identity-linking
+feature.
+
+Canonical stance: synonymity is an assertion. It has source, target, scope,
+confidence, evidence, method, lifecycle state, and privacy constraints. It does
+not require destructive merging.
+
+## Review Queue
+
+- Validate each conflict against populated source notes.
+- Add concrete examples and counterexamples once source summaries include
+  citations.
+- Decide whether Customer Account deserves a canonical concept or stays a
+  downstream commercial model.
+- Decide whether Realm should remain a Scope specialization or become a
+  separate canonical concept.