Seeded repo with initial and secondary research

DownstreamRecommendations.md

@@ -0,0 +1,34 @@
+# Downstream Recommendations
+
+Status: draft. This file captures implementation ideas derived from the canon
+without moving implementation work into this repository.
+
+## Recommended Consumption Pattern
+
+Downstream repositories should consume identity-canon as a conceptual reference.
+They should map their schemas, APIs, CLI commands, UI labels, and authorization
+policies to canonical terms, but they should not depend on this repository as a
+runtime package unless a later explicit package is extracted.
+
+## Near-Term Recommendations
+
+- When designing user-management schemas, separate Natural Person, Account,
+  Profile, Credential, and Principal fields.
+- When designing tenant-aware systems, model Tenant as a scope and relate it to
+  Organization, Customer, Vendor, and Realm explicitly.
+- When designing organization features, do not reuse Group or Role as a generic
+  replacement for Organization.
+- When designing authorization adapters, treat Principal and relationship
+  tuples as projections from canonical actors, accounts, and relationships.
+- When designing account-linking features, store Synonymity Assertions with
+  source, evidence, confidence, scope, lifecycle state, and privacy controls.
+- When designing UI copy, use product-friendly labels but maintain internal
+  mappings to canonical concepts.
+
+## Avoid For Now
+
+- Do not implement identity provider integrations in this repository.
+- Do not add database migrations or production APIs here.
+- Do not treat this glossary as a finalized schema.
+- Do not use `user` as a canonical table, API, or class name without a mapping
+  note that explains which canonical concept it represents.