Seeded repo with initial and secondary research

canon/DesignPrinciples.md

@@ -0,0 +1,75 @@
+# 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.
+
+## P1. Use Actor As The Participation Root
+
+Do not start the model with `user`. An Actor is anything that can participate
+in relationships, hold accounts, be represented, or be evaluated by downstream
+systems. Natural persons, organizations, communities, families, and artificial
+agents can all be actors.
+
+## P2. Keep Person, Account, Identity, Profile, And Principal Separate
+
+A natural person is not an account. An account is not a profile. A profile is
+not a credential. A principal is an authorization projection. A subject is an
+issuer-bound protocol view. These distinctions prevent the most common identity
+model collapse.
+
+## P3. Treat Scope As First Class
+
+Identifiers, accounts, relationships, roles, policies, and meanings are only
+stable within a scope. A scope may be a tenant, realm, relying party, sector,
+community, application, namespace, or authorization domain.
+
+## P4. Model Collective Actors Without Collapsing Them
+
+Organizations, legal entities, customers, vendors, communities, families,
+households, groups, and teams are not interchangeable. They may relate to each
+other, but each should keep its social, legal, operational, or commercial
+meaning visible.
+
+## P5. Model Relationships Explicitly
+
+Membership, affiliation, following, ownership, representation, delegation,
+administration, employment, guardianship, and trust are separate relationship
+types. Do not hide them inside groups, roles, or ad hoc attributes.
+
+## P6. Keep Authorization Projections Separate
+
+Authorization engines need principals, resources, actions, roles, policies, and
+relationship tuples. These are projections from the conceptual identity model,
+not the whole identity model.
+
+## P7. Treat Synonymity As An Assertion
+
+Weak matches, verified links, same-as claims, and merges are different. The
+canon should represent synonymity as a scoped, evidenced, revocable assertion
+with confidence and method, never as an automatic destructive merge.
+
+## P8. Preserve Source And Evidence
+
+Source systems, issuers, import jobs, operators, documents, and verification
+events matter. Claims and relationships should be traceable to evidence or
+source references when the model depends on them.
+
+## P9. Prefer Orthogonal Concepts Over Product Terms
+
+External systems are mapping targets, not the source of canonical truth. If a
+product calls something a user, organization, group, project, tenant, or realm,
+the canon should identify the underlying concept before adopting the label.
+
+## P10. Test Concepts Against Scenarios
+
+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.
+
+## P11. Keep Implementation Recommendations Downstream
+
+The repository may recommend downstream schemas, APIs, UI flows, or adapters,
+but it should not implement them directly. Implementation ideas belong in
+`DownstreamRecommendations.md` or a dedicated downstream workplan.