Detect Duplicates Across Chapter Boundaries
Peer mentors in NHF may belong to up to five chapters simultaneously. When a peer mentor registered under Chapter A logs an activity, and a coordinator from Chapter B separately logs what appears to be the same activity for the same peer mentor on the same day, both coordinators should be alerted. Cross-chapter activity queries must be performed at submission time using the peer mentor's full multi-chapter membership context. The detection logic must also run retroactively when a peer mentor is added to a second chapter after existing activities are present.
User Story
Audience Summaries
This story addresses a critical reporting accuracy risk unique to NHF's multi-chapter membership model. Because a single peer mentor can belong to up to five chapters simultaneously, a single one-hour activity could be logged independently by coordinators in multiple chapters, potentially appearing five times in Bufdir reports. This misrepresentation of service volume is not a minor data quality issue — it is a potential funding compliance violation that could damage NHF's standing with Bufdir and undermine the credibility of national-level reporting. Implementing cross-chapter duplicate detection at submission time and retroactively when affiliations change ensures that reported figures accurately reflect real peer support delivered, protecting both the organization's integrity and its continued access to public funding.
This is a high-complexity, high-priority story with significant cross-functional scope. The detection logic must query activity history across chapter boundaries at submission time, requiring the API to resolve the submitting peer mentor's full multi-chapter membership context before saving. A second trigger is needed for retroactive detection when a peer mentor gains a new chapter affiliation — this is an event-driven background job, not a synchronous UI action, and needs careful scheduling and error handling. Dependencies on story-duplicate-activity-detection-coordinator-1 mean this story cannot be started in isolation.
UAT requires test scenarios involving peer mentors registered across multiple chapters with overlapping activity dates. Coordination with the deduplication queue story (387) is essential since detected cross-chapter conflicts must flow into the same queue UI.
Implementation requires extending the duplicate detection service to accept a peer mentor's full chapter membership list as context when evaluating a new activity submission. The cross-chapter query must join activities, registrations, and chapter_memberships to find matching records by peer mentor ID, activity type, and date across all affiliated chapters — not just the submitting chapter. A second code path is needed: when a new chapter affiliation is created, a background job must re-evaluate the peer mentor's existing activity history for cross-chapter conflicts and insert flagged pairs into the deduplication queue. The 'Assign to My Chapter' resolution action requires a dedicated mutation that updates the activity's chapter ownership, writes an audit log entry, and clears the duplicate flag.
Performance must be validated for peer mentors with dense activity histories across multiple chapters.
Acceptance Criteria
- Given a peer mentor belongs to two chapters, When a coordinator in Chapter B registers an activity that matches an existing activity logged under Chapter A for the same peer mentor, Then a duplicate warning is triggered referencing the Chapter A record
- Given a cross-chapter duplicate warning is displayed, When the coordinator views it, Then the warning clearly states which chapter the conflicting record belongs to and who registered it
- Given a peer mentor is added to a second chapter, When the system processes the new chapter affiliation, Then a retroactive duplicate check runs against the peer mentor's existing activity history and flags any cross-chapter conflicts into the deduplication queue
- Given the coordinator resolves a cross-chapter duplicate by selecting 'Assign to My Chapter', Then the activity is credited only to the coordinator's chapter and a log entry is written for audit purposes
- Given cross-chapter detection runs, When no conflicts are found, Then no warnings are shown and the submission proceeds normally
Business Value
Multi-chapter membership is a structural reality in NHF with 1,400 chapters. Without cross-chapter duplicate detection, a single peer mentor's one-hour activity could appear in Bufdir reports for five separate chapters, quintupling the apparent volume of peer support delivered. This misrepresentation risks NHF's credibility with Bufdir and could constitute a funding compliance violation.
Components
- Duplicate Activity Warning Dialog ui
- Duplicate Activity Detection Service service
- Cross-Chapter Activity Query data
- Supabase Contact Chapter Adapter infrastructure
- Duplicate Warning Event Logger infrastructure
- Duplicate Detection Service service
- Duplicate Check Repository data
- Duplicate Activity Detector infrastructure
- Contact Chapter Repository data
- Multi-Chapter Membership Service service