Task Manager – UX Specification

Related Technical Authority: Task Manager – Technical Specification

1. Purpose

This UX specification governs the staff-facing experience of Task Manager — the single, calendar-backed system of record for all operational work across Primoro. It defines how authorised staff create, view, action, and complete tasks, callbacks, checklists, and work packages across the Web Portal, tablet app, and Staff App Mode. The primary roles it serves are practice administrators, clinical and decontamination staff, supervisors, and compliance officers.

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.

Ownership is always explicit — every task visible on every surface must display its current owner (user or role queue) without the user needing to drill in. This is inferred from the technical spec's requirement that OwnerId and OwnerType are non-null at all times (§3.1, §13.2).

Audit is a feature, not a footnote — state transitions and governance actions (cancellation, acknowledgement, AI confirmation) are always surfaced as distinct, named interactions rather than silent side-effects. This is inferred from the technical spec's requirement that all transitions be explicitly time-stamped and immutable (§3.2, §8).

AI suggestions are visually distinct and never self-confirming — Aiden-surfaced suggestions must be visually differentiated from staff-authored work, and the confirmation step must be the most prominent call to action on those surfaces. This is inferred from §4.5 and §7's non-negotiable RequiresConfirmation: true rule.

3. Design Philosophy

Task Manager's mental model is a governed calendar of work, not a to-do list. The design should reinforce that every item has a time window, an owner, and a state — and that nothing exists informally. This is inferred from the technical spec's explicit framing in §1: "if work matters, it exists in the calendar."

Empty states. An empty task list or queue is a meaningful, positive signal — it means work is up to date. Empty states should be calm and affirming rather than prompting unnecessary action. Where a queue is empty because no work has been assigned (e.g. a new role queue), the empty state should explain why and surface the relevant creation or template-assignment action to an administrator. Inferred from the role-first assignment model in §3.1 and §5.4.

Error states. Errors during state transitions (e.g. attempting a transition not permitted by the state machine, or submitting a cancellation without a reason) must explain precisely what is missing and what the user must do next. The system must not silently fail or leave a task in an ambiguous state. Inferred from §3.2's explicit rules on forbidden transitions and §13.2 rule 11 on mandatory cancellation reasons.

AI suggestions. AI-suggested tasks (from Aiden) appear as a visually distinct proposal card, not as a created task. The confirmation action is the primary call to action; dismissal is always available. The ConfidenceScore from AIIntent may be displayed as supporting context but never as a reason to skip the confirmation step. Inferred from §4.5 and §7.

Multi-step flows. Multi-step flows (task creation wizard, work package setup, template configuration, cancellation with reason) use a stepped pattern that shows progress and allows review before committing. Irreversible actions (cancellation, archival) require an explicit confirmation step. Inferred from §3.2's irreversible terminal states and §13.2 rules 3 and 11.

Undo/redo. Because all state transitions are immutable and audit-logged, true undo is not available for lifecycle transitions. The UI must make this clear before a user commits an irreversible action. For in-progress edits to task fields (e.g. title, description, due date) that have not yet been saved, standard browser/app undo behaviour applies within the editing session. Inferred from §3.2 and §8.

Read-only vs editable surfaces. Completed, cancelled, and archived tasks are always presented in a read-only state. The visual treatment must make read-only status unambiguous — it is not enough to simply disable inputs; the layout itself should shift to a read/inspect mode. This is inferred from the terminal state rules in §3.2 and the audit inspection requirement in §5.1.

Confidential tasks. Tasks marked Confidential: true must be visually differentiated in list and board views for users who hold the necessary permission. For users who do not hold permission, confidential tasks must not appear at all — not as a redacted row, not as a count. Inferred from §3.1's Confidential boolean and §9's access restriction rules.

4. Primary Surfaces

4.1 Web Portal

Who uses it: practice administrators, supervisors, compliance officers, and managers responsible for workload planning, exception handling, template administration, and audit inspection. Inferred from §5.1.

Key tasks performed here:

• Viewing workload and SLA state across all tasks, roles, and locations — including overdue and at-risk task counts. Inferred from §5.1.
• Exception management: reviewing and manually reassigning tasks flagged after access revocation where no role queue could be determined. Inferred from §5.1 and §9.
• Template and recurrence administration: creating, editing, and deactivating task templates and work package templates; configuring recurrence schedules and due-window rules. Inferred from §5.1 and §3.5.
• Read-only audit log inspection for tasks, checklists, work packages, and AI suggestion history. Inferred from §5.1 and §8.
• Configuring per-template and per-work-package settings (default ownership, checklist structure, claiming rules). Inferred from §13.3.
• Filtering and viewing tasks across all standard filter dimensions (status, SLA state, owner/role, origin, category, location, priority, confidential flag, overdue flag, date range). Inferred from §13.4.

Layout pattern: split-pane and dashboard. The primary workload view is a dashboard showing SLA and overdue summaries by role and location, with a drill-down to list or board view. Template administration uses a list-detail pattern. Audit inspection uses a read-only list-detail pattern. Inferred from the planning and oversight framing in §5.1 and the views described in §13.4.

Multi-calendar overlay (role/team calendars):

The calendar view supports a multi-calendar overlay model, analogous to the shared-calendar model in tools such as Microsoft Outlook and Google Calendar. Each configured role or team (e.g. Dental Nurses, Front of House, TCO, Practitioners) has its own calendar track, colour-coded with a unique colour per role.

• Default state: Users see their own calendar (tasks and work packages assigned to their role or to them personally).
• Overlay mode: Users may enable overlay mode to see multiple team calendars simultaneously on a single view. Each team's items are rendered in the team's assigned colour, allowing managers to see where work overlaps or where teams are operating concurrently.
• Filter / toggle: Individual team calendars can be toggled on or off from a calendar list panel (analogous to the Outlook/Google Calendar sidebar), allowing the user to show all, show a subset, or return to their own calendar only.
• Manager default: Practice managers default to seeing all team calendars overlaid, with the option to filter down.

Harry Leak: 'You've got a calendar for each role that we have configured in the back end… you can see an overlay of all of those work packages on one screen… or you can turn them off and just see one or two, or it defaults to your own… role might be colour A, role B will be colour B — they overlay, so you can see where they cross over.'

4.2 Tablet App

Who uses it: clinical staff and decontamination staff operating at point-of-work in surgery and decontamination rooms, where tasks are executed against work packages and checklists. Inferred from §5.2.

Key tasks performed here:

