Wiki source code of Workflows
Last modified by Robert Schaub on 2025/12/22 14:16
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
| |
1.1 | 1 | = Workflows = **Version:** 0.9.70 **Last Updated:** December 21, 2025 **Status:** CORRECTED - Automation Philosophy Consistent This page describes FactHarbor's core workflows with the automation-first philosophy. == 1. Core Workflow Principles == * **Automation First:** 90%+ content published automatically |
| 2 | * **No Approval Bottlenecks:** No centralized review queues | ||
| 3 | * **Quality Gates:** Automated validation before publication | ||
| 4 | * **Sampling Audits:** Pattern analysis for system improvement | ||
| 5 | * **Transparent Confidence:** All outputs labeled with confidence scores == 2. Claim Submission Workflow == === 2.1 Claim Extraction === When users submit content (text, articles, web pages), FactHarbor first extracts individual verifiable claims: **Input Types:** | ||
| 6 | * Single claim: "The Earth is flat" | ||
| 7 | * Text with multiple claims: "Climate change is accelerating. Sea levels rose 3mm in 2023. Arctic ice decreased 13% annually." | ||
| 8 | * URLs: Web pages analyzed for factual claims **Extraction Process:** | ||
| 9 | * LLM analyzes submitted content | ||
| 10 | * Identifies distinct, verifiable factual claims | ||
| 11 | * Separates claims from opinions, questions, or commentary | ||
| 12 | * Each claim becomes independent for processing **Output:** | ||
| 13 | * List of claims with context | ||
| 14 | * Each claim assigned unique ID | ||
| 15 | * Original context preserved for reference This extraction ensures: | ||
| 16 | * Each claim receives focused analysis | ||
| 17 | * Multiple claims in one submission are all processed | ||
| 18 | * Claims are properly isolated for independent verification | ||
| 19 | * Context is preserved for accurate interpretation **Flow:** | ||
| 20 | ``` | ||
| 21 | User submits → Duplicate detection → Categorization → Processing queue → User receives ID | ||
| 22 | ``` **Timeline:** Seconds **No approval needed:** Instant processing == 3. Automated Analysis Workflow == **Complete Pipeline:** ``` | ||
| 23 | Claim from queue | ||
| 24 | ↓ | ||
| 25 | Evidence gathering (AKEL) | ||
| 26 | ↓ | ||
| 27 | Source evaluation (track record check) | ||
| 28 | ↓ | ||
| 29 | Scenario generation | ||
| 30 | ↓ | ||
| 31 | Verdict synthesis | ||
| 32 | ↓ | ||
| 33 | Risk assessment | ||
| 34 | ↓ | ||
| 35 | Quality gates validation | ||
| 36 | ↓ | ||
| 37 | Decision: PUBLISH or BLOCK | ||
| 38 | ``` **Timeline:** 10-30 seconds **Automation Rate:** 90%+ published automatically === 3.1 Quality Gates Decision == **Gate Validation:** | ||
| 39 | 1. Gate 1: Source Quality ✓ | ||
| 40 | 2. Gate 2: Contradiction Search ✓ | ||
| 41 | 3. Gate 3: Uncertainty Quantification ✓ | ||
| 42 | 4. Gate 4: Structural Integrity ✓ **If ALL gates PASS:** | ||
| 43 | → **Publish immediately** (Mode 2: AI-Generated) | ||
| 44 | → Apply appropriate risk tier label | ||
| 45 | → Display confidence score | ||
| 46 | → Make available for sampling audit **If ANY gate FAILS:** | ||
| 47 | → **Block publication** (Mode 1: Draft-Only) | ||
| 48 | → Log failure reason | ||
| 49 | → Analyze failure pattern | ||
| 50 | → Queue system improvement task | ||
| 51 | → May re-process after improvements **CRITICAL:** No human approval step - gates are automated. == 4. Publication Workflow == **V0.9.70 CLARIFIED:** Risk tiers affect LABELS and AUDIT FREQUENCY, NOT approval requirements. === Standard Flow (90%+) === ``` | ||
| 52 | Pass quality gates | ||
| 53 | ↓ | ||
| 54 | Determine risk tier (A/B/C) | ||
| 55 | ↓ | ||
| 56 | Apply appropriate labels | ||
| 57 | ↓ | ||
| 58 | PUBLISH IMMEDIATELY | ||
| 59 | ↓ | ||
| 60 | Add to audit sampling pool | ||
| 61 | ``` **No delays, no approval queues** === High-Risk Content (Tier A - <10%) === **V0.9.70 CORRECTION:** ``` | ||
| 62 | Pass quality gates | ||
| 63 | ↓ | ||
| 64 | Identified as Tier A (medical/legal/safety) | ||
| 65 | ↓ | ||
| 66 | PUBLISH IMMEDIATELY with prominent warnings | ||
| 67 | ↓ | ||
| 68 | Higher sampling audit frequency (50%) | ||
| 69 | ``` **What changed from V0.9.69:** | ||
| 70 | - ❌ REMOVED: "Risk > 80% → Moderator review" | ||
| 71 | - ✅ ADDED: "Risk > 80% → Publish with WARNING labels" **Philosophy:** Publish with strong warnings, monitor closely through sampling. **Warning Labels for Tier A:** | ||
| 72 | ``` | ||
| 73 | ⚠️ HIGH-IMPACT TOPIC | ||
| 74 | AI-Generated Analysis This claim involves [medical/legal/financial/safety] topics. | ||
| 75 | - Confidence: [X]% | ||
| 76 | - Last Updated: [timestamp] | ||
| 77 | - This is NOT professional advice | ||
| 78 | - Consult qualified professionals for decisions [View Evidence] [See Methodology] [Report Issue] | ||
| 79 | ``` === Low Quality Content (<10%) === ``` | ||
| 80 | FAIL quality gates | ||
| 81 | ↓ | ||
| 82 | Confidence < threshold OR structural issues | ||
| 83 | ↓ | ||
| 84 | BLOCK (Mode 1: Draft-Only) | ||
| 85 | ↓ | ||
| 86 | Log failure patterns | ||
| 87 | ↓ | ||
| 88 | Queue for system improvement | ||
| 89 | ``` **NOT:** Send for human review **IS:** Improve prompts/algorithms based on failure patterns == 5. User Contribution Workflow == **Philosophy:** Wikipedia-style immediate application + audit trail ``` | ||
| 90 | Contributor edits published content | ||
| 91 | ↓ | ||
| 92 | System validates (basic checks) | ||
| 93 | ↓ | ||
| 94 | Applied IMMEDIATELY | ||
| 95 | ↓ | ||
| 96 | Logged in version history | ||
| 97 | ↓ | ||
| 98 | Reputation earned | ||
| 99 | ↓ | ||
| 100 | May be selected for sampling audit | ||
| 101 | ``` **No approval required:** Changes apply instantly **Quality control:** Through sampling audits and reputation system **New contributors** (<50 reputation): Limited to minor edits == 6. Sampling Audit Workflow == **Purpose:** Improve system quality through pattern analysis === 6.1 Selection Process === ``` | ||
| 102 | Published content | ||
| 103 | ↓ | ||
| 104 | Stratified sampling (by risk tier, confidence, traffic) | ||
| 105 | ↓ | ||
| 106 | Selected for audit (Tier A: 50%, B: 20%, C: 5%) | ||
| 107 | ↓ | ||
| 108 | Added to audit queue | ||
| 109 | ``` === 6.2 Audit Execution === ``` | ||
| 110 | Auditor receives sample | ||
| 111 | ↓ | ||
| 112 | Reviews against quality standards | ||
| 113 | ↓ | ||
| 114 | Identifies issues/patterns | ||
| 115 | ↓ | ||
| 116 | Logs findings | ||
| 117 | ↓ | ||
| 118 | System improvement tasks created | ||
| 119 | ``` **What auditors DO:** | ||
| 120 | * ✅ Analyze patterns across multiple outputs | ||
| 121 | * ✅ Identify systematic issues | ||
| 122 | * ✅ Recommend algorithm/prompt improvements | ||
| 123 | * ✅ Track accuracy trends **What auditors DON'T DO:** | ||
| 124 | * ❌ Approve individual outputs before publication | ||
| 125 | * ❌ Manually fix individual outputs | ||
| 126 | * ❌ Act as gatekeepers | ||
| 127 | * ❌ Override quality gates === 6.3 Improvement Loop === ``` | ||
| 128 | Audit findings aggregated | ||
| 129 | ↓ | ||
| 130 | Patterns identified | ||
| 131 | ↓ | ||
| 132 | System improvements proposed | ||
| 133 | ↓ | ||
| 134 | Implemented and tested | ||
| 135 | ↓ | ||
| 136 | Deployed | ||
| 137 | ↓ | ||
| 138 | Metrics monitored | ||
| 139 | ``` **Examples of Improvements:** | ||
| 140 | * Refine evidence search queries | ||
| 141 | * Adjust source reliability weights | ||
| 142 | * Enhance contradiction detection | ||
| 143 | * Improve claim extraction prompts | ||
| 144 | * Recalibrate risk tier thresholds == 7. Flagging Workflow == **Two types of flags:** === 7.1 Quality Issues === ``` | ||
| 145 | User flags quality issue | ||
| 146 | ↓ | ||
| 147 | Categorized automatically | ||
| 148 | ↓ | ||
| 149 | Added to sampling audit pool (priority) | ||
| 150 | ↓ | ||
| 151 | Pattern analysis | ||
| 152 | ↓ | ||
| 153 | System improvement if pattern found | ||
| 154 | ``` **NOT:** Manual correction of individual claim **IS:** Improve system to prevent similar issues === 7.2 Abuse/Spam === ``` | ||
| 155 | User flags abuse/spam | ||
| 156 | ↓ | ||
| 157 | Automated pre-moderation check | ||
| 158 | ↓ | ||
| 159 | Moderator review (if needed) | ||
| 160 | ↓ | ||
| 161 | Action taken (hide/ban) | ||
| 162 | ``` **Moderator role:** Handle abuse/spam, NOT content quality == 8. Moderation Workflow == **V0.9.70 CLARIFIED:** Moderators handle ABUSE, not content quality === 8.1 Content Moderation (Abuse/Spam) === **Moderator Queue Contains:** | ||
| 163 | * Flagged abusive content | ||
| 164 | * Spam detection alerts | ||
| 165 | * Harassment reports | ||
| 166 | * Privacy violations | ||
| 167 | * Terms of service violations **Moderator Actions:** | ||
| 168 | * Hide abusive content | ||
| 169 | * Ban repeat offenders | ||
| 170 | * Handle appeals | ||
| 171 | * Escalate to governing team **Moderators DO NOT:** | ||
| 172 | * ❌ Approve content for publication | ||
| 173 | * ❌ Review content quality before publication | ||
| 174 | * ❌ Act as editorial gatekeepers | ||
| 175 | * ❌ Manually fix AI outputs === 8.2 Appeal Process === ``` | ||
| 176 | User disagrees with moderation | ||
| 177 | ↓ | ||
| 178 | Appeals to different moderator | ||
| 179 | ↓ | ||
| 180 | If still disagrees, escalates to Governing Team | ||
| 181 | ↓ | ||
| 182 | Governing Team decision (final) | ||
| 183 | ``` == 9. Time Evolution Workflow == **Automatic Re-evaluation:** ``` | ||
| 184 | Published claim | ||
| 185 | ↓ | ||
| 186 | Monitoring for triggers: - New evidence published - Source retractions - Significant events - Scheduled review ↓ | ||
| 187 | Trigger detected | ||
| 188 | ↓ | ||
| 189 | AKEL re-processes claim | ||
| 190 | ↓ | ||
| 191 | Quality gates validate | ||
| 192 | ↓ | ||
| 193 | If verdict changes: Correction workflow | ||
| 194 | ↓ | ||
| 195 | If passes: Update published analysis | ||
| 196 | ``` **Correction Workflow (New in V0.9.70):** ``` | ||
| 197 | Verdict changed significantly | ||
| 198 | ↓ | ||
| 199 | Generate correction notice | ||
| 200 | ↓ | ||
| 201 | Publish correction banner (30 days) | ||
| 202 | ↓ | ||
| 203 | Update corrections log | ||
| 204 | ↓ | ||
| 205 | Notify users (email, RSS, API) | ||
| 206 | ↓ | ||
| 207 | Update ClaimReview schema | ||
| 208 | ``` == 10. Contributor Journey == 1. **Visitor** – Explores platform, reads documentation | ||
| 209 | 2. **New Contributor** – Submits first improvements (typo fixes, clarifications) | ||
| 210 | 3. **Contributor** – Contributes regularly, follows conventions | ||
| 211 | 4. **Trusted Contributor** – Track record of quality work | ||
| 212 | 5. **Reviewer** – Participates in sampling audits (pattern analysis) | ||
| 213 | 6. **Moderator** – Handles abuse/spam (not content quality) | ||
| 214 | 7. **Expert** (optional) – Provides domain expertise for contested claims **All contributions apply immediately** - no approval workflow == 11. Related Pages == * [[AKEL>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] - AI processing system | ||
| 215 | * [[Architecture>>FactHarbor.Specification.Architecture.WebHome]] - System architecture | ||
| 216 | * [[Requirements>>FactHarbor.Specification.Requirements.WebHome]] - Requirements and roles | ||
| 217 | * [[Decision Processes>>FactHarbor.Organisation.Decision-Processes.WebHome]] - Governance **V0.9.70 CHANGES:** **REMOVED:** | ||
| 218 | - ❌ "High Risk → Moderator review" (was approval workflow) | ||
| 219 | - ❌ "Review queue" language for publication | ||
| 220 | - ❌ Any implication that moderators approve content quality **ADDED/CLARIFIED:** | ||
| 221 | - ✅ Risk tiers affect warnings and audit frequency, NOT approval | ||
| 222 | - ✅ High-risk content publishes immediately with prominent warnings | ||
| 223 | - ✅ Quality gate failures → Block + improve system (not human review) | ||
| 224 | - ✅ Clear distinction: Sampling audits (improvement) vs. Content moderation (abuse) | ||
| 225 | - ✅ Moderator role clarified: Abuse only, NOT content quality | ||
| 226 | - ✅ User contributions apply immediately (Wikipedia model) | ||
| 227 | - ✅ Correction workflow for significant verdict changes | ||
| 228 | - ✅ Time evolution and re-evaluation workflow | ||
| 229 |