# Scenario Tests Status: draft. These are narrative tests for the conceptual model. They are not executable tests yet; they define expected representation checks for future model revisions. ## Test Format - Scenario: concrete identity situation. - Expected representation: the canonical concepts that should be used. - Checks: conditions the model must satisfy without collapsing terms. ## S01. Single Person With One Local Account Expected representation: one Natural Person, one Account in an application Scope, one local Identifier, one Profile, and one Membership or access relationship if the account belongs to a group. Checks: - The person is not identical to the account. - The profile is not the credential. - Authorization can project the account or subject into a Principal. ## S02. Person With Multiple Accounts Across Scopes Expected representation: one Natural Person, multiple Accounts, one Account per Scope, and optional Synonymity Assertions linking account records. Checks: - Each account keeps its source and lifecycle state. - Linking accounts does not merge them destructively. - Different scopes can use different identifiers. ## S03. Enterprise With Sub-Organizations Expected representation: Organization actors linked by structural relationships, plus Accounts and Membership relationships scoped to relevant systems. Checks: - Sub-organization is not automatically a tenant. - Legal entity status is modeled separately. - Membership and administration relationships are explicit. ## S04. Vendor Tenant Serving Customer Tenants Expected representation: Vendor and Customer relationship roles between Organization actors; Tenant scopes for platform isolation; optional Administration relationships for delegated support. Checks: - Customer is not collapsed into Tenant. - Vendor is not collapsed into Realm. - Cross-tenant administration is scoped and evidenced. ## S05. Customer Organization With Delegated Administrators Expected representation: Organization actor, Tenant scope, administrator Accounts, Delegation and Administration relationships. Checks: - Admin rights are relationships, not just group names. - Delegation has source, target, scope, and lifecycle state. - Authorization projection can consume the relationship separately. ## S06. Family With Guardian And Dependent Accounts Expected representation: Family or Household collective actor, Natural Person actors, guardian/dependent relationships, child Accounts, and privacy constraints. Checks: - Guardian relationship is not generic membership. - Household and legal family can differ. - Privacy-sensitive links can be scoped. ## S07. Spontaneous Interest Group Expected representation: Community or Group collective actor, Membership relationships, optional moderator Administration relationships. Checks: - Informal group does not need legal entity or tenant semantics. - Moderation is not the same as membership. - Group identity can exist without strong real-world identity proofing. ## S08. Community With Members, Moderators, And Followers Expected representation: Community actor; Membership relationships for members; Administration or moderation relationships for moderators; Following relationships for followers. Checks: - Follower is not a member unless the source says so. - Moderator authority is explicit and scoped. - Public profile can differ from account. ## S09. Social Media Follower Graph Expected representation: Actor or Persona profiles connected by Following relationships in a social Scope. Checks: - Following is directed. - Following does not imply affiliation, membership, trust, or authorization. - Pseudonymous profiles can remain scoped. ## S10. Bot Or Service Account Acting For An Organization Expected representation: Artificial Agent actor, Service Account, Organization actor, Representation or Delegation relationship, and Credential records. Checks: - Bot is not a natural person. - Service account has an owner or responsible actor. - Delegated authority has bounded scope and lifecycle. ## S11. AI Agent Acting Under Delegated Authority Expected representation: Artificial Agent actor, Account or Service Account, Delegation relationship from a Natural Person or Organization, and audit or evidence references for actions. Checks: - Delegation identifies who granted authority. - Agent actions can be attributed without treating the agent as the person. - Authorization projection can include delegated context. ## S12. Weak Identity Match From Imported Data Expected representation: source Identity Records linked by a weak Synonymity Assertion with method, evidence, confidence, scope, and lifecycle state. Checks: - Weak match does not merge accounts. - Consumers can reject or quarantine weak links. - Evidence source remains visible. ## S13. Strong Account Link After Explicit Verification Expected representation: Accounts linked by a strong Synonymity Assertion or Account Link relationship, with verification evidence and revocation path. Checks: - Strong link is still scoped. - Verification method is recorded. - Revocation or unlinking is possible. ## S14. Pseudonymous Profile Linked Only Within A Restricted Scope Expected representation: Persona or Profile with Scoped Identifier and privacy-limited Synonymity Assertion visible only inside an allowed Scope. Checks: - Public consumers cannot infer the hidden link. - The pseudonym can have relationships independent of legal identity. - Scope boundaries are explicit. ## S15. Organization Represented By A Legal Entity And Operational Tenants Expected representation: Organization actor, Legal Entity specialization or relationship, one or more Tenant scopes, and Representation relationships for authorized persons or agents. Checks: - Legal entity and tenant are separate model elements. - Multiple tenants can relate to one organization. - Representation authority is scoped and evidenced. ## Current Result After IDENTITY-WP-0003 corpus backfill, `model/ConceptualModel.md` documents an explicit representation path for each scenario (S01–S15). All fifteen scenarios remain representable without glossary or principle changes. Remaining ambiguities are tracked in `OpenQuestions.md` (Realm promotion, mandatory Synonymity Assertion fields). Customer Account is resolved: use Commercial Record for billing-side artifacts. These affect refinement, not scenario satisfiability.