neotoma 0.3.0 → 0.3.2

package/docs/releases/archived/aspirational/v1.0.0/business_viability_discovery_plan.md

@@ -1,135 +0,0 @@
-## Release v1.0.0 — Business Viability Discovery Plan
-### Purpose
-This document defines the business viability discovery activities for v1.0.0, focused on validating that AI-Native Individual Operators will pay €25-€125/month for MVP to give Claude/ChatGPT access to their personal data via MCP.
-**Related Documents:**
-- `discovery_plan.md` — Discovery overview and coordination
-- `value_discovery_plan.md` — Value discovery activities
-- `usability_discovery_plan.md` — Usability discovery activities
-- `participant_recruitment_log.md` — Participant tracking
-### 1. Hypothesis and Assumptions
-**Hypothesis:** "AI-Native Individual Operators will pay €25-€125/month for MVP to give Claude/ChatGPT access to their personal data via MCP"
-**Assumptions:**
-- Tier 1 ICP values AI-native personal data access enough to pay
-- MCP access is a key differentiator justifying premium pricing
-- Monthly subscription is preferred over one-time payment
-- €25-€125 range aligns with perceived value of AI-native workflow
-- Problem + solution validated before testing pricing
-### 2. Discovery Method
-**Method**: Willingness-to-pay interviews (live, Mom Test methodology)
-**Why Live Required:**
-- Must probe past purchasing behavior: "Tell me about tools you've purchased..." requires follow-up
-- Van Westendorp Price Sensitivity Meter: Requires conversation to contextualize price responses
-- Detect commitment signals: Budget allocation, switching costs need conversation to validate
-- Understand value drivers: "What would make you pay?" requires probing to understand true drivers
-- Avoid false positives: People overstate willingness to pay on surveys
-### 3. Participants
-- **Segment**: AI-Native Individual Operators
-- **Count**: 8 participants
-- **Recruitment**: Subset from value discovery participants (those expressing high interest AND commitment signals AND actual AI usage patterns)
-### 4. Precondition
-**Only conduct pricing interviews AFTER problem validated (AI lacks personal data access) AND solution addresses it (MCP solves workflow)**
-### 5. Interview Structure
-**Duration**: 20-30 minutes per interview
-#### Section 1: Past Purchasing Behavior (Start Here)
-**Goal**: Understand past behavior related to AI tools and productivity tools, not hypothetical willingness to pay
-**Questions:**
-1. "Tell me about tools you've purchased to improve how you work with AI or access your data."
-   - Follow-ups:
-     - What tools did you buy? (AI tools, data access tools, productivity tools)
-     - What did you pay for them?
-     - What made you decide to pay?
-     - Are you still using them? Why or why not?
-2. "What tools have you tried for giving AI access to your data but didn't pay for? Why didn't you pay?"
-   - Follow-ups:
-     - What was missing?
-     - What would have made you pay?
-     - What price would have changed your mind?
-3. "Walk me through your current productivity and AI tool stack."
-   - Follow-ups:
-     - What AI tools do you pay for? (Claude Pro, ChatGPT Plus, etc.)
-     - What productivity tools do you pay for?
-     - What do you pay for each?
-     - How do you decide what's worth paying for?
-     - What's your monthly budget for productivity and AI tools?
-#### Section 2: Willingness to Pay (Based on Past Behavior)
-**Questions:**
-1. "If this gave Claude/ChatGPT access to your personal data via MCP and solved [validated problem - preparing data manually], how would you decide whether to pay for it?"
-   - Follow-ups:
-     - What would need to be true?
-     - What features would be must-have?
-     - How would you justify the cost?
-     - How much time/money would this need to save you?
-2. "Tell me about tools similar to this that you've evaluated — tools that connect AI to your data."
-   - Follow-ups:
-     - What did you look at?
-     - What did they cost?
-     - Why didn't you buy them? (or why did you?)
-3. "If this existed today at [price point], would you switch from your current workaround (copy-paste, manual prep)?"
-   - Follow-ups:
-     - What would make you switch?
-     - What would prevent you from switching?
-     - How long would you evaluate before deciding?
-#### Section 3: Price Sensitivity (Van Westendorp with Past Behavior Context)
-**Approach**: Van Westendorp Price Sensitivity Meter with past behavior context
-**Questions:**
-1. "Given that you pay €X for [similar tool - Claude Pro, ChatGPT Plus, productivity tools], at what price would this be so expensive you wouldn't consider it?"
-2. "At what price would you consider it expensive but still consider buying?"
-3. "At what price would you consider it a bargain?"
-4. "At what price would it be so cheap you'd question the quality?"
-**Price Anchoring:**
-- For context: Claude Pro is $20/mo, ChatGPT Plus is $20/mo, productivity tools range from €10-€100/mo
-- MVP features: Upload documents, deterministic extraction, MCP access to Claude/ChatGPT, timeline view
-- Value: Save time preparing data for AI, enable new AI-native workflows
-#### Section 4: Commitment Signals
-**Questions:**
-- "What would make you cancel or stop using this?"
-- "Deal-breakers"
-- "What would make you switch to a competitor?"
-- "What problems would cause you to leave?"
-**Look For:**
-- Past purchasing behavior (actual subscriptions, not hypothetical)
-- Budget allocation (where they currently spend money)
-- Switching costs (from current workarounds)
-- Commitment signals (actual purchases, not hypothetical interest)
-### 6. Mom Test Principles
-**Methodology**: The Mom Test (https://www.momtestbook.com)
-**Question Framing**: Focus on past purchasing behavior for AI tools and productivity tools, not hypothetical willingness to pay
-**Commitment Signals:**
-- Past purchases of AI tools (Claude Pro, ChatGPT Plus)
-- Past purchases of productivity/data access tools
-- Budget allocation for AI and productivity tools
-- Switching costs from current workarounds (time, money)
-- Price sensitivity based on past behavior
-**Red Flags:**
-- Hypothetical interest without past purchasing evidence
-- Vague enthusiasm about pricing without commitment
-- Agreement without past behavior context
-- No actual paid tool usage
-### 7. Success Criteria
-- ≥50% express willingness to pay ≥€25/month (based on past purchasing behavior)
-- ≥30% express willingness to pay ≥€50/month
-- Optimal price point (PSM intersection) within €25-€125 range
-- ≥60% prefer monthly subscription over one-time
-- Clear value drivers for paying identified (time saved, new workflows enabled)
-- Past purchasing behavior aligns with target price point
-### 8. Timeline
-**Timeline**: Week -6 to Week -5
-**Schedule:**
-- Week -6: Schedule participants (subset from value discovery), prepare interview guide
-- Week -6 to -5: Conduct pricing interviews (8 participants)
-- Week -5: Synthesize findings, calculate PSM optimal price point
-### 9. Deliverable
-**Deliverable**: `business_viability_report.md`
-Includes:
-- Willingness-to-pay analysis
-- Van Westendorp Price Sensitivity Meter results (optimal price point)
-- Value drivers for paying
-- Past purchasing behavior analysis
-- Pricing model recommendations
-- Comparison against success criteria
-### 10. Related Documents
-- `discovery_plan.md` — Discovery overview and coordination
-- `value_discovery_plan.md` — Value discovery activities
-- `usability_discovery_plan.md` — Usability discovery activities
-- `participant_recruitment_log.md` — Participant tracking
-- `docs/feature_units/standards/discovery_process.md` — Discovery process standard

package/docs/releases/archived/aspirational/v1.0.0/compliance_reports/FU-100_compliance.md

@@ -1,23 +0,0 @@
-# FU-100 Compliance Report
-**Generated:** 2025-12-14T06:22:10.678Z
-## Summary
-- **Total Requirements:** 4
-- **✅ Passed:** 3
-- **❌ Failed:** 1
-- **Compliance Rate:** 75.0%
-## Requirements Status
-| Requirement | Location | Status | Evidence | Gap |
-|------------|----------|--------|----------|-----|
-| Rule-based schema detection (regex patterns per schema type) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/helpers.ts:      schema_version: "1.0",; src/__fixtures__/helpers.ts:      schema_version: "1.0", | - |
-| Rule-based field extraction (regex parsers per schema) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/validation.ts: * Validate fixture has required schema_version field; src/__fixtures__/validation.ts:    errors.push("Missing or invalid schema_version field"); | - |
-| PDFDocument fallback (not custom sanitized types) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/config/plaid.ts:function parseCommaSeparated(value: string | undefined, fallback: string[]): string[] {; src/config/plaid.ts:  if (!value) return fallback; | - |
-| code changes to comply with manifest** | Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References | ❌ Fail | - | Required but not found in codebase. Expected: code changes to comply with manifest** |
-## Implementation Gaps
-1. **Critical Gap:** code changes to comply with manifest**
-   - **Requirement:** Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References, line 1789
-   - **Current:** Not implemented
-   - **Required:** code changes to comply with manifest**
-   - **Files to modify:** [To be determined based on requirement]
-## Recommendations
-The following requirements need to be implemented before FU-100 can be marked as complete:
-- code changes to comply with manifest**

package/docs/releases/archived/aspirational/v1.0.0/compliance_reports/FU-101_compliance.md

@@ -1,23 +0,0 @@
-# FU-101 Compliance Report
-**Generated:** 2025-12-14T06:22:10.736Z
-## Summary
-- **Total Requirements:** 4
-- **✅ Passed:** 3
-- **❌ Failed:** 1
-- **Compliance Rate:** 75.0%
-## Requirements Status
-| Requirement | Location | Status | Evidence | Gap |
-|------------|----------|--------|----------|-----|
-| Rule-based schema detection (regex patterns per schema type) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/helpers.ts:      schema_version: "1.0",; src/__fixtures__/helpers.ts:      schema_version: "1.0", | - |
-| Rule-based field extraction (regex parsers per schema) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/validation.ts: * Validate fixture has required schema_version field; src/__fixtures__/validation.ts:    errors.push("Missing or invalid schema_version field"); | - |
-| PDFDocument fallback (not custom sanitized types) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/config/plaid.ts:function parseCommaSeparated(value: string | undefined, fallback: string[]): string[] {; src/config/plaid.ts:  if (!value) return fallback; | - |
-| code changes to comply with manifest** | Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References | ❌ Fail | - | Required but not found in codebase. Expected: code changes to comply with manifest** |
-## Implementation Gaps
-1. **Critical Gap:** code changes to comply with manifest**
-   - **Requirement:** Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References, line 1789
-   - **Current:** Not implemented
-   - **Required:** code changes to comply with manifest**
-   - **Files to modify:** [To be determined based on requirement]
-## Recommendations
-The following requirements need to be implemented before FU-101 can be marked as complete:
-- code changes to comply with manifest**

package/docs/releases/archived/aspirational/v1.0.0/compliance_reports/FU-102_compliance.md

@@ -1,23 +0,0 @@
-# FU-102 Compliance Report
-**Generated:** 2025-12-14T06:22:10.789Z
-## Summary
-- **Total Requirements:** 4
-- **✅ Passed:** 3
-- **❌ Failed:** 1
-- **Compliance Rate:** 75.0%
-## Requirements Status
-| Requirement | Location | Status | Evidence | Gap |
-|------------|----------|--------|----------|-----|
-| Rule-based schema detection (regex patterns per schema type) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/helpers.ts:      schema_version: "1.0",; src/__fixtures__/helpers.ts:      schema_version: "1.0", | - |
-| Rule-based field extraction (regex parsers per schema) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/validation.ts: * Validate fixture has required schema_version field; src/__fixtures__/validation.ts:    errors.push("Missing or invalid schema_version field"); | - |
-| PDFDocument fallback (not custom sanitized types) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/config/plaid.ts:function parseCommaSeparated(value: string | undefined, fallback: string[]): string[] {; src/config/plaid.ts:  if (!value) return fallback; | - |
-| code changes to comply with manifest** | Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References | ❌ Fail | - | Required but not found in codebase. Expected: code changes to comply with manifest** |
-## Implementation Gaps
-1. **Critical Gap:** code changes to comply with manifest**
-   - **Requirement:** Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References, line 1789
-   - **Current:** Not implemented
-   - **Required:** code changes to comply with manifest**
-   - **Files to modify:** [To be determined based on requirement]
-## Recommendations
-The following requirements need to be implemented before FU-102 can be marked as complete:
-- code changes to comply with manifest**

package/docs/releases/archived/aspirational/v1.0.0/compliance_reports/FU-103_compliance.md

@@ -1,23 +0,0 @@
-# FU-103 Compliance Report
-**Generated:** 2025-12-14T06:22:10.851Z
-## Summary
-- **Total Requirements:** 4
-- **✅ Passed:** 3
-- **❌ Failed:** 1
-- **Compliance Rate:** 75.0%
-## Requirements Status
-| Requirement | Location | Status | Evidence | Gap |
-|------------|----------|--------|----------|-----|
-| Rule-based schema detection (regex patterns per schema type) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/helpers.ts:      schema_version: "1.0",; src/__fixtures__/helpers.ts:      schema_version: "1.0", | - |
-| Rule-based field extraction (regex parsers per schema) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/validation.ts: * Validate fixture has required schema_version field; src/__fixtures__/validation.ts:    errors.push("Missing or invalid schema_version field"); | - |
-| PDFDocument fallback (not custom sanitized types) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/config/plaid.ts:function parseCommaSeparated(value: string | undefined, fallback: string[]): string[] {; src/config/plaid.ts:  if (!value) return fallback; | - |
-| code changes to comply with manifest** | Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References | ❌ Fail | - | Required but not found in codebase. Expected: code changes to comply with manifest** |
-## Implementation Gaps
-1. **Critical Gap:** code changes to comply with manifest**
-   - **Requirement:** Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References, line 1789
-   - **Current:** Not implemented
-   - **Required:** code changes to comply with manifest**
-   - **Files to modify:** [To be determined based on requirement]
-## Recommendations
-The following requirements need to be implemented before FU-103 can be marked as complete:
-- code changes to comply with manifest**

package/docs/releases/archived/aspirational/v1.0.0/compliance_reports/FU-105_compliance.md

@@ -1,23 +0,0 @@
-# FU-105 Compliance Report
-**Generated:** 2025-12-14T06:22:10.905Z
-## Summary
-- **Total Requirements:** 4
-- **✅ Passed:** 3
-- **❌ Failed:** 1
-- **Compliance Rate:** 75.0%
-## Requirements Status
-| Requirement | Location | Status | Evidence | Gap |
-|------------|----------|--------|----------|-----|
-| Rule-based schema detection (regex patterns per schema type) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/helpers.ts:      schema_version: "1.0",; src/__fixtures__/helpers.ts:      schema_version: "1.0", | - |
-| Rule-based field extraction (regex parsers per schema) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/__fixtures__/validation.ts: * Validate fixture has required schema_version field; src/__fixtures__/validation.ts:    errors.push("Missing or invalid schema_version field"); | - |
-| PDFDocument fallback (not custom sanitized types) | Neotoma MVP Feature Units — Execution Plan > Execution Order and Dependencies > Phase 1: Core Services (Domain Layer) > FU-100: File Analysis Service | ✅ Pass | src/config/plaid.ts:function parseCommaSeparated(value: string | undefined, fallback: string[]): string[] {; src/config/plaid.ts:  if (!value) return fallback; | - |
-| code changes to comply with manifest** | Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References | ❌ Fail | - | Required but not found in codebase. Expected: code changes to comply with manifest** |
-## Implementation Gaps
-1. **Critical Gap:** code changes to comply with manifest**
-   - **Requirement:** Neotoma MVP Feature Units — Execution Plan > Detailed Documentation References, line 1789
-   - **Current:** Not implemented
-   - **Required:** code changes to comply with manifest**
-   - **Files to modify:** [To be determined based on requirement]
-## Recommendations
-The following requirements need to be implemented before FU-105 can be marked as complete:
-- code changes to comply with manifest**

package/docs/releases/archived/aspirational/v1.0.0/continuous_discovery_log.md

@@ -1,77 +0,0 @@
-## Release v1.0.0 — Continuous Discovery Log
-### Purpose
-Track continuous discovery activities during v1.0.0 development:
-- Weekly user interviews (2-3 users per week)
-- Prototype testing after UI FUs
-- Beta testing in final weeks
-- Key learnings and adjustments
-### Timeline
-- **Start**: Week 0 (development start)
-- **End**: Week 12 (pre-deployment)
-- **Frequency**: Weekly interviews, prototype tests after UI FUs
-### Discovery Activities
-#### Week 0-3 (Batch 0)
-**Planned Activities:**
-- Week 1: User interviews on upload workflows (2-3 users)
-- Week 2: User interviews on file type preferences (2-3 users)
-- Week 3: Prototype testing on upload UI (3-5 users)
-**Findings:**
-_To be filled during execution_
-**Adjustments:**
-_To be filled during execution_
-#### Week 3-6 (Batch 1)
-**Planned Activities:**
-- Week 4: User interviews on entity/event understanding (2-3 users)
-- Week 5: User interviews on timeline expectations (2-3 users)
-- Week 6: Prototype testing on entity/event views (3-5 users)
-**Findings:**
-_To be filled during execution_
-**Adjustments:**
-_To be filled during execution_
-#### Week 6-9 (Batch 2)
-**Planned Activities:**
-- Week 7: User interviews on graph/timeline views (2-3 users)
-- Week 8: User interviews on search expectations (2-3 users)
-- Week 9: Prototype testing on timeline view (3-5 users)
-**Findings:**
-_To be filled during execution_
-**Adjustments:**
-_To be filled during execution_
-#### Week 9-11 (Batch 3)
-**Planned Activities:**
-- Week 10: User interviews on MCP usage patterns (2-3 users)
-- Week 11: Prototype testing on full workflow (3-5 users)
-**Findings:**
-_To be filled during execution_
-**Adjustments:**
-_To be filled during execution_
-#### Week 11-12 (Beta Testing)
-**Planned Activities:**
-- Invite discovery participants + early access signups
-- Private beta with 25 users
-- End-to-end workflow testing
-- Bug reporting and feedback collection
-**Findings:**
-_To be filled during execution_
-**Adjustments:**
-_To be filled during execution_
-### Summary of Key Learnings
-_To be synthesized at end of development (Week 12)_
-**Value Validation:**
-- [Key findings on value proposition]
-**Usability Insights:**
-- [Key findings on usability and workflow]
-**Feature Priorities:**
-- [Features users found most/least valuable]
-**Scope Adjustments:**
-- [Any features added/removed based on continuous discovery]
-### Participant Tracking
-| Week | Segment | Count | Activity | Status |
-|------|---------|-------|----------|--------|
-| 1 | AI-Native Operators | 2-3 | Interviews | Planned |
-| 2 | AI-Native Operators | 2-3 | Interviews | Planned |
-| 3 | Mixed | 3-5 | Prototype Test | Planned |
-| ... | ... | ... | ... | ... |
-### Status
-- **Current Status**: Not started (awaiting development kickoff)
-- **Owner**: Mark Hendrickson

package/docs/releases/archived/aspirational/v1.0.0/continuous_discovery_plan.md

@@ -1,145 +0,0 @@
-## Release v1.0.0 — Continuous Discovery Plan
-### Purpose
-This document defines the continuous discovery activities for v1.0.0 during development, focused on validating MCP workflow assumptions, gathering feedback on completed features, and testing AI query scenarios.
-**Related Documents:**
-- `discovery_plan.md` — Discovery overview and coordination
-- `value_discovery_plan.md` — Value discovery activities
-- `usability_discovery_plan.md` — Usability discovery activities
-- `continuous_discovery_log.md` — Continuous discovery tracking template
-### 1. Overview
-**Enabled**: Yes
-**Timeline**: Throughout development (Week 0 to Week 12)
-**Purpose**: Validate assumptions continuously during development, gather feedback on completed features, test AI-native workflows with real users
-### 2. Continuous Discovery Activities
-#### Activity 1: Weekly User Interviews
-**Frequency**: 1x per week
-**Participants**: 2-3 ICP users per week (rotating from discovery participants)
-**Duration**: 30 minutes per interview
-**Focus**: Feedback on completed features, validate MCP workflow assumptions, test AI query scenarios
-**Format**: Check-ins, show progress on MCP integration, gather feedback on AI-native workflows
-**Why Live Required**: Need conversation to understand feedback context, probe issues, validate assumptions
-**Topics to Cover:**
-- Feedback on recently completed features
-- Test MCP workflow with actual Claude/ChatGPT connection
-- Validate AI query scenarios users want to try
-- Identify blockers or confusion points
-- Gather feature requests or improvements
-#### Activity 2: Prototype Testing After UI FUs
-**Frequency**: After FU-300, FU-700, and any other UI FUs
-**Participants**: 3-5 users per test
-**Focus**: Usability validation, MCP workflow completion, AI query understanding
-**Format**: Show working prototype, test MCP connection, gather feedback on AI-native workflows
-**Why Live Required**: Must observe user behavior, detect confusion, probe usability issues
-**Testing Focus:**
-- After FU-300 (Design System): Test UI components and design system usage
-- After FU-700 (Authentication UI): Test signup/login flow
-- After any UI changes: Test workflow completion, identify usability issues
-#### Activity 3: Competitor User Discovery
-**Frequency**: Week 2 to Week 10 (ongoing)
-**Participants**: Competitor users identified through social media outreach (Supermemory.ai, Mem0, ChatGPT Memory users, etc.)
-**Focus**: Understand competitor user pain points, validate Neotoma differentiation, identify switching motivations
-**Format**:
-- Social media engagement (Twitter, Reddit, Discord) to identify potential interview participants
-- Short discovery interviews (15-20 minutes) with competitor users expressing dissatisfaction
-- Validate Neotoma's differentiation (privacy, determinism, cross-platform, entity resolution)
-**Why Live Required**: Need conversation to understand competitor limitations, validate differentiation, identify switching triggers
-**Discovery Questions**:
-- What limitations do you experience with [competitor]?
-- What features are missing that you need?
-- How important is privacy vs. convenience?
-- Would cross-platform access (ChatGPT + Claude + Cursor) be valuable?
-- What would make you switch to an alternative?
-**Outreach Sources**:
-- Twitter/X: Followers of Supermemory.ai, MemCP, MemMachine, OpenMemory, Mem0 MCP, Cognee, Roampal, Memara, and other MCP memory tool accounts
-- Reddit: Users in r/ChatGPT, r/ClaudeAI, r/Cursor, r/MCP discussing memory limitations
-- Discord: AI tool communities, MCP communities
-- LinkedIn: Professionals discussing AI memory tools
-- GitHub: Users of MCP memory tool repositories
-**Goals**:
-- Validate Neotoma differentiation resonates with competitor users
-- Identify key switching triggers
-- Build pipeline of potential early adopters
-- Refine messaging based on competitor user feedback
-#### Activity 4: Beta Testing (Private)
-**Frequency**: Last 2 weeks before deployment (Week 11-12)
-**Participants**: Discovery participants + early access signups + competitor users (from Activity 3)
-**Focus**: End-to-end validation, MCP query testing with real Claude/ChatGPT, bug identification
-**Format**: Full access to MVP, connect to Claude/ChatGPT, collect feedback, identify blockers
-**Why Live Required**: Complex workflows need observation, bug reports need context, MCP setup needs guidance
-**Beta Testing Goals:**
-- End-to-end workflow validation
-- Real-world usage scenarios
-- Bug identification and prioritization
-- Performance testing with real data volumes
-- MCP connection setup and troubleshooting
-### 3. Discovery Schedule
-**Week 0-2 (Early Development):**
-- Weekly interviews: Focus on design system, early UI feedback
-- Prototype testing: After FU-300 (Design System)
-- Competitor user discovery: Begin identifying competitor users on social media
-**Week 3-6 (Core Features):**
-- Weekly interviews: Focus on ingestion, extraction, entity resolution workflows
-- Prototype testing: After FU-700 (Authentication UI)
-- Test early MCP integration
-- Competitor user discovery: Conduct interviews with competitor users, validate differentiation
-**Week 7-10 (Integration & Polish):**
-- Weekly interviews: Focus on complete workflows, MCP query scenarios
-- Test full upload → extraction → MCP query flow
-- Gather feedback on timeline view, search
-- Competitor user discovery: Continue outreach, refine messaging based on feedback
-**Week 11-12 (Beta Testing):**
-- Beta testing with full access (includes competitor users from discovery)
-- End-to-end validation
-- Bug identification and fixes
-- Performance testing
-### 4. Tracking and Documentation
-**Tracking Template**: `continuous_discovery_log.md`
-**Capture for Each Session:**
-- Date and participants
-- Features tested or discussed
-- Feedback received (positive and negative)
-- Issues identified (blockers, confusion points)
-- Action items for implementation
-- Follow-up needed
-**Weekly Synthesis:**
-- Aggregate feedback from weekly interviews
-- Identify patterns and common themes
-- Prioritize issues and improvements
-- Update implementation priorities if needed
-### 5. Integration with Development
-**Feedback Loop:**
-1. Gather feedback in weekly interviews
-2. Synthesize findings weekly
-3. Update implementation priorities (if needed)
-4. Implement high-priority fixes/improvements
-5. Test improvements in next interview cycle
-**Decision-Making:**
-- Critical blockers: Fix immediately (may delay feature completion)
-- Important improvements: Prioritize for current sprint
-- Nice-to-have: Add to backlog for post-MVP
-### 6. Success Criteria
-**Continuous Discovery Success:**
-- Weekly interviews conducted throughout development (12+ interviews)
-- Competitor user discovery interviews (5+ competitor users interviewed)
-- Prototype testing after each major UI FU
-- Beta testing identifies critical bugs before launch
-- Feedback incorporated into implementation (prioritized)
-- MCP workflow validated with real users before launch
-- Neotoma differentiation validated with competitor users
-### 7. Deliverable
-**Deliverable**: `continuous_discovery_log.md`
-Includes:
-- Weekly interview summaries
-- Competitor user discovery interviews and findings
-- Prototype testing results
-- Beta testing findings
-- Feedback synthesis and action items
-- Issues tracked and resolved
-- Competitor user pain points and switching triggers
-### 8. Related Documents
-- `discovery_plan.md` — Discovery overview and coordination
-- `value_discovery_plan.md` — Value discovery activities
-- `usability_discovery_plan.md` — Usability discovery activities
-- `continuous_discovery_log.md` — Continuous discovery tracking template
-- `release_plan.md` — Release overview and scope
-- `status.md` — Release status tracking