Rewards Manager – Technical Specification

1. Module Purpose & Scope (Authoritative)

Rewards Manager is Primoro's behaviour-led, trust-first loyalty module. It recognises and reinforces positive patient behaviour — attendance, recall compliance, plan participation, and engagement — without discount-driven marketing, vouchers, or manual administration. It sits within the patient retention layer of the Primoro platform, spanning both the patient-facing mobile app and the staff operational dashboard.

It governs:

• The patient points ledger: earning, balance tracking, and redemption
• Refer-a-Friend: referral lifecycle, reward issuance, and abuse prevention
• Charity donation: points-to-cause conversion with optional Gift Aid capture
• Optional recognition layers: tiers, badges, and milestones
• Rewards and referrals operational dashboard for staff

It explicitly does not:

• Operate as a promotions or campaigns engine (owned by Campaign Manager)
• Issue cash or operate a financial payment rail (owned by Integrated Payments, optional)
• Modify clinical records (owned by the PMS)
• Aggregate behavioural cohort analytics (owned by Loyalty Insights, if enabled)

1.1 Loyalty Insights Signal Boundary

When Loyalty Insights is enabled, it consumes signals from Rewards Manager in read-only mode. Loyalty Insights MUST NOT write to, mutate, or trigger any change in the Rewards Manager ledger or any canonical object. Rewards Manager emits outcome events (earn, redemption, referral state transitions, charity donations) as a signal source regardless of whether Loyalty Insights is enabled; the events are published to the platform event bus and Loyalty Insights subscribes to them independently.

The following signals are available for Loyalty Insights consumption:

• Reward earn events (trigger type, points awarded, timestamp)
• Redemption events (redemption type, points deducted, state, timestamp)
• Referral pipeline state transitions (state, channel, timestamp)
• Charity donation events (points donated, timestamp)

Signal availability guarantees: signals are emitted on a best-effort, at-least-once basis via the async event bus. Loyalty Insights is responsible for idempotent consumption. If Loyalty Insights is not enabled, events are still emitted but unconsumed; this has no effect on Rewards Manager operation or data integrity.

2. Ownership & Responsibilities

2.1 Rewards Manager IS Responsible For

• Owning and maintaining the patient points ledger, including all earn, redemption, and adjustment transactions
• Owning reward eligibility logic and redemption state
• Owning native account credit tracking for reward offsets against invoices or treatment charges
• Emitting outcome events (earn, redemption, referral state transitions, charity donations) in a form consumable by downstream modules
• Enforcing all abuse-prevention safeguards: self-referral blocking, referral caps, single-use redemption, duplicate account detection
• Providing the Rewards & Referrals Management Dashboard for staff operational visibility
• Logging all outcomes resulting from Loyalty Insights-initiated handoffs so that handoff contracts can be verified and closed
• Consuming plan-lifecycle events (enrolment, suspension, cancellation) from Care Plan Subscriptions and Hygiene Subscriptions to trigger or suppress earn accrual accordingly; Rewards Manager alone decides whether and when points are issued against those events

2.2 Rewards Manager IS NOT Responsible For

• Automating credit application at checkout — that enhancement is owned by Integrated Payments (optional); when Integrated Payments is enabled, it applies available reward credits at checkout and emits redemption confirmation events back to Rewards Manager, which records them as Reward Transactions
• Fulfilling product-based redemptions — owned by Product Shop (optional)
• Delivering reward notifications and confirmations to patients — owned by Communication Hub
• Aggregating reward, referral, and charity metrics into programme-level analytics — owned by Performance Dashboards and Loyalty Insights (optional)
• Mutating reward balances from outside this module — no other module may issue or modify redemptions
• Accruing points on behalf of Care Plan Subscriptions or Hygiene Subscriptions — those modules explicitly exclude reward accrual from their scope; Rewards Manager owns all points ledger mutations triggered by plan-participation events

3. Core Objects (Normative)

3.1 Points Ledger (Canonical Artefact)

A Points Ledger is a governed digital artefact representing the lifetime rewards account for a single patient within a practice.

Minimum required fields:

• LedgerID
• PatientID (FK to patient record)
• PointsEarned
• PointsRedeemed
• PointsBalance
• TransactionHistory (immutable append-only log)
• CreatedAt
• UpdatedAt
• AuditTrail (immutable)

3.2 Reward Transaction (Canonical Artefact)

A Reward Transaction is an immutable record of a single points event against a patient ledger.

Minimum required fields:

• TransactionID
• LedgerID (FK)
• TransactionType (earn / redeem / adjustment / donation)
• Points (positive or negative delta)
• TriggerEvent (behaviour or action that caused the transaction)
• ActorID (patient or staff user)
• Timestamp
• ReasonNote (required for manual adjustments)
• AuditTrail (immutable)

3.3 Referral (Canonical Artefact)

A Referral is a governed artefact representing a single refer-a-friend invitation and its lifecycle from creation through reward issuance.

Minimum required fields:

• ReferralID
• ReferrerPatientID (FK)
• ReferralCode (unique per patient)
• ShareChannel (WhatsApp / SMS / email / copy-link / QR)
• ReferralState (see §3.4)
• SharedAt
• FirstViewedAt
• ConsentCaptured (boolean)
• ReferredPatientID (FK, populated post-registration)
• RewardTransactionID (FK, populated post-issuance)
• CreatedAt
• AuditTrail (immutable)

3.4 Referral State Machine (Authoritative)

States:

• Invite Created — referral code generated, not yet shared
• Shared — referral link distributed via a recorded channel
• Invite Viewed — referred individual has opened the link
• Referred Patient Registered — new patient record created
• New Patient Exam Booked — appointment confirmed in Appointment Manager
• Attended — appointment attendance confirmed
• Reward Issued — referrer points transaction committed
• Reward Redeemed — referrer has consumed the issued reward

Rules:

• State transitions are auditable and timestamped
• Reward issuance MUST NOT occur before the Attended state is confirmed
• States are append-only; no state may be removed from the history
• Once a referral has reached Attended, it cannot revert to an earlier state.
• Manual state overrides require an authorised staff role and a logged reason

3.5 Redemption (Canonical Artefact)

A Redemption is a governed record of a patient's exercise of an available reward entitlement.

Minimum required fields:

• RedemptionID
• LedgerID (FK)
• RedemptionType (care-credit / free-service / product / charity-donation)
• PointsDeducted
• RedemptionState (Pending / Confirmed / Cancelled)
• InitiatedBy (patient / staff / integrated-payments)
• InitiatedAt
• ConfirmedAt
• AuditTrail (immutable)

3.6 Redemption State Machine (Authoritative)

States:

• Pending — redemption request submitted, not yet confirmed
• Confirmed — points deducted atomically; entitlement active
• Cancelled — redemption voided before confirmation (auditable)

Rules:

• Points deduction is atomic; partial deductions are prohibited
• A Confirmed redemption cannot be reversed except by an authorised manual adjustment with logged justification
• A Cancelled redemption returns points to the ledger via a compensating Reward Transaction, not by mutating the original record.

4. Rewards Model

4.1 Earning Behaviours (Authoritative)

Points accrual is event-driven, timestamped, and fully auditable.

The module MUST:

• Award points automatically when a configured trigger event is confirmed
• Record each earning event as an immutable Reward Transaction
• Respect per-practice configuration of which behaviours are eligible

The module MAY award points for:

• Appointment attendance
• Recall compliance
• Active Care Plan or Hygiene Plan participation
• Product Shop purchases (when Product Shop is enabled)
• App engagement actions (configured per practice)
• Approved referrals (Refer-a-Friend, after attendance confirmed)

The module MUST NOT award points for:

• Declining treatment
• Clinical decision outcomes
• Any behaviour that could constitute an inappropriate incentive under applicable clinical or regulatory guidance
• NHS treatments (excluded from accrual by default; configurable per practice)