• Viewing the active work package and its constituent tasks for the current shift/time window. Inferred from §5.2 and §6.4.
• Executing checklist items step by step, capturing evidence (notes, comments, photos, file attachments) against individual checklist items. Inferred from §3.3 and §5.2.
• Marking tasks and checklist items as complete with explicit user attribution. Inferred from §5.2's CompletedByUserId field and §13.2 rule 5.
• Viewing task status, due time, and overdue indicator for each task in the work package. Inferred from the tablet data contract fields in §5.2.

Touch ergonomics: checklist-first UX with glove-friendly tap targets of at least 48 px. Explicit user attribution is required on shared devices; device-level authentication is enforced via Access Manager before any task action is permitted. Inferred from §5.2's "checklist-first UX", "explicit user attribution on shared devices", and "device-level authentication enforced via Access Manager".

Layout pattern: single-pane, task/checklist-focused. The view surfaces one work package at a time, with tasks listed in sequence and checklist items expanded inline. Inferred from the checklist-first framing in §5.2 and the ordered Tasks[] structure in §3.4.

4.3 Mobile App (Patient or Staff)

Task Manager does not surface directly in the patient mobile app. Patient-facing work such as callback requests is mediated through Communication Hub and Aftercare Manager. Inferred from §5.3.

Staff App Mode provides personal and role-based task management for staff on mobile. Key tasks: viewing personal task list; viewing and acting on role-based queues; claiming tasks from a queue; acknowledging tasks (confirming awareness without claiming); executing checklists with evidence capture; completing tasks at point of work. Inferred from §5.4.

Who uses Staff App Mode: all staff members who hold tasks or belong to role queues, including those working across multiple locations or away from a fixed workstation. Inferred from §5.4.

Key tasks performed here:

• Viewing personal task list and role-based queues, filtered and sorted by priority, due time, and SLA state. Inferred from §5.4 and §13.4.
• Claiming a task from a role queue, making the user the explicit owner. Inferred from §5.4.
• Acknowledging a task — recording awareness without claiming or beginning execution. Acknowledge and claim are distinct controls and must never be merged into a single action. Inferred from §5.4 and §13.2 rule 9.
• Completing checklist items with evidence capture (notes, comments, photos, attachments). Inferred from §5.4.
• Completing tasks at point of work, recording completion timestamp and attributing to the acting user. Inferred from §5.4.

5. Interaction Model

5.1 Primary Flows

Flow 1 — Manual task creation (Web Portal / Staff App Mode)

Inferred from §4.1 and the canonical Task fields in §3.1.

1. User selects the action to create a new task.
2. User enters title, description, category, and priority.
3. User sets a due date/time or a time window (start and end); at least one is required before saving.
4. User assigns an owner: either a named user or a role queue.
5. User optionally attaches a checklist structure or evidence requirements.
6. User optionally marks the task as confidential (if their role permits).
7. User reviews the summary and confirms creation.
8. Task enters Created state; creation event is recorded in the audit log with actor identity, timestamp, and Origin: Manual.

Flow 2 — Claiming and completing a task from a role queue (Staff App Mode)

Inferred from §5.4 and the state machine in §3.2.

1. User opens their role-based queue.
2. User selects a task to view its detail.
3. User chooses to acknowledge (confirm awareness, no ownership change) or claim (take ownership).
4. If acknowledging: acknowledgement is recorded as a distinct audit event; task state and owner do not change; acknowledgement indicator becomes visible to supervisors.
5. If claiming: ownership transfers to the user; task moves to Active if in Created, or remains in Active; audit event recorded.
6. User begins work; moves task to In Progress.
7. User executes any attached checklist items, capturing evidence per item.
8. User marks the task complete; task moves to Completed; CompletedTimestamp and CompletedByUserId are recorded; completion event is audit-logged.

Flow 3 — Aiden AI task suggestion confirmation (Web Portal / Staff App Mode)

Inferred from §4.5 and §7.

1. Aiden surfaces an AIIntent to an authorised user; the suggestion appears as a visually distinct proposal card — not as a created task.
2. The ConfidenceScore is displayed as supporting context alongside the suggestion detail.
3. The user reviews the suggested task (title, proposed owner, due date/time).
4. The user either confirms (creates the task with Origin: AI-Suggested and a LinkedEntities back-link to the originating AIIntent) or dismisses the suggestion.
5. Both confirmation and dismissal are recorded in the audit log.
6. (needs UX writer input — confirmation and dismissal action labels and microcopy for the AI proposal card)

Flow 4 — Task cancellation (Web Portal / Staff App Mode)

Inferred from §3.2 and §13.2 rule 11.

1. Authorised user selects the cancel action on a task that is not yet Completed, Cancelled, or Archived.
2. A confirmation modal appears; it is not dismissible by clicking outside (irreversible action).
3. User must enter or select a cancellation reason; the confirm action is disabled until a reason is provided.
4. User confirms; task moves to Cancelled; cancellation reason and actor are recorded in the audit log.
5. (needs UX writer input — confirmation modal heading, body copy, and reason field placeholder)

Flow 5 — Checklist execution with evidence capture (Tablet App / Staff App Mode)

Inferred from §3.3, §5.2, and §5.4.

1. User opens a task or work package that has an attached checklist.
2. Checklist items are displayed in sequence.
3. For each item, user marks completion; optionally adds a note, comment, photo, or file attachment as evidence.
4. Evidence is attributed to the acting user with a timestamp.
5. On completing all items, user is prompted to confirm completion of the parent task (if applicable).
6. Checklist events are recorded in the audit log independently of the parent task's lifecycle.

Flow 6 — Exception management after access revocation (Web Portal)

Inferred from §9 and §5.1.

1. Access Manager emits an access revocation event.
2. Task Manager automatically reverts ownership of all in-flight tasks owned by the revoked user to their associated role queue.
3. Where no role queue can be determined, affected tasks are flagged and surfaced in the Web Portal exception view.
4. An administrator reviews the exception view, which lists flagged tasks with their current state, original owner, and due time.
5. Administrator manually reassigns each flagged task to a new owner or role queue.
6. Reassignment is audit-logged with the administrator's identity, timestamp, and the revocation event reference.

If a staff member is mid-task at the point of revocation — for example, actively executing a checklist on the tablet app — the session must be terminated via Access Manager's force-logout mechanism. Any checklist progress that was recorded before the revocation event is preserved in the audit log and attributed to the revoked user up to the moment of revocation. The task is then treated as unowned and is moved to the exception queue. The UI must surface a clear, non-dismissible session-ended state to any user who attempts to continue work on the affected device. Inferred from Access Manager §3.5 and §5.3 (revocation as a terminal, immediate state) and §13.2 rule 5.

