docs: establish domain vocabulary and identity scenarios (#5)

.planning/README.md

@@ -74,6 +74,7 @@ Confirmed planning decisions inform product documents and implementation issues;
 | Session | Scope | Status |
 | --- | --- | --- |
 | [20261015T085738Z-3](decisions/20261015T085738Z-3/session.md) | Product functionality and initial scope; no technical stack | confirmed |
+| [20261015T163800Z-5](decisions/20261015T163800Z-5/session.md) | Domain model: practice/contact identity and appointment lifecycle; no stack | active |
 
 ## Follow-ups
 
@@ -83,8 +84,8 @@ Confirmed planning decisions inform product documents and implementation issues;
 | [AI-generated additional UI translations](follow-ups/20261015T110819Z-ai-generated-additional-ui-translations/follow-up.md) | feat | captured | Expansion beyond the initial four languages |
 | [Choose beta operating countries](follow-ups/20261015T121349Z-choose-beta-operating-countries/follow-up.md) | question | captured | Before beta eligibility/local operating rules |
 | [Validate WhatsApp linked-line onboarding](follow-ups/20261015T142428Z-validate-whatsapp-linked-line-onboarding/follow-up.md) | research | captured | Technical integration planning before promising connection modes |
-| [Define detailed booking and rescheduling policies](follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md) | question | captured | Before implementing the affected scheduling policies or activating them for a practice |
-| [Define identity, permissions and sharing access rules](follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md) | question | captured | Before enabling affected record access, membership administration, sharing or booking changes |
+| [Define detailed booking and rescheduling policies](follow-ups/20261015T155426Z-define-detailed-booking-policies/follow-up.md) | question | in-progress | Before implementing the affected scheduling policies or activating them for a practice |
+| [Define identity, permissions and sharing access rules](follow-ups/20261015T155426Z-define-identity-permissions-and-sharing/follow-up.md) | question | in-progress | Before enabling affected record access, membership administration, sharing or booking changes |
 | [Define handoff, group and notification workflows](follow-ups/20261015T155426Z-define-handoff-and-notification-workflows/follow-up.md) | question | captured | Before implementing or enabling the corresponding handoff, group or delivery-failure flows |
 | [Define profile, intake and correction details](follow-ups/20261015T155426Z-define-profile-fields-and-intake-details/follow-up.md) | question | captured | Before implementing affected profile/intake behavior or collecting real patient intake |
 | [Define beta validation and public-release criteria](follow-ups/20261015T155426Z-define-beta-validation-and-release-gates/follow-up.md) | question | captured | Before inviting real beta practices or claiming readiness for broader advertising |

.planning/decisions/20261015T163800Z-5/D000-modeling-scope.md

@@ -0,0 +1,79 @@
+---
+{
+  "schema_version": 1,
+  "id": "20261015T163800Z-5/D000",
+  "session": ".planning/decisions/20261015T163800Z-5/session.md",
+  "title": "Domain-modeling scope and established vocabulary",
+  "status": "confirmed",
+  "round": 0,
+  "created_at": "2026-10-15T16:38:00Z",
+  "updated_at": "2026-10-15T16:38:00Z",
+  "asked_at": null,
+  "answered_at": null,
+  "confirmed_at": null,
+  "decision_owner": "user",
+  "recorded_by": "assistant",
+  "issue_url": "https://github.com/codeonym-org/medora/issues/5",
+  "predecessors": [
+    ".planning/decisions/20261015T085738Z-3/D040-shared-understanding-confirmation.md"
+  ],
+  "related_decisions": [],
+  "supersedes": [],
+  "superseded_by": [],
+  "affected_components": [
+    "Domain vocabulary",
+    "Domain relationships"
+  ],
+  "follow_ups": [],
+  "sources": [
+    ".planning/decisions/20261015T085738Z-3/scope-review.md",
+    "User message invoking mattpocock-skills:domain-modeling"
+  ]
+}
+---
+
+# Context — why ask this?
+
+The user moved from the confirmed product foundation into explicit domain modeling. Existing decisions supply resolved terms; identity and lifecycle relationships still need sharpening.
+
+## Predecessor decisions
+
+[Confirmed product foundation](../20261015T085738Z-3/scope-review.md) and its final confirmation.
+
+## Question
+
+Not applicable: the user explicitly requested domain-modeling work.
+
+## Recommendation and alternatives
+
+Create a root glossary for resolved definitions and a separate domain-model document for relationships/scenarios. No ADR is justified merely by starting a glossary.
+
+## User reply — original words
+
+Source: current conversation; original message timestamp unavailable.
+
+> $mattpocock-skills:domain-modeling lets model the domain, okey?
+
+## Interpretation
+
+Actively model the domain using the named skill, checking the confirmed foundation and recording terminology as it crystallizes. Keep the work stack-neutral, consistent with the preceding discussion.
+
+## Decision and rationale
+
+Domain-modeling work is authorized. The initial glossary captures already-confirmed concepts; this instruction does not resolve the new scenario questions.
+
+## Consequences and affected components
+
+Use GLOSSARY.md for definitions only, docs/domain-model.md for relationship analysis, and this session for the original exchanges.
+
+## Assumptions, evidence, and open questions
+
+There is no application code to compare against the concepts. No technology or storage design is selected.
+
+## Extra notes and follow-ups
+
+The previous discovery session remains confirmed and unchanged; this is a new session linked to issue #5.
+
+## History
+
+- 2026-10-15T16:38:00Z — Recorded the user invocation and initialized the modeling context.

.planning/decisions/20261015T163800Z-5/D001-staff-identity-and-membership.md

@@ -0,0 +1,97 @@
+---
+{
+  "schema_version": 1,
+  "id": "20261015T163800Z-5/D001",
+  "session": ".planning/decisions/20261015T163800Z-5/session.md",
+  "title": "Staff accounts and memberships",
+  "status": "confirmed",
+  "round": 1,
+  "created_at": "2026-10-15T16:38:00Z",
+  "updated_at": "2026-10-16T10:18:23Z",
+  "asked_at": null,
+  "answered_at": null,
+  "confirmed_at": null,
+  "decision_owner": "user",
+  "recorded_by": "assistant",
+  "issue_url": "https://github.com/codeonym-org/medora/issues/5",
+  "predecessors": [
+    ".planning/decisions/20261015T085738Z-3/D001-first-practice.md",
+    ".planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md"
+  ],
+  "related_decisions": [],
+  "supersedes": [],
+  "superseded_by": [],
+  "affected_components": [
+    "Practice Membership",
+    "Practice Owner",
+    "Doctor",
+    "Staff Account"
+  ],
+  "follow_ups": [],
+  "sources": [
+    ".planning/decisions/20261015T085738Z-3/D001-first-practice.md",
+    ".planning/decisions/20261015T085738Z-3/D034-practice-configuration-ownership.md",
+    "GLOSSARY.md",
+    "docs/domain-model.md"
+  ],
+  "reply_recorded_at": "2026-10-16T10:18:23Z",
+  "reply_reference": "Joint user reply: ok, next; in response to the three first-round recommendations"
+}
+---
+
+# Context — why ask this?
+
+A person may work in several practices and an explicit admin account is confirmed. The account identity, membership and role combination now need a precise relationship.
+
+## Predecessor decisions
+
+- [D001-first-practice](../20261015T085738Z-3/D001-first-practice.md)
+- [D034-practice-configuration-ownership](../20261015T085738Z-3/D034-practice-configuration-ownership.md)
+
+These established requirements are inputs; no outcome of another first-round modeling question is assumed.
+
+## Question
+
+Dr Sara owns Practice A and also works at Practice B. Should she use one Medora staff account with separate memberships, allowing her to be Owner/Admin and Doctor in A but only Doctor in B?
+
+## Recommendation and alternatives
+
+Use one staff identity with practice-scoped memberships and role combinations. Entering another practice must change the active permissions and accessible records, not carry the first practice's authority across.
+
+This was the recommendation presented before the joint reply; the acceptance and its limited interpretation are recorded below.
+
+## User reply — original words
+
+Joint reply to the first three modeling recommendations, recorded 2026-10-16T10:18:23Z; original message timestamp unavailable:
+
+> ok, next
+
+## Interpretation
+
+Read as acceptance of the three recommendations just presented and a request to continue. This is a joint acknowledgment, not three separately worded answers. For this decision: One Staff Account can hold separate Practice Memberships, with multiple roles in a membership. Sara can be Owner/Admin and Doctor in A and Doctor only in B; authority and records remain practice-scoped.
+
+No additional policy values, verification method or implementation choices are inferred.
+
+## Decision and rationale
+
+Confirmed within this scenario: One Staff Account can hold separate Practice Memberships, with multiple roles in a membership. Sara can be Owner/Admin and Doctor in A and Doctor only in B; authority and records remain practice-scoped.
+
+The user supplied no separate rationale. The recommendation and its reasoning above are assistant-authored.
+
+## Consequences and affected components
+
+Practice Membership, Practice Owner, Doctor. The reply will sharpen terminology and relationships in the glossary/model.
+
+## Assumptions, evidence, and open questions
+
+The joint reply confirms the relationship described above. No database schema, account implementation, global person-matching scheme or automatic verification method is selected. Detailed permissions and independent request-closure policies remain open. No application code exists to cross-check.
+
+## Extra notes and follow-ups
+
+The booking-policy and identity/permissions follow-ups remain open; vocabulary work does not resolve their full scope.
+
+## History
+
+- 2026-10-15T16:38:00Z — Prepared this scenario from the confirmed foundation; user response pending.
+
+- 2026-10-16T10:18:23Z — Saved the joint reply verbatim and recorded its acceptance of the existing recommendation; no additional commitments inferred.

.planning/decisions/20261015T163800Z-5/D002-shared-contact-point.md

@@ -0,0 +1,103 @@
+---
+{
+  "schema_version": 1,
+  "id": "20261015T163800Z-5/D002",
+  "session": ".planning/decisions/20261015T163800Z-5/session.md",
+  "title": "A shared patient-side number",
+  "status": "confirmed",
+  "round": 1,
+  "created_at": "2026-10-15T16:38:00Z",
+  "updated_at": "2026-10-16T10:18:23Z",
+  "asked_at": null,
+  "answered_at": null,
+  "confirmed_at": null,
+  "decision_owner": "user",
+  "recorded_by": "assistant",
+  "issue_url": "https://github.com/codeonym-org/medora/issues/5",
+  "predecessors": [
+    ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md",
+    ".planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md",
+    ".planning/decisions/20261015T085738Z-3/D025-remembered-language-preference-owner.md",
+    ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md"
+  ],
+  "related_decisions": [],
+  "supersedes": [],
+  "superseded_by": [],
+  "affected_components": [
+    "Communication Contact",
+    "Patient",
+    "Patient Profile",
+    "Contact Point"
+  ],
+  "follow_ups": [],
+  "sources": [
+    ".planning/decisions/20261015T085738Z-3/D016-booking-for-someone-else.md",
+    ".planning/decisions/20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md",
+    ".planning/decisions/20261015T085738Z-3/D025-remembered-language-preference-owner.md",
+    ".planning/decisions/20261015T085738Z-3/D029-first-contact-existing-record-access.md",
+    "GLOSSARY.md",
+    "docs/domain-model.md"
+  ],
+  "reply_recorded_at": "2026-10-16T10:18:23Z",
+  "reply_reference": "Joint user reply: ok, next; in response to the three first-round recommendations"
+}
+---
+
+# Context — why ask this?
+
+Patient and Communication Contact are already distinct. The remaining ambiguity is whether an external sender address identifies a unique person; this affects matching, remembered language and representative verification.
+
+## Predecessor decisions
+
+- [D016-booking-for-someone-else](../20261015T085738Z-3/D016-booking-for-someone-else.md)
+- [D019-contact-with-multiple-patient-profiles](../20261015T085738Z-3/D019-contact-with-multiple-patient-profiles.md)
+- [D025-remembered-language-preference-owner](../20261015T085738Z-3/D025-remembered-language-preference-owner.md)
+- [D029-first-contact-existing-record-access](../20261015T085738Z-3/D029-first-contact-existing-record-access.md)
+
+These established requirements are inputs; no outcome of another first-round modeling question is assumed.
+
+## Question
+
+Two parents use the same WhatsApp number to arrange appointments for their child. Should Medora allow separate Communication Contacts to share that contact address, rather than assuming the number identifies one person?
+
+## Recommendation and alternatives
+
+Yes. Model a contact address separately from the person. If the actual speaker is unclear, ask or leave identity unverified; never infer representative authority or a person-specific preference solely from the shared number.
+
+This was the recommendation presented before the joint reply; the acceptance and its limited interpretation are recorded below.
+
+## User reply — original words
+
+Joint reply to the first three modeling recommendations, recorded 2026-10-16T10:18:23Z; original message timestamp unavailable:
+
+> ok, next
+
+## Interpretation
+
+Read as acceptance of the three recommendations just presented and a request to continue. This is a joint acknowledgment, not three separately worded answers. For this decision: Separate Communication Contacts may share a Contact Point. A shared address alone establishes neither the speaker, representative authority nor a person-specific preference; ask or leave identity unverified when uncertain.
+
+No additional policy values, verification method or implementation choices are inferred.
+
+## Decision and rationale
+
+Confirmed within this scenario: Separate Communication Contacts may share a Contact Point. A shared address alone establishes neither the speaker, representative authority nor a person-specific preference; ask or leave identity unverified when uncertain.
+
+The user supplied no separate rationale. The recommendation and its reasoning above are assistant-authored.
+
+## Consequences and affected components
+
+Communication Contact, Patient, Patient Profile. The reply will sharpen terminology and relationships in the glossary/model.
+
+## Assumptions, evidence, and open questions
+
+The joint reply confirms the relationship described above. No database schema, account implementation, global person-matching scheme or automatic verification method is selected. Detailed permissions and independent request-closure policies remain open. No application code exists to cross-check.
+
+## Extra notes and follow-ups
+
+The booking-policy and identity/permissions follow-ups remain open; vocabulary work does not resolve their full scope.
+
+## History
+
+- 2026-10-15T16:38:00Z — Prepared this scenario from the confirmed foundation; user response pending.
+
+- 2026-10-16T10:18:23Z — Saved the joint reply verbatim and recorded its acceptance of the existing recommendation; no additional commitments inferred.