FactHarbor - Complete Analysis Summary
Consolidated Document - No Timelines
Date: December 19, 2025

-

1. POC Specification - DEFINITIVE

POC Goal
Prove that AI can extract claims and determine verdicts automatically without human intervention.

POC Output (4 Components Only)

• • 1. ANALYSIS SUMMARY
       - 3-5 sentences
       - How many claims found
       - Distribution of verdicts  
       - Overall assessment

2. CLAIMS IDENTIFICATION
- 3-5 numbered factual claims
- Extracted automatically by AI

3. CLAIMS VERDICTS
- Per claim: Verdict label + Confidence % + Brief reasoning (1-3 sentences)
- Verdict labels: WELL-SUPPORTED / PARTIALLY SUPPORTED / UNCERTAIN / REFUTED

4. ARTICLE SUMMARY (optional)
- 3-5 sentences
- Neutral summary of article content

Total output: 200-300 words

What's NOT in POC

❌ Scenarios (multiple interpretations)  
❌ Evidence display (supporting/opposing lists)  
❌ Source links  
❌ Detailed reasoning chains  
❌ User accounts, history, search  
❌ Browser extensions, API  
❌ Accessibility, multilingual, mobile  
❌ Export, sharing features  
❌ Any other features

Critical Requirement

FULLY AUTOMATED - NO MANUAL EDITING

This is non-negotiable. POC tests whether AI can do this without human intervention.

POC Success Criteria

Passes if:
- ✅ AI extracts 3-5 factual claims automatically
- ✅ AI provides reasonable verdicts (≥70% make sense)
- ✅ Output is comprehensible
- ✅ Team agrees approach has merit
- ✅ Minimal or no manual editing needed

Fails if:
- ❌ Claim extraction poor (< 60% accuracy)
- ❌ Verdicts nonsensical (< 60% reasonable)
- ❌ Requires manual editing for most analyses (> 50%)
- ❌ Team loses confidence in approach

POC Architecture

Frontend: Simple input form + results display  
Backend: Single API call to Claude (Sonnet 4.5)  
Processing: One prompt generates complete analysis  
Database: None required (stateless)

POC Philosophy

 "Build less, learn more, decide faster. Test the hardest part first."

-

2. Gap Analysis - Strategic Framework

Framework Definition

Importance = f(risk, impact, strategy)
- Risk: What breaks if we don't have this?
- Impact: How many users? How severe?
- Strategy: Does it advance FactHarbor's mission?

Urgency = f(fail fast and learn, legal, promises made)
- Fail fast: Do we need to test assumptions?
- Legal: External requirements/deadlines?
- Promises: Commitments to stakeholders?

18 Gaps Identified

Category 1: Accessibility & Inclusivity

1. WCAG 2.1 Compliance
   2. Multilingual Support

Category 2: Platform Integration
3. Browser Extensions
4. Embeddable Widgets
5. ClaimReview Schema

Category 3: Media Verification
6. Image/Video/Audio Verification

Category 4: Mobile & Offline
7. Mobile Apps / PWA
8. Offline Access

Category 5: Education & Media Literacy
9. Educational Resources
10. Media Literacy Integration

Category 6: Collaboration & Community

1. 1. Professional Collaboration Tools
      12. Community Discussion

Category 7: Export & Sharing
13. Export Capabilities (PDF, CSV)
14. Social Sharing Optimization

Category 8: Advanced Features
15. User Analytics
16. Personalization
17. Media Archiving
18. Advanced Search

Importance/Urgency Analysis

VERY HIGH Importance + HIGH Urgency:

1. Accessibility (WCAG)
      - Risk: Legal liability, 15-20% users excluded
      - Urgency: European Accessibility Act (June 28, 2025)
      - Action: Must be built from start (retrofitting 100x more expensive)

2. Educational Resources
   - Risk: Platform fails if users can't understand
   - Urgency: Required for any adoption
   - Action: Basic onboarding essential

HIGH Importance + MEDIUM Urgency:
3. Browser Extensions - Standard user expectation, test demand first
4. Media Verification - Cannot address visual misinformation without it
5. Multilingual - Global mission requires it, plan early

HIGH Importance + LOW Urgency:
6. Mobile Apps - 90%+ users on mobile, but web-first viable
7. ClaimReview Schema - SEO/discoverability, can add anytime

