Wiki source code of Workflows
Version 3.1 by Robert Schaub on 2025/12/12 09:32
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | = Workflows = |
| 2 | |||
| 3 | This chapter defines the core workflows used across the FactHarbor system. | ||
| 4 | |||
| 5 | Each workflow describes: | ||
| 6 | * Purpose | ||
| 7 | * Participants | ||
| 8 | * Steps | ||
| 9 | * Automation vs. manual work | ||
| 10 | |||
| |
3.1 | 11 | == 1. Claim Workflow == |
| |
1.1 | 12 | |
| |
3.1 | 13 | **Purpose:** Transform raw text or input material into a normalized, classified, deduplicated, and versioned claim. |
| |
1.1 | 14 | |
| |
3.1 | 15 | **Participants:** |
| 16 | * Contributor | ||
| 17 | * AKEL | ||
| 18 | * Reviewer | ||
| |
1.1 | 19 | |
| |
3.1 | 20 | **Steps:** |
| 21 | 1. **Ingestion**: User submits text/URL; AKEL extracts claims. | ||
| 22 | 1. **Normalization**: Standardize wording, reduce ambiguity. | ||
| 23 | 1. **Classification**: Domain, Evaluability, Safety (AKEL draft → Human confirm). | ||
| 24 | 1. **Duplicate Detection**: Check embeddings for existing claims. | ||
| 25 | 1. **Version Creation**: Store new ClaimVersion. | ||
| 26 | 1. **Cluster Assignment**: Assign to Claim Cluster. | ||
| 27 | 1. **Scenario Linking**: Connect to existing or draft new scenarios. | ||
| 28 | 1. **Publication**: Make visible. | ||
| |
1.1 | 29 | |
| |
3.1 | 30 | **Flow:** Ingest → Normalize → Classify → Deduplicate → Cluster → Version → Publish |
| |
1.1 | 31 | |
| |
3.1 | 32 | == 2. Scenario Workflow == |
| |
1.1 | 33 | |
| |
3.1 | 34 | **Purpose:** Define the specific analytic contexts needed to evaluate each claim. |
| |
1.1 | 35 | |
| |
3.1 | 36 | **Steps:** |
| 37 | 1. **Scenario Proposal**: Drafted by contributor or AKEL. | ||
| 38 | 1. **Required Fields**: Definitions, Assumptions, ContextBoundary, EvaluationMethod, SafetyClass. | ||
| 39 | 1. **Safety Interception**: AKEL flags non-falsifiable or unsafe content. | ||
| 40 | 1. **Conflict Check**: Merge similar scenarios, flag contradictions. | ||
| 41 | 1. **Reviewer Validation**: Ensure clarity and validity. | ||
| 42 | 1. **Expert Approval**: Mandatory for high-risk domains. | ||
| 43 | 1. **Version Storage**: Save ScenarioVersion. | ||
| |
1.1 | 44 | |
| |
3.1 | 45 | **Flow:** Draft → Validate → Safety Check → Review → Expert → Version → Activate |
| |
1.1 | 46 | |
| |
3.1 | 47 | == 3. Evidence Workflow == |
| |
1.1 | 48 | |
| |
3.1 | 49 | **Purpose:** Structure, classify, validate, version, and link evidence to scenarios. |
| |
1.1 | 50 | |
| |
3.1 | 51 | **Steps:** |
| 52 | 1. **Submission**: File, URL, or text. | ||
| 53 | 1. **Metadata Extraction**: Type, Category, Provenance, ReliabilityHints. | ||
| 54 | 1. **Relevance Check**: Verify applicability to scenario. | ||
| 55 | 1. **Reliability Assessment**: Score reliability (Reviewer + Expert). | ||
| 56 | 1. **Link Creation**: Create ScenarioEvidenceLink with relevance score. | ||
| 57 | 1. **Versioning**: Update EvidenceVersion. | ||
| |
1.1 | 58 | |
| |
3.1 | 59 | **Flow:** Submit → Extract → Relevance → Reliability → Link → Version |
| |
1.1 | 60 | |
| |
3.1 | 61 | == 4. Verdict Workflow == |
| |
1.1 | 62 | |
| |
3.1 | 63 | **Purpose:** Generate likelihood estimates **per scenario** based on evidence. |
| |
1.1 | 64 | |
| |
3.1 | 65 | **Steps:** |
| 66 | 1. **Aggregation**: Collect linked evidence for a specific scenario. | ||
| 67 | 1. **Draft Verdict**: AKEL proposes likelihood and uncertainty for that scenario. | ||
| 68 | 1. **Reasoning**: AKEL drafts explanation chain. | ||
| 69 | 1. **Validation**: Reviewer checks logic and hallucinations. | ||
| 70 | 1. **Expert Review**: Required for sensitive topics. | ||
| 71 | 1. **Storage**: Save VerdictVersion. | ||
| |
1.1 | 72 | |
| |
3.1 | 73 | **Flow:** Aggregate → Draft → Reasoning → Review → Expert → Version |
| |
1.1 | 74 | |
| |
3.1 | 75 | == 5. Re-evaluation Workflow == |
| |
1.1 | 76 | |
| |
3.1 | 77 | **Purpose:** Keep verdicts current when inputs change. |
| |
1.1 | 78 | |
| |
3.1 | 79 | **Steps:** |
| 80 | 1. **Trigger**: Evidence update, Scenario change, or Contradiction. | ||
| 81 | 1. **Impact Analysis**: Identify affected nodes. | ||
| 82 | 1. **Re-calculation**: AKEL proposes new likelihoods. | ||
| 83 | 1. **Validation**: Human review. | ||
| 84 | 1. **Storage**: New version. | ||
| |
1.1 | 85 | |
| |
3.1 | 86 | **Flow:** Trigger → Analyze → Recompute → Review → Version |
| |
1.1 | 87 | |
| |
3.1 | 88 | == 6. Federation Synchronization Workflow == |
| |
1.1 | 89 | |
| |
3.1 | 90 | **Purpose:** Exchange structured data between nodes. |
| |
1.1 | 91 | |
| |
3.1 | 92 | **Steps:** |
| 93 | 1. Detect Version Changes. | ||
| 94 | 1. Build Signed Bundle (Merkle tree). | ||
| 95 | 1. Push/Pull to Peers. | ||
| 96 | 1. Validate Signatures & Lineage. | ||
| 97 | 1. Resolve Conflicts (Merge/Fork). | ||
| 98 | 1. Trigger Re-evaluation. | ||
| |
1.1 | 99 | |
| |
3.1 | 100 | == 7. User Role & Review Workflow == |
| |
1.1 | 101 | |
| |
3.1 | 102 | **Purpose:** Ensure correctness and safety. |
| |
1.1 | 103 | |
| |
3.1 | 104 | **Steps:** |
| 105 | 1. Submission. | ||
| 106 | 1. Auto-check (AKEL). | ||
| 107 | 1. Reviewer Validation. | ||
| 108 | 1. Expert Validation (if needed). | ||
| 109 | 1. Moderator Oversight (if flagged). | ||
| |
1.1 | 110 | |
| |
3.1 | 111 | == 8. AKEL Workflow == |
| |
1.1 | 112 | |
| |
3.1 | 113 | **Stages:** |
| 114 | * Input Understanding | ||
| 115 | * Scenario Drafting | ||
| 116 | * Evidence Processing | ||
| 117 | * Verdict Drafting | ||
| 118 | * Safety & Integrity | ||
| 119 | * Human Approval | ||
| |
1.1 | 120 | |
| |
3.1 | 121 | == 9. Global Trigger Flow (Cascade) == |
| |
1.1 | 122 | |
| |
3.1 | 123 | **Sources:** Claim/Scenario/Evidence change, Verdict contradiction, Federation update. |
| |
1.1 | 124 | |
| |
3.1 | 125 | **Flow:** Trigger → Dependency Graph → Re-evaluation → Updated Verdicts |
| |
1.1 | 126 | |
| |
3.1 | 127 | {{include reference="FactHarbor.Specification.Diagrams.Global Trigger Cascade.WebHome"/}} |