4.1.1 Payment Event Earning Trigger (Integrated Payments)

When Integrated Payments is enabled, reward earn events tied to patient payments MUST be triggered only on receipt of a Captured payment event from Integrated Payments — not on Initiated or Authorised events. This ensures points are awarded only once confirmed payment settlement has occurred. Rewards Manager MUST suppress or discard earn triggers received for payment events in any state earlier than Captured. A duplicate-suppression check (§17.2, rule 7) MUST be applied to Captured events to prevent double-earning if the event is delivered more than once.

4.1.2 Plan-Participation Earning Rules

Care Plan Subscriptions and Hygiene Subscriptions emit plan-lifecycle events (enrolment, suspension, cancellation) to Rewards Manager. Rewards Manager owns the decision of whether each event qualifies for point accrual:

• Enrolment events MAY trigger an earn transaction if the practice has configured a plan-participation reward
• Suspension events MUST suppress ongoing plan-participation accrual for the duration of the suspension
• Cancellation events MUST terminate plan-participation accrual; no earn transaction is issued for a cancellation unless explicitly configured by the practice
• Rewards Manager MUST NOT rely on Care Plan Subscriptions or Hygiene Subscriptions to calculate or validate the points amount; that logic is owned solely by Rewards Manager

4.2 Redemption Rules (Authoritative)

Practices may enable one or more supported redemption types:

• Care or treatment credit (native, always available)
• Free services
• Product Shop items (requires Product Shop)
• Charity donation (with optional Gift Aid capture)

The module MUST:

• Restrict patients to redemption types explicitly enabled by the practice
• Deduct points immediately and atomically on redemption confirmation
• Enforce single-use redemption; a redeemed entitlement cannot be applied twice
• Provide a guided manual fallback workflow for staff when Integrated Payments is not enabled
• Record a Reward Transaction for every redemption confirmation received from Integrated Payments, treating the Integrated Payments redemption event as the authoritative trigger for that transaction

The module MAY:

• Automate checkout redemption when Integrated Payments is enabled
• Display expiring reward notifications to patients via Communication Hub

The module MUST NOT:

• Issue cash
• Permit points balances to go below zero

4.3 Credit & Invoice Interaction (Locked)

Rewards Manager includes a native credit mechanism.

• Reward credits are owned and tracked within Rewards Manager; they do not require Integrated Payments
• Credits may be applied against invoices or treatment charges via staff-assisted application or PMS adjustment workflows
• When Integrated Payments is enabled, credits MAY be applied automatically at checkout. Integrated Payments applies the credit, records it on the receipt, and emits a redemption confirmation event to Rewards Manager; Rewards Manager consumes this event and commits the corresponding Reward Transaction. Integrated Payments does not own the reward logic or ledger.

4.4 Optional Recognition Layers

Practices may optionally enable:

• Tier indicators (e.g. Bronze / Silver / Gold)
• Progress feedback and milestone notifications
• Badges

These layers are:

• Non-competitive by default
• Ignorable by patients without penalty
• Cosmetic unless explicitly configured otherwise by the practice
• Recognition layer configuration is stored at practice level and does not affect points ledger integrity.

5. Refer-a-Friend (Authoritative Sub-Module)

5.1 Referral Flow

• Each patient receives a unique referral link and code
• Sharing is app-first with deep linking; the system records the share channel (WhatsApp, SMS, email, copy-link, QR), timestamp of share, and timestamp of first view
• New-patient validation is enforced; existing patients are ineligible to be referred
• Consent for follow-up messaging is captured at the point the referred individual engages with the link

5.2 Referral Reward Issuance

• Referrer rewards MUST NOT be issued until the Attended state is confirmed (see §3.4)
• Referral abuse prevention rules MUST be enforced: configurable referral caps per practice, self-referral blocking, and duplicate account detection

5.3 Referral Nudges & Assisted Conversion

Where a referral invite has been shared but has not progressed:

The module MAY send configurable, consent-gated nudges to the referred individual, including reminders to book a new patient exam or claim a referral benefit before expiry. Nudges MUST be time-boxed and MUST cease immediately once the referral progresses.

The dashboard MUST support staff-initiated follow-up where a referred patient has engaged but not booked, or where a referral reward has been issued but not redeemed. Staff may contact the referred patient or referrer via Communication Hub. All outreach actions are logged against the patient or referral record.

6. Charity Donations (Authoritative)

• Patients may donate points to charities configured by the practice
• Gift Aid eligibility is captured where required by applicable regulation
• Practices may optionally match patient donations
• All donation events are logged as Reward Transactions and surfaced in dashboards

7. AI Boundaries (Non-Negotiable)

This module embeds AI Aiden in an advisory, guard-railed capacity.

AI MAY:

• Surface insights to staff — e.g. referrals stalling at a consistent stage, high volumes of unredeemed rewards, patients with available credit who have not attended recently, reward types with low utilisation
• Suggest which referrals or rewards warrant human follow-up
• Recommend nudge timing or messaging variants for human review and approval
• Flag expiring or overlooked entitlements

AI MAY NOT:

• Issue rewards or modify points balances
• Change referral or reward rules
• Contact patients autonomously without explicit staff configuration and consent
• Auto-approve or bypass any governance, audit, or access check
• Replace required clinical or managerial judgement on reward eligibility

All AI actions MUST be:

• Transparent and attributable
• Logged in the audit trail with the suggestion presented and the human decision recorded
• Subject to human control at every step

8. Audit & Compliance

The system MUST log:

• All Reward Transaction events (earn, redeem, adjustment, donation) with actor ID and timestamp
• All Referral state transitions, including the channel of share and the actor triggering each transition
• All Redemption state transitions with actor and justification
• Manual point adjustments with mandatory reason note and authorising actor
• All AI suggestions surfaced to staff, including whether accepted or rejected
• All cross-module events emitted or consumed (earning triggers from Appointment Manager, notifications to Communication Hub, handoff outcomes from Loyalty Insights, redemption confirmation events from Integrated Payments)
• All staff-initiated outreach actions logged against the patient or referral record
• Charity donation events including Gift Aid eligibility capture

Audit logs MUST be:

• Immutable and append-only; no record may be modified or deleted
• Timestamped and user-attributed
• Exportable for compliance inspection

Compliance constraints (locked):

• Rewards MUST NOT bias clinical advice or be presented in a way that could influence clinical decisions
• NHS treatments are excluded from accrual by default
• Marketing versus service messaging distinctions are respected
• Per-patient opt-out from the rewards programme MUST be supported and honoured immediately

9. Access Control

Access control is enforced via Access Manager roles. The following table describes the minimum role-based permissions this module requires; specific role names are defined in Access Manager.

Rules:

• Manual point adjustments require a mandatory reason note and are audit-logged
• No module other than Rewards Manager may mutate the points ledger
• MFA requirements for sensitive operations (e.g. manual adjustments above a configurable threshold) are governed by Access Manager policy.

10. Delivery Surfaces & Access (Authoritative)

10.1 Patient Mobile App

The primary surface. Patients can:

• View their points balance and transaction history
• Browse available redemption options enabled by the practice
• Initiate redemptions
• Generate, share, and track their referral link
• Opt out of the rewards programme
• View tier status, badges, and milestones if configured

10.2 Web Portal (Staff)

Staff can access:

• Patient rewards summary within the patient record (balance, recent earn/redemption events, active entitlements)
• The Rewards & Referrals Management Dashboard (see §11)
• Manual adjustment workflow (restricted roles)
• Staff-initiated outreach via Communication Hub

10.3 Tablet App

Staff may view a patient's current points balance and active entitlements at the point of care to support assisted redemption workflows; full dashboard access is available via the web portal.

10.4 Engagement Signals

The module emits the following signals for staff visibility and downstream analytics:

• Reward earn events (type, points, trigger)
• Redemption events (type, points, state)
• Referral pipeline state changes
• Charity donation events
• AI insight surfacing events (logged for transparency)

11. Rewards & Referrals Management Dashboard (Required)

Rewards Manager MUST expose a dedicated operational dashboard for staff.

11.1 Rewards Overview

The dashboard MUST display:

• Total points issued, redeemed, and outstanding
• Active rewards and entitlements (available, redeemed, expired)
• Pending redemptions awaiting staff action
• Charity donations and matched giving summaries

Each metric MUST support click-through into underlying records.

11.2 Referral Tracking Pipeline

Referral activity MUST be displayed using the state pipeline defined in §3.4.

The dashboard MUST allow staff to filter and drill into:

• Referrals by share channel (to measure channel effectiveness)
• Referrals where invites were shared but not claimed
• Referrals with registered patients who have not yet booked
• Referrals where rewards are issued but not redeemed

The system MUST record and display:

• Channel type, timestamp of share, and timestamp of first view
• Whether consent was captured for follow-up messaging

12. Integration Contracts

12.1 Inbound (this module consumes from)

12.2 Outbound (this module emits to)

12.3 PMS Boundary

The PMS owns clinical records. Rewards Manager does not read from or write to clinical records. Reward credit offsets against invoices or treatment charges are communicated to the PMS via staff-assisted application or PMS adjustment workflows; Rewards Manager does not directly mutate PMS financial records.

13. Integration Summary

• Appointment Manager — inbound attendance events that trigger earn transactions and referral state transitions
• Recall & Reconnect — inbound recall compliance events that trigger earn transactions
• Care Plan Subscriptions — inbound plan-lifecycle events (enrolment, suspension, cancellation) that trigger or suppress earn transactions; Rewards Manager owns all accrual decisions
• Hygiene Subscriptions — inbound subscription-lifecycle events (enrolment, suspension, cancellation) that trigger or suppress earn transactions; Rewards Manager owns all accrual decisions
• Product Shop — inbound purchase events for earn; outbound fulfilment instructions for product redemptions
• Integrated Payments — inbound Captured payment events triggering payment-linked earn transactions; inbound redemption confirmation events triggering checkout credit Reward Transactions; outbound credit balance query enabling automated checkout redemption (optional)
• Communication Hub — outbound notification triggers for all reward, referral, and nudge events
• Performance Dashboards — outbound engagement metrics: referral conversions by stage and channel, reward utilisation by type, points issued and redeemed, charity donation totals
• Loyalty Insights — outbound outcome events for cohort analysis (read-only consumption, never writes back); inbound handoff initiations requiring outcome logging
• Access Manager — RBAC enforcement for all read/write/adjust operations
• Campaign Manager — explicitly out of scope; promotions are not owned by Rewards Manager

14. Non-Functional Requirements

• Performance: Points ledger reads (balance, recent transactions) MUST return within 500 ms at the 95th percentile under normal load. Earn event processing MUST complete within 2 seconds of the triggering event being received.
• Reliability: The module MUST target 99.9% availability. Earn event processing MUST be idempotent; duplicate trigger events MUST NOT produce duplicate transactions. Graceful degradation MUST allow patients to view their current balance even if real-time earn processing is temporarily unavailable.
• Scalability: The ledger and transaction model MUST support multi-practice, multi-tenant deployment. Per-practice configuration MUST be fully isolated.
• Security: All patient rewards data MUST be encrypted at rest and in transit. Manual adjustment operations MUST require re-authentication or elevated session confirmation per Access Manager policy. Reward abuse detection signals MUST NOT expose other patients' data.
• Privacy: The module MUST honour patient opt-out from the rewards programme immediately and completely. Points history retained after opt-out MUST comply with the platform's data retention policy. GDPR subject access and erasure requests are handled in accordance with platform-wide privacy governance.
• Observability: The module MUST export metrics covering: earn event throughput, redemption confirmation latency, referral pipeline stage counts, AI suggestion acceptance rate, and manual adjustment frequency. Structured logs MUST be emitted for every state transition on all canonical objects. Distributed traces MUST cover the earn-event path from trigger ingestion to ledger commit.