-

1.7 POC Alignment with Full Specification

POC Intentional Simplifications

POC1 tests core AI capability, not full architecture:

What POC Tests:
- Can AI extract claims from articles?
- Can AI evaluate claims with reasonable verdicts?
- Is fully automated approach viable?
- Is output comprehensible to users?

What POC Excludes (Intentionally):
- ❌ Scenarios (deferred to POC2 - open architectural questions remain)
- ❌ Evidence display (deferred to POC2)
- ❌ Multi-component AKEL pipeline (simplified to single API call)
- ❌ Quality gate infrastructure (simplified basic checks)
- ❌ Production data model (stateless POC)
- ❌ Review workflow system (no review queue)

Why Simplified:
- Fail fast: Test hardest part first (AI capability)
- Learn before building: POC1 informs architecture decisions
- Iterative: Add complexity based on POC1 learnings
- Risk management: Prove concept before major investment

Full System Architecture (Future)

Workflow:
Claims → Scenarios → Evidence → Verdicts

AKEL Components:
- Orchestrator
- Claim Extractor & Classifier
- Scenario Generator
- Evidence Summarizer
- Contradiction Detector
- Quality Gate Validator
- Audit Sampling Scheduler

Publication Modes:
- Mode 1: Draft-Only
- Mode 2: AI-Generated (POC uses this)
- Mode 3: AKEL-Generated (Human-Reviewed)

POC vs. Full System Summary

Gap Between POC and Beta

Significant architectural expansion needed:

1. Scenario generation component design and implementation
   2. Evidence Model full structure
   3. Multi-phase workflow with gates
   4. Component-based AKEL architecture
   5. Production data model and storage
   6. Review workflow and audit systems

POC proves concept. Beta builds product.

MEDIUM Importance + LOW Urgency:
8-14. All other features - valuable but not urgent

Strategic Decisions Needed:
- Community discussion: Allow or stay evidence-focused?
- Personalization: How much without filter bubbles?
- Media verification: Partner with existing tools or build?

Key Insight: Milestones Change Priorities

POC: Only educational resources urgent (basic explainer)  
Beta: Accessibility becomes urgent (test with diverse users)  
Release: Legal requirements become critical (WCAG, GDPR)

Importance/urgency are contextual, not absolute.

-

3. Key Strategic Recommendations

Immediate Actions

For POC:

1. Focus on core functionality only (claims + verdicts)
   2. Create basic explainer (1 page)
   3. Test AI quality without manual editing
   4. Make GO/NO-GO decision

Planning:

1. Define accessibility strategy (when to build)
   2. Decide on multilingual priorities (which languages first)
   3. Research media verification options (partner vs build)
   4. Evaluate browser extension approach

Testing Strategy

POC Tests: Can AI do this without humans?  
Beta Tests: What do users need? What works? What doesn't?  
Release Tests: Is it production-ready?

Key Principle: Test assumptions before building features.

Build Sequence (Priority Order)

Must Build:

1. Core analysis (claims + verdicts) ← POC
   2. Educational resources (basic → comprehensive)
   3. Accessibility (WCAG 2.1 AA) ← Legal requirement

Should Build (Validate First):
4. Browser extensions ← Test demand
5. Media verification ← Pilot with existing tools
6. Multilingual ← Start with 2-3 languages

Can Build Later:
7. Mobile apps ← PWA first
8. ClaimReview schema ← After content library
9. Export features ← Based on user requests
10. Everything else ← Based on validation

Decision Framework

For each feature, ask:

1. Importance: Risk + Impact + Strategy alignment?
   2. Urgency: Fail fast + Legal + Promises?
   3. Validation: Do we know users want this?
   4. Priority: When should we build it?

Don't build anything without answering these questions.

-

4. Critical Principles

Automation First
- AI makes content decisions
- Humans improve algorithms
- Scale through code, not people

Fail Fast
- Test assumptions quickly
- Don't build unvalidated features
- Accept that experiments may fail
- Learn from failures

Evidence Over Authority
- Transparent reasoning visible
- No single "true/false" verdicts
- Multiple scenarios shown
- Assumptions made explicit

User Focus
- Serve users' needs first
- Build what's actually useful
- Don't build what's just "cool"
- Measure and iterate

