Skip to Content
Last modified by Robert Schaub on 2026/02/08 08:26
From version 2.3
edited by Robert Schaub
on 2025/12/24 20:30
Change comment: Update document after refactoring.
To version 2.4
edited by Robert Schaub
on 2026/01/20 20:24
Change comment: Renamed back-links.

Summary

Details

Page properties
Content
... ... @@ -3,6 +3,7 @@
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 +
6 6  * **Resilience** against censorship or political pressure
7 7  * **Autonomy** for local governance and moderation
8 8  * **Scalability** across many independent communities
... ... @@ -22,6 +22,7 @@
22 22  == 2. Federated FactHarbor Nodes ==
23 23  
24 24  Each FactHarbor instance ("node") maintains:
26 +
25 25  * Its own database
26 26  * Its own AKEL instance
27 27  * Its own reviewers, experts, and contributors
... ... @@ -28,6 +28,7 @@
28 28  * Its own governance rules
29 29  
30 30  Nodes exchange structured information:
33 +
31 31  * Claims
32 32  * Scenarios
33 33  * Evidence metadata (not necessarily full files)
... ... @@ -48,6 +48,7 @@
48 48  `factharbor://factharbor.energy/claim/CLM-55812`
49 49  
50 50  **Supported types**:
54 +
51 51  * `claim`
52 52  * `scenario`
53 53  * `evidence`
... ... @@ -56,6 +56,7 @@
56 56  * `cluster`
57 57  
58 58  **Properties**:
63 +
59 59  * Globally consistent
60 60  * Human-readable
61 61  * Hash-derived
... ... @@ -72,6 +72,7 @@
72 72  === 4.1 Trust Levels ===
73 73  
74 74  **Trusted Nodes**:
80 +
75 75  * Claims auto-imported
76 76  * Scenarios accepted without re-review
77 77  * Evidence considered valid
... ... @@ -79,6 +79,7 @@
79 79  * High synchronization priority
80 80  
81 81  **Neutral Nodes**:
88 +
82 82  * Claims imported but flagged for review
83 83  * Scenarios require local validation
84 84  * Evidence requires re-assessment
... ... @@ -86,6 +86,7 @@
86 86  * Normal synchronization priority
87 87  
88 88  **Untrusted Nodes**:
96 +
89 89  * Claims quarantined, manual import only
90 90  * Scenarios rejected by default
91 91  * Evidence not accepted
... ... @@ -103,6 +103,7 @@
103 103  === 4.3 Local Trust Authority ===
104 104  
105 105  Each node's governance team decides:
114 +
106 106  * Which nodes to trust
107 107  * Trust level criteria
108 108  * Trust escalation/degradation rules
... ... @@ -116,6 +116,7 @@
116 116  === 5.1 What Nodes Share ===
117 117  
118 118  **Always shared** (if federation enabled):
128 +
119 119  * Claims and claim clusters
120 120  * Scenario structures
121 121  * Evidence metadata and content hashes
... ... @@ -122,6 +122,7 @@
122 122  * Integrity signatures
123 123  
124 124  **Optionally shared**:
135 +
125 125  * Full evidence files (large documents)
126 126  * Verdicts (nodes may choose to keep verdicts local)
127 127  * Vector embeddings
... ... @@ -129,6 +129,7 @@
129 129  * AKEL distilled knowledge
130 130  
131 131  **Never shared**:
143 +
132 132  * Internal user lists
133 133  * Reviewer comments and internal discussions
134 134  * Governance decisions and meeting notes
... ... @@ -138,6 +138,7 @@
138 138  === 5.2 Large Evidence Files ===
139 139  
140 140  Evidence files are:
153 +
141 141  * Stored locally by default
142 142  * Referenced via global content hash
143 143  * Optionally served through IPFS
... ... @@ -144,7 +144,6 @@
144 144  * Accessible via direct peer-to-peer transfer
145 145  * Can be stored in S3-compatible object storage
146 146  
147 -
148 148  == 6. Synchronization Protocol ==
149 149  
150 150  Nodes exchange data using multiple synchronization methods:
... ... @@ -154,6 +154,7 @@
154 154  **Mechanism**: Webhooks
155 155  
156 156  When local content changes:
169 +
157 157  1. Node builds signed bundle
158 158  2. Sends webhook notification to subscribed nodes
159 159  3. Remote nodes fetch bundle
... ... @@ -166,6 +166,7 @@
166 166  **Mechanism**: Scheduled polling
167 167  
168 168  Nodes periodically:
182 +
169 169  1. Query partner nodes for updates
170 170  2. Fetch changed entities since last sync
171 171  3. Validate and import
... ... @@ -178,6 +178,7 @@
178 178  **Mechanism**: WebSub-like protocol
179 179  
180 180  Nodes subscribe to:
195 +
181 181  * Specific claim clusters
182 182  * Specific domains (medical, energy, etc.)
183 183  * Specific scenario types
... ... @@ -190,12 +190,12 @@
190 190  === 6.4 Large Asset Transfer ===
191 191  
192 192  For files >10MB:
208 +
193 193  * S3-compatible object storage
194 194  * IPFS (content-addressed)
195 195  * Direct peer-to-peer transfer
196 196  * Chunked HTTP transfer with resume support
197 197  
198 -
199 199  == 7. Federation Sync Workflow ==
200 200  
201 201  Complete synchronization sequence for creating and sharing new content:
... ... @@ -203,6 +203,7 @@
203 203  === 7.1 Step 1: Local Node Creates New Versions ===
204 204  
205 205  User or AKEL creates:
221 +
206 206  * New claim version
207 207  * New scenario version
208 208  * New evidence version
... ... @@ -209,6 +209,7 @@
209 209  * New verdict version
210 210  
211 211  All changes tracked with:
228 +
212 212  * VersionID
213 213  * ParentVersionID
214 214  * AuthorType
... ... @@ -218,6 +218,7 @@
218 218  === 7.2 Step 2: Federation Layer Builds Signed Bundle ===
219 219  
220 220  Federation layer packages:
238 +
221 221  * Entity data (claim, scenario, evidence metadata, verdict)
222 222  * Version lineage (ParentVersionID chain)
223 223  * Cryptographic signatures
... ... @@ -225,6 +225,7 @@
225 225  * Trust metadata
226 226  
227 227  Bundle format:
246 +
228 228  * JSON-LD for structured data
229 229  * Content-addressed hashes
230 230  * Digital signatures for integrity
... ... @@ -232,6 +232,7 @@
232 232  === 7.3 Step 3: Bundle Includes Required Data ===
233 233  
234 234  Each bundle contains:
254 +
235 235  * **Claims**: Full claim text, classification, domain
236 236  * **Scenarios**: Definitions, assumptions, boundaries
237 237  * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files)
... ... @@ -242,11 +242,13 @@
242 242  === 7.4 Step 4: Bundle Pushed to Trusted Neighbor Nodes ===
243 243  
244 244  Based on trust table:
265 +
245 245  * Push to **trusted nodes** immediately
246 246  * Queue for **neutral nodes** (batched)
247 247  * Skip **untrusted nodes**
248 248  
249 249  Push methods:
271 +
250 250  * Webhook notification
251 251  * Direct API call
252 252  * Pub/Sub message queue
... ... @@ -254,6 +254,7 @@
254 254  === 7.5 Step 5: Remote Nodes Validate Lineage and Signatures ===
255 255  
256 256  Receiving node:
279 +
257 257  1. Verifies cryptographic signatures
258 258  2. Validates version lineage (ParentVersionID chain)
259 259  3. Checks for conflicts with local data
... ... @@ -265,6 +265,7 @@
265 265  === 7.6 Step 6: Accept or Branch Versions ===
266 266  
267 267  **Accept** (if validation passes):
291 +
268 268  * Import new versions
269 269  * Maintain provenance metadata
270 270  * Link to local related entities
... ... @@ -271,6 +271,7 @@
271 271  * Update local indices
272 272  
273 273  **Branch** (if conflict detected):
298 +
274 274  * Create parallel version tree
275 275  * Mark as "external branch"
276 276  * Allow local reviewers to merge or reject
... ... @@ -277,6 +277,7 @@
277 277  * Preserve both version histories
278 278  
279 279  **Reject** (if validation fails):
305 +
280 280  * Log rejection reason
281 281  * Notify source node (optional)
282 282  * Quarantine for manual review (optional)
... ... @@ -284,17 +284,18 @@
284 284  === 7.7 Step 7: Local Re-evaluation Runs if Required ===
285 285  
286 286  After import, local node checks:
313 +
287 287  * Does new evidence affect existing verdicts?
288 288  * Do new scenarios require re-assessment?
289 289  * Are there contradictions with local content?
290 290  
291 291  If yes:
319 +
292 292  * Trigger AKEL re-evaluation
293 293  * Queue for reviewer attention
294 294  * Update affected verdicts
295 295  * Notify users following related content
296 296  
297 -
298 298  == 8. Cross-Node AI Knowledge Exchange ==
299 299  
300 300  Each node runs its own AKEL instance and may exchange AI-derived knowledge:
... ... @@ -302,26 +302,31 @@
302 302  === 8.1 What Can Be Shared ===
303 303  
304 304  **Vector embeddings**:
332 +
305 305  * For cross-node claim clustering
306 306  * For semantic search alignment
307 307  * Never includes training data
308 308  
309 309  **Canonical claim forms**:
338 +
310 310  * Normalized claim text
311 311  * Standard phrasing templates
312 312  * Domain-specific formulations
313 313  
314 314  **Scenario templates**:
344 +
315 315  * Reusable scenario structures
316 316  * Common assumption patterns
317 317  * Evaluation method templates
318 318  
319 319  **Contradiction alerts**:
350 +
320 320  * Detected conflicts between claims
321 321  * Evidence conflicts across nodes
322 322  * Scenario incompatibilities
323 323  
324 324  **Metadata and insights**:
356 +
325 325  * Aggregate quality metrics
326 326  * Reliability signal extraction
327 327  * Bubble detection patterns
... ... @@ -354,10 +354,10 @@
354 354  * No external AI control over local content
355 355  * Privacy-preserving knowledge exchange
356 356  
357 -
358 358  == 9. Decentralized Processing ==
359 359  
360 360  Each node independently performs:
392 +
361 361  * AKEL processing
362 362  * Scenario drafting and validation
363 363  * Evidence review
... ... @@ -365,6 +365,7 @@
365 365  * Truth landscape summarization
366 366  
367 367  Nodes can specialize:
400 +
368 368  * Health-focused node with medical experts
369 369  * Energy-focused node with domain knowledge
370 370  * Small node delegating scenario libraries to partners
... ... @@ -371,15 +371,16 @@
371 371  * Regional node with language/culture specialization
372 372  
373 373  Optional data sharing includes:
407 +
374 374  * Embeddings for clustering
375 375  * Claim clusters for alignment
376 376  * Scenario templates for efficiency
377 377  * Verdict comparison metadata
378 378  
379 -
380 380  == 10. Scaling to Thousands of Users ==
381 381  
382 382  Nodes scale independently through:
416 +
383 383  * Horizontally scalable API servers
384 384  * Worker pools for AKEL tasks
385 385  * Hybrid storage (local + S3/IPFS)
... ... @@ -389,6 +389,7 @@
389 389  Federation allows effectively unlimited horizontal scaling by adding new nodes.
390 390  
391 391  Communities may form:
426 +
392 392  * Domain-specific nodes (epidemiology, energy, climate)
393 393  * Language or region-based nodes
394 394  * NGO or institutional nodes
... ... @@ -396,6 +396,7 @@
396 396  * Academic research nodes
397 397  
398 398  Nodes cooperate through:
434 +
399 399  * Scenario library sharing
400 400  * Shared or overlapping claim clusters
401 401  * Expert delegation between nodes
... ... @@ -402,7 +402,6 @@
402 402  * Distributed AKEL task support
403 403  * Cross-node quality audits
404 404  
405 -
406 406  == 11. Federation and Release 1.0 ==
407 407  
408 408  **POC**: Single node, optional federation experiments
... ... @@ -410,6 +410,7 @@
410 410  **Beta 0**: 2-3 nodes, basic federation protocol
411 411  
412 412  **Release 1.0**: Full federation support with:
448 +
413 413  * Robust synchronization protocol
414 414  * Trust model implementation
415 415  * Cross-node AI knowledge exchange
... ... @@ -417,11 +417,9 @@
417 417  * Distributed audit collaboration
418 418  * Inter-node expert consultation
419 419  
420 -
421 421  == 12. Related Pages ==
422 422  
423 -* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
458 +* [[AKEL (AI Knowledge Extraction Layer)>>Archive.FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
424 424  * [[Data Model>>FactHarbor.Specification.Data Model.WebHome]]
425 425  * [[Architecture>>FactHarbor.Specification.Architecture.WebHome]]
426 426  * [[Workflows>>FactHarbor.Specification.Workflows.WebHome]]
427 -