Flow 7 — Task created from a Communication Hub thread conversion (Web Portal / Staff App Mode)

Inferred from Communication Hub's UX principle 'Chat ≠ work, but chat can create work' and its design philosophy on message-to-structured-request conversion.

When a staff member converts a Communication Hub message thread into a structured task request, the following applies within Task Manager:

1. Task Manager receives a task creation event with Origin: Workflow and a LinkedEntities reference to the originating Communication Hub thread.
2. The task appears in the relevant role queue or is assigned to a named owner, depending on the routing rules configured for the thread type.
3. The task card and task detail view surface the LinkedEntities back-link as a navigable reference to the originating thread in Communication Hub, using the standard back-link component (see §10, UX consistency rules).
4. The acting staff member reviews the pre-populated task fields (title, description, priority, and proposed due date/time as derived from the thread context) and may edit them before confirming.
5. On confirmation, the task enters Created state; creation is audit-logged with Origin: Workflow and the thread reference.
6. From this point, the task follows the standard lifecycle (Flows 1–5). The Communication Hub thread is not updated by Task Manager directly; Communication Hub owns the thread state.

Tasks arriving via thread conversion are not AI-suggested tasks and must not receive the AI suggestion card treatment, even if the conversion was assisted by AI within Communication Hub. The distinguishing signal is Origin: Workflow with a Communication Hub LinkedEntities reference. (needs UX writer input — task card label for thread-converted origin)

Flow 8 — AI Guardian-suggested task review and confirmation (Web Portal / Staff App Mode)

Inferred from AI Guardian technical spec §7 (AI MAY suggest tasks for human approval before outputs are committed to Task Manager).

AI Guardian may surface task suggestions independently of Aiden. These suggestions arrive in Task Manager as provisional items that have not yet been committed to the task record. The flow is structurally identical to Flow 3 (Aiden AI suggestion confirmation) with the following distinctions:

1. The proposal card must identify the originating AI system (AI Guardian) so that staff are clear about which AI produced the suggestion. The card must not imply the suggestion came from Aiden if it originated from AI Guardian.
2. The RequiresConfirmation: true rule applies without exception; AI Guardian cannot commit a task directly.
3. Confirmation and dismissal are both audit-logged, including which AI system originated the suggestion.
4. After confirmation, the task is created with Origin: AI-Suggested and a LinkedEntities reference to the AI Guardian intent record.

Where both Aiden and AI Guardian suggestions are present in a queue simultaneously, they must be visually distinguishable — the AI-origin badge must include the source system label, not merely a generic AI indicator. (needs UX writer input — AI Guardian suggestion card labelling and differentiation from Aiden cards)

Flow 9 — Learning pathway task completion (Staff App Mode / Web Portal)

Inferred from Knowledge, Training & Learning UX spec (Flow A, step 7) and §4.3 (Knowledge, Training & Learning subsection).

Knowledge, Training & Learning creates Task Manager tasks corresponding to lessons and pathway milestones assigned to staff. These tasks have Origin: Workflow and a LinkedEntities reference to the learning pathway record. The completion model for these tasks differs from manually created tasks in one important respect: completion may be triggered automatically by Knowledge, Training & Learning when the staff member completes the lesson or passes an assessment within that module.

1. The task appears in the staff member's personal task list with Origin: Workflow and a learning-pathway back-link. It is visually identified as a learning task via its category label and the back-link indicator.
2. If the staff member completes the lesson within Knowledge, Training & Learning, that module emits a completion event; Task Manager moves the task to Completed and records CompletedTimestamp and CompletedByUserId automatically. No further action is required from the staff member within Task Manager.
3. If the task appears as overdue (the staff member has not engaged with the pathway by the due date), it surfaces in the standard overdue view and may escalate to a supervisor queue.
4. The task detail view surfaces the back-link to the learning pathway record in Knowledge, Training & Learning. Pass/fail logic and content delivery remain entirely within that module; Task Manager only tracks completion state.

Staff must not be able to manually mark a learning-pathway task as Completed from within Task Manager without the corresponding completion event from Knowledge, Training & Learning. The complete action must be absent (not disabled) for this task category unless the authorised override permission is held. (needs UX writer input — task card label for learning origin; supervisor override copy) Inferred from §13.2 and §4.3.

Flow 10 — AI Meeting Notes task (Web Portal / Staff App Mode)

Inferred from AI Meeting Notes subsection of §4.3 and gap 5cdfa59b.

Tasks originating from AI Meeting Notes sign-off arrive in Task Manager with Origin: Workflow and a LinkedEntities reference to the meeting note record. These tasks are distinguished from AI-suggested tasks in a significant respect: they have been explicitly confirmed by the meeting organiser during the AI Meeting Notes sign-off flow before they reach Task Manager. They are therefore pre-vetted human-confirmed tasks, not pending AI suggestions.

The UX implications are:

1. Tasks from AI Meeting Notes must not receive the AI suggestion card treatment and must not prompt a second confirmation step within Task Manager. They enter Created state directly and appear as standard task cards with Origin: Workflow.
2. The task card and detail view carry the LinkedEntities back-link to the originating meeting note. This back-link must use the standard navigable reference component.
3. An informational label on the task detail view should indicate that this task was confirmed during a meeting sign-off, giving staff the context that the action was already human-approved. (needs UX writer input — meeting-origin label copy)
4. From creation, the task follows the standard lifecycle (Flows 1–5) with no special restrictions.

Flow 11 — Task creation from AI Concierge call context (Web Portal / Staff App Mode)

Inferred from AI Concierge UX spec §4.1, §3 (Multi-step flows), and confirmation-gate requirements.

When a staff member uses the Agent Console during an active AI Concierge-handled call and triggers a 'create task' action, the following applies:

1. The Agent Console passes the call context (patient reference, conversation summary, suggested task title, and proposed category) to Task Manager as a pre-populated task creation request.
2. Task Manager surfaces a task creation review panel — not a full creation wizard — pre-populated with the call-context fields. The staff member may edit any field.
3. Before committing, a confirmation step is required. This step is not optional and must not be skipped, consistent with AI Concierge's mandate that confirmation steps are required for all irreversible actions initiated from call context. The confirmation step makes clear that creating this task is an audited, committed action.
4. On confirmation, the task is created with Origin: Workflow and a LinkedEntities reference to the AI Concierge call record. Creation is audit-logged with the staff member's identity and the call reference.
5. The task then follows the standard lifecycle. The AI Concierge call session is not affected by Task Manager's task state.

