Wiki source code of Data Model

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

Hide last authors
Robert Schaub 1.1 1 = Data Model =
2
Robert Schaub 2.1 3 This page describes the current data model for FactHarbor 0.9.25.
Robert Schaub 1.1 4
5 == 1. Versioning Strategy ==
6
7 Every entity in FactHarbor has a full immutable version history. This ensures:
Robert Schaub 2.4 8
Robert Schaub 1.1 9 * Complete auditability
10 * Ability to reconstruct historical state
11 * Federation-compatible lineage tracking
12 * Transparent evolution of claims, scenarios, and verdicts
13
14 === 1.1 Core Versioning Principles ===
15
16 **Immutability**:
Robert Schaub 2.4 17
Robert Schaub 1.1 18 * Each version is stored independently
19 * Versions cannot be deleted, only superseded
20 * Historical versions remain accessible
21
22 **Lineage**:
Robert Schaub 2.4 23
Robert Schaub 1.1 24 * Each version links to its parent via `ParentVersionID`
25 * Forms directed acyclic graph (DAG) of changes
26 * Supports branching in federated environments
27
28 **Provenance**:
Robert Schaub 2.4 29
Robert Schaub 1.1 30 * Every version timestamped (`CreatedAt`)
31 * Author type recorded (`AuthorType`: Human, AI, ExternalNode)
32 * Justification captured (`JustificationText`)
33 * Digital signatures for integrity (`SignatureHash` in Release 1.0)
34
35 **Federation Support**:
Robert Schaub 2.4 36
Robert Schaub 1.1 37 * Versions can originate from remote nodes
38 * Conflict detection via lineage comparison
39 * Parallel version trees for branching scenarios
40 * Cross-node version synchronization
41
42 === 1.2 Common Version Fields ===
43
44 All versioned entities include:
45
46 * **VersionID**: Unique identifier for this specific version
47 * **ParentVersionID**: Link to previous version (null for first version)
48 * **CreatedAt**: Timestamp (ISO 8601, UTC)
49 * **AuthorType**: Human | AI | ExternalNode
50 * **CreatedBy**: Foreign key to User or TechnicalUser
51 * **JustificationText**: Brief explanation of changes
52 * **PublicationMode**: Mode1 (draft) | Mode2 (AI-published) | Mode3 (human-reviewed)
53 * **ReviewStatus**: Workflow state (draft|in_review|approved|rejected)
54 * **NodeOrigin**: Node ID where version was created (for federation)
55 * **SignatureHash**: Cryptographic signature (Release 1.0)
56
57 === 1.3 Versioning Architecture Diagram ===
58
Robert Schaub 2.16 59 {{include reference="Archive.FactHarbor 2026\.01\.20.Specification.Diagrams.Versioning Architecture.WebHome"/}}
Robert Schaub 1.1 60
61
62 == 2. Core Entity Definitions ==
63
64 === 2.1 User Entities ===
65
66 **USER** (base user table):
Robert Schaub 2.4 67
Robert Schaub 1.1 68 * ``UserID`` (PK)
69 * ``UserType`` (Reader|Contributor|Reviewer|Auditor|Expert|Moderator|Maintainer)
70 * ``DisplayName``
71 * ``Email`` (for Contributors and above)
72 * ``RegisteredAt``
73 * ``LastActive``
74 * ``Status`` (active|suspended|banned)
75
76 **TECHNICAL_USER** (system processes):
Robert Schaub 2.4 77
Robert Schaub 1.1 78 * ``SystemID`` (PK)
79 * ``SystemName``
80 * ``Purpose`` (AKEL|FederationSync|BackupService|Monitor|Audit)
81 * ``CreatedBy`` (FK to Maintainer who created this system user)
82 * ``CreatedAt``
83 * ``Status`` (active|paused|deprecated)
84 * ``ApiKey`` (encrypted)
85 * ``Permissions`` (JSON - authorized operations)
86
87 **Examples of Technical Users**:
Robert Schaub 2.4 88
Robert Schaub 1.1 89 * AKEL instances (AI processing)
90 * Federation sync bots
91 * Scheduled audit tasks
92 * Backup services
93 * Monitoring systems
94 * External API integrations
95
96 === 2.2 Content Entities ===
97
98 The system relies on the following versioned core entities:
99
100 **CLAIM_CLUSTER**:
Robert Schaub 2.4 101
Robert Schaub 1.1 102 * ``ClusterID`` (PK)
103 * ``EmbeddingVectorRef``
104 * ``Theme``
105 * Groups related claims into topical clusters
106 * One Cluster has many Claims
107 * A Claim belongs to exactly one primary cluster
108
109 **CLAIM / CLAIM_VERSION**:
Robert Schaub 2.4 110
Robert Schaub 1.1 111 * ``CLAIM`` is the long-lived anchor for a real-world claim
112 * ``CLAIM_VERSION`` is an immutable snapshot that includes:
Robert Schaub 2.4 113 * ``VersionID`` (PK)
114 * ``ClaimID`` (FK to CLAIM)
115 * ``ParentVersionID`` (FK to prior version, nullable)
116 * ``Text``
117 * ``Domain``
118 * ``ClaimType`` (literal|metaphorical|rhetorical|supernatural)
119 * ``Evaluability`` (empirical|subjective|non-falsifiable)
120 * ``RiskTier`` (A|B|C) - replaced SafetyCategory for consistency
121 * ``PublicationMode`` (Mode1|Mode2|Mode3)
122 * ``ReviewStatus`` (draft|in_review|approved|rejected)
123 * ``CreatedAt``, ``AuthorType``, ``CreatedBy``, ``JustificationText``
124 * ``NodeOrigin``, ``SignatureHash``
125 * ``Status`` (active|superseded|merged)
Robert Schaub 1.1 126
127 **SCENARIO / SCENARIO_VERSION**:
Robert Schaub 2.4 128
Robert Schaub 1.1 129 * ``SCENARIO`` is the anchor for a scenario across time
130 * ``SCENARIO_VERSION`` is an immutable snapshot:
Robert Schaub 2.4 131 * ``VersionID`` (PK)
132 * ``ScenarioID`` (FK to SCENARIO)
133 * ``ParentVersionID``
134 * ``ClaimID`` (FK to CLAIM)
135 * ``Definitions`` (JSON)
136 * ``Boundaries`` (JSON)
137 * ``Assumptions`` (JSON)
138 * ``Context`` (text)
139 * ``EvaluationMethod`` (text)
140 * ``PublicationMode`` (Mode1|Mode2|Mode3)
141 * ``ReviewStatus`` (draft|in_review|approved|rejected)
142 * ``CreatedAt``, ``AuthorType``, ``CreatedBy``, ``JustificationText``
143 * ``NodeOrigin``, ``SignatureHash``
144 * ``Status`` (active|superseded|deprecated)
Robert Schaub 1.1 145
146 **Note**: SafetyClass removed from Scenario - risk tier is at claim level
147
148 **EVIDENCE / EVIDENCE_VERSION**:
Robert Schaub 2.4 149
Robert Schaub 1.1 150 * ``EVIDENCE`` is the anchor
151 * ``EVIDENCE_VERSION`` is the versioned snapshot:
Robert Schaub 2.4 152 * ``VersionID`` (PK)
153 * ``EvidenceID`` (FK to EVIDENCE)
154 * ``ParentVersionID``
155 * ``Type`` (paper|dataset|report|transcript|expert|media)
156 * ``Category`` (empirical|historical|rhetorical|dataset|meta-analysis)
157 * ``Reliability`` (low|medium|high)
158 * ``Provenance`` (URL, DOI, source metadata)
159 * ``ExtractionMethod`` (manual|OCR|API|AKEL)
160 * ``ContentHash`` (SHA256 of evidence content)
161 * ``PublicationMode`` (Mode1|Mode2|Mode3)
162 * ``ReviewStatus`` (draft|verified|disputed|retracted)
163 * ``CreatedAt``, ``AuthorType``, ``CreatedBy``, ``JustificationText``
164 * ``NodeOrigin``, ``SignatureHash``
165 * ``Status`` (active|superseded)
Robert Schaub 1.1 166
167 **VERDICT / VERDICT_VERSION**:
Robert Schaub 2.4 168
Robert Schaub 1.1 169 * ``VERDICT`` is the anchor
170 * ``VERDICT_VERSION`` is the snapshot:
Robert Schaub 2.4 171 * ``VersionID`` (PK)
172 * ``VerdictID`` (FK to VERDICT)
173 * ``ParentVersionID``
174 * ``ClaimID`` (FK to CLAIM)
175 * ``ScenarioVersionID`` (FK to specific SCENARIO_VERSION)
176 * ``EvidenceVersionSet`` (JSON array of Evidence VersionIDs used)
177 * ``LikelihoodRange`` (0–1, with uncertainty bounds)
178 * ``ExplanationChain`` (JSON)
179 * ``UncertaintyFactors`` (JSON)
180 * ``PublicationMode`` (Mode1|Mode2|Mode3)
181 * ``ReviewStatus`` (draft|in_review|approved|retracted)
182 * ``CreatedAt``, ``AuthorType``, ``CreatedBy``, ``JustificationText``
183 * ``NodeOrigin``, ``SignatureHash``
184 * ``Status`` (current|outdated|superseded|retracted)
Robert Schaub 1.1 185
186 == 3. Many-to-Many Linking Tables ==
187
188 **ScenarioEvidenceLink**:
Robert Schaub 2.4 189
Robert Schaub 1.1 190 * Links scenario versions to evidence versions with relevance scoring
191 * ``ScenarioID``, ``ScenarioVersionID``
192 * ``EvidenceID``, ``EvidenceVersionID``
193 * ``RelevanceScore`` (0–1) - How relevant this evidence is to this scenario
194 * ``LinkJustification`` - Brief explanation of relevance
195
196 **Purpose**:
Robert Schaub 2.4 197
Robert Schaub 1.1 198 * Evidence can be used by multiple scenarios
199 * Scenarios can draw from multiple pieces of evidence
200 * Relevance scoring helps prioritize evidence
201 * Version-specific linking preserves historical accuracy
202
203 **ClaimCluster**:
Robert Schaub 2.4 204
Robert Schaub 1.1 205 * Semantic clustering of similar claims
206 * ``ClusterID`` (PK)
207 * ``EmbeddingVector`` - Vector representation for semantic search
208 * ``MemberList`` - List of ClaimIDs in this cluster
209 * ``Theme`` - Human-readable theme description
210
Robert Schaub 2.1 211 == 4. Key Changes Since 0.9.1 ==
Robert Schaub 1.1 212
213 **Updated Field Names**:
Robert Schaub 2.4 214
Robert Schaub 2.1 215 * `SafetyCategory` → ``RiskTier`` (consistency with risk tier system A/B/C)
Robert Schaub 1.1 216 * `SafetyClass` removed from Scenario (redundant with claim-level RiskTier)
217
218 **Added Fields to All Version Entities**:
Robert Schaub 2.4 219
Robert Schaub 1.1 220 * `PublicationMode` - Track Mode 1/2/3 status
221 * `ReviewStatus` - Track workflow state
222 * `NodeOrigin` - Federation provenance
223 * `CreatedBy` - FK to User/TechnicalUser (clarified)
224
225 **New Entity**:
Robert Schaub 2.4 226
Robert Schaub 1.1 227 * `TECHNICAL_USER` - Separate system processes from human users
228
229 **Clarifications**:
Robert Schaub 2.4 230
Robert Schaub 1.1 231 * `ScenarioVersionID` in Verdict (not just ScenarioID) - links to specific version
232 * `ContentHash` in Evidence - SHA256 for integrity checking
233
234 == 5. Data Model Behavior ==
235
236 === 5.1 Late-Arriving Evidence ===
237
238 When new evidence versions appear:
Robert Schaub 2.4 239
Robert Schaub 1.1 240 1. Existing verdicts marked as **outdated**
241 2. Scenario relevance must be re-evaluated
242 3. Re-evaluation engine triggers verdict recomputation
243 4. New verdict versions created
244 5. Users notified of updates
245
246 === 5.2 Scenario Evolution ===
247
248 When a scenario's assumptions or definitions change:
Robert Schaub 2.4 249
Robert Schaub 1.1 250 * Creates new scenario version (not in-place update)
251 * All dependent verdicts must be recalculated
252 * Previous scenario versions remain accessible
253 * Version lineage preserved
254
255 === 5.3 Federated Nodes ===
256
257 Each node may share partial data:
Robert Schaub 2.4 258
Robert Schaub 1.1 259 * Claims and scenarios shared if relevant
260 * Evidence metadata shared, not always full files
261 * Version synchronization via NodeOrigin tracking
262 * Branching allowed for divergent interpretations
263
264 == 6. Visual Diagrams ==
265
266 The following diagrams provide visual representations of the data model structure and relationships.
267
268 === 6.1 Core Data Model ERD ===
269
Robert Schaub 2.14 270 {{include reference="Archive.FactHarbor 2026\.01\.20.Specification.Diagrams.Core Data Model ERD.WebHome"/}}
Robert Schaub 1.1 271
272 === 6.2 User Roles Structure ===
273
Robert Schaub 2.15 274 {{include reference="Archive.FactHarbor 2026\.01\.20.Specification.Diagrams.User Class Diagram.WebHome"/}}
Robert Schaub 1.1 275
276 === 6.3 Content Workflow ===
277
Robert Schaub 2.13 278 {{include reference="Archive.FactHarbor 2026\.01\.20.Specification.Diagrams.Claim and Scenario Workflow.WebHome"/}}
Robert Schaub 1.1 279
280
281 == 7. Related Pages ==
282
Robert Schaub 2.17 283 * [[Federation & Decentralization>>Archive.FactHarbor 2026\.01\.20.Specification.Federation & Decentralization.WebHome]]
Robert Schaub 2.11 284 * [[AKEL (AI Knowledge Extraction Layer)>>Archive.FactHarbor 2026\.01\.20.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
Robert Schaub 2.12 285 * [[Architecture>>Archive.FactHarbor 2026\.01\.20.Specification.Architecture.WebHome]]