Skip to Content
Last modified by Robert Schaub on 2025/12/24 20:35
From version 1.3
edited by Robert Schaub
on 2025/12/16 20:40
Change comment: Renamed back-links.
To version 1.1
edited by Robert Schaub
on 2025/12/16 20:34
Change comment: Imported from XAR

Summary

Details

Page properties
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
... ... @@ -16,7 +16,6 @@
16 16  == 1. Federated FactHarbor Nodes ==
17 17  
18 18  Each FactHarbor instance ("node") maintains:
19 -
20 20  * Its own database
21 21  * Its own AKEL instance
22 22  * Its own reviewers, experts, and contributors
... ... @@ -23,7 +23,6 @@
23 23  * Its own governance rules
24 24  
25 25  Nodes exchange structured information:
26 -
27 27  * Claims
28 28  * Scenarios
29 29  * Evidence metadata (not necessarily full files)
... ... @@ -44,7 +44,6 @@
44 44  `factharbor://factharbor.energy/claim/CLM-55812`
45 45  
46 46  **Supported types**:
47 -
48 48  * `claim`
49 49  * `scenario`
50 50  * `evidence`
... ... @@ -53,7 +53,6 @@
53 53  * `cluster`
54 54  
55 55  **Properties**:
56 -
57 57  * Globally consistent
58 58  * Human-readable
59 59  * Hash-derived
... ... @@ -70,7 +70,6 @@
70 70  === 3.1 Trust Levels ===
71 71  
72 72  **Trusted Nodes**:
73 -
74 74  * Claims auto-imported
75 75  * Scenarios accepted without re-review
76 76  * Evidence considered valid
... ... @@ -78,7 +78,6 @@
78 78  * High synchronization priority
79 79  
80 80  **Neutral Nodes**:
81 -
82 82  * Claims imported but flagged for review
83 83  * Scenarios require local validation
84 84  * Evidence requires re-assessment
... ... @@ -86,7 +86,6 @@
86 86  * Normal synchronization priority
87 87  
88 88  **Untrusted Nodes**:
89 -
90 90  * Claims quarantined, manual import only
91 91  * Scenarios rejected by default
92 92  * Evidence not accepted
... ... @@ -104,7 +104,6 @@
104 104  === 3.3 Local Trust Authority ===
105 105  
106 106  Each node's governance team decides:
107 -
108 108  * Which nodes to trust
109 109  * Trust level criteria
110 110  * Trust escalation/degradation rules
... ... @@ -118,7 +118,6 @@
118 118  === 4.1 What Nodes Share ===
119 119  
120 120  **Always shared** (if federation enabled):
121 -
122 122  * Claims and claim clusters
123 123  * Scenario structures
124 124  * Evidence metadata and content hashes
... ... @@ -125,7 +125,6 @@
125 125  * Integrity signatures
126 126  
127 127  **Optionally shared**:
128 -
129 129  * Full evidence files (large documents)
130 130  * Verdicts (nodes may choose to keep verdicts local)
131 131  * Vector embeddings
... ... @@ -133,7 +133,6 @@
133 133  * AKEL distilled knowledge
134 134  
135 135  **Never shared**:
136 -
137 137  * Internal user lists
138 138  * Reviewer comments and internal discussions
139 139  * Governance decisions and meeting notes
... ... @@ -143,7 +143,6 @@
143 143  === 4.2 Large Evidence Files ===
144 144  
145 145  Evidence files are:
146 -
147 147  * Stored locally by default
148 148  * Referenced via global content hash
149 149  * Optionally served through IPFS
... ... @@ -150,6 +150,7 @@
150 150  * Accessible via direct peer-to-peer transfer
151 151  * Can be stored in S3-compatible object storage
152 152  
140 +
153 153  == 5. Synchronization Protocol ==
154 154  
155 155  Nodes exchange data using multiple synchronization methods:
... ... @@ -159,7 +159,6 @@
159 159  **Mechanism**: Webhooks
160 160  
161 161  When local content changes:
162 -
163 163  1. Node builds signed bundle
164 164  2. Sends webhook notification to subscribed nodes
165 165  3. Remote nodes fetch bundle
... ... @@ -172,7 +172,6 @@
172 172  **Mechanism**: Scheduled polling
173 173  
174 174  Nodes periodically:
175 -
176 176  1. Query partner nodes for updates
177 177  2. Fetch changed entities since last sync
178 178  3. Validate and import
... ... @@ -185,7 +185,6 @@
185 185  **Mechanism**: WebSub-like protocol
186 186  
187 187  Nodes subscribe to:
188 -
189 189  * Specific claim clusters
190 190  * Specific domains (medical, energy, etc.)
191 191  * Specific scenario types
... ... @@ -198,12 +198,12 @@
198 198  === 5.4 Large Asset Transfer ===
199 199  
200 200  For files >10MB:
201 -
202 202  * S3-compatible object storage
203 203  * IPFS (content-addressed)
204 204  * Direct peer-to-peer transfer
205 205  * Chunked HTTP transfer with resume support
206 206  
191 +
207 207  == 6. Federation Sync Workflow ==
208 208  
209 209  Complete synchronization sequence for creating and sharing new content:
... ... @@ -211,7 +211,6 @@
211 211  === 6.1 Step 1: Local Node Creates New Versions ===
212 212  
213 213  User or AKEL creates:
214 -
215 215  * New claim version
216 216  * New scenario version
217 217  * New evidence version
... ... @@ -218,7 +218,6 @@
218 218  * New verdict version
219 219  
220 220  All changes tracked with:
221 -
222 222  * VersionID
223 223  * ParentVersionID
224 224  * AuthorType
... ... @@ -228,7 +228,6 @@
228 228  === 6.2 Step 2: Federation Layer Builds Signed Bundle ===
229 229  
230 230  Federation layer packages:
231 -
232 232  * Entity data (claim, scenario, evidence metadata, verdict)
233 233  * Version lineage (ParentVersionID chain)
234 234  * Cryptographic signatures
... ... @@ -236,7 +236,6 @@
236 236  * Trust metadata
237 237  
238 238  Bundle format:
239 -
240 240  * JSON-LD for structured data
241 241  * Content-addressed hashes
242 242  * Digital signatures for integrity
... ... @@ -244,7 +244,6 @@
244 244  === 6.3 Step 3: Bundle Includes Required Data ===
245 245  
246 246  Each bundle contains:
247 -
248 248  * **Claims**: Full claim text, classification, domain
249 249  * **Scenarios**: Definitions, assumptions, boundaries
250 250  * **Evidence metadata**: Source URLs, hashes, reliability scores (not always full files)
... ... @@ -255,13 +255,11 @@
255 255  === 6.4 Step 4: Bundle Pushed to Trusted Neighbor Nodes ===
256 256  
257 257  Based on trust table:
258 -
259 259  * Push to **trusted nodes** immediately
260 260  * Queue for **neutral nodes** (batched)
261 261  * Skip **untrusted nodes**
262 262  
263 263  Push methods:
264 -
265 265  * Webhook notification
266 266  * Direct API call
267 267  * Pub/Sub message queue
... ... @@ -269,7 +269,6 @@
269 269  === 6.5 Step 5: Remote Nodes Validate Lineage and Signatures ===
270 270  
271 271  Receiving node:
272 -
273 273  1. Verifies cryptographic signatures
274 274  2. Validates version lineage (ParentVersionID chain)
275 275  3. Checks for conflicts with local data
... ... @@ -281,7 +281,6 @@
281 281  === 6.6 Step 6: Accept or Branch Versions ===
282 282  
283 283  **Accept** (if validation passes):
284 -
285 285  * Import new versions
286 286  * Maintain provenance metadata
287 287  * Link to local related entities
... ... @@ -288,7 +288,6 @@
288 288  * Update local indices
289 289  
290 290  **Branch** (if conflict detected):
291 -
292 292  * Create parallel version tree
293 293  * Mark as "external branch"
294 294  * Allow local reviewers to merge or reject
... ... @@ -295,7 +295,6 @@
295 295  * Preserve both version histories
296 296  
297 297  **Reject** (if validation fails):
298 -
299 299  * Log rejection reason
300 300  * Notify source node (optional)
301 301  * Quarantine for manual review (optional)
... ... @@ -303,18 +303,17 @@
303 303  === 6.7 Step 7: Local Re-evaluation Runs if Required ===
304 304  
305 305  After import, local node checks:
306 -
307 307  * Does new evidence affect existing verdicts?
308 308  * Do new scenarios require re-assessment?
309 309  * Are there contradictions with local content?
310 310  
311 311  If yes:
312 -
313 313  * Trigger AKEL re-evaluation
314 314  * Queue for reviewer attention
315 315  * Update affected verdicts
316 316  * Notify users following related content
317 317  
290 +
318 318  == 7. Cross-Node AI Knowledge Exchange ==
319 319  
320 320  Each node runs its own AKEL instance and may exchange AI-derived knowledge:
... ... @@ -322,31 +322,26 @@
322 322  === 7.1 What Can Be Shared ===
323 323  
324 324  **Vector embeddings**:
325 -
326 326  * For cross-node claim clustering
327 327  * For semantic search alignment
328 328  * Never includes training data
329 329  
330 330  **Canonical claim forms**:
331 -
332 332  * Normalized claim text
333 333  * Standard phrasing templates
334 334  * Domain-specific formulations
335 335  
336 336  **Scenario templates**:
337 -
338 338  * Reusable scenario structures
339 339  * Common assumption patterns
340 340  * Evaluation method templates
341 341  
342 342  **Contradiction alerts**:
343 -
344 344  * Detected conflicts between claims
345 345  * Evidence conflicts across nodes
346 346  * Scenario incompatibilities
347 347  
348 348  **Metadata and insights**:
349 -
350 350  * Aggregate quality metrics
351 351  * Reliability signal extraction
352 352  * Bubble detection patterns
... ... @@ -379,10 +379,10 @@
379 379  * No external AI control over local content
380 380  * Privacy-preserving knowledge exchange
381 381  
350 +
382 382  == 8. Decentralized Processing ==
383 383  
384 384  Each node independently performs:
385 -
386 386  * AKEL processing
387 387  * Scenario drafting and validation
388 388  * Evidence review
... ... @@ -390,7 +390,6 @@
390 390  * Truth landscape summarization
391 391  
392 392  Nodes can specialize:
393 -
394 394  * Health-focused node with medical experts
395 395  * Energy-focused node with domain knowledge
396 396  * Small node delegating scenario libraries to partners
... ... @@ -397,16 +397,15 @@
397 397  * Regional node with language/culture specialization
398 398  
399 399  Optional data sharing includes:
400 -
401 401  * Embeddings for clustering
402 402  * Claim clusters for alignment
403 403  * Scenario templates for efficiency
404 404  * Verdict comparison metadata
405 405  
372 +
406 406  == 9. Scaling to Thousands of Users ==
407 407  
408 408  Nodes scale independently through:
409 -
410 410  * Horizontally scalable API servers
411 411  * Worker pools for AKEL tasks
412 412  * Hybrid storage (local + S3/IPFS)
... ... @@ -416,7 +416,6 @@
416 416  Federation allows effectively unlimited horizontal scaling by adding new nodes.
417 417  
418 418  Communities may form:
419 -
420 420  * Domain-specific nodes (epidemiology, energy, climate)
421 421  * Language or region-based nodes
422 422  * NGO or institutional nodes
... ... @@ -424,7 +424,6 @@
424 424  * Academic research nodes
425 425  
426 426  Nodes cooperate through:
427 -
428 428  * Scenario library sharing
429 429  * Shared or overlapping claim clusters
430 430  * Expert delegation between nodes
... ... @@ -431,6 +431,7 @@
431 431  * Distributed AKEL task support
432 432  * Cross-node quality audits
433 433  
398 +
434 434  == 10. Federation and Release 1.0 ==
435 435  
436 436  **POC**: Single node, optional federation experiments
... ... @@ -438,7 +438,6 @@
438 438  **Beta 0**: 2-3 nodes, basic federation protocol
439 439  
440 440  **Release 1.0**: Full federation support with:
441 -
442 442  * Robust synchronization protocol
443 443  * Trust model implementation
444 444  * Cross-node AI knowledge exchange
... ... @@ -446,9 +446,11 @@
446 446  * Distributed audit collaboration
447 447  * Inter-node expert consultation
448 448  
413 +
449 449  == 11. Related Pages ==
450 450  
451 -* [[AKEL (AI Knowledge Extraction Layer)>>Test.FactHarbor V0\.9\.23 Lost Data.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
416 +* [[AKEL (AI Knowledge Extraction Layer)>>Test.FactHarborV09.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
452 452  * [[Data Model>>Test.FactHarborV09.Specification.Data Model.WebHome]]
453 -* [[Architecture>>Test.FactHarbor V0\.9\.23 Lost Data.Specification.Architecture.WebHome]]
418 +* [[Architecture>>Test.FactHarborV09.Specification.Architecture.WebHome]]
454 454  * [[Workflows>>Test.FactHarborV09.Specification.Workflows.WebHome]]
420 +