Tasks created from call context are not AI-suggested tasks (they are staff-initiated from a call, even if call handling was AI-assisted) and must not receive the AI suggestion card treatment. (needs UX writer input — confirmation panel heading and call-context origin label)

Flow 12 — Workflow-originated tasks from subscription exceptions, recall hand-offs, family profile events, and HR workflows (Web Portal / Staff App Mode)

Inferred from Hygiene Subscriptions §6.3 and §10.2, Recall & Reconnect §6.1, Family Profiles UX §4.1, and HR & People Manager workflow spec.

Several modules generate Task Manager tasks automatically in response to workflow events. These all arrive with Origin: Workflow and a LinkedEntities reference to the originating record. The UX treatment is consistent across all of them, with module-specific distinctions noted below.

Subscription exception tasks (from Hygiene Subscriptions — payment failures, stock unavailability, escalated intervention): tasks are routed to the reception/admin role queue. The task title and description include sufficient context for the staff member to act without opening the originating record (e.g. the patient name, subscription type, and nature of the exception). The back-link to the subscription record is available for detail but must not be the only way to understand what action is needed.

Recall hand-off tasks (from Recall & Reconnect — 'Needs Personal Follow-up' state): tasks are routed to the role queue appropriate to the recall type. The task must surface the patient context clearly. Staff should be able to identify that the item is a recall follow-up from the task card without opening the detail view. The LinkedEntities back-link to the recall record in Recall & Reconnect allows staff to view full contact history.

Family profile event tasks (from Family Profiles — pending invite redemptions, permission modifications, age-based transitions): tasks appear in the Web Portal with a clear indication of which patient profile they relate to, including the family profile context where relevant. Administrators monitoring pending invite redemptions or overdue transition events can see the affected profile directly from the task card. The LinkedEntities back-link navigates to the relevant record in Family Profiles.

HR workflow step tasks (from HR & People Manager — disciplinary, grievance, onboarding, probation confirmation gates): these tasks carry the Confidential flag and are routed to the appropriate HR or management role queue. The task card must respect the confidential treatment rules (§3 Design Philosophy, confidential tasks). The task title and description must not expose sensitive HR workflow details to users who do not hold the relevant permission. The LinkedEntities back-link to the HR workflow instance is accessible only to users with the relevant permission. Inferred from §4.3 (HR & People Manager subsection) and §9.

For all workflow-originated tasks in this flow: - Staff claim, acknowledge, and complete them using the standard flow (Flow 2). - Cancellation follows the standard cancellation flow (Flow 4) with a mandatory reason. - The origin label on the task card identifies the source module category (e.g. 'Subscription', 'Recall', 'Family Profile', 'HR Workflow') so staff understand the provenance without needing to open the detail view. - (needs UX writer input — origin label copy for each workflow category)

Flow 13 — Performance Dashboard attention-indicator handoff (Web Portal / Staff App Mode)

Inferred from Performance Dashboards UX spec §2 (attention indicators always link to a drill-down or a Task Manager workflow).

When a staff member navigates from a Performance Dashboard attention indicator to Task Manager, they arrive in a pre-filtered view scoped to the tasks or queue relevant to the indicator that was activated. The handoff must not drop the user on an unfiltered task list.

1. The Performance Dashboard emits a deep-link or navigation event to Task Manager with filter parameters (e.g. role queue, SLA state, date range, location) derived from the attention indicator context.
2. Task Manager applies those filter parameters to the list or board view on arrival, making the pre-filtered scope visible in the active filter bar so the user knows the view is not showing all tasks.
3. The user may clear or modify the filters. No filters are locked by the handoff.
4. Actions taken on tasks within this pre-filtered view follow the standard interaction model. The fact that the user arrived via a dashboard handoff has no effect on task state or permissions.

Task Manager does not consume Performance Dashboard data; it only receives inbound navigation events. Task state changes within Task Manager are the authoritative source of the data that Performance Dashboards displays; Task Manager does not push updates directly to the dashboard — that integration is governed by the outbound event stream. Inferred from §6.2.

Flow 15 — Drag-and-drop work package scheduling onto team calendar (Web Portal)

Inferred from Harry Leak's description of the intended scheduling workflow.

1. A manager opens the work package triage list — a centralised list of work packages that are due or need to be scheduled.
2. The manager opens or overlays the team's calendar (Daily or Weekly view).
3. The manager drags a work package from the triage list onto the calendar at the intended start time (30-minute increment precision).
4. The system creates a scheduled instance of the work package with the assigned team, start time, and calculated end time (based on configured duration).
5. The scheduled instance is immediately visible to all team members in their own calendar views.
6. The work package is removed from the unscheduled triage list once placed.

This workflow is the primary intended mechanism for converting planned work into day-of operational tasks. Harry Leak: 'We need to get to this really — centralising the work packages and then being able to drop them on the team's calendar, drag and drop, from a triage list.'

5.2 State Machines (Mirror of Technical Spec § 3.2)

All state transition representations are inferred from the authoritative state machine in §3.2.

SLA state is a secondary badge displayed alongside the task state. On-track is calm/neutral; At-risk carries a warning treatment; Breached carries an error treatment and surfaces the task in the exception/overdue view. SLA state is never the only signal — the primary task state badge is always present. Inferred from §3.1's SLAState field and §13.4's filter requirement.

Kanban board moves: dragging a task card to a new column is treated identically to a programmatic state transition; the drag interaction must include a brief confirmation affordance (e.g. a drop-zone highlight and snap animation) so the user is aware they are committing an audited transition. Forbidden transitions (e.g. moving a Completed task back to In Progress) must be visually blocked — the target column must not accept the card. Inferred from §3.2 and §13.2 rule 3.

Overdue flag: when a task's Overdue flag is true, this is surfaced as a persistent, high-visibility indicator on the task card in all views — not as a pop-up or notification. It is never the only signal; the task state and SLA state are always visible alongside it. The flag is computed by Task Manager; the UI consumes and displays it directly without recomputing. Inferred from §3.1, §5.2, and §13.2 rule 8.

Decontamination work package completion attribution: on the Decon Wall Tablet (surfaced via Surgery & Decon Day View), work package state, due times, and overdue highlighting must all be consistent with the state machine defined here. Completion of decon tasks must always record CompletedByUserId via the authenticated session — the attributed user must be the staff member who physically performed the work, not the device identity. If the device session has timed out or the attributed user cannot be confirmed, the completion action must be blocked and the user prompted to re-authenticate via Access Manager before proceeding. This is required so that the governance-always-visible principle and the explicit-ownership principle are upheld at the point of decon workflow completion. Inferred from Surgery & Decon Day View §4.2 and §5.2's CompletedByUserId requirement.

