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.

research/authorization-relationships/openfga-modeling.md

@@ -1,50 +1,111 @@
-# Openfga Modeling
+# OpenFGA Modeling
 
 ## Source Type
 
-TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
+Product documentation and open-source implementation reference for OpenFGA
+authorization modeling (Zanzibar-inspired).
 
 ## Domain
 
-TODO: Classify the source domain.
+Relationship-based access control modeling, authorization schema design, and
+multi-tenant permission systems.
 
 ## Why This Source Matters
 
-OpenFGA authorization models, relationship tuples, users, objects, and relations.
+OpenFGA provides a concrete, documented modeling language for Zanzibar-style
+relationship tuples with authorization models, stores, and checks.
 
 ## Key Concepts
 
-TODO:
-- concept 1
-- concept 2
-- concept 3
+- **Authorization model**: declarative schema of types, relations, and
+  permission definitions.
+- **Type definition**: object type with relations and optional `define` rules.
+- **Relation**: named edge on a type; may allow direct assignment or computed
+  rules.
+- **Define / rewrite rules**: union (`+`), intersection, exclusion, and
+  inheritance (`from relation`).
+- **Tuple**: `user:type#relation@object:type` stored fact.
+- **Userset**: indirect reference such as `user:anne#member@group:engineering`.
+- **Store**: isolated tuple set with its own model.
+- **Check / ListObjects / ListUsers**: query APIs.
+- **Contextual tuples**: ephemeral tuples supplied at check time.
+- **Conditions**: CEL-based contextual rules on relations (newer versions).
 
 ## Relevant Terminology
 
-TODO: Extract terms used by the source and note their source-specific meaning.
+| Term | Source meaning |
+| --- | --- |
+| User (in tuple) | Subject identifier in `user:` namespace. |
+| Object | Entity in `object:` namespace with type. |
+| Relation | Named permission edge on a type. |
+| Type | Schema class for objects (document, folder, organization). |
+| Model | Collection of type definitions. |
+| Store | Isolated authorization dataset. |
+| define | Computed relation rule. |
+| from | Inheritance from related object's relation. |
+| contextual tuple | Runtime-only tuple for conditional checks. |
 
 ## Modeling Assumptions
 
-TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
+- **Model-first design**: relations are declared in schema before tuples are written.
+- **User and object IDs are opaque strings**; no embedded identity semantics.
+- **Organization/tenant patterns** are modeled as types (e.g., `organization`,
+  `tenant`) with `member`, `admin` relations.
+- **Inheritance chains** (folder contains document) are common modeling pattern.
+- **Store isolation** provides multi-tenant authorization separation.
+- **Identity management is external**; OpenFGA consumes identifiers.
+- **Permissions are computed**, not stored as standalone grants.
 
 ## Identity-Canon Implications
 
-TODO: Explain what this source suggests for the canonical identity model.
+- OpenFGA aligns with Zanzibar mappings; adds explicit **authorization model**
+  as schema artifact (downstream, not canonical).
+- Type definitions like `organization#member` parallel **Organization** +
+  **Membership Relationship** but in authz projection.
+- **Store** maps to **Authorization Domain** Scope or tenant-scoped authz partition.
+- `user:` prefix in tuples maps to **Authorization Principal** identifier.
+- Contextual tuples support request-time **Delegation** context without
+  persisting relationship.
+- Model examples for parent-child org hierarchies support S03, S04, S05.
+- Reinforces **P6**: tuples are projections from actors/relationships.
 
 ## Terminology Conflicts
 
-TODO: Record where this source uses terms differently from other sources.
+- **User**: OpenFGA `user:` is tuple subject prefix, not human or account.
+- **Organization type**: authz type ≠ Organization collective actor unless
+  explicitly linked.
+- **Member relation**: authz member ≠ community member without model alignment.
+- **Store vs. Tenant**: store is authz isolation; tenant is broader scope.
+- **Permission vs. Relation**: permissions are computed from relations; products
+  often say "permission" for relation name.
 
 ## Candidate Canonical Mappings
 
-TODO: Map source-specific concepts to identity-canon candidate concepts.
+| OpenFGA concept | Candidate canonical concept |
+| --- | --- |
+| Tuple | Relationship Tuple (authorization projection) |
+| user: (subject) | Authorization Principal |
+| object: (entity) | Authorization Resource |
+| Relation | Relationship type (authz-implied) |
+| Type definition | Authorization schema (downstream) |
+| Store | Authorization Domain Scope |
+| define/from rules | Authorization derivation (non-canonical) |
+| organization#member | Membership Relationship (projection) |
+| organization#admin | Administration Relationship (projection) |
+| contextual tuple | Delegation context (ephemeral) |
 
 ## Open Questions
 
-TODO:
-- Question 1
-- Question 2
+- Should canon document standard OpenFGA type patterns (org/team/resource) as
+  downstream recommendations only?
+- How should principal identifiers be aligned with Account IDs vs. Authenticated
+  Subject `sub` values?
+- Do conditional (CEL) relations require canonical Context as a first-class
+  projection?
+- Should one Store always map 1:1 to a Tenant Scope?
 
 ## References
 
-TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
+- OpenFGA documentation — https://openfga.dev/docs
+- OpenFGA modeling guide — https://openfga.dev/docs/modeling
+- OpenFGA configuration language — https://openfga.dev/docs/configuration-language