MATCH Flow App: Product Requirements Document

Executive Summary

The MATCH Flow App transforms the MATCH Framework from a static checklist into a dynamic, verb-based decision support system. Rather than asking users "What do you own?" (inventory-based), the app asks "How do you think?" (logic-based).

This PRD provides developers with the core logic flows, functional requirements, data architecture, and technical priorities needed to build an app that feels like a navigation tool, not a medical chart.

The fundamental innovation: Every MATCH Pillar is a variable. If one variable fails, the app programmatically suggests "boosts" to the remaining four.

Part 1: The Core Logic – The "If-Then" Engine

1.1 Primary Design Principle: Redundancy Protocol

The app's architecture is built on a single rule:

The Goal: Transform the user's experience from panic ("I failed") to agency ("Here's my backup plan").

1.2 If-Then Logic Trees

The developer must implement these core decision trees as the app's decision engine:

Scenario 1: Tools Fail (Barrier Breach)

Scenario 2: Medications Fail (Missed Dose)

Scenario 3: Communication Fails (Boundary Breach)

Scenario 4: Awareness Fails (Status Unknown)

Scenario 5: Habits Fail (Supply Shortage)

Part 2: Functional Requirements – The "Verb" Features

The developer must prioritize these three interactive modules as the core of the app:

2.1 Module A: The "Stress Test" Simulator

Function: A randomized scenario generator that trains users to adapt their MATCH plan when pieces break.

Core Requirement: Create a database of "Constraints" that overlay on the user's saved MATCH plan. Users toggle their MATCH pillars to test if they remain "SafER" under pressure.

Constraints Database

Success Criteria:

• At least 20 unique constraint combinations available
• Constraints load from local database (offline-capable)
• User can toggle pillars and see real-time "SafER" score
• Scenarios reflect diverse relationship types, substances, and environments

2.2 Module B: The "Live Session" HUD

Function: A pre-event configuration tool that generates a "Priority Pillar" recommendation for a specific night.

Core Requirement: A 3-step intake form that captures context and outputs a personalized shield recommendation.

The 3 Steps

1. Environment Scan: Where are you going? Will there be substances? Social context? Privacy level?
2. Mindset Assessment: Current mental state? Emotional energy? What are you seeking (connection/pleasure)?
3. Partner Context: Partner familiarity? Do you know their status? Communication comfort?

Success Criteria:

• Form completes in less than 2 minutes
• Personalized output feels relevant and actionable
• User can save session and return to it later
• Session data feeds into post-encounter habit logging

2.3 Module C: Script & Resource Library

Function: Instant access to situational language mapped to specific "Friction Points."

Core Requirement: Create a searchable, categorized library of Pocket Scripts and Conversation Starters linked to specific barriers they address.

Friction Point Categories

Success Criteria:

• 30+ base scripts covering all friction points
• Scripts are tested by real users and feedback-refined
• Search and filter work offline
• User can copy or customize scripts in less than 10 seconds
• Generated scripts feel natural, not robotic

Part 3: Data & Content Assets

The developer should structure the app's database around these content repositories:

3.1 Framework Definitions: The MATCH System

The app's data architecture should follow this schema structure:

3.2 Educational Content References

Pull content from HARNESS Curriculum Modules 2-3:

• Medical Shields: How PrEP works, U=U concept, vaccine efficacy, window periods
• Sexual Barriers: Condom application, lube's role, internal vs. external options
• Consent FRIES: Freely given, Reversible, Informed, Enthusiastic, Specific

3.3 Emergency Logic & Guides

Implement these critical decision trees:

• PEP Protocol: 72-hour countdown, clinic finder, testing schedule
• STI Exposure: Doxy-PEP window, testing timelines
• Clinic Finder: Geolocation for 24-hour ERs, sexual health clinics, LGBTQ+ affirming providers

Part 4: Technical Priorities for the Developer

4.1 Privacy First: Local-First Architecture

Critical Requirement: The app must prioritize user privacy above all else.

4.2 Offline Access: Robust Disconnected Functionality

Critical Requirement: The app must work seamlessly without internet.

4.3 UI/UX: Navigation Tool, Not Medical Chart

Design Philosophy: The interface should feel like a decision-making tool your friends would use, not a clinical form.

Visual Direction: Use HARNESS Visual Toolkit branding with bold, energetic colors (Safety Orange, Electric Yellow, Deep Purple) and dark mode as default.

Part 5: Development Roadmap & Priority Matrix

5.1 Phase 1: Core Foundation (MVP)

Priority: Must-have for launch

• If-Then decision engine (Redundancy Protocol)
• Live Session HUD (3-step intake + shield output)
• Basic MATCH Framework data structure
• Basic Script Library (15+ scripts)
• Stress Test (10 randomized scenarios)
• Local storage and offline functionality
• Privacy-first architecture (encrypted storage)

Estimated Effort: 8-12 weeks

5.2 Phase 2: Gamification & Polish

Priority: High-value features for engagement

• Stress Test streak tracking and badges
• Personalized MATCH plan builder
• Session history and analytics
• Advanced script customization
• UI/UX refinement

Estimated Effort: 4-6 weeks

5.3 Phase 3: Advanced Features

Priority: Future expansion

• Clinic Finder with geolocation
• PEP Timer with push notifications
• Health data integration (HIPAA)
• Optional cloud backup with end-to-end encryption
• Community features (peer support)

Estimated Effort: 6-10 weeks

Part 6: Testing & Validation

6.1 User Testing Requirements

Before launch, validate:

• If-Then Logic: Redundancy Protocol correctly suggests boosts
• Scenario Realism: Real users test Stress Test scenarios for accuracy
• Script Naturalness: Pocket Scripts feel conversational
• Offline Functionality: All critical features work without internet
• Privacy Assurance: Encrypted data is secure

6.2 Accessibility Compliance

• WCAG 2.1 AA compliance (minimum)
• High contrast mode support
• Screen reader optimization
• Keyboard navigation (no mouse required)

Part 7: Developer Handoff Checklist

Before beginning development, ensure the developer has:

• Reviewed the HARNESS Curriculum, especially "Optimizing the MATCH Framework"
• Read and understood this PRD completely
• Reviewed the MATCH Flow App concept page
• Confirmed understanding of If-Then decision logic
• Reviewed the Visual Toolkit branding guidelines
• Set up development environment with offline testing
• Established testing protocol with real users

Key Resources for Developer Reference

• HARNESS Curriculum Hub: Focus on "Optimizing the MATCH Framework" section
• Visual Toolkit Branding: Color, typography, and design metaphors
• Redundancy Logic Trees: Core decision flows
• If-Then Scenario Examples: Foundational logic patterns
• Script & Friction Points: Content reference for library structure

Conclusion

The MATCH Flow App transforms sexual health from static documentation into dynamic, decision-based practice. By prioritizing verb-based logic, If-Then redundancy, and fearless, non-judgmental language, the app empowers users to navigate real-world complexity with confidence.

The developer's role is to translate this strategic blueprint into an intuitive, private, offline-capable tool that feels less like a medical app and more like a trusted decision-making companion.

Stay fearless. Build resilience. Empower choice.