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.

canon/CanonicalGlossary.md

@@ -1,7 +1,8 @@
 # Canonical Glossary
 
-Status: draft. These definitions are initial candidate canon terms. They are
-intended to be challenged by source-note backfill and scenario testing.
+Status: draft. Updated after IDENTITY-WP-0003 corpus backfill and scenario
+review. Definitions remain candidate canon terms until human review promotes
+them.
 
 ## Actor
 
@@ -126,8 +127,10 @@ but it is not automatically identical to any of them.
 
 An issuer, security, or administrative namespace used by an identity system.
 
-Candidate status: treat Realm as a Scope specialization unless source analysis
-shows it needs a separate canonical role.
+After Keycloak and federation source review, Realm remains a **Scope
+specialization** for hard identity/admin boundaries (separate user namespaces,
+credentials, clients, IdPs). It is not interchangeable with Tenant or
+Organization.
 
 ## Organization
 
@@ -228,8 +231,17 @@ another for claims, identifiers, credentials, or decisions.
 A scoped, evidenced assertion that two or more identifiers, records, accounts,
 profiles, or actors refer to the same target for a stated purpose.
 
-Synonymity assertions may be weak, strong, verified, inferred, revoked,
-privacy-limited, or source-specific.
+Recommended relation types: `same_as`, `probably_same_as`, `linked_to`,
+`represents`, `controls`, `acts_for`.
+
+Recommended strength bands: weak, medium, strong, authoritative.
+
+Synonymity assertions may be verified, inferred, revoked, privacy-limited, or
+source-specific. They do not require destructive merging of source records.
+
+Common sources: OIDC iss+sub account binding, SAML persistent NameID mapping,
+entity-resolution matches, operator verification, VC cryptographic proof,
+schema.org sameAs (weak by default).
 
 ## Evidence Source
 
@@ -244,6 +256,37 @@ assertion.
 Examples: proposed, active, suspended, revoked, expired, archived, deleted,
 superseded.
 
+Security event streams (SSF/CAEP/RISC) and VC status mechanisms are common
+Evidence Sources that trigger lifecycle transitions.
+
+## Assurance Level
+
+Confidence metadata about identity proofing, authentication, or federation
+derived from sources such as NIST SP 800-63-4.
+
+Dimensions:
+
+- Identity Assurance Level (IAL): confidence that a subscriber is the claimed person.
+- Authenticator Assurance Level (AAL): confidence in authentication mechanism.
+- Federation Assurance Level (FAL): confidence in federation assertion protection.
+
+Assurance levels attach to bindings, credentials, and federation relationships;
+they do not replace authorization decisions.
+
+## Relationship Tuple
+
+An authorization projection encoding a subject-relation-object fact in engines
+such as Zanzibar, OpenFGA, or Ory Keto.
+
+Relationship tuples are not canonical identity roots. They project from actors,
+accounts, memberships, and delegations into authorization domains.
+
+## Pseudonymous Identifier
+
+An identifier designed to limit cross-scope correlation, aligned with privacy
+patterns such as OIDC pairwise subjects, tenant-local subjects, and GDPR
+pseudonymization with separately stored re-identification keys.
+
 ## Non-Canonical Convenience Term: User
 
 `User` may be used in prose when quoting or mapping external systems, but it

canon/DesignPrinciples.md

@@ -1,8 +1,9 @@
 # Design Principles
 
-Status: draft. These principles make the proposal's modeling stance explicit.
-They are constraints for canonical vocabulary and conceptual model work, not
-implementation requirements for downstream systems.
+Status: draft. Refined after IDENTITY-WP-0003 corpus backfill. These principles
+make the proposal's modeling stance explicit. They are constraints for canonical
+vocabulary and conceptual model work, not implementation requirements for
+downstream systems.
 
 ## P1. Use Actor As The Participation Root
 
@@ -66,7 +67,23 @@ the canon should identify the underlying concept before adopting the label.
 Every canonical concept should survive concrete scenarios: enterprise
 directories, vendor/customer tenancy, families, communities, social graphs,
 service accounts, delegated agents, weak matches, strong links, and
-pseudonymous profiles.
+pseudonymous profiles. After corpus backfill, all fifteen scenarios in
+`scenarios/ScenarioTests.md` have explicit representation paths in
+`model/ConceptualModel.md`.
+
+## P12. Distinguish Assurance Dimensions
+
+Identity proofing, authentication, and federation assurance are separable
+dimensions (NIST IAL, AAL, FAL). Do not collapse them into a single "trust
+level" on an account. Record assurance metadata on bindings, credentials, and
+federation relationships where sources provide it.
+
+## P13. Prefer Non-Destructive Linking
+
+Entity resolution, federation account linking, and semantic web equivalence
+patterns should produce Synonymity Assertions, not silent record merges.
+Probabilistic matches default to weak strength with review lifecycle. Deterministic
+and verified matches may be strong but remain scoped and revocable.
 
 ## P11. Keep Implementation Recommendations Downstream