5.3 Empty / Loading / Error / Offline States

All states below are inferred from the surfaces and data model described in the technical spec. Specific copy is not defined here.

Task list / queue (empty state) When a personal task list or role queue contains no tasks, the screen should display a calm, affirming empty state communicating that there is no outstanding work. Where the queue is empty because no tasks have been assigned (e.g. a newly configured role), the empty state should surface the relevant administrative action to an administrator. For non-administrator users, it should simply confirm there is nothing to action. (needs UX writer input — empty state heading and body copy for each context)

Board view (empty state) An empty board (no tasks in any column) should communicate clearly that no work exists in the current filter scope, and offer a shortcut to adjust filters or create a task (where the user has creation permission). (needs UX writer input — empty board copy)

Loading state List, queue, and board views must use a skeleton loading treatment — placeholder cards that approximate the shape of real content — rather than a full-screen spinner. This reduces perceived latency on tablet surfaces where staff may be mid-workflow. Inferred from the performance requirement in §14 and the checklist-first tablet UX in §5.2.

Error state Where a state transition fails (e.g. network error during a checklist item completion), the UI must preserve the user's in-progress input and display an inline error that explains what failed and offers a retry action. The user must not be required to re-enter evidence. Inferred from the reliability requirement in §14 and the evidence attribution requirement in §13.2 rule 5.

Offline state The technical spec does not explicitly define offline-first behaviour. However, given the tablet app's point-of-work context in a surgery or decontamination environment, the UI must communicate clearly when connectivity is lost and indicate which actions (if any) are available offline. At minimum, the last-loaded checklist state should remain visible. Full offline write capability requires a product decision not yet specified. (needs UX writer input — offline banner copy and capability statement) (open question — see §13)

6. Component Inventory

New components introduced or extended by this module:

• Task card — a compact summary card used in list, queue, and board views. Displays task title, owner (user or role), due time or time window, status badge, SLA state badge, overdue flag (when true), origin indicator, and confidential indicator (when applicable). Inferred from §3.1 and §13.4.
• AI suggestion card — a visually distinct proposal card used to surface Aiden AIIntent suggestions and AI Guardian suggestions. Displays suggested title, proposed owner, proposed due date, confidence score, AI-source label (identifying whether the suggestion came from Aiden or AI Guardian), and confirm/dismiss actions. Must not be styled to resemble a created task card. Inferred from §4.5 and §7.
• Checklist execution panel — an inline or slide-over panel showing checklist items in sequence, with per-item completion toggle, evidence capture controls (note, comment, photo, file attachment), and attribution display. Inferred from §3.3 and §5.2.
• State transition badge — a pill or chip component with distinct visual treatments for each of the seven task lifecycle states and three SLA states. Used on task cards and task detail views. Inferred from §3.2 and §13.2.
• Kanban board column — a drag-and-drop column representing a single lifecycle state. Columns for forbidden target states must visually reject dropped cards. Inferred from §3.2 and §13.4.
• Exception flag indicator — a prominent indicator on a task card and in the Web Portal exception view, used to surface tasks that require manual reassignment after access revocation. Inferred from §5.1 and §9.
• Cancellation reason modal — a confirmation modal with a mandatory free-text or structured reason field. The confirm action is disabled until a reason is provided. Inferred from §3.2 and §13.2 rule 11.
• Audit event timeline — a read-only chronological list of all audit events for a task or work package, showing event type, actor, and timestamp. Accessible via progressive disclosure from the task detail view. Inferred from §8 and §5.1.
• Acknowledge / Claim action pair — two distinct, co-located controls available on tasks in Created and Active states within role-based queue views. These must never be merged into a single action. Inferred from §5.4.
• LinkedEntities back-link — a consistent navigable reference component used across all surfaces to link a task detail view to its originating record in another module (e.g. a lab case in Lab Manager, a meeting note in AI Meeting Notes, an HR workflow in HR & People Manager, a learning pathway in Knowledge, Training & Learning, a Communication Hub thread, or a Recall & Reconnect record). The visual treatment must be identical regardless of the target module. Inferred from the consistent LinkedEntities pattern across §4.3 integration sections and Flows 7–12 above.
• Call-context task creation panel — a pre-populated task creation review panel surfaced when a task is initiated from an AI Concierge call context via the Agent Console. Displays pre-filled fields from the call context and requires an explicit confirmation step before committing. Inferred from Flow 11 and AI Concierge UX spec §4.1.

Reused from the design system:

• Form inputs (text, date/time picker, file upload) — used in task creation, checklist evidence capture, and template administration.
• Filter bar — standard multi-select filter component, applied across list, queue, and board views as described in §13.4.
• Toast notification — used for low-urgency confirmations (e.g. task saved, checklist item marked complete).
• In-app banner — used for higher-urgency signals (e.g. overdue task count alert, SLA breach notification).
• Skeleton loader — used for list, queue, and board loading states.

7. Visual Design Notes

(needs UX writer input — typography scale and sizing)

(needs UX writer input — specific colour values)

• Colour — semantic usage: SLA state must use the platform's semantic colour system: On-track maps to the success/positive colour; At-risk maps to warning; Breached maps to error. The overdue flag indicator uses the error colour. Confidential task indicators use a neutral but distinct treatment that does not imply urgency. AI suggestion cards use a visually distinct surface colour or border treatment — not the same as a standard task card. Inferred from §3.1, §3.2, and §7.
• Iconography: all iconography must be accompanied by a visible text label — never icon-only — on all staff-facing surfaces including tablet. This is especially important for the acknowledge, claim, complete, and cancel actions given their distinct governance implications. Inferred from the platform's action-first principle and the audit significance of each action.
• Motion: Kanban card drag-and-drop transitions and drop-zone highlights may use subtle motion to provide affordance feedback. All motion must respect prefers-reduced-motion. State badge changes (e.g. a task becoming overdue) should not use animation to draw attention — the colour/badge change is sufficient. Inferred from §3.2 and the calm-by-default principle.
• Origin indicator: tasks created with Origin: AI-Suggested must carry a persistent visual marker (e.g. a labelled badge) in list, board, and detail views. This marker must not be removable by the user. Tasks with Origin: Workflow must carry an origin label identifying the source module category (e.g. 'From Communication Hub', 'From Recall', 'From HR Workflow', 'From Learning Pathway') where this can be determined from the LinkedEntities reference. This label is informational and must not affect task priority or visibility rules. Inferred from §3.1 and §7.

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 (Web Portal), VoiceOver (Staff App Mode / mobile), and TalkBack (Android tablet, where applicable).

