Changes for page Architecture

Last modified by Robert Schaub on 2026/02/08 08:22

From version 2.7
edited by Robert Schaub
on 2026/01/20 20:28
Change comment: Renamed back-links.
To version 1.1
edited by Robert Schaub
on 2025/12/16 21:42
Change comment: Imported from XAR

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -Archive.FactHarbor 0\.9\.40.Specification.WebHome
1 +FactHarbor.Specification.WebHome
Content
... ... @@ -11,11 +11,11 @@
11 11  * **UI Frontend**
12 12  * **REST API Layer**
13 13  * **Core Logic Layer**
14 -** Claim Processing
15 -** Scenario Engine
16 -** Evidence Repository
17 -** Verdict Engine
18 -** Re-evaluation Engine
14 +** Claim Processing
15 +** Scenario Engine
16 +** Evidence Repository
17 +** Verdict Engine
18 +** Re-evaluation Engine
19 19  ** Roles / Identity / Reputation
20 20  * **AKEL (AI Knowledge Extraction Layer)**
21 21  * **Federation Layer**
... ... @@ -22,7 +22,7 @@
22 22  * **Workers & Background Jobs**
23 23  * **Storage Layer (Postgres + VectorDB + ObjectStore)**
24 24  
25 -{{include reference="Archive.FactHarbor.Specification.Diagrams.High-Level Architecture.WebHome"/}}
25 +{{include reference="FactHarbor.Specification.Diagrams.High-Level Architecture.WebHome"/}}
26 26  
27 27  Key ideas:
28 28  
... ... @@ -32,6 +32,7 @@
32 32  * Storage is separated for scalability and clarity 
33 33  * Federation Layer provides optional distributed operation 
34 34  
35 +
35 35  = Storage Architecture =
36 36  
37 37  FactHarbor separates structured data, embeddings, and evidence files:
... ... @@ -41,7 +41,7 @@
41 41  * **Object Storage** — PDFs, datasets, raw evidence, transcripts 
42 42  * **Optional (Release 1.0)**: Redis for caching, IPFS for decentralized object storage 
43 43  
44 -{{include reference="Archive.FactHarbor.Specification.Diagrams.Storage Architecture.WebHome"/}}
45 +{{include reference="FactHarbor.Specification.Diagrams.Storage Architecture.WebHome"/}}
45 45  
46 46  
47 47  = Core Backend Module Architecture =
... ... @@ -59,7 +59,7 @@
59 59  * Deduplicate via embeddings 
60 60  * Assign to claim clusters 
61 61  
62 -Flow:
63 +Flow:
63 63  **Ingest → Normalize → Classify → Deduplicate → Cluster**
64 64  
65 65  
... ... @@ -73,7 +73,7 @@
73 73  * Manage versioning and lifecycle 
74 74  * Provide contextual evaluation settings to the Verdict Engine 
75 75  
76 -Flow:
77 +Flow:
77 77  **Create → Validate → Version → Lifecycle → Safety**
78 78  
79 79  
... ... @@ -88,7 +88,7 @@
88 88  * Detect retractions or disputes 
89 89  * Provide structured metadata to the Verdict Engine 
90 90  
91 -Flow:
92 +Flow:
92 92  **Store → Classify → Score → Version → Update/Retract**
93 93  
94 94  
... ... @@ -102,7 +102,7 @@
102 102  * Track uncertainty factors 
103 103  * Maintain verdict version timelines 
104 104  
105 -Flow:
106 +Flow:
106 106  **Aggregate → Compute → Explain → Version → Timeline**
107 107  
108 108  
... ... @@ -123,7 +123,7 @@
123 123  * Contradiction detection 
124 124  * Federation sync updates 
125 125  
126 -Flow:
127 +Flow:
127 127  **Trigger → Impact Analysis → Recompute → Publish Update**
128 128  
129 129  
... ... @@ -142,7 +142,7 @@
142 142  
143 143  AKEL runs in parallel to human review — never overrides it.
144 144  
145 -{{include reference="Archive.FactHarbor.Specification.Diagrams.AKEL Architecture.WebHome"/}}
146 +{{include reference="FactHarbor.Specification.Diagrams.AKEL Architecture.WebHome"/}}
146 146  
147 147  
148 148  = Federated Architecture =
... ... @@ -169,7 +169,7 @@
169 169  * Resilience 
170 170  * Domain specialization 
171 171  
172 -{{include reference="Archive.FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}
173 +{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}
173 173  
174 174  
175 175  = Request → Verdict Flow =
... ... @@ -177,10 +177,11 @@
177 177  Simple end-to-end flow:
178 178  
179 179  **User → UI Frontend → REST API → FactHarbor Core
180 - → (Claim Processing → Scenario Engine → Evidence Repository → Verdict Engine)
181 - → Summary View → UI Frontend → User**
181 + → (Claim Processing → Scenario Engine → Evidence Repository → Verdict Engine)
182 + → Summary View → UI Frontend → User**
182 182  
183 183  
185 +
184 184  = Federation Sync Workflow =
185 185  
186 186  Sequence:
... ... @@ -188,6 +188,7 @@
188 188  **Detect Local Change → Build Signed Bundle → Push to Peers → Validate Signature → Merge or Fork → Trigger Re-evaluation**
189 189  
190 190  
193 +
191 191  = Versioning Architecture =
192 192  
193 193  All entities (Claim, Scenario, Evidence, Verdict) use immutable version chains: