Loyalty Insights – UX Specification

Related Technical Authority: Loyalty Insights – Technical Specification

1. Purpose

This UX specification governs the staff-facing experience for Loyalty Insights, Primoro's intelligence layer for patient loyalty, engagement, and retention. It defines how authorised staff interact with dynamically computed loyalty statuses, explainable AI-generated insight, practitioner-linked cohort views, and structured action handoffs to executing modules. The primary roles it serves are practice staff (any authorised), authorised managerial users, and practice administrators.

2. Core UX Principles (Non-Negotiable)

These principles take precedence over visual preferences. If a design choice conflicts with a principle below, the principle wins.

• Action-first — users see the action they need next, not abstract status displays.
• Governance always visible — when AI is involved, users always know what AI did and what they're confirming.
• No dead toggles — every UI control either does something or doesn't appear.
• Calm by default — the interface gets out of the way; alerts are reserved for things that genuinely need attention.
• Progressive disclosure — advanced detail is one click away, not always-on.
• Explainability is non-negotiable — every loyalty status, flag, or AI suggestion MUST be accompanied by a plain-language explanation of contributing factors. A status shown without explanation is a design failure. Inferred from technical spec §3.2, §5.1, and §7.
• Read-only clarity — surfaces that display insight but do not permit action (e.g. Rewards Manager signal data, practitioner-linked cohort views) are visually distinct from editable or actionable surfaces. Inferred from technical spec §2.2 and §6.3.
• Neutral language in cohort views — no comparative language that implies ranking, competition, or blame. Language MUST frame findings as operational context, not individual performance. Inferred from technical spec §6.3.

3. Design Philosophy

Loyalty Insights is an insight-first, execution-elsewhere module. Its mental model is that of a trusted interpreter: it reads signals across the practice, makes sense of them, and hands a clearly framed recommendation to the person who can act. Inferred from technical spec §1.

Empty states reflect missing optional-module licences or insufficient signal history, never broken integrations. When an optional signal category (e.g. Rewards Manager, Care Plan Subscriptions) is not enabled, the UI communicates this as a configuration choice, not a system failure. Inferred from technical spec §4.2.

Error states distinguish between data-unavailable (graceful degradation — core status still shown) and calculation-failed (explicit, actionable error with support escalation path). Inferred from technical spec §15 Reliability.

AI suggestions (from Aiden) are always visually distinct from computed status outputs and from staff-initiated actions. A suggestion is an offer, not a decision. Staff must explicitly accept, modify, or reject any Aiden suggestion before it can proceed. Inferred from technical spec §7.

Multi-step flows (e.g. initiating an action handoff) use a lightweight confirmation pattern rather than a full wizard, because the insight is already visible on screen and the handoff is a short, purposeful act. Inferred from technical spec §3.3.

Undo/redo is scoped to action handoffs that have not yet been acted upon by the target module. Once a target module has executed, reversal is that module's responsibility and this module's UI reflects that boundary clearly. Inferred from technical spec §3.3.

Practitioner-linked cohort views are read-only, trend-oriented, and contextualised. They are never presented as point-in-time scorecards. The UI reinforces their advisory and non-deterministic nature at the point of display. Inferred from technical spec §6.3.

Configuration surfaces (signal weighting, thresholds) are scoped to Admin users and require MFA. They are separated from insight-consumption surfaces so that analytical users are never accidentally routed into configuration flows. Inferred from technical spec §9 and §14.3.

4. Primary Surfaces

4.1 Web Portal

Who uses it: practice owners, managers, front-of-house staff, and authorised managerial users — primarily for insight consumption, action initiation, and (for admins) configuration. Inferred from technical spec §9.

Key tasks performed here:

• View the practice-level loyalty dashboard — retention trend, recall compliance trend, loyalty status distribution, and churn risk alerts. Inferred from technical spec §6.1.
• Drill down from practice-level metrics to cohort lists and individual patient loyalty panels. Inferred from technical spec §6.1 and §14.4.
• View a patient's current loyalty status, contributing factors, and recommended next actions. Inferred from technical spec §6.2.
• Initiate action handoffs to Recall & Reconnect, Communication Hub, Campaigns / Outreach, or Rewards Manager from a patient or cohort view. Inferred from technical spec §3.3 and §6.2.
• Review and act on AI Aiden suggestions — accept, modify, or reject. Inferred from technical spec §7.
• View practitioner-linked cohort insight (authorised managerial roles only). Inferred from technical spec §6.3.
• View referral effectiveness and reward-impact analytics when Rewards Manager is enabled. Inferred from technical spec §6.4.
• Configure signal weighting, churn alert thresholds, and optional signal category enablement (admin only). Inferred from technical spec §14.3.
• Export audit logs (admin only). Inferred from technical spec §9.

