← AI Assistant (Aiden)
AI Assistant (Aiden)
Editing ux
v0.2 — draft
Save draft
Promote to published
✕ Discard draft
Tab to switch the tab. Save writes a vNEW-DRAFT.md alongside the published file.
Markdown source
# AI Assistant (Aiden) – UX Specification Related Technical Authority: AI Assistant (Aiden) – Technical Specification ## 1. Purpose This UX specification governs the experience of Aiden — Primoro's embedded AI guidance layer — across all surfaces where it appears: the patient mobile app, the staff tablet app, the web portal, the website chat widget, and (when enabled) the AI phone assistant. It defines how Aiden presents guidance, surfaces actions, communicates its own involvement, escalates to humans, and stays within its clinical and governance boundaries. The primary roles it serves are patients managing their own care journey and staff seeking operational clarity and guided next actions. ## 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 - **Human always in control** — Aiden never executes a consequential action without explicit human confirmation; every suggested action is a proposal, not a decision. Inferred from the technical spec's non-negotiable human-controlled AI requirement in §4.3 and §7. - **AI involvement always declared** — wherever Aiden has contributed to a presented action or piece of guidance, that involvement is visually marked; there is no silent AI. Inferred from the mandatory `ai_involved` flag on every AuditEvent defined in §3.5 and §8. - **Clinical safety never negotiable** — any symptom-based or clinical prompt results in the safe fallback response and a prompt to contact the practice; there is no design variation that changes this behaviour. Inferred from the non-negotiable clinical safety rules in §4.5 and §7. - **Modular presence** — Aiden only surfaces capabilities that correspond to enabled modules for the active practice; a surface with no relevant guidance available MAY be suppressed entirely. Inferred from the modular enablement governance in §4.2 and §13.2. - **Patients, not clients** — all AI-generated suggestions, guidance items, and user-facing copy produced or surfaced by Aiden must refer to the people receiving care as "patients", never "clients" or any other term. This is a non-negotiable domain terminology standard, consistent with the equivalent principle established in Communication Hub, and applies across every surface Aiden appears on: web portal, tablet, mobile app, website chat widget, and AI phone assistant. Copy that violates this convention must be corrected before a surface is promoted from draft to published. Inferred from the Communication Hub non-negotiable UX standard and the need for coherent healthcare domain language across all AI-surfaced copy. ## 3. Design Philosophy Aiden's mental model is that of a knowledgeable, calm colleague standing just behind the user's shoulder — present when helpful, silent when not needed. Inferred from the technical spec's framing in §1: "calm, action-first intelligence layer… guides patients and supports staff without replacing human judgement." **Empty states:** When Aiden has no relevant guidance for the current screen and context, the Aiden surface should be suppressed rather than showing a placeholder. Showing an empty AI panel creates noise. Inferred from §4.2: "Aiden MAY suppress the Aiden surface entirely when no clarity or guidance value is offered in the current context." **Error states:** When an upstream module API is unavailable, Aiden must not present stale or incorrect data. The degraded state is a calm, honest message indicating that guidance is temporarily unavailable, with a prompt to contact the practice or a human staff member where appropriate. Inferred from §14 reliability requirements. *(needs UX writer input — exact wording for the degraded/unavailable state message)* **AI suggestions:** Every suggestion Aiden surfaces is visually distinguished from user-initiated controls — it carries an AI badge or equivalent visual treatment so users understand its provenance. Suggestions are proposals; the confirmation step is always user-initiated. This principle is shared across all AI-enabled modules on the platform: Task Manager, Campaign Manager, Rewards Manager, AI Concierge, AI Guardian, and others each independently mandate that AI-surfaced suggestions are visually distinct, never pre-selected, and never self-confirming. Aiden's visual and interaction treatment for AI suggestions must therefore be consistent with the platform-wide convention these modules establish. Inferred from §4.3 and §11 governance requirements, and aligned with the equivalent non-negotiable principles in Task Manager §2, Campaign Manager §2–§3, AI Concierge §2, and AI Guardian UX spec. **Multi-step flows:** For actions that require confirmation (all non-navigational actions), a clear confirmation step is interposed before the action is dispatched to the relevant module. The confirmation step summarises what will happen and who will be affected. Inferred from `RequiresConfirmation: true` on all non-navigational AIAction objects per §3.3 and §13.2. **Undo/redo:** Aiden does not own the underlying data of any action it suggests; undo/redo behaviour belongs to the target module (e.g. Appointment Manager, Digital Forms). Aiden's role ends once the confirmed action has been handed to the target module. Inferred from §2.2 ownership boundaries. **Read-only vs editable surfaces:** Aiden's guidance panel is always read-only from Aiden's perspective — it surfaces and explains; it does not own editable fields. Editable interaction happens in the target module's own surface, which Aiden may deep-link the user to. Inferred from the action-first principle in §4.1. **Escalation stance:** Escalation is presented to the user as a positive handoff — "here's what I can help with" — rather than a failure message. The default fallback wording defined in the technical spec sets this tone. Inferred from §4.6: "I can't do that directly, but here's what I can help with…" *(needs UX writer input — full escalation message copy and tone variants)* ## 4. Primary Surfaces ### 4.1 Web Portal Who uses it: clinical staff, administrative staff, practice managers, and governance/admin users. Inferred from §5.1 which describes "role-aware how-to guidance, operational clarity, suggested next actions during patient conversations, and internal Q&A using practice-approved knowledge" in the staff web portal. Key tasks performed here: - Receiving role-aware operational guidance ("what's due / missing") drawn from the CORE calendar. Inferred from §5.1 and §4.2. - Reviewing and acting on at-risk or overdue work surfaced from Smart Dashboards alert signals. Inferred from §4.4 and §5.1. - Confirming or dismissing AI-suggested next actions during patient conversations. Inferred from §5.1: "suggested next actions during patient conversations." - Asking internal Q&A questions answered from the practice-approved knowledge base. Inferred from §5.1 and §6.1. - Reviewing engagement signals and escalation telemetry (governance/admin role). Inferred from §5.6 and §13.4. - Configuring enabled channels, intent types, escalation threshold, knowledge sources, and tone variants at practice level (admin role). Inferred from §13.3 practice-level configuration surfaces. Layout pattern: split-pane. Aiden appears as a persistent or collapsible panel alongside the primary working surface, so staff can receive guidance in context without leaving their current task. Inferred from the screen-aware and action-first principles in §4.1 and §4.2, which imply Aiden must be present in context without displacing the primary workflow. ### 4.2 Tablet App Who uses it: clinical staff and front-of-house staff working in practice, using the Staff App Mode on the in-practice tablet. Inferred from §5.2. Key tasks performed here: - Receiving role-aware guidance equivalent to the web portal surface — what is due, at risk, or missing for the current context. Inferred from §5.2: "equivalent capabilities to the web portal: role-aware guidance, at-risk work surfacing, and suggested next actions." - Confirming or dismissing AI-suggested next actions during in-practice patient encounters. Inferred from §5.2. - Asking internal Q&A questions from the practice-approved knowledge base while working chairside or at reception. Inferred from §4.4 and §6.1. Touch ergonomics: tap targets must be ≥ 48 px to accommodate glove-friendly or single-handed use. The Aiden panel must be reachable without occluding the primary content the staff member is working with. Confirmation actions for AI-suggested steps must be prominent enough to be triggered deliberately and not accidentally. Inferred from the confirmation-required rule in §4.3 and general in-practice use context described in §5.2. ### 4.3 Mobile App (Patient) Who uses it: patients managing their own care journey from their personal mobile device. Inferred from §5.3. Key tasks performed here: - Viewing, booking, rescheduling, or cancelling appointments within practice rules, guided by Aiden. Inferred from §5.3. - Understanding appointment types and preparation instructions in plain English. Inferred from §5.3. - Receiving plain-English explanation of treatment plans and bundled pricing (non-clinical). Inferred from §5.3. - Being prompted to complete missing forms or acknowledgements, and launching them directly. Inferred from §5.3: "Highlighting missing forms or actions and launching completion." - Viewing current balances and available payment options (when Integrated Payments is enabled). Inferred from §5.3. - Asking approved FAQs and receiving aftercare guidance (non-diagnostic). Inferred from §5.3. Aiden's patient-facing surface must support conversational, plain-English interaction. Actions are surfaced as tappable controls (buttons, deep-links) wherever supported, never as free-text descriptions of steps to take manually. Inferred from the action-first non-negotiable in §4.1. ### 4.4 Website Chat (When Treatment Pipeline Is Enabled) Who uses it: prospective patients or website visitors enquiring about treatments before becoming active patients. Inferred from §5.4. Key tasks performed here: - Asking pre-treatment FAQs and receiving answers from the approved knowledge base. Inferred from §5.4. - Submitting enquiry details that result in a Lead record being created (one Lead per intake interaction). Inferred from §5.4 and the Treatment Pipeline constraints therein. - Requesting a callback, which is backed by a calendar entry. Inferred from §5.4: "creates lead callbacks (calendar-backed)." - Booking an appointment only where `BookingEligibility` has already been explicitly set by an authorised staff member. Inferred from §5.4 Treatment Pipeline constraints. This surface is intake and signposting only. The UI must clearly communicate that the chat cannot book appointments unless eligibility has been confirmed by the practice, and must not imply that Aiden can advance a patient's treatment journey autonomously. Inferred from §5.4 and §7 AI MAY NOT items. ### 4.5 AI Phone Assistant (When Enabled) Who uses it: patients calling the practice, handled by Aiden as a voice receptionist. Inferred from §5.5. Voice is treated as an interface, not a separate logic layer — the same AIContext, AIIntent, AIAction, EscalationEvent, and AuditEvent contracts apply. UX considerations specific to this surface (voice interaction design, IVR-style menus vs conversational voice) are owned by the AI Phone Assistant module; Aiden provides the logic layer. Inferred from §5.5: "Voice is an interface, not a different logic layer." *(needs UX writer input — voice interaction patterns, hold/transfer language, and escalation handoff script are owned by the AI Phone Assistant module UX spec)* ## 5. Interaction Model ### 5.1 Primary Flows #### Patient — guided appointment reschedule The following flow is inferred from §4.1 (action-first), §4.3 (human-controlled AI), §5.3 (Patient App capabilities), and §3.6 (AIIntent / AIAction state machine). Aiden's reschedule suggestion must respect Appointment Manager's constraint model. Before the confirmation step is shown, Aiden surfaces the available slots together with any relevant constraint context (practitioner availability, booking blocks, practice rules) so the patient can make an informed selection. This reflects Appointment Manager's principle that AI suggestions are advisory and must be contextualised, not presented as the only possible outcome. Inferred from Appointment Manager UX §2. ``` Patient opens Patient App │ ▼ Aiden resolves AIContext (UserId, Channel=PatientApp, ScreenContext, EnabledModules) │ ▼ Aiden detects upcoming appointment in CORE calendar │ ▼ Aiden surfaces contextual prompt: "You have an appointment on [date] — would you like to reschedule?" [State: Pending] │ ┌────┴────┐ User taps User dismisses "Reschedule" prompt │ │ ▼ ▼ Aiden surfaces [State: Abandoned] available slots AuditEvent emitted from Appointment Manager (with constraint context: availability, blocks, practitioner absence shown) [State: Presented] │ User selects slot │ ▼ Confirmation step shown — summarises new date/time [RequiresConfirmation: true] │ ├── User confirms ──► Booking intent emitted to Appointment Manager │ [State: Confirmed] │ AuditEvent emitted (ai_involved: true) │ └── User cancels ──► [State: Abandoned] AuditEvent emitted ``` #### Patient — missing form prompt Inferred from §4.1, §5.3, and §6.1 (Digital Forms integration). Aiden detects incomplete forms via the Digital Forms API and surfaces a direct prompt. Aiden does not own or replicate the form completion experience — it initiates the deep-link handoff to the Digital Forms surface and does not re-prompt for a form that is already open or in progress. Where Digital Forms has itself assigned a form via an AI-suggested assignment (per Digital Forms §4.4), Aiden's prompt must not create a duplicate journey; Aiden checks form status before surfacing the prompt and suppresses it if the form is already in progress. Inferred from Digital Forms §4.4 and the ownership boundary in §2.2 of the technical spec. ``` Patient opens Patient App (any screen) │ ▼ Aiden detects incomplete form via Digital Forms API (suppressed if form already in progress) │ ▼ Aiden surfaces prompt: "Your [form name] is due — I can open it for you" [State: Pending] │ ┌────┴────┐ User taps User dismisses "Open form" prompt │ │ ▼ ▼ Deep-link to [State: Abandoned] Digital Forms AuditEvent emitted form surface [State: Confirmed — navigational, no separate confirmation step] AuditEvent emitted (ai_involved: true) ``` #### Staff — at-risk work surfacing Inferred from §4.4 (Smart Dashboards signal handling), §5.1 (web portal), and §5.2 (tablet). Aiden's at-risk work surfacing follows the same governance requirements that Task Manager defines for AI-surfaced suggestions: suggestions must be visually distinct from confirmed tasks, must carry an AI badge, and must never be self-confirming. A suggestion from Aiden that corresponds to a Task Manager action must be treated as advisory — staff must independently act on it in Task Manager; Aiden does not create or confirm tasks on the staff member's behalf. Inferred from Task Manager §2 non-negotiable principles. ``` Staff member opens a patient record or dashboard view │ ▼ Aiden receives Smart Dashboards alert signal (Attention or Overdue) │ ▼ Aiden surfaces contextual signal with status exactly as assigned: • Attention → prompt (moderate visual weight) • Overdue → prioritised, visible call to action (higher visual weight) [State: Pending] │ Staff reviews signal │ ┌────┴────┐ Staff acts Staff dismisses on suggestion or defers │ │ ▼ ▼ Confirmation [State: Abandoned] step shown AuditEvent emitted [State: Presented] │ Staff confirms │ ▼ Action dispatched to target module [State: Confirmed] AuditEvent emitted (ai_involved: true) ``` #### Staff — HR and coverage-risk advisory Inferred from HR & People Manager spec and §5.2 (tablet / staff app mode). When the HR & People Manager module is enabled, Aiden may surface plain-language coverage risk explanations and leave approval guidance to authorised staff. These suggestions appear as a distinct advisory panel within the Aiden surface — clearly separate from user-initiated HR controls — and carry the AI badge. Coverage risk explanations are advisory only: the staff member must take any consequential leave or rota action independently in HR & People Manager or Rota Manager. Aiden does not commit, approve, or modify any rota or leave state. Inferred from HR & People Manager spec ("AI as advisor, never as actor") and Rota Manager UX principle ("AI is advisory, never decisive"). The advisory panel is dismissible. Dismissal is logged as an AuditEvent (`ai_involved: true`). If the staff member re-opens the relevant record, Aiden resolves a fresh AIContext and may re-surface the advisory where the risk condition still applies. When Aiden surfaces a coverage-gap suggestion linked to staff availability patterns in Rota Manager, the suggestion must explicitly note that it is based on rota data and must not imply that any rota change has been pre-committed. Inferred from Rota Manager UX: "AI suggestions about availability or coverage gaps appear in a distinct advisory panel and require explicit approval before affecting rota state." #### Staff — AI-recommended Treatment Pipeline stage transition Inferred from Treatment Pipeline Manager UX §2 and §5.4 of this spec. When Aiden recommends a pipeline stage transition to a staff member (e.g. advancing a lead from enquiry to opportunity), the recommendation is surfaced as an AI suggestion card with the AI badge and a mandatory confirmation step. The stage transition is never executed autonomously. The confirmation step summarises the proposed new stage, the patient or lead it affects, and the module that will action the change. Staff must explicitly confirm before the intent is dispatched to Treatment Pipeline Manager. Inferred from Treatment Pipeline Manager UX §2: "AI-recommended stage transitions must never execute autonomously." ``` Staff reviews a patient or lead record │ ▼ Aiden surfaces: "Based on recent activity, this lead may be ready to advance to [Stage]" [AI badge present; State: Pending] │ ┌────┴────┐ Staff reviews Staff dismisses suggestion suggestion │ │ ▼ ▼ Confirmation [State: Abandoned] step shown: AuditEvent emitted "Advance [Lead] to [Stage]?" [RequiresConfirmation: true; State: Presented] │ Staff confirms │ ▼ Stage transition intent dispatched to Treatment Pipeline Manager [State: Confirmed] AuditEvent emitted (ai_involved: true) ``` #### Staff — Campaign Manager content suggestions Inferred from Campaign Manager §2–§3. When Aiden surfaces suggestions for campaign templates, audience segments, or optimisation recommendations within a Campaign Manager workflow, those suggestions are advisory, carry the AI badge, and remain in `Draft` state until a human explicitly reviews and approves them. Aiden does not activate campaigns, select audiences, or pre-fill confirmed settings. The confirmation pattern mirrors the standard AI suggestion card flow. Inferred from Campaign Manager §2: "Aiden suggestions are advisory, badged, and never pre-selected; they remain in Draft state until human review." #### Staff — Smart Treatment Proposals content suggestions Inferred from Smart Treatment Proposals (STP) technical spec §8.2 and §9.4, and STP UX §3. Where Aiden suggests FAQ blocks or contributes to AI Quality Monitor draft proposals within the Smart Treatment Proposals surface, those suggestions are never final and are never surfaced to patients without explicit human approval. Aiden's suggestion card for proposal-related content must carry the AI badge and must clearly indicate the approval state (e.g. "Draft — awaiting review"). Aiden must not auto-surface or pre-approve proposal-related suggestions. Inferred from STP UX §3: "all AI suggestions must be marked and require human approval before surfacing to patients." #### Staff — Rewards and referral insight suggestions Inferred from Rewards Manager UX §3 and §4.3. When Aiden is enabled to surface rewards-related or referral insights to staff (e.g. a referral nudge for a patient), those insights are presented as suggestions requiring human review, never as completed actions. Aiden must not auto-execute any rewards transaction, earn, or deduction. The suggestion card carries the AI badge and a mandatory confirmation step before any downstream intent is emitted. Inferred from Rewards Manager UX §3: "every AI-surfaced insight on the staff dashboard is presented as a suggestion requiring human review, never as a completed action." #### Escalation flow (all surfaces) Inferred from §4.6, §3.4, §3.6, and §13.2 rule 4. ``` User input received │ ▼ Aiden evaluates: • Action not supported in-app? AND • Question not answerable from approved data? AND • (User asks for human OR ConfidenceScore < threshold)? │ YES │ ▼ Aiden presents fallback guidance: "I can't do that directly, but here's what I can help with…" [State: Escalated — MUST NOT revert to Pending or Presented] │ ▼ EscalationEvent emitted + AuditEvent emitted (ai_involved: true) │ ▼ Communication Hub receives escalation trigger for human follow-up ``` #### Clinical safety fallback (all surfaces) Inferred from §4.5 and §13.2 rule 5. ``` User input contains symptom-based or clinical content │ ▼ Aiden triggers mandatory safe fallback response: "I can't assess symptoms, but if you're worried or in pain it's best to contact the practice." │ ▼ AuditEvent emitted (ai_involved: true) │ ▼ No further AI guidance on clinical content is presented ``` ### 5.2 State Machines (Mirror of Technical Spec § 3.6) The following treatments mirror the AIIntent / AIAction state machine defined in §3.6 of the technical spec. | State | Entry condition visible to user | Visual treatment | Confirmation pattern | |---|---|---|---| | `Pending` | Intent resolved; Aiden has surfaced a prompt or action | AI badge present; suggestion styled distinctly from user-initiated controls (e.g. outlined/bordered with AI indicator) | None yet — user has not engaged | | `Presented` | User has engaged with the suggestion; available options shown | Action controls (buttons, deep-links) displayed; AI badge retained on the suggestion origin | Confirmation step not yet shown — user selects an option | | `Confirmed` | User has explicitly tapped/clicked the confirm action | Confirmation step shown before dispatch; success feedback after dispatch (toast) | `RequiresConfirmation: true` for all non-navigational actions; purely navigational actions (open a screen) do not require a confirmation step | | `Escalated` | Confidence threshold not met, action unsupported, or user requested human | Calm informational message with fallback options; no error styling | No confirmation required — escalation is presented as a helpful handoff | | `Abandoned` | User exited or dismissed without completing | No persistent UI residue — surface returns to its idle or suppressed state | None | Rules reflected in the UI: - An `Escalated` state must never visually revert to `Pending` or `Presented` — if the user re-engages, a fresh AIContext is resolved. Inferred from §3.6: "Once Escalated, an intent MUST NOT revert to Pending or Presented." - Every state transition produces an AuditEvent; the UI does not need to surface this to the user, but governance users can inspect it via the Audit & Compliance module. Inferred from §3.6 and §8. - Irreversible transitions (Confirmed actions dispatched to target modules) must be preceded by a confirmation step that clearly summarises what will happen. Inferred from §4.3 and §3.3 `RequiresConfirmation`. ### 5.3 Aiden Suggestions Within Communication Hub Threads Inferred from Communication Hub UX §3 and §6.2 of this spec. When Aiden detects a relevant intent within a Communication Hub thread (e.g. a patient message that implies an appointment request or a form submission), Aiden MAY surface an inline suggestion directly within the thread view. The suggestion is rendered as a visually distinct inline prompt — separate from the thread messages themselves — and carries the AI badge. Staff can act on, dismiss, or ignore the suggestion without leaving the thread context. Rules for this surface: - The inline suggestion must not be styled as a message bubble or as staff-authored content — it must be visually distinct from thread content. Inferred from Communication Hub UX §3. - **Typing indicator continuity:** When an inline suggestion prompt appears mid-composition — i.e. while a staff member is actively typing a reply — the typing indicator for that thread participant MUST remain active and must not be cleared or interrupted by the appearance of the suggestion UI. The suggestion is rendered in a dedicated inline slot that does not overlap or displace the composer area, so the staff member's in-progress input and the thread's typing indicator state are both preserved. This ensures that other thread participants see no visual disruption as a consequence of Aiden surfacing a suggestion. Inferred from Communication Hub technical spec (§ Integration with Message-to-Work Conversion): "TypingIndicator remains active during AI suggestion prompts and user decision." - Dismissal of an inline suggestion is logged as an AuditEvent (`ai_involved: true`). Inferred from §8. - If the suggestion is acted upon, the standard confirmation step is interposed before the intent is dispatched to the target module. Inferred from `RequiresConfirmation: true` for all non-navigational actions. - Aiden does not read, store, or process message content beyond the resolved AIContext for the current thread session. Message ownership and routing remain with Communication Hub. Inferred from §2.2 ownership boundaries. ### 5.4 Smart Dashboards Boundary Clarification Inferred from Smart Dashboards spec §3 and §7, and §4.4 of this spec. Aiden does not surface AI suggestions directly on the Smart Dashboards card layer. The Smart Dashboards module, in its current build, does not embed AI within its dashboard surface — AI signals from a future AI Guardian module will arrive as AlertSignals in a future release, at which point this boundary will be revisited. Until then, Aiden's interaction with Smart Dashboards is strictly one-directional: Smart Dashboards emits `Attention` and `Overdue` signals that Aiden consumes and surfaces within its own panel, contextualised to the staff member's current task. Aiden does not inject UI elements into the Smart Dashboards card layer itself. Inferred from Smart Dashboards §7: "In the current build, AI is not embedded in the dashboard surface." When Aiden surfaces a Smart Dashboards-originated signal, it must include a provenance label indicating the signal's origin (Smart Dashboards), consistent with the platform-wide requirement that AI-origin and data-source labels accompany metrics wherever they appear. Inferred from Performance Dashboards spec §2: "metrics originating from AI Concierge MUST be presented with a clear provenance label" — Aiden adopts the same transparency convention for signals it surfaces from Smart Dashboards. ### 5.5 Empty / Loading / Error / Offline States The following requirements apply to every screen or panel where Aiden appears. Inferred from the screen-aware guidance rules in §4.2 and reliability requirements in §14. **Empty state:** When Aiden has resolved an AIContext but has no relevant guidance, suggestion, or signal for the current screen, the Aiden panel or surface is suppressed entirely. There is no "Aiden has nothing to say" placeholder shown to the user. Inferred from §4.2: "Aiden MAY suppress the Aiden surface entirely when no clarity or guidance value is offered." **Loading state:** While Aiden is resolving an AIContext or awaiting an upstream API response, a minimal skeleton or subtle loading indicator should be shown within the Aiden panel area, so the user is not presented with an empty space without explanation. The loading state must not block interaction with the primary surface. Inferred from the non-blocking API call requirement in §14 and the action-first principle. **Error state:** When an upstream module API is unavailable, Aiden degrades gracefully — it presents a calm, honest message that guidance is temporarily unavailable, and where relevant prompts the user to contact the practice directly. It does not surface stale or cached guidance that may be incorrect. Inferred from §14: "Aiden MUST degrade gracefully on upstream API failure… Safe fallback to human workflows is the default degraded state." *(needs UX writer input — exact wording for the degraded state message on each surface)* **Offline state:** In an offline state, Aiden cannot resolve a fresh AIContext and must not present guidance. The Aiden surface should indicate that AI guidance is unavailable offline, and direct the user to the relevant in-app functionality directly where possible. Inferred from §14 reliability and §13.2 rule 1: "no guidance may be presented without a resolved context." *(needs UX writer input — offline state message copy)* ## 6. Component Inventory New components introduced or extended by this module: - **Aiden panel** — the collapsible or persistent side-panel (web/tablet) or inline card (mobile) housing Aiden's guidance, suggestions, and conversational interface. Appears on all enabled surfaces. Inferred from §5.1, §5.2, §5.3. - **AI suggestion card** — a visually distinct card component for a surfaced AIAction or guidance item; carries an AI badge, the suggested action or message, and (where `RequiresConfirmation: true`) a confirm/dismiss control pair. Inferred from §4.3 and §3.3. - **AI confirmation step** — an interstitial or inline confirmation component that appears before a non-navigational AIAction is dispatched; summarises what will happen and to whom. Inferred from §4.3 and the `RequiresConfirmation` rule in §13.2. - **Escalation handoff message** — a styled message component presenting the fallback copy and any available human-contact or in-app alternative actions when Aiden escalates. Inferred from §4.6. - **Clinical safety message** — a non-dismissible inline message component presenting the mandated safe fallback wording on any symptom-based prompt. Inferred from §4.5 and §13.2 rule 5. - **Smart Dashboards signal indicator** — a visual badge or label attached to at-risk items surfaced by Aiden, carrying the status value (`OnTrack` / `Attention` / `Overdue`) exactly as assigned by Smart Dashboards. Inferred from §4.4. - **AI badge / AI involvement indicator** — a persistent, accessible label applied to any AI-originated suggestion or guidance item, ensuring the user always knows AI was involved. Inferred from §3.5 `ai_involved` flag and the governance-always-visible principle. - **Website chat widget** — the embedded chat interface on the practice website through which Aiden handles pre-treatment enquiries, FAQ responses, and lead intake. Inferred from §5.4. - **Inline thread suggestion** — a visually distinct inline prompt component used within Communication Hub threads to surface Aiden's intent-detection suggestions without interrupting the thread flow. Rendered in a dedicated slot that does not overlap the composer area, preserving the typing indicator state and the staff member's in-progress input. Inferred from Communication Hub UX §3 and §5.3 of this spec. - **Advisory panel** — a distinct, dismissible panel variant used for purely advisory outputs (e.g. HR coverage risk explanations, Rota Manager availability context) where no confirmable action is available; the panel carries the AI badge and dismissal logs an AuditEvent. Inferred from HR & People Manager spec and Rota Manager UX. Reused from the design system: - Toast notification — for post-confirmation success feedback (e.g. appointment rescheduled). Inferred from §5.1 confirmation patterns. - In-app banner — for persistent or time-sensitive signals (e.g. overdue item requiring attention). Inferred from §4.4 Overdue signal treatment. - Button (primary, secondary, destructive) — used within AI suggestion cards and confirmation steps for confirm/dismiss controls. Inferred from §4.1 action-first principle. - Skeleton loader — used in the Aiden panel loading state while context resolves. Inferred from loading state requirement in §5.3 of this spec. - Deep-link / navigation action — used to route the user directly to a target module surface (e.g. open a Digital Form, open appointment booking). Inferred from §4.1. ## 7. Visual Design Notes - **AI badge / AI involvement indicator:** Every AI-originated suggestion, guidance item, or action must carry a consistently styled AI indicator so the user always knows Aiden contributed. This is a governance requirement, not a decoration. The visual form of the AI badge must be consistent across Aiden and other AI-enabled modules on the platform (AI Concierge, AI Guardian, Task Manager, Campaign Manager) to avoid ambiguity — a staff member or patient must encounter the same visual convention regardless of which module is surfacing AI content. Inferred from the `ai_involved` flag mandate in §3.5 and §8, the governance-always-visible principle, and the equivalent AI transparency mandates in AI Concierge §2 and AI Guardian UX spec. *(needs UX writer input — exact label text for the AI badge, e.g. "Suggested by Aiden" or similar; and cross-module badge harmonisation with design system)* - **Smart Dashboards status colours:** The `OnTrack` / `Attention` / `Overdue` signal statuses must use semantic colour values (success/info, warning, error) consistently with the platform design system, and must not be altered or reinterpreted by Aiden's UI layer. Inferred from §4.4: statuses must be presented exactly as assigned. - **Iconography:** AI-related surfaces (the Aiden panel, AI badge) should use a consistent icon to identify Aiden's presence. Icon must never appear without an accessible label. Inferred from the governance-always-visible principle and platform accessibility baseline. *(needs UX writer input — specific icon selection)* - **Clinical safety message:** The clinical safety fallback message must be visually distinct and non-dismissible — it must not be styled as a regular chat bubble or guidance card. Inferred from §4.5 non-negotiable status. - **Motion:** State transitions within the Aiden panel (panel opening, suggestion appearing, confirmation step appearing) may use subtle motion. Motion MUST be suppressible via `prefers-reduced-motion`. Inferred from platform accessibility standards and the calm-by-default principle. - **Product Shop staff-facing recommendation surface:** Where Aiden surfaces AI-generated product recommendations for staff review (when Product Shop is enabled), those recommendations must be visually distinct from staff-authored recommendations and must carry the AI badge. AI-generated product suggestions must never be presented directly to the patient; they remain in a staff-only approval state until explicitly confirmed by a staff member. This is enforced at the UX layer — the suggestion card used here is the standard AI suggestion card with a `RequiresConfirmation: true` confirmation step. Inferred from Product Shop UX §3. - Typography, colour palette, and component sizing: *(deferred to design system — no module-specific overrides implied by the technical spec)* ## 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 / TalkBack Module-specific accessibility requirements: - The AI badge / AI involvement indicator must have a programmatic accessible label so screen reader users are informed that a suggestion is AI-originated, equivalent to the visual treatment. Inferred from the governance-always-visible principle and `ai_involved` flag mandate. - Conversational content in the Aiden panel (suggestions, escalation messages, clinical safety messages) must be announced to screen readers when it appears dynamically, using appropriate ARIA live region roles. Inferred from the conversational, dynamic nature of the Aiden surface described in §5.1–§5.3. - The clinical safety fallback message must be announced immediately to screen reader users when triggered — it must not rely solely on a visual styling distinction. Inferred from §4.5 non-negotiable clinical safety rules. - On the tablet app, all confirmation controls within Aiden panels must meet the ≥ 48 px touch target guideline appropriate for in-practice use with potential glove wear. Inferred from §5.2 Staff App Mode in-practice context. > Note: Technical spec open question 5 (accessibility conformance level) is unresolved. WCAG 2.2 AA is adopted as the platform baseline in this spec, consistent with the UX template default, pending engineering confirmation. ## 9. Internationalisation - Locale-aware date/time/number formatting - All user-facing strings externalised - Layouts tolerant of 30% string-length growth (German, French) - RTL support: requirement not confirmed by the technical spec. To be determined — the admin configuration surface (§13.3) references "language and tone variants" but no specific locales are listed for MVP. Inferred from open question 6 in the technical spec. *(needs UX writer input — confirm supported locales and whether RTL is in scope for MVP)* - Tone variants: admin-level configuration allows tone variants per practice. The UX must accommodate different approved tone profiles without structural layout changes. Inferred from §13.3: "Language and tone variants" as a configurable practice-level setting. *(needs UX writer input — enumerate approved tone profiles and any surface-specific constraints)* ## 10. Cross-Module UX Touchpoints Where this module's UX intersects with related modules: - **Appointment Manager** — Aiden surfaces appointment actions (reschedule, cancel, book) as deep-link controls within the Aiden panel; tapping them routes the user to Appointment Manager's booking surface or opens a confirmation step before emitting a booking intent. The handoff is one-directional at point of action; return context (booking confirmed) is communicated back via the CORE Calendar and may trigger a fresh Aiden prompt. Inferred from §5.3, §6.1, and §6.2. - **Digital Forms** — Aiden detects incomplete forms via the Digital Forms API and surfaces a prompt with a direct deep-link to the relevant form. The user is taken into the Digital Forms surface; Aiden does not own the form completion experience. Aiden suppresses the prompt if the form is already in progress to avoid duplicate journeys. Inferred from §5.3, §6.1, and Digital Forms §4.4. - **Task Manager** — Aiden surfaces AI-suggested task prompts to staff with an `AI-Suggested` origin marker visible in the Task Manager surface. Aiden never presents a "create task" control; it presents a suggestion that staff must act on independently in Task Manager. The visual treatment in Task Manager of AI-originated suggestions (the `Origin: AI-Suggested` value) should be consistent with Aiden's AI badge convention. Inferred from §3.3, §4.1 Task Manager constraint, and §6.2. - **Communication Hub** — when Aiden escalates, an escalation trigger is emitted to Communication Hub for human follow-up. The user sees the escalation handoff message in Aiden's surface; the subsequent communication (email, message, callback) is owned entirely by Communication Hub and is outside Aiden's UX boundary. Aiden may also surface inline intent-detection suggestions within Communication Hub threads; these are rendered as visually distinct inline prompts, carry the AI badge, and are placed in a dedicated slot that does not displace the composer area or interrupt the thread's typing indicator state (see §5.3). Inferred from §6.2, §4.6, and Communication Hub UX §3. - **Smart Dashboards** — Aiden surfaces `Attention` and `Overdue` signals from Smart Dashboards within its panel, using the status values and severity exactly as assigned. Staff who want deeper analytics are directed to Smart Dashboards. Aiden does not replicate dashboards; it contextualises signals for the current task. Aiden does not inject UI elements into the Smart Dashboards card layer (see §5.4 of this spec). Inferred from §4.4, §6.1, and Smart Dashboards §7. - **Treatment Pipeline** — on the website chat surface, Aiden's intake flow culminates in a Lead record in Treatment Pipeline. The user (prospective patient) does not see the pipeline stage; Aiden only confirms that the enquiry has been received and that the practice will follow up. Staff see the Lead in Treatment Pipeline; triage and Opportunity creation are staff-only actions outside Aiden's UX boundary. When Aiden recommends a pipeline stage transition to staff, the recommendation follows the mandatory confirmation flow described in §5.1. Inferred from §5.4, §7, and Treatment Pipeline Manager UX §2. - **Integrated Payments** — when enabled, Aiden surfaces balance and payment option information within the patient mobile app as informational cards with a deep-link to the Integrated Payments surface for action. Aiden does not own the payment flow. Inferred from §5.3 and §6.1. - **Loyalty Insights** — when enabled, Aiden may surface churn risk signals or proportionate action suggestions to staff, drawn from Loyalty Insights data. These are presented as contextual prompts with the same AI suggestion card treatment; Aiden does not display raw loyalty scores. Inferred from §6.1 and §7. - **Knowledge, Training & Learning** — Aiden draws FAQ and staff Q&A answers from the approved knowledge base. The UX should indicate when an answer is drawn from approved practice knowledge, to distinguish it from Aiden's own reasoning. Inferred from §6.1 and §2.2: "Aiden consumes that module's APIs and does not duplicate or override its governance." *(needs UX writer input — label or indicator for knowledge-base-sourced answers)* - **Access Manager** — the active user's resolved role must be visible somewhere in the UI context (e.g. the platform header) so staff understand which permissions govern what Aiden is showing them. This is a platform-level concern but is relevant to Aiden's governance-always-visible principle. Access Manager is the enforcement point for all AI-initiated requests; Aiden's UI must not present actions or guidance that Access Manager would deny for the active role, and must not surface a denied action as if it were merely unavailable rather than access-controlled. Inferred from §9, §4.2, and Access Manager §2 and technical spec §7. - **Audit & Compliance** — governance and admin users can navigate from the Aiden engagement signals view to the Audit & Compliance module to inspect immutable AuditEvent records. The handoff surface (a link or navigation control) should be clearly labelled. Inferred from §5.6 and §8. - **AI Phone Assistant** — when enabled, the phone channel uses the same Aiden logic layer. Staff-facing views of escalated calls (e.g. callback records) should be visually consistent with escalations originating from other channels. Inferred from §5.5 and §13.5. - **AI Quality Monitor** — where Aiden surfaces suggestions linked to or informed by AI Quality Monitor findings, those suggestions must carry the AI Quality Monitor finding's explainability note and current review state as part of the suggestion card's governance metadata. Aiden must not obscure or omit AI Quality Monitor governance markers. Inferred from AI Quality Monitor UX: "every AI-generated output must carry persistent markers indicating AI origin and review state." - **AI Guardian** — Aiden and AI Guardian both surface AI suggestions that are provisional until human approval. The acceptance/rejection interaction patterns (suggestion card, AI badge, confirm/dismiss controls, AuditEvent emission) must be visually and behaviourally consistent across both modules to reduce cognitive load for staff who encounter suggestions from both systems. *(needs platform design decision — cross-module suggestion card standardisation)*. Inferred from AI Guardian UX spec. - **Rewards Manager** — when Aiden surfaces rewards or referral insights to staff, those insights follow the standard AI suggestion card pattern with mandatory human review and no auto-execution of transactions. Inferred from Rewards Manager UX §3 and §5.1 of this spec. - **HR & People Manager / Rota Manager** — when enabled, Aiden surfaces coverage risk and leave guidance as advisory panels to authorised staff. These panels are distinct from confirmable suggestion cards; they carry the AI badge and are dismissible. No rota or leave state is modified by Aiden. Inferred from HR & People Manager spec and Rota Manager UX. - **Smart Treatment Proposals** — Aiden may suggest FAQ blocks or contribute to AI Quality Monitor draft proposals within the STP surface; all such suggestions are marked as Draft, carry the AI badge, and require explicit human approval before reaching patients. Inferred from STP UX §3 and technical spec §8.2. - **Product Shop** — when enabled, Aiden may suggest product recommendations for staff review on the tablet surface. These suggestions carry the AI badge and must not be presented to patients until staff have explicitly confirmed them. Inferred from Product Shop UX §3. - **Campaign Manager** — when enabled, Aiden may suggest campaign templates, audience segments, or optimisation recommendations; all suggestions are advisory, remain in Draft state, and require staff confirmation before activation. Inferred from Campaign Manager §2–§3. - **Performance Dashboards** — Aiden follows the platform-wide convention that AI-origin and data-source provenance labels accompany any metrics or signals it surfaces, consistent with the requirement in Performance Dashboards §2 that metrics originating from AI sources carry a clear provenance label. Inferred from Performance Dashboards §2. UX consistency rules: - The AI badge / AI involvement indicator must appear on every AI-originated suggestion or guidance item regardless of surface (web, tablet, mobile, website chat). The visual form may adapt to the surface but the semantic meaning and accessibility label must be consistent. The badge must also be consistent with the equivalent AI attribution marker used by AI Concierge — the platform must not present two different visual conventions for AI attribution across modules. Inferred from the governance-always-visible principle, `ai_involved` mandate, and AI Concierge §2. - Confirmation controls (confirm/dismiss pairs) must always be clearly labelled — never icon-only. Inferred from the governance-always-visible principle and accessibility requirements. *(needs UX writer input — confirm/dismiss button label conventions)* - Smart Dashboards status semantics (`OnTrack` / `Attention` / `Overdue`) must use the same semantic colour and label conventions wherever they appear, whether in Smart Dashboards itself or surfaced via Aiden. Inferred from §4.4. - Suggestions that are advisory only (no confirmable action) must use the advisory panel component rather than the AI suggestion card, to avoid implying that a confirmable action is available when none is. Inferred from the no-dead-toggles principle and the advisory panel component definition in §6. - All user-facing copy surfaced by Aiden — in suggestion cards, advisory panels, escalation messages, clinical safety messages, confirmation steps, and informational guidance — must use "patient" or "patients" as the domain term for the people receiving care. No other term (e.g. "client", "customer") is acceptable on any surface. This is enforced at the copy-review stage before any surface is promoted from draft to published, consistent with the patients-not-clients principle in §2. ## 11. Governance & Auditability - AI suggestions are visually distinct from user-initiated actions on every surface — they carry an AI badge or equivalent indicator at all times. This is non-negotiable and applies across all channels. Inferred from the `ai_involved: true` mandate on every AI-emitted event in §3.5 and §8, and the governance-always-visible principle. - Every non-navigational action surfaced by Aiden is preceded by an explicit confirmation step. The confirmation step summarises the action and its target before the user commits. Inferred from `RequiresConfirmation: true` on all non-navigational AIActions in §3.3 and §13.2. - Audit-significant actions (confirmed AI-suggested actions, escalations, clinical safety triggers) emit AuditEvents that are accessible to governance users via the Audit & Compliance module. The Aiden UI itself does not need to surface the audit log — it surfaces engagement signals (escalation frequency, unhandled intents, confirmation/abandonment outcomes) for operational review. Inferred from §5.6, §8, and §13.4. - The current user's role (as resolved by Access Manager) governs which Aiden guidance surfaces and actions are visible. Role context should be transparent to the user — staff can see that their role determines what Aiden shows them, consistent with the platform header role/permissions visibility convention. Access Manager is the authoritative enforcement point for all AI-initiated action requests; Aiden's UX must not surface or imply the availability of actions that would be denied by Access Manager for the active role. Inferred from §9, §4.2, and Access Manager §2 (core UX principle: "Governance always visible — when AI is involved, users always know what AI did") and Access Manager technical spec §7. - Read-only states within Aiden's own surfaces (e.g. escalation messages, clinical safety messages, informational guidance cards) are visually distinct from actionable suggestion cards with confirm/dismiss controls. Inferred from the action-first principle and `RequiresConfirmation` governance. - Clinical safety fallback messages are non-dismissible and non-editable — the UI must not allow a user to override or bypass the safe fallback response. Inferred from §4.5 non-negotiable clinical safety rules. - Engagement signal views available to admin/governance users must enforce Access Manager role permissions — patient-identifiable detail must not be surfaced beyond the permitted access level for the viewing role. Inferred from §13.4 and §5.6. - AuditEvents emitted by Aiden must include the `actor_type` field distinguishing AI-generated events from user-generated events. This metadata must be present and correctly set so that the Audit & Compliance module and the Security & Privacy module can render AI-generated audit events as visually distinct from user-generated events in the audit log view. Aiden's event emission must conform to this field contract. Inferred from Security & Privacy UX §3: "AI-generated audit events must be visually distinguished from user-generated events in the audit log." - Where Aiden participates in an aftercare interaction (e.g. contributing to a patient conversation that is later reviewed by staff in Aftercare Manager), that participation must be visually marked before staff act on or resolve the record. Aftercare Manager surfaces must display the AI involvement indicator on any Aiden-contributed content within conversation review or escalation records. The visual treatment is governed by Aiden's AI badge convention; Aftercare Manager renders it consistently. Inferred from Aftercare Manager UX §2: "whenever Aiden participates in a patient interaction, that participation is visually marked before staff act on or resolve the record." - Where Aiden surfaces suggestions linked to AI Quality Monitor findings, the suggestion card must carry the finding's explainability note and current review state as visible governance metadata. Aiden must not present an AI Quality Monitor-informed suggestion in a way that obscures the finding's origin or review status. Inferred from AI Quality Monitor UX: "every AI-generated output must carry persistent markers indicating AI origin and review state." - Staff-facing product recommendation suggestions (Product Shop) must remain in a staff-approval state until explicitly confirmed; the UX must not allow AI-generated product suggestions to reach patients without passing through the staff confirmation step. Inferred from Product Shop UX §3: "AI-generated product suggestions are never presented directly to the patient." - The acceptance/rejection interaction patterns for AI suggestions (suggestion card, confirm/dismiss controls, AuditEvent emission on both paths) must be consistent between Aiden and AI Guardian, as both modules present AI suggestions requiring human approval to the same staff population. *(needs platform design decision — cross-module suggestion card standardisation)*. Inferred from AI Guardian UX spec. ## 12. Notification & Communication Patterns The following patterns are inferred from §4.4 (Smart Dashboards signal handling), §4.6 (escalation), §5.6 (engagement signals), §6.2 (outbound integrations), and §8 (audit). - **In-app banner** — used for persistent, prioritised `Overdue` signals surfaced from Smart Dashboards in the staff web portal and tablet app. An overdue item warrants a "prioritised, visible call to action" (per §4.4) — a banner is the appropriate persistent treatment. Also used for any degraded-state message when Aiden is unavailable due to upstream API failure. Inferred from §4.4 and §14 reliability requirements. - **Toast** — used for transient success feedback after a confirmed AI-suggested action is dispatched to a target module (e.g. appointment rescheduled, form opened). Toasts are brief and do not require user action. Inferred from the confirmed state in §3.6 and the calm-by-default principle. - **Push notification** — when Aiden detects a time-sensitive signal for a patient (e.g. overdue form, upcoming appointment requiring attention), push notification is delivered via Communication Hub, not directly by Aiden. Aiden emits the escalation or signal trigger; Communication Hub owns delivery. Inferred from §6.2: "Communication Hub — escalation triggers for human follow-up" and §2.2: "Message routing or SLA ownership — owned by Communication Hub." - **Email/SMS** — post-escalation follow-up communications to patients or staff are routed via Communication Hub. Aiden emits an escalation trigger; it does not compose or send messages. Inferred from §6.2 and §2.2. ## 13. Open Questions > UX decisions to resolve before this spec is promoted from `draft` to `published`. - **AI badge copy and visual form** — what is the exact label for the AI involvement indicator on suggestion cards across surfaces? (e.g. "Suggested by Aiden", "AI", "Aiden suggests") — *(needs UX writer input)*. Inferred from governance-always-visible requirement and `ai_involved` flag mandate. This also requires cross-module harmonisation with AI Concierge and AI Guardian badge conventions. - **Escalation and degraded-state message copy** — the default fallback wording ("I can't do that directly, but here's what I can help with…") is specified in the technical spec but full message copy for all escalation scenarios and degraded states across all surfaces is not. *(needs UX writer input)*. Inferred from §4.6 and §14. - **Clinical safety message copy** — the safe fallback response for symptom-based prompts is described in §4.5 but the exact approved wording has not been locked. *(needs UX writer input and clinical/legal sign-off)*. - **Supported locales and RTL scope for MVP** — technical spec open question 6 is unresolved. Which languages and tone profiles are in scope for MVP, and is RTL layout required? Inferred from §13.3 configuration surface and open question 6 in the technical spec. - **Default escalation confidence threshold and UI implications** — technical spec open question 1 is unresolved. The configurable escalation threshold affects when the escalation state is triggered; the default value and any admin-facing UI for setting the threshold need to be confirmed. Inferred from §13.3 and open question 1 in the technical spec. - **Aiden panel placement and collapsibility per surface** — the technical spec does not specify whether the Aiden panel is always-visible, collapsed by default, or contextually revealed. This is a significant layout decision that affects the calm-by-default principle and the action-first principle. *(needs UX and product design decision)*. - **Knowledge-base source attribution** — when Aiden answers a question using content from Knowledge, Training & Learning, what visual treatment indicates this origin? Is it sufficient to label it as "Aiden" or should the knowledge source be attributed separately? Inferred from §6.1 and §2.2. - **Voice surface UX ownership** — technical spec open question 3 is unresolved. Does Aiden or the AI Phone Assistant module own the UX specification for voice interactions (IVR patterns, hold/transfer language, voice escalation handoff)? This spec assumes AI Phone Assistant owns that surface. Inferred from §5.5 and open question 3 in the technical spec. - **Engagement signals view — scope and placement** — the admin/governance engagement signals view (escalation frequency, unhandled intents, confirmation/abandonment rates) is described in §5.6 and §13.4 but its exact placement (within Aiden's own admin surface vs within Smart Dashboards or Audit & Compliance) is not specified. *(needs product design decision)*. - **Treatment Pipeline intake confirmation message** — when a Lead is created via the website chat flow, what does the prospective patient see to confirm their enquiry was received? *(needs UX writer input)*. Inferred from §5.4 and the one-Lead-per-intake constraint in §13.2 rule 8. - **Cross-module suggestion card standardisation** — Aiden and AI Guardian both surface AI suggestion cards requiring human acceptance/rejection. A platform-level design decision is needed to standardise the suggestion card component (visual form, AI badge, confirm/dismiss controls) so both modules present a consistent pattern to staff. *(needs platform design decision and coordination with AI Guardian UX spec)*. - **Advisory panel vs suggestion card boundary** — when does Aiden use the advisory panel (no confirmable action) vs the AI suggestion card (confirmable action)? The boundary for HR/Rota coverage guidance, Smart Dashboards contextual signals, and informational cards needs a consistent decision rule. *(needs UX and product design decision)*.
Live preview
💬
Comments
0
💡
Ask
0
📋
Activity
Open panel
→
Working...