Kanban drag-and-drop: the board view's drag-and-drop interaction MUST have a fully operable keyboard alternative (e.g. a move action in the task card's action menu that opens a state-selection modal). Drag-and-drop alone is not accessible. Inferred from the audit-logged Kanban interaction requirement in §3.2 and WCAG 2.1 success criterion 2.1.1.

Shared tablet devices: device-level authentication flows on the tablet app must meet touch target and contrast requirements regardless of the authentication method used (e.g. PIN entry, biometric prompt). Inferred from §5.2 and §9's device-level authentication requirement.

State badges: task lifecycle and SLA state must not be conveyed by colour alone; a text label or icon-plus-label treatment is required so that the state is perceivable by users with colour-vision deficiencies. Inferred from the state machine visual treatment requirement and WCAG 1.4.1.

Evidence capture — photo upload: photo capture on tablet and mobile must not require a mouse interaction; camera capture must be accessible via the device's native OS file/camera picker. Inferred from §3.3's photo evidence requirement and WCAG 2.1.1.

9. Internationalisation

Locale-aware date/time/number formatting.

All user-facing strings externalised.

Layouts tolerant of 30% string-length growth (German, French).

RTL support: required, consistent with platform-wide standards.

Date/time fields: due dates, time windows, completion timestamps, and audit event timestamps must all be rendered in the user's locale and timezone. The underlying data model stores UTC (TIMESTAMPTZ); the UI layer is responsible for all locale-aware rendering. Inferred from the TIMESTAMPTZ field types in §13.1.

Cancellation reason field: if cancellation reasons are presented as a structured list rather than free text, all reason strings must be externalised for translation. The same applies to template titles surfaced as system defaults. Inferred from §3.2's cancellation reason requirement and §3.5's template fields.

10. Cross-Module UX Touchpoints

All touchpoints below are inferred from the integration contracts in §6 and §10.

• Rota Manager — When a WorkPackage-type shift becomes active, Task Manager surfaces the corresponding work package on the tablet app without requiring any manual action from staff. The transition point is invisible to the user — the work package simply becomes the active view at the correct time. Administrators configuring work package templates in the Web Portal may navigate to Rota Manager to set up the corresponding shift type; this cross-module navigation should be surfaced as a contextual link from the template configuration screen. Inferred from §6.4.
• Communication Hub — Task state-change notifications are emitted to Communication Hub as events; Communication Hub is responsible for delivering these to staff via in-app, push, email, or SMS. Task Manager does not own the notification delivery UI. The outbound trigger is invisible to the task-acting user; recipients see the notification in Communication Hub's surfaces. Additionally, Communication Hub message threads may be converted into Task Manager tasks by staff (see Flow 7); the resulting task carries a LinkedEntities back-link to the originating thread and the standard Workflow origin label. Inferred from §6.2, §5.3's patient app boundary, and Flow 7.
• Aiden — AI task suggestions from Aiden surface within Task Manager's Web Portal and Staff App Mode as AI suggestion cards (see Component Inventory). The user does not leave Task Manager to interact with the suggestion; the confirmation flow is embedded. After confirmation or dismissal, the card is replaced by the created task card (on confirmation) or removed (on dismissal). Aiden never executes task creation without explicit human confirmation; the confirmation step is the most prominent call to action on the AI suggestion card and must not be bypassable. Inferred from §4.5, §7, and Aiden's core principle that no consequential action is taken without explicit human confirmation.
• AI Meeting Notes — Confirmed action tasks and retention review tasks created from AI Meeting Notes sign-off appear in Task Manager with an Origin: Workflow label and a LinkedEntities reference to the meeting note record. From the task detail view, the back-link should be surfaced as a navigable reference so that the user can open the originating meeting note record in AI Meeting Notes. Because these tasks have already been confirmed by the meeting organiser during sign-off, they enter Created state directly and must not be presented as AI suggestions requiring a second confirmation step within Task Manager (see Flow 10). Inferred from §4.3 (AI Meeting Notes subsection).
• Lab Manager — Escalation tasks generated by Lab Manager SLA breaches appear in Task Manager with Origin: Workflow and a LinkedEntities reference to the lab case. The task detail view should surface the back-link as a navigable reference to the originating lab case in Lab Manager. Inferred from §4.3 (Lab Manager subsection).
• Inventory & Compliance Manager — Compliance cycle tasks appear in Task Manager with Origin: Workflow; their SLA state reflects the Inventory & Compliance Manager lifecycle mapping (§4.3). The task detail view should surface the LinkedEntities back-link to the compliance record. Compliance tasks may carry checklist items with evidence attachments (photos, files) reflecting the compliance schedule's evidence requirements; the checklist execution panel (see Component Inventory) must support this without any compliance-specific modifications — the standard evidence capture model applies. The compliance task card should surface its SLA state and overdue flag with the standard visual treatments so that administrators reviewing the compliance schedule can see green/amber/red status at a glance in the task list. Administrators configuring compliance SLA windows do so in Inventory & Compliance Manager, not Task Manager. Inferred from §4.3 (Inventory & Compliance Manager subsection), §2.2, and Inventory & Compliance Manager UX §4.1.
• HR & People Manager — Policy workflow step tasks appear in Task Manager with Origin: Workflow and carry a LinkedEntities back-link to the HR workflow instance. Given the sensitive nature of HR workflow tasks, the Confidential flag is likely to be set on many of these; the UI must handle their restricted visibility correctly (see Flow 12 for routing and confidentiality treatment). Inferred from §4.3 (HR & People Manager subsection) and §9.
• Knowledge, Training & Learning — Pathway assignment tasks appear in Task Manager with Origin: Workflow and a LinkedEntities back-link to the learning pathway record. Deadline tracking and overdue visibility are governed by Task Manager; the content and pass/fail logic remain in Knowledge, Training & Learning. Completion of learning-pathway tasks may be triggered automatically by Knowledge, Training & Learning on lesson completion; staff must not be able to manually mark such tasks complete from within Task Manager without the corresponding completion event, unless an authorised override is held (see Flow 9). Inferred from §4.3 (Knowledge, Training & Learning subsection).
• Access Manager — RBAC permissions govern which actions are visible on every surface. Controls for actions the current user does not hold permission to perform must not appear — they must be absent, not disabled. The exception is where the UI needs to communicate that an action exists but requires a different role (e.g. a tooltip on a greyed-out reassign button for non-supervisor users). Device-level authentication for shared tablet devices is managed via Access Manager; Task Manager's tablet UI must integrate with the Access Manager authentication prompt rather than implementing its own. Access revocation is treated as a terminal, immediate event: on revocation, the affected user's session is force-logged out by Access Manager, and any tasks owned by that user are returned to their role queue or flagged in the exception view (see Flow 6). Inferred from §9 and Access Manager §3.5 and §5.3.
• Audit & Compliance — The audit event stream is emitted to the Audit & Compliance module; Task Manager surfaces a read-only per-task audit timeline (see Component Inventory) for administrators and compliance officers within the Web Portal. Full cross-module audit inspection is handled by the Audit & Compliance module, not by Task Manager directly. Inferred from §5.1 and §6.2.
• Admin Control Plane — Practice-level settings (default SLA windows, retention policies, role-queue definitions, evidence requirements, confidential task visibility rules) are configured in Admin Control Plane, not in Task Manager's own settings UI. Task Manager consumes these settings. Links to Admin Control Plane configuration screens should be surfaced contextually where an administrator is in a configuration flow within Task Manager (e.g. when no default SLA window is set for a task category). Admin Control Plane may also generate onboarding workflow tasks and health event escalation tasks that arrive in Task Manager with Origin: Workflow and a LinkedEntities reference to the originating ACP workflow or health event record. These tasks follow the standard workflow-originated task pattern (see Flow 12) and are routed to the appropriate administrative role queue. Inferred from §13.3 and Admin Control Plane spec §4.2 and technical spec §13.2.
• Aftercare Manager — Aftercare escalation and follow-up monitoring may generate Task Manager tasks where clinical or administrative intervention is required beyond the automated Aftercare instruction flow. These tasks arrive with Origin: Workflow and a LinkedEntities reference to the relevant Aftercare instruction or escalated conversation record. The task card should surface sufficient patient context for the staff member to understand what follow-up is needed without navigating to Aftercare Manager. The LinkedEntities back-link provides access to the full Aftercare record for detail. Routing follows the standard role-queue assignment rules; the specific queue is determined by the escalation type configured in Aftercare Manager. Inferred from Aftercare Manager UX §4.1 (live dashboard monitoring and escalated conversation response) and §4.3 integration patterns.
• Smart Dashboards — On the mobile app (Staff App Mode), the task queue is the first primary signal in the fixed three-card dashboard order defined by Smart Dashboards. Task Manager supplies the task data for this card; the card surfaces a summary of the user's personal task list and role-based queue (count of outstanding tasks, overdue count, and SLA state summary). Tapping the task card in the Smart Dashboard navigates the user into Task Manager's queue view with no filter pre-applied. Critically, task state changes made within Task Manager's own surfaces are the authoritative source; the Smart Dashboard task card is a read surface only and must not expose controls that trigger Task Manager state transitions. Any action-taking (claiming, completing, acknowledging) must happen within Task Manager's own surfaces, not from within the dashboard card. Inferred from Smart Dashboards §4.3, §5.2, and §13.2 rule 9.
• Staff App Mode — Staff App Mode provides the mobile shell within which Task Manager's staff-facing personal queue and checklist execution features are surfaced. The acknowledge/claim action pair, role-based queue view, and checklist execution panel (see Component Inventory) must conform to the interaction contract defined by Staff App Mode. Inferred from §5.4.