Layout pattern: the primary layout is a dashboard at the practice level, transitioning to a list-detail pattern for cohort drill-down, and a panel embedded within the patient record for patient-level views. Configuration surfaces use a form layout. Inferred from technical spec §6.1, §6.2, and §14.3.

4.2 Tablet App

Who uses it: front-of-house staff and clinical staff who may need to glance at a patient's loyalty status or initiate a handoff from within a patient record during or between appointments. Inferred from technical spec §6.2 and the practice-staff role model.

Key tasks performed here:

• View a patient's current loyalty status and contributing factors from within the patient record. Inferred from technical spec §6.2.
• Initiate an action handoff for a patient directly from the patient loyalty panel. Inferred from technical spec §3.3.
• View churn risk alerts for the practice (read-only, summary level). Inferred from technical spec §6.1.

Touch ergonomics: tap targets ≥48 px; confirmation actions for handoff initiation use large, clearly separated confirm and cancel targets to prevent accidental triggers in a busy front-of-house environment. Inferred from accessibility and clinical-environment conventions implied by the broader Primoro platform context.

4.3 Mobile App (Patient or Staff)

Loyalty Insights is a staff-facing analytical module. There is no patient-facing surface defined or implied by the technical specification. Inferred from technical spec §1 and §2.

Staff mobile access to the practice-level dashboard and patient loyalty panel is a reasonable extension of the web portal, but the technical spec does not explicitly define a mobile surface. This section is flagged as requiring product decision before design begins.

(Needs UX writer input — confirm whether a staff mobile view of the loyalty dashboard and patient panel is in scope for the Post-MVP build, or deferred.)

5. Interaction Model

5.1 Primary Flows

Flow 1 — Practice dashboard to patient handoff

Inferred from technical spec §6.1, §6.2, §3.3, and §14.4.

1. Staff lands on the practice-level loyalty dashboard.
2. Staff reviews overall retention trend, recall compliance trend, status distribution, and churn risk alerts.
3. Staff selects a status segment (e.g. "At-Risk") to drill down to the cohort list for that status.
4. Staff selects an individual patient from the cohort list to open the patient loyalty panel.
5. Staff reviews current status, contributing factors (plain language), and Aiden's recommended next action (if any).
6. Staff chooses to initiate an action handoff (e.g. to Recall & Reconnect).
7. Staff reviews the pre-populated handoff reason and selects the target module.
8. Staff confirms the handoff. A confirmation toast confirms submission. The handoff record is logged.
9. Staff may cancel the handoff at any point before the target module acts.

Practice Dashboard
       │
       ▼
[Filter / select status segment]
       │
       ▼
Cohort List (filtered)
       │
       ▼
Patient Loyalty Panel
       │
  ┌────┴────┐
  │         │
Review    Initiate Handoff
Aiden         │
suggestion    ▼
  │      Handoff Confirmation Modal
  │           │
  │      [Confirm] → Handoff logged → Toast confirmation
  │      [Cancel]  → Return to panel
  │
  ▼
Accept / Modify / Reject Aiden suggestion
       │
       ▼
Disposition logged → (if accepted) Handoff flow or no further action

Flow 2 — Practitioner-linked cohort insight (managerial role)

Inferred from technical spec §6.3.

1. Authorised managerial user navigates to the practitioner-linked cohort insight surface.
2. System enforces role check; unauthorised access is rejected before any data is displayed.
3. User selects a practitioner cohort and a time period (rolling 30 / 90 / 180 / 365 days).
4. Dashboard renders cohort loyalty trends with contextual factors visible alongside metrics.
5. User may drill down to the patient cohort list associated with that practitioner.
6. No ordinal rankings, percentile labels, or league tables are rendered at any drill-down level.
7. User may choose to initiate a handoff or flag for follow-up action from the cohort view.

Flow 3 — Admin configuration of signal weighting

Inferred from technical spec §14.3 and §9.

1. Admin navigates to the Loyalty Insights configuration surface (requires MFA re-authentication).
2. Admin reviews current signal category enablement and weighting settings.
3. Admin adjusts settings within governed bounds.
4. Admin submits changes; a confirmation step summarises the changes and their scope.
5. Change is applied; an audit event is logged with actor, timestamp, and before/after values.