Honest Assessment
- Don't cherry-pick examples
- Document failures openly
- Accept limitations
- No overpromising

-

5. POC Decision Gate

After POC, Choose:

GO (Proceed to Beta):
- AI quality ≥70% without editing
- Approach validated
- Team confident
- Clear path to improvement

NO-GO (Pivot or Stop):
- AI quality < 60%
- Requires manual editing for most
- Fundamental flaws identified
- Not feasible with current technology

ITERATE (Improve & Retry):
- Concept has merit
- Specific improvements identified
- Addressable with better prompts
- Test again after changes

-

6. Key Risks & Mitigations

Risk 1: AI Quality Not Good Enough
Mitigation: Extensive prompt testing, use best models  
Acceptance: POC might fail - that's what testing reveals

Risk 2: Users Don't Understand Output
Mitigation: Create clear explainer, test with real users  
Acceptance: Iterate on explanation until comprehensible

Risk 3: Approach Doesn't Scale
Mitigation: Start simple, add complexity only when proven  
Acceptance: POC proves concept, beta proves scale

Risk 4: Legal/Compliance Issues
Mitigation: Plan accessibility early, consult legal experts  
Acceptance: Can't launch publicly without compliance

Risk 5: Feature Creep
Mitigation: Strict scope discipline, say NO to additions  
Acceptance: POC is minimal by design

-

7. Success Metrics

POC Success
- AI output quality ≥70%
- Manual editing needed < 30% of time
- Team confidence: High
- Decision: GO to beta

Platform Success (Later)
- User comprehension ≥80%
- Return user rate ≥30%
- Flag rate (user corrections) < 10%
- Processing time < 30 seconds
- Error rate < 1%

Mission Success (Long-term)
- Users make better-informed decisions
- Misinformation spread reduced
- Public discourse improves
- Trust in evidence increases

-

8. What Makes FactHarbor Different

Not Traditional Fact-Checking
- ❌ No simple "true/false" verdicts
- ✅ Multiple scenarios with context
- ✅ Transparent reasoning chains
- ✅ Explicit assumptions shown

Not AI Chatbot
- ❌ Not conversational
- ✅ Structured Evidence Models
- ✅ Reproducible analysis
- ✅ Verifiable sources

Not Just Automation
- ❌ Not replacing human judgment
- ✅ Augmenting human reasoning
- ✅ Making process transparent
- ✅ Enabling informed decisions

-

9. Core Philosophy

Three Pillars:

• • 1. Scenarios Over Verdicts
       - Show multiple interpretations
       - Make context explicit
       - Acknowledge uncertainty
       - Avoid false certainty

2. Transparency Over Authority
- Show reasoning, not just conclusions
- Make assumptions explicit
- Link to evidence
- Enable verification

3. Evidence Over Opinions
- Ground claims in sources
- Show supporting AND opposing evidence
- Evaluate source quality
- Avoid cherry-picking

-

10. Next Actions

Immediate
□ Review this consolidated summary  
□ Confirm POC scope agreement  
□ Make strategic decisions on key questions  
□ Begin POC development  

Strategic Planning
□ Define accessibility approach  
□ Select initial languages for multilingual  
□ Research media verification partners  
□ Evaluate browser extension frameworks  

Continuous
□ Test assumptions before building  
□ Measure everything  
□ Learn from failures  
□ Stay focused on mission  

-

Summary of Summaries

POC Goal: Prove AI can do this automatically  
POC Scope: 4 simple components, 200-300 words  
POC Critical: Fully automated, no manual editing  
POC Success: ≥70% quality without human correction  

Gap Analysis: 18 gaps identified, 2 critical (Accessibility + Education)  
Framework: Importance (risk + impact + strategy) + Urgency (fail fast + legal + promises)  
Key Insight: Context matters - urgency changes with milestones  

Strategy: Test first, build second. Fail fast. Stay focused.  
Philosophy: Scenarios, transparency, evidence. No false certainty.  

-

Document Status

This document supersedes all previous analysis documents.

All gap analysis, POC specifications, and strategic frameworks are consolidated here without timeline references.

For detailed specifications, refer to:
- User Needs document (in project knowledge)
- Requirements document (in project knowledge)
- This summary (comprehensive overview)

Previous documents are archived for reference but this is the authoritative summary.

-

End of Consolidated Summary