Skip to Content
Last modified by Robert Schaub on 2026/02/08 08:26
From version 2.10
edited by Robert Schaub
on 2026/02/08 08:15
Change comment: Renamed back-links.
To version 2.2
edited by Robert Schaub
on 2025/12/17 18:07
Change comment: Update document after refactoring.

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -Archive.FactHarbor 0\.9\.40.Specification.WebHome
1 +FactHarbor.Archive.FactHarbor 0\.9\.40.Specification.WebHome
Content
... ... @@ -3,7 +3,6 @@
3 3  FactHarbor is designed to operate as a **federated network of nodes** rather than a single central server.
4 4  
5 5  Decentralization provides:
6 -
7 7  * **Resilience** against censorship or political pressure
8 8  * **Autonomy** for local governance and moderation
9 9  * **Scalability** across many independent communities
... ... @@ -17,13 +17,12 @@
17 17  
18 18  The following diagram shows the complete federated architecture with node components and communication layers.
19 19  
20 -{{include reference="Archive.FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}
19 +{{include reference="FactHarbor.Specification.Diagrams.Federation Architecture.WebHome"/}}
21 21  
22 22  
23 23  == 2. Federated FactHarbor Nodes ==
24 24  
25 25  Each FactHarbor instance ("node") maintains:
26 -
27 27  * Its own database
28 28  * Its own AKEL instance
29 29  * Its own reviewers, experts, and contributors
... ... @@ -30,7 +30,6 @@
30 30  * Its own governance rules
31 31  
32 32  Nodes exchange structured information:
33 -
34 34  * Claims
35 35  * Scenarios
36 36  * Evidence metadata (not necessarily full files)
... ... @@ -51,7 +51,6 @@
51 51  `factharbor://factharbor.energy/claim/CLM-55812`
52 52  
53 53  **Supported types**:
54 -
55 55  * `claim`
56 56  * `scenario`
57 57  * `evidence`
... ... @@ -60,7 +60,6 @@
60 60  * `cluster`
61 61  
62 62  **Properties**:
63 -
64 64  * Globally consistent
65 65  * Human-readable
66 66  * Hash-derived
... ... @@ -77,7 +77,6 @@
77 77  === 4.1 Trust Levels ===
78 78  
79 79  **Trusted Nodes**:
80 -
81 81  * Claims auto-imported
82 82  * Scenarios accepted without re-review
83 83  * Evidence considered valid
... ... @@ -85,7 +85,6 @@
85 85  * High synchronization priority
86 86  
87 87  **Neutral Nodes**:
88 -
89 89  * Claims imported but flagged for review
90 90  * Scenarios require local validation
91 91  * Evidence requires re-assessment
... ... @@ -93,7 +93,6 @@
93 93  * Normal synchronization priority
94 94  
95 95  **Untrusted Nodes**:
96 -
97 97  * Claims quarantined, manual import only
98 98  * Scenarios rejected by default
99 99  * Evidence not accepted
... ... @@ -111,7 +111,6 @@
111 111  === 4.3 Local Trust Authority ===
112 112  
113 113  Each node's governance team decides:
114 -
115 115  * Which nodes to trust
116 116  * Trust level criteria
117 117  * Trust escalation/degradation rules
... ... @@ -125,7 +125,6 @@
125 125  === 5.1 What Nodes Share ===
126 126  
127 127  **Always shared** (if federation enabled):
128 -
129 129  * Claims and claim clusters
130 130  * Scenario structures
131 131  * Evidence metadata and content hashes
... ... @@ -132,7 +132,6 @@
132 132  * Integrity signatures
133 133  
134 134  **Optionally shared**:
135 -
136 136  * Full evidence files (large documents)
137 137  * Verdicts (nodes may choose to keep verdicts local)
138 138  * Vector embeddings
... ... @@ -140,7 +140,6 @@
140 140  * AKEL distilled knowledge
141 141  
142 142  **Never shared**:
143 -
144 144  * Internal user lists
145 145  * Reviewer comments and internal discussions
146 146  * Governance decisions and meeting notes
... ... @@ -150,7 +150,6 @@
150 150  === 5.2 Large Evidence Files ===
151 151  
152 152  Evidence files are:
153 -
154 154  * Stored locally by default
155 155  * Referenced via global content hash
156 156  * Optionally served through IPFS
... ... @@ -157,6 +157,7 @@
157 157  * Accessible via direct peer-to-peer transfer
158 158  * Can be stored in S3-compatible object storage
159 159  
147 +
160 160  == 6. Synchronization Protocol ==
161 161  
162 162  Nodes exchange data using multiple synchronization methods:
... ... @@ -166,7 +166,6 @@
166 166  **Mechanism**: Webhooks
167 167  
168 168  When local content changes:
169 -
170 170  1. Node builds signed bundle
171 171  2. Sends webhook notification to subscribed nodes
172 172  3. Remote nodes fetch bundle
... ... @@ -179,7 +179,6 @@
179 179  **Mechanism**: Scheduled polling
180 180  
181 181  Nodes periodically:
182 -
183 183  1. Query partner nodes for updates
184 184  2. Fetch changed entities since last sync
185 185  3. Validate and import
... ... @@ -192,7 +192,6 @@
192 192  **Mechanism**: WebSub-like protocol
193 193  
194 194  Nodes subscribe to:
195 -
196 196  * Specific claim clusters
197 197  * Specific domains (medical, energy, etc.)
198 198  * Specific scenario types
... ... @@ -205,12 +205,12 @@
205 205  === 6.4 Large Asset Transfer ===
206 206  
207 207  For files >10MB:
208 -
209 209  * S3-compatible object storage
210 210  * IPFS (content-addressed)
211 211  * Direct peer-to-peer transfer
212 212  * Chunked HTTP transfer with resume support
213 213  
198 +
214 214  == 7. Federation Sync Workflow ==
215 215  
216 216  Complete synchronization sequence for creating and sharing new content:
... ... @@ -218,7 +218,6 @@
218 218  === 7.1 Step 1: Local Node Creates New Versions ===
219 219  
220 220  User or AKEL creates:
221 -
222 222  * New claim version
223 223  * New scenario version
224 224  * New evidence version
... ... @@ -225,7 +225,6 @@
225 225  * New verdict version
226 226  
227 227  All changes tracked with:
228 -
229 229  * VersionID
230 230  * ParentVersionID
231 231  * AuthorType
... ... @@ -235,7 +235,6 @@
235 235  === 7.2 Step 2: Federation Layer Builds Signed Bundle ===
236 236  
237 237  Federation layer packages:
238 -
239 239  * Entity data (claim, scenario, evidence metadata, verdict)
240 240  * Version lineage (ParentVersionID chain)
241 241  * Cryptographic signatures
... ... @@ -243,7 +243,6 @@
243 243  * Trust metadata
244 244  
245 245  Bundle format:
246 -
247 247  * JSON-LD for structured data
248 248  * Content-addressed hashes
249 249  * Digital signatures for integrity
... ... @@ -251,7 +251,6 @@
251 251  === 7.3 Step 3: Bundle Includes Required Data ===
252 252  
253 253  Each bundle contains:
254 -
255 255  * **Claims**: Full claim text, classification, domain
256 256  * **Scenarios**: Definitions, assumptions, boundaries
257 257  * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files)
... ... @@ -262,13 +262,11 @@
262 262  === 7.4 Step 4: Bundle Pushed to Trusted Neighbor Nodes ===
263 263  
264 264  Based on trust table:
265 -
266 266  * Push to **trusted nodes** immediately
267 267  * Queue for **neutral nodes** (batched)
268 268  * Skip **untrusted nodes**
269 269  
270 270  Push methods:
271 -
272 272  * Webhook notification
273 273  * Direct API call
274 274  * Pub/Sub message queue
... ... @@ -276,7 +276,6 @@
276 276  === 7.5 Step 5: Remote Nodes Validate Lineage and Signatures ===
277 277  
278 278  Receiving node:
279 -
280 280  1. Verifies cryptographic signatures
281 281  2. Validates version lineage (ParentVersionID chain)
282 282  3. Checks for conflicts with local data
... ... @@ -288,7 +288,6 @@
288 288  === 7.6 Step 6: Accept or Branch Versions ===
289 289  
290 290  **Accept** (if validation passes):
291 -
292 292  * Import new versions
293 293  * Maintain provenance metadata
294 294  * Link to local related entities
... ... @@ -295,7 +295,6 @@
295 295  * Update local indices
296 296  
297 297  **Branch** (if conflict detected):
298 -
299 299  * Create parallel version tree
300 300  * Mark as "external branch"
301 301  * Allow local reviewers to merge or reject
... ... @@ -302,7 +302,6 @@
302 302  * Preserve both version histories
303 303  
304 304  **Reject** (if validation fails):
305 -
306 306  * Log rejection reason
307 307  * Notify source node (optional)
308 308  * Quarantine for manual review (optional)
... ... @@ -310,18 +310,17 @@
310 310  === 7.7 Step 7: Local Re-evaluation Runs if Required ===
311 311  
312 312  After import, local node checks:
313 -
314 314  * Does new evidence affect existing verdicts?
315 315  * Do new scenarios require re-assessment?
316 316  * Are there contradictions with local content?
317 317  
318 318  If yes:
319 -
320 320  * Trigger AKEL re-evaluation
321 321  * Queue for reviewer attention
322 322  * Update affected verdicts
323 323  * Notify users following related content
324 324  
297 +
325 325  == 8. Cross-Node AI Knowledge Exchange ==
326 326  
327 327  Each node runs its own AKEL instance and may exchange AI-derived knowledge:
... ... @@ -329,31 +329,26 @@
329 329  === 8.1 What Can Be Shared ===
330 330  
331 331  **Vector embeddings**:
332 -
333 333  * For cross-node claim clustering
334 334  * For semantic search alignment
335 335  * Never includes training data
336 336  
337 337  **Canonical claim forms**:
338 -
339 339  * Normalized claim text
340 340  * Standard phrasing templates
341 341  * Domain-specific formulations
342 342  
343 343  **Scenario templates**:
344 -
345 345  * Reusable scenario structures
346 346  * Common assumption patterns
347 347  * Evaluation method templates
348 348  
349 349  **Contradiction alerts**:
350 -
351 351  * Detected conflicts between claims
352 352  * Evidence conflicts across nodes
353 353  * Scenario incompatibilities
354 354  
355 355  **Metadata and insights**:
356 -
357 357  * Aggregate quality metrics
358 358  * Reliability signal extraction
359 359  * Bubble detection patterns
... ... @@ -386,10 +386,10 @@
386 386  * No external AI control over local content
387 387  * Privacy-preserving knowledge exchange
388 388  
357 +
389 389  == 9. Decentralized Processing ==
390 390  
391 391  Each node independently performs:
392 -
393 393  * AKEL processing
394 394  * Scenario drafting and validation
395 395  * Evidence review
... ... @@ -397,7 +397,6 @@
397 397  * Truth landscape summarization
398 398  
399 399  Nodes can specialize:
400 -
401 401  * Health-focused node with medical experts
402 402  * Energy-focused node with domain knowledge
403 403  * Small node delegating scenario libraries to partners
... ... @@ -404,16 +404,15 @@
404 404  * Regional node with language/culture specialization
405 405  
406 406  Optional data sharing includes:
407 -
408 408  * Embeddings for clustering
409 409  * Claim clusters for alignment
410 410  * Scenario templates for efficiency
411 411  * Verdict comparison metadata
412 412  
379 +
413 413  == 10. Scaling to Thousands of Users ==
414 414  
415 415  Nodes scale independently through:
416 -
417 417  * Horizontally scalable API servers
418 418  * Worker pools for AKEL tasks
419 419  * Hybrid storage (local + S3/IPFS)
... ... @@ -423,7 +423,6 @@
423 423  Federation allows effectively unlimited horizontal scaling by adding new nodes.
424 424  
425 425  Communities may form:
426 -
427 427  * Domain-specific nodes (epidemiology, energy, climate)
428 428  * Language or region-based nodes
429 429  * NGO or institutional nodes
... ... @@ -431,7 +431,6 @@
431 431  * Academic research nodes
432 432  
433 433  Nodes cooperate through:
434 -
435 435  * Scenario library sharing
436 436  * Shared or overlapping claim clusters
437 437  * Expert delegation between nodes
... ... @@ -438,6 +438,7 @@
438 438  * Distributed AKEL task support
439 439  * Cross-node quality audits
440 440  
405 +
441 441  == 11. Federation and Release 1.0 ==
442 442  
443 443  **POC**: Single node, optional federation experiments
... ... @@ -445,7 +445,6 @@
445 445  **Beta 0**: 2-3 nodes, basic federation protocol
446 446  
447 447  **Release 1.0**: Full federation support with:
448 -
449 449  * Robust synchronization protocol
450 450  * Trust model implementation
451 451  * Cross-node AI knowledge exchange
... ... @@ -453,9 +453,11 @@
453 453  * Distributed audit collaboration
454 454  * Inter-node expert consultation
455 455  
420 +
456 456  == 12. Related Pages ==
457 457  
458 -* [[AKEL (AI Knowledge Extraction Layer)>>Archive.FactHarbor 2026\.01\.20.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
459 -* [[Data Model>>Archive.FactHarbor.Specification.Data Model.WebHome]]
460 -* [[Architecture>>Archive.FactHarbor 2026\.01\.20.Specification.Architecture.WebHome]]
461 -* [[Workflows>>Archive.FactHarbor.Specification.Workflows.WebHome]]
423 +* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
424 +* [[Data Model>>FactHarbor.Specification.Data Model.WebHome]]
425 +* [[Architecture>>FactHarbor.Specification.Architecture.WebHome]]
426 +* [[Workflows>>FactHarbor.Specification.Workflows.WebHome]]
427 +