5.2 State Machines (Mirror of Technical Spec §3)

The Patient Loyalty Profile state machine defines four states: Highly Engaged, Stable, At-Risk, Disengaged. Inferred from technical spec §3.2.

No staff user can manually set or override a loyalty status. The UI MUST NOT expose any control that implies this is possible. The current status reflects the system's computed state at all times. Inferred from technical spec §3.2 and §9.

Status transitions are not animated in a way that draws attention — the updated status simply reflects the newly computed value on next view. Transitions are not user-initiated events. Inferred from technical spec §3.2 and the "calm by default" principle.

Action Handoff state machine: Initiated → Pending (awaiting target module execution) → Completed (outcome received) | Cancelled (reversed before target module acted). Inferred from technical spec §3.3.

5.3 Empty / Loading / Error / Offline States

All states below are inferred from technical spec §4.2, §15 Reliability, and §14.2 rule 5.

Practice-level dashboard

• Empty state: Shown when the module has just been activated and no signal data has yet been ingested. Displays a clear explanation that profiles are being built, with an estimated readiness indicator. Not an error. Inferred from technical spec §14.2 rule 1.
• Loading state: Skeleton layout matching the dashboard's metric cards and chart areas. No spinner on the full page.
• Error state: If the dashboard cannot load (e.g. calculation service unavailable), a clear message is shown with a retry action and a support escalation path. Core status data based on Categories 1–3 is shown if available; optional-module data is shown as temporarily unavailable rather than broken. Inferred from technical spec §15 Reliability.
• Offline state: Last-known dashboard state is shown with a prominent "data may be out of date" banner and a timestamp of the last successful load. No handoff initiation is permitted while offline. Inferred from platform-level connectivity constraints.

Patient loyalty panel

• Empty state: Shown when a patient record exists in Primoro Core but insufficient signal history is available for status assignment. Explains which signals are missing and what activity would generate them. Inferred from technical spec §14.2 rule 1.
• Loading state: Inline skeleton within the patient record panel.
• Error state: Inline error message with retry. Does not block the rest of the patient record.
• Offline state: Last-known status shown with staleness indicator.

Optional signal categories (Categories 4–5)

• When a source module (e.g. Rewards Manager) is not licensed or not enabled, the corresponding signal category section is shown as "not enabled" with a plain-language explanation and — where appropriate — a prompt to an admin to enable the integration. It MUST NOT appear empty, broken, or errored. Inferred from technical spec §4.2.

Practitioner-linked cohort insight

• Empty state: Shown when no cohort data meets the selected filter criteria (e.g. no patients associated with the selected practitioner in the selected period). Clear, neutral explanation. Inferred from technical spec §6.3.
• Loading state: Skeleton chart and list.
• Error state: Inline error with retry and support escalation.
• Unauthorised access attempt: Role check failure shows a clear "you do not have permission to view this" message. No data is partially revealed. Inferred from technical spec §9 and §14.2 rule 9.

6. Component Inventory

New components introduced or extended by this module:

• Loyalty status badge — compact, colour-coded badge displaying one of the four loyalty statuses (Highly Engaged / Stable / At-Risk / Disengaged) with an accessible label. Appears on the patient loyalty panel, cohort list rows, and dashboard status-distribution card. Inferred from technical spec §3.1 and §6.2.
• Contributing factors panel — expandable section listing the signals and their relative weight that drove the current loyalty status, in plain language. Appears on the patient loyalty panel and within practitioner-linked cohort drill-down. Inferred from technical spec §3.1, §5.2, and §6.3.
• AI Aiden suggestion card — visually distinct card (e.g. AI badge, differentiated border treatment) presenting a single Aiden suggestion with confidence context, plain-language explanation, and three explicit actions: Accept, Modify, Reject. Appears on the patient loyalty panel and cohort views. Inferred from technical spec §7.
• Action handoff confirmation modal — lightweight modal presenting the pre-populated handoff reason, target module, and initiating context, with Confirm and Cancel actions. Appears when any staff user initiates a handoff. Inferred from technical spec §3.3.
• Signal category availability indicator — inline label or icon indicating whether an optional signal category (Plan, Rewards) is active, not enabled, or temporarily unavailable. Appears within the contributing factors panel and signal filter controls. Inferred from technical spec §4.2.
• Practitioner cohort trend chart — time-series chart showing loyalty outcome trends for a patient cohort over a selectable rolling period, with contextual factor annotations. Explicitly renders no ordinal rankings or percentile labels. Appears in the practitioner-linked cohort insight surface. Inferred from technical spec §6.3.
• Churn risk alert strip — summary alert surface on the practice dashboard highlighting cohorts or segments with elevated churn risk. Links to cohort drill-down. Inferred from technical spec §6.1.