UX consistency rules:

• The acknowledge and claim actions must always appear as two distinct, co-located controls in role-based queue views across both Web Portal and Staff App Mode. They must never be merged. Inferred from §5.4.
• LinkedEntities back-links to originating records in other modules must use a consistent navigable reference component across all surfaces — the same visual treatment whether the back-link points to a lab case, a meeting note, an HR workflow, a learning pathway, a Communication Hub thread, a Recall & Reconnect record, an Aftercare instruction, or an Admin Control Plane workflow. Inferred from the consistent LinkedEntities pattern across §4.3 integration sections and Flows 7–12.
• The AI suggestion card must use a consistent visual treatment wherever it appears (Web Portal, Staff App Mode) so that staff recognise it as an AI-originated item regardless of context. Where the suggestion originates from AI Guardian rather than Aiden, the source system label must distinguish the two. Inferred from §4.5, §7, and Flow 8.
• Workflow-originated tasks from different source modules must carry a consistent origin label pattern (source module category) so that staff can identify the provenance of a task at a glance in any list, queue, or board view. Inferred from Flows 7, 9, 10, 11, and 12.

11. Governance & Auditability

All governance treatments below are inferred from §7, §8, and §9.

• AI suggestions are visually distinct from user-authored work. AI suggestion cards use a distinct surface treatment (e.g. a labelled border or background differentiation) and carry a persistent AI-origin badge identifying the source system (Aiden or AI Guardian). After an AI suggestion is confirmed and becomes a task, the task card retains an AI-Suggested origin badge in all views. This badge is never removable. Inferred from §4.5, §7, §3.1's Origin field, and Flow 8.
• Audit-significant actions show a confirmation step. Cancellation and bulk reassignment require an explicit confirmation step with a mandatory reason or acknowledgement. Dragging a task card on the Kanban board constitutes an audited state transition; the drop affordance must make clear that a transition is being committed. Task creation from AI Concierge call context also requires an explicit confirmation step (see Flow 11). Inferred from §3.2 and §8.
• The current user's role and active permissions are visible. The header of all staff-facing surfaces must display the current user's identity and their active role context. On shared tablet devices, the attributed user must be clearly visible after authentication. Inferred from §5.2's explicit user attribution requirement and §9.
• Read-only states are visually distinct from editable. Completed, cancelled, and archived tasks must render in a distinct read-only layout — not simply with disabled inputs. The audit event timeline is always read-only and must be visually framed as a record, not an editable form. Inferred from §3.2's terminal state rules and §5.1's read-only audit inspection surface.
• Confidential tasks are access-controlled at the UI layer. Users without the relevant permission must not see confidential task cards, titles, or counts in any view. For users with permission, confidential tasks carry a persistent confidential indicator. HR workflow tasks are a primary example of confidential tasks; the UI must not expose their content to users outside the permitted role set. Inferred from §3.1, §9, and Flow 12.
• Access revocation exception view. The Web Portal must surface a dedicated exception view listing tasks flagged after access revocation where no role queue could be determined. This view must show enough context (task title, state, SLA state, overdue flag, original owner, due time) for an administrator to make a reassignment decision without needing to open each task individually. Inferred from §5.1 and §9.
• Task origin is always visible. The Origin value (Manual, Callback, Workflow, Template-Generated, AI-Suggested) must be displayed on the task detail view and optionally on task cards in list and board views. For Workflow-origin tasks, the source module category label supplements the origin value so that the specific provenance is clear. It is never hidden. Inferred from §3.1 and the filter requirement on Origin in §13.4.

