Complete IDENTITY-WP-0003 corpus backfill and model refinement

Backfill all 23 research source notes with terminology extracts, modeling
assumptions, conflicts, canonical mappings, and references. Refresh terminology
artifacts, refine the conceptual model with explicit scenario paths, reconcile
canon surfaces and open questions, and mark the workplan finished.

model/ConceptualModel.md

@@ -1,15 +1,14 @@
 # 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.
+Status: draft. Refined after IDENTITY-WP-0003 corpus backfill and scenario
+representation review. Implementation-neutral.
 
 ## 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`.
+Identity-canon models identity-related systems as scoped actors, records,
+identifiers, claims, credentials, relationships, and projections. Social, legal,
+operational, authentication, and authorization meanings stay visible instead of
+collapsing into `user`, `group`, or `tenant`.
 
 ## Entity Families
 
@@ -58,7 +57,7 @@ meanings visible instead of collapsing them into `user`, `group`, or `tenant`.
 
 ## Relationship Classes
 
-Relationships should be explicit model elements when they affect meaning,
+Relationships are explicit model elements when they affect meaning,
 authorization, privacy, or lifecycle.
 
 Core relationship classes:
@@ -90,26 +89,121 @@ Recommended relationship fields:
 
 ## Identity Linking Model
 
-Identity linking should not merge records by default. It should create
-Synonymity Assertions.
+Identity linking does not merge records by default. It creates Synonymity
+Assertions with relation types (`same_as`, `probably_same_as`, `linked_to`,
+`represents`), strength bands, scope, evidence, and lifecycle state.
 
-Weak synonymity examples:
+Weak synonymity: probabilistic entity-resolution matches, schema.org sameAs,
+shared attributes without verification.
 
-- 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: deterministic keys (OIDC iss+sub, persistent SAML NameID),
+operator-verified links, VC cryptographic proof.
 
-Strong synonymity examples:
+Privacy-limited synonymity: pairwise OIDC sub, pseudonymous persona links,
+GDPR pseudonymization with separated re-identification key.
 
-- account holder completes explicit account-linking flow;
-- issuer signs a claim binding an identifier to a subject;
-- operator verifies a link against authoritative evidence.
+## Scenario Representation Paths
 
-Privacy-limited synonymity examples:
+Each scenario in `scenarios/ScenarioTests.md` maps to canonical elements as
+follows.
 