Reused from the design system:

• Data table / list component — used for cohort lists with status, filter, and drill-down. Inferred from technical spec §6.1 and §14.4.
• Filter bar — supporting status, practitioner, time period, and signal category filters. Inferred from technical spec §14.4.
• Skeleton loader — used across dashboard, list, and panel loading states.
• Toast notification — used for handoff confirmation and action feedback. Inferred from technical spec §3.3.
• Confirmation modal (base) — extended by the action handoff confirmation modal above.
• Form components — used in admin configuration surfaces. Inferred from technical spec §14.3.
• In-app banner — used for staleness warnings, optional-module unavailability notices, and offline state. Inferred from technical spec §4.2 and §15.

7. Visual Design Notes

• Typography: heading scale, body scale, and monospace usage to be defined by the platform design system. (Needs UX writer input — confirm type scale application for status badges and contributing-factor labels.)
• Colour: semantic colour usage maps directly to loyalty status — the four statuses (Highly Engaged, Stable, At-Risk, Disengaged) MUST use the design system's positive, neutral, warning, and alert semantic colours respectively. No custom palette. Inferred from technical spec §5.1 and the badge component requirement.
• AI Aiden suggestions MUST be visually distinct from computed status outputs and staff-initiated actions. The distinction is achieved through a dedicated AI badge and a differentiated container treatment (e.g. border style). Inferred from technical spec §7 and governance principle.
• Practitioner-linked cohort charts MUST NOT use colour or labelling conventions that imply ranking (e.g. red/amber/green traffic-light scoring of practitioners). Neutral palette with trend lines only. Inferred from technical spec §6.3.
• Iconography: icon set, sizing, and never icon-only without label — to be defined by the platform design system.
• Motion: transitions are used sparingly. Status badge changes are not animated. Loading skeletons fade in. Motion can be reduced via prefers-reduced-motion.

8. Accessibility & Inclusivity

The module MUST meet WCAG 2.2 AA. Specifically:

• Text contrast ≥4.5:1 (normal) / ≥3:1 (large).
• All interactive controls reachable via keyboard.
• Focus states visible.
• Form fields have programmatic labels.
• ARIA used only where native semantics are insufficient.
• Touch targets ≥44×44 px on mobile/tablet.
• Motion can be reduced via prefers-reduced-motion.
• Screen reader tested on NVDA, VoiceOver, and TalkBack.
• Loyalty status badges MUST carry a text label — never rely on colour alone to convey status meaning. Inferred from the four-state status model and WCAG 1.4.1 (use of colour). Inferred from technical spec §3.2 and §5.1.
• The contributing factors panel, when collapsed, MUST expose its summary to screen readers so that a user navigating by keyboard or assistive technology can understand the status without expanding the panel. Inferred from technical spec §5.2 explainability requirement.
• The AI Aiden suggestion card's three-action group (Accept / Modify / Reject) MUST be navigable as a group with clear focus management, and each action MUST have a programmatic label that includes the context of the suggestion (not just a generic "Accept" button). Inferred from technical spec §7.

9. Internationalisation

• Locale-aware date/time/number formatting — all dates (last calculated, handoff timestamps, trend period labels) and numbers (signal values, cohort sizes) MUST use the user's locale settings.
• All user-facing strings externalised — including plain-language contributing factor descriptions and Aiden suggestion text.
• Layouts tolerant of 30% string-length growth (German, French) — status badge labels, contributing factor titles, and filter labels MUST accommodate longer translated strings without truncation or overflow.
• RTL support: not required for the initial build unless the platform's locale roadmap specifies otherwise. (Needs UX writer input — confirm RTL requirement with platform internationalisation roadmap.)
• Aiden's plain-language suggestion text and contributing factor explanations are generated content; the localisation strategy for AI-generated strings MUST be defined before the build contract is locked. Inferred from technical spec §7 and the explainability requirement in §5.2. (Needs UX writer input — define localisation approach for AI-generated plain-language content.)

10. Cross-Module UX Touchpoints

