# Conceptual Model

Status: draft. This is the first narrative model extracted from the research
proposal. It is intentionally implementation-neutral and should be refined by
source-note backfill and scenario testing.

## Core Claim

Identity-canon should model identity-related systems as scoped actors,
records, identifiers, claims, credentials, relationships, and projections. The
model should keep social, legal, operational, authentication, and authorization
meanings visible instead of collapsing them into `user`, `group`, or `tenant`.

## Entity Families

### Actor Layer

- Actor: participation root.
- Natural Person: human actor.
- Artificial Agent: non-human automated actor.
- Collective Actor: actor composed of, representing, or organizing multiple
  actors.
- Organization, Community, Family or Household, Group, and Team: candidate
  collective actor specializations.

### Record Layer

- Account: operational access record in a scope.
- Service Account: software-oriented account.
- Identity Record: source-specific record about an actor or account.
- Profile: presentation or attribute surface.
- Persona: contextual presentation of an actor.

### Reference Layer

- Identifier: value or reference within a scope.
- Scoped Identifier: identifier designed for limited correlation.
- Credential: proof or control material.
- Claim: statement made by a source or issuer.
- Evidence Source: support for claims, relationships, and synonymity.

### Scope Layer

- Scope: boundary for meaning.
- Tenant: administrative or isolation scope.
- Realm: issuer or security namespace.
- Namespace: naming scope.
- Authorization Domain: scope in which principals, resources, actions, and
  policies are evaluated.

### Projection Layer

- Authenticated Subject: protocol projection of an identified entity.
- Authorization Principal: decision-engine projection of an actor, account, or
  subject.
- Authorization Resource, Action, Policy, and Relationship Tuple: downstream
  authorization projections, not canonical identity roots.

## Relationship Classes

Relationships should be explicit model elements when they affect meaning,
authorization, privacy, or lifecycle.

Core relationship classes:

- Membership: actor participates in a collective actor or scope.
- Affiliation: actor is associated with another actor or collective.
- Following: actor subscribes to or follows another actor or profile.
- Ownership: actor controls or is responsible for a record, resource, tenant,
  or organization.
- Representation: actor acts on behalf of another actor.
- Delegation: actor grants bounded authority to another actor.
- Administration: actor manages records, relationships, or configuration in a
  scope.
- Trust: actor, issuer, verifier, or system relies on another for a purpose.
- Synonymity: records or identifiers are asserted to refer to the same target
  under stated evidence and scope.

Recommended relationship fields:

- relationship type;
- source and target;
- scope;
- source system or issuer;
- evidence reference;
- confidence or assurance when relevant;
- lifecycle state;
- privacy constraints;
- authorization implication, if any.

## Identity Linking Model

Identity linking should not merge records by default. It should create
Synonymity Assertions.

Weak synonymity examples:

- imported records match on name and email hash;
- two profiles share a phone number but lack explicit verification;
- an entity-resolution job proposes a duplicate.

Strong synonymity examples:

- account holder completes explicit account-linking flow;
- issuer signs a claim binding an identifier to a subject;
- operator verifies a link against authoritative evidence.

Privacy-limited synonymity examples:

- pairwise subject identifier bound only for one relying party;
- pseudonymous community profile linked only inside a restricted scope;
- legal identity reference stored separately from a public persona.

## Invariants

- A Natural Person can control zero, one, or many Accounts.
- An Account belongs to exactly one primary operational Scope, but can have
  relationships to other scopes.
- A Profile presents an Actor, Account, or Persona within a Scope.
- A Principal is a projection for authorization and should not replace Actor or
  Account in the canon.
- A Tenant can be related to an Organization or Customer, but should not be
  treated as identical to either.
- A Group can carry Membership relationships, but Role assignment and
  relationship semantics must stay explicit.
- A Synonymity Assertion can link records without destroying source identity or
  evidence.
- Lifecycle state applies to relationships and assertions, not only accounts.

## External Mapping Rule

When mapping an external system, first identify which canonical layer the
source term belongs to:

1. Actor layer: who or what participates?
2. Record layer: what operational record exists?
3. Reference layer: what values, claims, or credentials refer or prove?
4. Scope layer: where is the meaning valid?
5. Relationship layer: what typed connection is asserted?
6. Projection layer: what downstream protocol or authorization view is needed?

Only after that mapping should source-specific labels such as `user`, `group`,
`organization`, `realm`, `tenant`, `subject`, or `principal` be adopted in a
downstream artifact.