15. Explicit Non-Goals

• Issuing cash or operating a financial payment instrument (Integrated Payments, if required)
• Acting as a promotions or campaigns engine (Campaign Manager)
• Aggregating programme-level behavioural analytics and cohort reporting (Loyalty Insights)
• Modifying clinical records in any form (PMS)
• Operating a third-party loyalty marketplace or card-based scheme
• Fulfilling product inventory and dispatch for product redemptions (Product Shop)
• Calculating or validating reward accrual on behalf of Care Plan Subscriptions or Hygiene Subscriptions

16. Versioning & Governance

This specification is owned by: the Rewards Manager module owner.

Changes to this spec require:

• Review by the Post-MVP module owner
• Impact analysis across all declared related modules (see /propose)
• Version bump (patch for clarifications, minor for capability changes, major for breaking contract changes)

17. Build Contract (Engineering & QA)

17.1 Canonical Data Model

(No schema DDL captured in original — the following represents the canonical objects defined in §3. Full table definitions to be authored by engineering during build.)

Objects defined:

• points_ledger — one record per patient per practice
• reward_transaction — immutable append-only log of all points events
• referral — one record per referral invitation
• redemption — one record per redemption exercise

All objects MUST carry an immutable audit_trail column and a created_at timestamp. Foreign key relationships follow the hierarchy: patient → ledger → transaction / referral / redemption.

17.2 Core Behaviour Rules

1. A patient's PointsBalance MUST always equal PointsEarned minus PointsRedeemed as derived from the immutable TransactionHistory; it MUST NOT be stored as a mutable field that can be set independently.
2. A Reward Transaction MUST be created for every points event; no points may move without a corresponding immutable transaction record.
3. Points deduction on redemption MUST be atomic; if the deduction cannot complete, the redemption MUST fail and no state change occurs.
4. A referral reward transaction MUST NOT be created unless the linked Referral record has reached the Attended state.
5. Self-referral MUST be blocked at the point of referral code generation and again at registration of the referred patient.
6. Manual point adjustments MUST require a non-empty ReasonNote and an authorised actor; they MUST be rejected silently to any caller lacking the required role.
7. Duplicate trigger events (e.g. duplicate attendance webhook, duplicate Captured payment event) MUST be detected and suppressed; only one earn transaction per unique trigger event MUST be committed.
8. Patient opt-out MUST immediately suppress all future earn events and remove the patient from referral nudge sequences; existing balances remain visible to staff in the audit record.
9. NHS treatment appointment events MUST be excluded from earn triggers unless the practice has explicitly enabled this (configurable, off by default).
10. All AI suggestions surfaced to staff MUST generate an AI event log record capturing the suggestion type, the presenting data, and the human response.
11. Payment-linked earn events MUST only be triggered on receipt of a Captured payment event from Integrated Payments; Initiated and Authorised payment events MUST NOT trigger earn transactions.
12. Plan-participation earn events triggered by Care Plan Subscriptions or Hygiene Subscriptions enrolment events MUST be suppressed for the duration of any suspension period and permanently ceased on cancellation, unless the practice has explicitly configured a cancellation earn reward.
13. Redemption confirmation events received from Integrated Payments MUST be recorded as Reward Transactions with InitiatedBy set to integrated-payments; the same atomic deduction and duplicate-suppression rules apply as for any other redemption.

17.3 Configuration Surfaces

17.4 Filtering & Views

The Rewards & Referrals Dashboard MUST support filtering by:

• Date range
• Referral state
• Share channel
• Redemption type
• Points range
• Individual patient

Saved filter views MUST be persistable per staff user.

17.5 Module Extension Map