All touchpoints below are inferred from the integration contracts in technical spec §10 and §11.

• Primoro Core — The patient loyalty panel is embedded within or directly accessible from the patient record in Primoro Core. Navigation between the patient record and the loyalty panel MUST feel seamless; the loyalty panel is a contextual layer on the patient record, not a separate application. Inferred from technical spec §6.2 and §11.1.
• Recall & Reconnect — Staff initiates a handoff to Recall & Reconnect from the patient loyalty panel or cohort view. The handoff passes a pre-populated reason derived from the contributing factors. Outcome feedback from Recall & Reconnect is displayed on the handoff record in Loyalty Insights. Inferred from technical spec §3.3 and §11.2.
• Communication Hub — Handoff to Communication Hub for engagement-driven outreach follows the same UX pattern as the Recall & Reconnect handoff. Staff review the pre-populated outreach trigger reason before confirming. Inferred from technical spec §3.3 and §11.2.
• Campaigns / Outreach — Cohort-level handoffs to Campaigns / Outreach are initiated from the cohort list view. The cohort filter criteria are included in the handoff payload and summarised in the confirmation modal. Inferred from technical spec §3.3 and §11.2.
• Rewards Manager — Signal data from Rewards Manager (points, referrals, donations) is consumed read-only and displayed within contributing factors and the referral/rewards insight surface. No Rewards Manager write operations are available from within Loyalty Insights. If Rewards Manager is not enabled, its signal sections are shown as "not enabled." Inferred from technical spec §6.4, §11.4, and §4.2.
• Care Plan Subscriptions / Hygiene Subscriptions — Plan longevity and cancellation risk signals are displayed within the contributing factors panel when these modules are enabled. If not enabled, the signal category is shown as "not enabled" rather than absent or errored. Inferred from technical spec §4.1 and §4.2.
• AI Assistant (Aiden) — Aiden suggestions appear inline on the patient loyalty panel and in cohort views. They are visually distinct (AI badge, differentiated container). Staff disposition (accept / modify / reject) is captured before any action proceeds. The suggestion card is a standard, reusable component across all surfaces where Aiden is embedded. Inferred from technical spec §7.
• Access Manager — Role enforcement is invisible to staff in the happy path — they simply do not see controls or surfaces they are not permitted to use. Unauthorised access attempts (e.g. direct URL to practitioner cohort view) show a clear permission-denied state, not a blank page or error. Inferred from technical spec §9.
• Audit & Compliance — Staff do not interact with Audit & Compliance directly from within Loyalty Insights except via the admin audit log export function. The UI does not expose the raw audit log; it exposes a filtered export action. Inferred from technical spec §8 and §9.
• Performance Dashboards — Loyalty Insights may surface aggregated loyalty trend data to Performance Dashboards. The UX handoff is one-directional from this module's perspective — staff navigating to broader performance views are directed to Performance Dashboards, which owns that surface. Inferred from technical spec §10.

UX consistency rules:

• Action handoff confirmation always uses the same modal pattern regardless of the target module. The modal always shows: patient (or cohort) context, target module name, handoff reason, and two actions (Confirm, Cancel). Inferred from technical spec §3.3.
• Aiden suggestion cards follow the same visual pattern and three-action structure (Accept / Modify / Reject) wherever they appear. Inferred from technical spec §7.
• "Not enabled" treatment for optional signal categories uses the same component and language pattern wherever it appears (contributing factors panel, referral/rewards insight surface, signal filter controls). Inferred from technical spec §4.2.
• Drill-down navigation (practice dashboard → cohort list → patient panel) uses a consistent breadcrumb or back-navigation pattern so that staff can always return to their previous context without losing filter state. Inferred from technical spec §14.4.

11. Governance & Auditability