12. Notification & Communication Patterns

All patterns below are inferred from §6.2 (outbound to Communication Hub) and §8 (audit events that may trigger notifications).

• In-app banner — used within Task Manager's own surfaces for high-priority operational signals that require immediate staff attention and are scoped to the current view: for example, a notification that tasks have been flagged for manual reassignment in the exception view following access revocation, or that the overdue task count for the user's role queue has increased since their last session. Banners must be dismissible and must not auto-dismiss for high-urgency signals. Inferred from §5.1 and §9.
• Toast — used for low-urgency, transient confirmations of completed actions: for example, a task has been saved, a checklist item has been marked complete, or a task has been successfully claimed. Toasts auto-dismiss and do not require user action. Inferred from standard operational confirmation patterns and the action-first principle.
• Push notification — delivered via Communication Hub, not directly by Task Manager. Task Manager emits a state-change notification trigger event to Communication Hub (§6.2); Communication Hub determines delivery channel and timing. Task Manager's UX does not define push notification copy or delivery rules — these are owned by Communication Hub. (needs UX writer input — agreement with Communication Hub module on which state-change events warrant push notification)
• Email and SMS — also delivered via Communication Hub following the same pattern as push notifications. Task Manager emits the trigger event; Communication Hub owns delivery. Task Manager does not send email or SMS directly. Inferred from §6.2 and §1's explicit "does not deliver or store messages" boundary.
• Overdue flag indicator — not a notification in the traditional sense, but a persistent, in-context visual signal on the task card itself (see §5.2 and Component Inventory). It is always visible in the relevant list, queue, and board views without requiring the user to take any action to surface it. Inferred from §5.2's Overdue field and the calm-by-default principle.

13. Open Questions

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

1. Offline capability on tablet app — the technical spec does not define offline-first behaviour for the tablet app. Given the point-of-work context, it must be decided whether checklist execution should be available offline with queued sync, or whether a clear "offline — actions unavailable" state is the intended experience. This decision affects the component inventory and loading/offline state designs. Inferred from §14's reliability requirement and the tablet app's operational context.

2. Work-package board view scope — the technical spec (§15, open question 5) is silent on whether a board view scoped to a single work package (showing its constituent tasks across lifecycle state columns) is required. This must be clarified before the board view component and Kanban column layout can be finalised.

3. Confidential task event payload in Communication Hub — the technical spec (§15, open question 1) does not define whether confidential task titles and descriptions are redacted in outbound Communication Hub trigger events. The UX impact is that staff receiving notifications about confidential tasks via Communication Hub may see redacted or no task detail; the notification design for those cases must be agreed between Task Manager and Communication Hub module owners.

4. Compliance lifecycle state mapping confirmation — the state mapping between Inventory & Compliance Manager and Task Manager (§4.3) is a draft proposal pending sign-off. Until this is confirmed, the visual treatment of compliance-originated tasks (particularly the Overdue / SLAState: Breached display) cannot be finalised. Inferred from §15, open question 2.

5. Blocked state — reason capture — the technical spec lists Blocked as an optional task state (§3.2) but does not specify whether a reason must be captured when a task is moved to Blocked. The UX pattern for this transition (confirmation modal, inline field, or none) must be decided before the Kanban board and state transition interaction model can be finalised.

6. Overdue flag recomputation — perceived latency on tablet — the technical spec (§15, open question 4) has not resolved whether the Overdue flag is event-driven, polling-based, or read-time computed. The answer determines whether the tablet app needs a live-update/polling pattern or whether a page refresh is sufficient to reflect a newly overdue task. This affects the tablet loading state design.

7. AI Guardian vs Aiden suggestion routing — it is not yet specified whether both AI Guardian and Aiden may surface task suggestions simultaneously to the same user, and if so, whether there is a priority or deduplication rule. This must be agreed between the AI Guardian, Aiden, and Task Manager module owners before the AI suggestion card labelling and queue ordering can be finalised. Inferred from Flows 3 and 8.

8. Smart Dashboard task card — action scope — it must be confirmed with the Smart Dashboards module owner that no task-state-changing actions will be exposed on the task summary card in the fixed mobile dashboard. If any action shortcuts are proposed for the dashboard card (e.g. a one-tap complete), this would require a governance and audit review before it could be incorporated. Inferred from §10 (Smart Dashboards touchpoint) and the audit-is-a-feature principle.

9. Aftercare-initiated task routing rules — the specific role queues and routing logic for tasks generated by Aftercare Manager escalations have not been defined. These must be agreed between Aftercare Manager and Task Manager module owners before the touchpoint integration can be fully specified. Inferred from §10 (Aftercare Manager touchpoint).

10. (needs UX writer input — all confirmation modal copy, empty state copy, AI suggestion card microcopy, offline banner copy, cancellation reason field labels, origin label copy for workflow-originated task categories, and call-context task creation panel copy across all surfaces)

1. Task Manager left-hand navigation map — the left-hand navigation structure for the Task Manager module in the web portal has not been standardised. Prototype screens have used inconsistent labels and groupings across items including 'Task categories', 'Governance dashboard', 'My Task Overview', 'List view', 'Kanban view', 'Calendar', 'SLA', and 'Templates'. Before UX design is finalised, the navigation map must be defined, specifying: (a) which items appear as top-level menu entries, (b) which items appear as sub-menu entries nested under a parent 'Tasks' entry, and (c) which items are deferred to a later delivery phase and therefore excluded from the current navigation surface entirely. This decision must be agreed between Harry and Elvina and is a prerequisite for the navigation component inventory, active-state styling, and responsive collapse behaviour.

14. Tablet Day View

The tablet day view is a strict, flat chronological view of a single day's tasks. There are no time-segment controls (morning / midday / evening), and no toggle to restore segment-based navigation. The segment-based design is replaced entirely on this surface.

The view header displays the current date in the format Weekday DD Month (e.g. Wednesday 16 April), rendered prominently at the top of the screen. Prev/next day navigation buttons flank the date, allowing users to flick between days — for example, to review the following day's scheduled work before end of shift. Swiping left or right on the main content area performs the same prev/next navigation as the buttons.

There is no concept of a "today only" lock on this surface; navigating to past or future days is always permitted.