• Recognition layer tiers are additive; future tier models can be introduced without modifying the ledger schema
• Additional earning behaviour types can be added by extending the TriggerEvent enumeration without altering existing transaction records
• Additional redemption types can be added without modifying the Redemption state machine
• Loyalty Insights integration is additive; the module emits events regardless of whether Loyalty Insights is enabled
• Integrated Payments integration is additive; the module operates in staff-assisted manual mode when Integrated Payments is not enabled

17.6 Acceptance Criteria

The build of Rewards Manager is complete when:

• [ ] All canonical objects (Points Ledger, Reward Transaction, Referral, Redemption) can be created, read, and updated through the API
• [ ] State machine transitions for Referral (§3.4) and Redemption (§3.6) enforce all defined rules; invalid transitions are rejected
• [ ] Points accrual fires automatically and idempotently from all configured trigger events
• [ ] Referral rewards are not issued until the Attended state is confirmed (negative test: reward MUST NOT issue on registration or booking alone)
• [ ] Redemption is atomic; a failed deduction leaves the ledger unchanged
• [ ] Self-referral blocking and referral cap enforcement are verified by automated tests
• [ ] Charity donation events are logged correctly and surfaced in dashboards
• [ ] Staff visibility (patient record summary and Rewards & Referrals Dashboard) operates end-to-end
• [ ] Patient opt-out suppresses earn events immediately (verified by integration test)
• [ ] All integrations in §12 are wired and tested
• [ ] AI boundaries in §7 are enforced; negative tests confirm AI cannot issue rewards or modify balances
• [ ] Audit log captures every event category in §8; logs are immutable and exportable
• [ ] Access control is enforced per §9; unauthorised operations return appropriate rejections
• [ ] Core functionality operates without Integrated Payments, Product Shop, or Loyalty Insights enabled
• [ ] All non-functional requirements in §14 are met and evidenced by load and latency tests
• [ ] Payment-linked earn events are suppressed for Initiated and Authorised payment states; earn is triggered only on Captured (negative and positive tests)
• [ ] Integrated Payments redemption confirmation events are recorded as Reward Transactions with correct actor attribution and are subject to duplicate suppression
• [ ] Plan-suspension events from Care Plan Subscriptions and Hygiene Subscriptions suppress earn accrual for the suspension period; cancellation events permanently suppress accrual (verified by integration tests)
• [ ] Loyalty Insights signal emission is verified end-to-end; Loyalty Insights read-only boundary is confirmed by negative test (no write path from Loyalty Insights to Rewards Manager exists)
• [ ] Performance Dashboards receives referral conversion and reward utilisation metrics via the outbound event contract

18. Open Questions

1. Nudge consent model: The original states that nudges to referred individuals are subject to consent, but does not define where or how consent is captured for non-registered referred individuals — this needs a decision before the referral nudge feature can be built.
2. Gift Aid compliance: The original flags Gift Aid eligibility capture but does not specify the data fields required or the regulatory jurisdiction assumed — this requires legal/compliance sign-off before the charity donation feature is finalised.
3. Duplicate account detection: The original mandates duplicate account detection as an abuse-prevention safeguard but does not define the detection algorithm or the signals used — engineering needs a definition before implementation.
4. NHS treatment exclusion scope: The original states NHS treatments may be excluded from accrual but leaves the definition of "NHS treatment" ambiguous in a mixed NHS/private practice context — a configurable definition or classification approach needs to be agreed.
5. Referral cap default value: The original states referral caps are configurable per practice but does not specify a recommended or enforced default — a safe default needs to be defined before release.
6. Integrated Payments event schema: The precise schema for the Captured payment event and the redemption confirmation event emitted by Integrated Payments has not been formally agreed — a joint contract definition between Rewards Manager and Integrated Payments engineering is required before the payment-linked earn and automated checkout features can be built.
7. Plan-lifecycle event schema: The exact event schema emitted by Care Plan Subscriptions and Hygiene Subscriptions for enrolment, suspension, and cancellation has not been formally specified — a cross-module contract definition is required before plan-participation accrual rules can be implemented.