• AI Aiden suggestions are visually distinct from computed loyalty statuses and from staff-initiated actions at all times — they carry an AI badge and a differentiated container treatment. A suggestion is never presented as a confirmed fact or a system decision. Inferred from technical spec §7.
• Every Aiden suggestion card displays the plain-language suggestion, the confidence context, and the three disposition actions. Staff must record a disposition (accept / modify / reject) before the suggestion can influence any downstream action. The UI enforces this sequencing. Inferred from technical spec §7 and §14.2 rule 7.
• All audit-significant actions visible in the UI — handoff initiation, Aiden suggestion disposition, admin configuration changes — show an explicit confirmation step. The confirmation step summarises what will be recorded. Inferred from technical spec §8.
• The practitioner-linked cohort insight surface displays a persistent, plain-language notice explaining the permitted purpose of these views and the governance constraints (support and coaching only; not for disciplinary or remuneration use). This notice is not dismissible. Inferred from technical spec §6.3.
• Admin configuration surfaces require MFA re-authentication before changes can be submitted. The UI communicates this requirement before the user begins making changes, not after. Inferred from technical spec §9.
• Read-only surfaces (Rewards Manager signal data, practitioner cohort views) are visually distinct from editable or actionable surfaces — they carry a clear read-only indicator and do not render controls that imply editability. Inferred from technical spec §11.4 and §6.3.
• The current user's role context is visible in the header or navigation so that staff always know which capabilities are available to them in the current session. Inferred from technical spec §9.

12. Notification & Communication Patterns

All patterns below are inferred from technical spec §6.1 (churn risk alerts), §3.3 (handoff outcomes), §7 (AI suggestion events), and §8 (audit events), combined with the platform's Communication Hub integration pattern.

• In-app banner — used for: (a) optional signal category unavailability (e.g. "Rewards Manager signals are not enabled — only core signals are shown"); (b) data-staleness warnings when the user is viewing a dashboard that could not be refreshed (offline or degraded state); (c) post-activation "profiles are being built" notice on the dashboard. Inferred from technical spec §4.2 and §15 Reliability.
• Toast — used for: (a) successful handoff submission; (b) successful Aiden suggestion disposition (accept or reject); (c) successful admin configuration save. Toasts are brief, non-blocking, and do not require staff acknowledgement. Inferred from technical spec §3.3 and §7.
• In-app alert / churn risk alert strip — used on the practice-level dashboard to surface elevated churn risk for patient segments. This is a persistent, scannable alert surface (not a toast) because it requires staff attention and links to actionable drill-down. Inferred from technical spec §6.1.
• Push notification — if the platform supports push delivery of churn risk alerts or handoff outcome notifications to staff, these MUST be delivered via Communication Hub and NOT emitted directly by Loyalty Insights. Inferred from technical spec §10 and the Communication Hub integration boundary.
• Email / SMS — any email or SMS notification related to loyalty insight events (e.g. weekly loyalty summary for managers) MUST be delivered via Communication Hub. Loyalty Insights emits the trigger event; Communication Hub owns the delivery. Inferred from technical spec §10 and §11.2.

13. Open Questions

The following UX decisions must be resolved before this spec is promoted from draft to published.

1. Numerical score display policy — the technical spec prohibits showing a raw numerical score without context, but does not decide whether numerical scores are ever shown. The UX spec cannot define score-display components until this is decided. Corresponds to technical spec Open Question 6.
2. Staff mobile surface scope — is a staff mobile view of the loyalty dashboard and patient panel in scope for this build? Section 4.3 is currently a placeholder. Inferred gap from technical spec, which does not define a mobile surface.
3. AI confidence threshold and suppression — at what confidence level does Aiden surface a suggestion? Is there a configurable threshold below which suggestions are not shown? This affects the design of the Aiden suggestion card (e.g. whether a confidence indicator is shown, and how low-confidence states are handled). Corresponds to technical spec Open Question 3.
4. Practitioner-linked cohort insight — default activation state — is this surface enabled by default for all practices at activation, or must an admin explicitly enable it? This determines whether the surface needs an "enable this feature" onboarding state. Corresponds to technical spec Open Question 4.
5. Handoff reversibility — UI mechanism and time window — how does staff cancel a pending handoff? Is there a time-limited cancel action on the handoff record, or a dedicated cancellation flow? The technical spec states handoffs must be reversible prior to target module execution but does not define the UI pattern or window. Corresponds to technical spec Open Question 5.
6. Data retention and profile deletion UX — when a patient is archived or deleted from Primoro Core, what does the loyalty panel show? Is there a deletion-in-progress state? This affects empty/error state design for the patient panel. Corresponds to technical spec Open Question 1.
7. Localisation of AI-generated plain-language content — Aiden's contributing factor explanations and suggestion text are generated content. The strategy for translating or localising these strings must be defined before internationalisation design can be completed. See §9.
8. (Needs UX writer input — microcopy for all confirmation modals, toast messages, plain-language governance notice on practitioner cohort views, and "not enabled" state labels for optional signal categories.)
9. (Needs UX writer input — neutral language glossary for practitioner-linked cohort insight surface, aligned with technical spec §6.3 language constraints.)