-- 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.
+### S01 — Single Person With One Local Account
+
+`Natural Person` → operates → `Account` (in `Scope`) → has `Identifier`(s) →
+presents `Profile` → optional `Membership Relationship` to `Group` → authz
+projects `Account` to `Authorization Principal`.
+
+### S02 — Person With Multiple Accounts Across Scopes
+
+`Natural Person` → operates → multiple `Account` (one primary `Scope` each) →
+optional `Synonymity Assertion` (`linked_to` or `same_as`, scoped) between
+accounts → independent `Lifecycle State` per account.
+
+### S03 — Enterprise With Sub-Organizations
+
+`Organization` actors → structural child/parent relationships → `Identity
+Record`/`Account` per directory source (LDAP/SCIM) → `Membership Relationship`
+to org units → `Legal Entity` as specialization or relationship when evidenced.
+
+### S04 — Vendor Tenant Serving Customer Tenants
+
+`Organization`(vendor) + `Organization`(customer) → `Vendor`/`Customer`
+relationship roles → separate `Tenant` scopes → `Trust Relationship` for
+federation → `Administration Relationship` for delegated support.
+
+### S05 — Customer Organization With Delegated Administrators
+
+`Organization` → owns `Tenant` scope → administrator `Account`(s) →
+`Delegation Relationship` + `Administration Relationship` → authz projection
+via Cedar Principal or OpenFGA admin tuple.
+
+### S06 — Family With Guardian And Dependent Accounts
+
+`Family or Household` collective actor → `Natural Person` (guardian, dependent)
+→ `Representation Relationship` (guardian→dependent) → child `Account` with
+privacy constraints → optional NIST IAL-capped proofing metadata.
+
+### S07 — Spontaneous Interest Group
+
+`Community` or `Group` collective actor → `Membership Relationship` (informal)
+→ optional `Administration Relationship` (moderator) → no `Tenant` or `Legal
+Entity` required.
+
+### S08 — Community With Members, Moderators, And Followers
+
+`Community` actor → `Membership Relationship` (members) → `Administration
+Relationship` (moderators) → `Following Relationship` (followers) → `Profile`
+may differ from `Account`.
+
+### S09 — Social Media Follower Graph
+
+`Actor`/`Persona` → `Profile` in social `Scope` → directed `Following
+Relationship` edges → no implied `Membership` or authz tuple.
+
+### S10 — Bot Or Service Account Acting For An Organization
+
+`Artificial Agent` → `Service Account` → `Organization` actor →
+`Representation` or `Delegation Relationship` → `Credential` → authz tuple
+(e.g., `org#delegate@service_account`).
+
+### S11 — AI Agent Acting Under Delegated Authority
+
+`Artificial Agent` → `Account` or `Service Account` → `Delegation
+Relationship` from `Natural Person` or `Organization` → `Evidence Source` for
+actions → Cedar `Context.delegatedBy` or contextual OpenFGA tuple.
+
+### S12 — Weak Identity Match From Imported Data
+
+Source `Identity Record`(s) → `Synonymity Assertion` (`probably_same_as`, weak,
+scoped) → `Evidence Source` (import job, match score) → `Lifecycle State`
+`proposed` until reviewed.
+
+### S13 — Strong Account Link After Explicit Verification
+
+`Account`(s) or `Identifier`(s) → `Synonymity Assertion` (`same_as`, strong) →
+`Evidence Source` (verification event, VC proof, re-authentication) →
+revocation/supersession path via `Lifecycle State`.
+
+### S14 — Pseudonymous Profile Linked Only Within Restricted Scope
+
+`Persona`/`Profile` → `Scoped Identifier` → `Synonymity Assertion`
+(privacy-limited, restricted `Scope`) → separated re-identification
+`Evidence Source` per GDPR pseudonymization pattern.
+
+### S15 — Organization Represented By Legal Entity And Operational Tenants
+
+`Organization` actor → `Legal Entity` relationship or specialization → one or
+more `Tenant` scopes → `Representation Relationship` for authorized persons or
+agents.
+
+## Scenario Gaps
+
+No scenario requires glossary or principle changes that the current model
+cannot satisfy. Remaining ambiguities are documented in `OpenQuestions.md`:
+
+- mandatory Synonymity Assertion field set;
+- Realm vs. Tenant promotion for Keycloak-heavy mappings;
+- Customer Account as separate concept vs. Organization + Customer role.
 
 ## Invariants
 
@@ -117,20 +211,24 @@ Privacy-limited synonymity examples:
 - 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
+- A Principal is a projection for authorization and must 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
+- A Tenant can be related to an Organization or Customer, but is not identical
+  to either.
+- A Group carries Membership relationships; Role assignment and relationship
+  semantics stay explicit.
+- A Synonymity Assertion links records without destroying source identity or
   evidence.
 - Lifecycle state applies to relationships and assertions, not only accounts.
+- Authorization tuples (Zanzibar/OpenFGA) and Cedar principals are projections
+  from canonical actors, accounts, and relationships — not alternate identity
+  roots.
+- OIDC Subject and SAML Principal are Authenticated Subject projections, not
+  Natural Persons.
 
 ## External Mapping Rule
 
-When mapping an external system, first identify which canonical layer the
-source term belongs to:
+When mapping an external system, identify the canonical layer first:
 
 1. Actor layer: who or what participates?
 2. Record layer: what operational record exists?
@@ -142,3 +240,20 @@ source term belongs to:
 Only after that mapping should source-specific labels such as `user`, `group`,
 `organization`, `realm`, `tenant`, `subject`, or `principal` be adopted in a
 downstream artifact.
+
+## Source Grounding
+
+This revision is grounded in the backfilled research corpus (23 source notes).
+Key cross-cutting findings:
+
+- Provisioning sources (SCIM, LDAP) model records and group membership, not
+  actors directly.
+- Federation sources (OIDC, SAML, NIST, SSF) define subject identifiers,
+  assurance, and lifecycle events.
+- Authorization sources (Zanzibar, OpenFGA, Cedar, Cerbos) are projection
+  layers over opaque identifiers.
+- Social sources (ActivityPub, FOAF, Schema.org, WebID) separate person, actor,
+  account, and social edges.
+- VC/DID sources add portable claims and decentralized identifiers.
+- Entity-resolution and GDPR sources define synonymity strength and privacy
+  constraints.