Skip to Content
Last modified by Robert Schaub on 2025/12/24 20:35
From version 5.1
edited by Robert Schaub
on 2025/11/27 12:28
Change comment: There is no comment for this version
To version 6.1
edited by Robert Schaub
on 2025/11/27 12:31
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,3 +1,418 @@
1 +(((
2 +
3 +)))
4 +
5 += 5. Data Model =
6 +
7 +The FactHarbor data model centers on four fully versioned, immutable entities:
8 +
9 +* **Claim**
10 +* **Scenario**
11 +* **Evidence**
12 +* **Verdict**
13 +
14 +These entities form the structured **“truth landscape”** for each claim.
15 +The model is explicitly **versioned**, **traceable**, and **federation-ready**.
16 +
17 +To keep the system auditable and explainable, FactHarbor uses a consistent
18 +**identity vs. version** pattern:
19 +
20 +* Identity entities (e.g. {{code}}CLAIM{{/code}}, {{code}}SCENARIO{{/code}})
21 + define *what* something is in a stable sense.
22 +* Version entities (e.g. {{code}}CLAIM_VERSION{{/code}}, {{code}}SCENARIO_VERSION{{/code}})
23 + define *how that thing looked at a given point in time*.
24 +
25 +All reasoning (e.g. verdicts, review actions) is attached to **versions**, never to
26 +mutable identities.
27 +
28 +----
29 +
30 += 5.1 Core entities and versioning pattern =
31 +
32 +(% class="wikitable" %)
33 +| **Logical concept** | **Identity entity** | **Version entity** | **Notes**
34 +| Claim (what people argue about) | {{code}}CLAIM{{/code}} | {{code}}CLAIM_VERSION{{/code}} | Claim text, phrasing, and metadata live in {{code}}CLAIM_VERSION{{/code}}. The identity {{code}}CLAIM{{/code}} stays stable across rephrasings.
35 +| Scenario (interpretive frame) | {{code}}SCENARIO{{/code}} | {{code}}SCENARIO_VERSION{{/code}} | A SCENARIO belongs to a CLAIM. Its versions capture evolving definitions, assumptions, and boundaries.
36 +| Evidence (source / datapoint) | {{code}}EVIDENCE{{/code}} | {{code}}EVIDENCE_VERSION{{/code}} | Identity of a source vs. specific extractions / updates over time.
37 +| Verdict (assessment) | {{code}}VERDICT{{/code}} | {{code}}VERDICT_VERSION{{/code}} | A VERDICT is defined per SCENARIO; VERDICT_VERSION captures the history of assessments.
38 +| Scenario–Evidence link | {{code}}SCENARIO_EVIDENCE_LINK{{/code}} | {{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}} | Links bind scenario versions to evidence versions with relevance & direction.
39 +| Claim cluster (semantic group) | {{code}}CLAIM_CLUSTER{{/code}} | – | Groups semantically related claims; mainly for discovery and navigation.
40 +
41 +Key design decisions:
42 +
43 +* A {{code}}CLAIM{{/code}} belongs to exactly one {{code}}CLAIM_CLUSTER{{/code}}.
44 +* A {{code}}SCENARIO{{/code}} belongs to exactly one {{code}}CLAIM{{/code}}
45 + (scenarios live at the *claim* level, not per individual phrasing).
46 +* Verdicts and Scenario–Evidence links are always attached to **versions**:
47 +* {{code}}SCENARIO_VERSION{{/code}} +
48 +{{code}}EVIDENCE_VERSION{{/code}} →
49 +{{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}}
50 +* {{code}}SCENARIO_VERSION{{/code}} →
51 +{{code}}VERDICT_VERSION{{/code}}
52 +
53 +This ensures that when a Scenario or Evidence changes, old verdicts and links
54 +remain intact as historical records and can be revisited.
55 +
56 +----
57 +
58 += 5.2 Core Data Model ERD (expanded, versioned) =
59 +
60 +The following Mermaid ER diagram shows the main entities and their relationships.
61 +The convention is that fields ending in {{code}}Id{{/code}} are primary keys,
62 +and fields with {{code}}...IdFk{{/code}} are foreign keys.
63 +
64 +{{comment}} Core Data Model ERD (Mermaid, from /Specification/Diagrams/Data Model) {{/comment}}
65 +{{include document="FactHarbor.Playground.Core Data Model ERD Page (from Specification chat).WebHome"/}}
66 +
67 += Core Data Model ERD (Versioned) =
68 +
69 +This diagram shows the full core data model with all versioned entities.
70 +
71 +{{mermaid}}
72 +erDiagram
73 + CLAIM_CLUSTER {
74 + string ClusterID PK
75 + string EmbeddingVectorRef
76 + string Theme
77 + }
78 +
79 + CLAIM {
80 + string ClaimID PK
81 + string ClusterID FK
82 + string Status
83 + datetime CreatedAt
84 + }
85 +
86 + CLAIM_VERSION {
87 + string ClaimVersionID PK
88 + string ClaimID FK
89 + string Text
90 + string ClaimType
91 + string Domain
92 + datetime CreatedAt
93 + }
94 +
95 + SCENARIO {
96 + string ScenarioID PK
97 + string ClaimID FK
98 + string Name
99 + datetime CreatedAt
100 + }
101 +
102 + SCENARIO_VERSION {
103 + string ScenarioVersionID PK
104 + string ScenarioID FK
105 + string Definitions
106 + string Assumptions
107 + string Boundaries
108 + datetime CreatedAt
109 + }
110 +
111 + EVIDENCE {
112 + string EvidenceID PK
113 + string SourceType
114 + string URL
115 + float ReliabilityScore
116 + }
117 +
118 + EVIDENCE_VERSION {
119 + string EvidenceVersionID PK
120 + string EvidenceID FK
121 + string Summary
122 + float ReliabilityScore
123 + datetime CreatedAt
124 + }
125 +
126 + SCENARIO_EVIDENCE_LINK {
127 + string LinkID PK
128 + string ScenarioVersionID FK
129 + string EvidenceVersionID FK
130 + float Relevance
131 + string Direction
132 + }
133 +
134 + VERDICT {
135 + string VerdictID PK
136 + string ScenarioID FK
137 + }
138 +
139 + VERDICT_VERSION {
140 + string VerdictVersionID PK
141 + string VerdictID FK
142 + float Verdict
143 + float Confidence
144 + string Reasoning
145 + datetime CreatedAt
146 + }
147 +
148 + CLAIM_CLUSTER ||--o{ CLAIM : contains
149 + CLAIM ||--o{ CLAIM_VERSION : versions
150 +
151 + CLAIM ||--o{ SCENARIO : has
152 + SCENARIO ||--o{ SCENARIO_VERSION : versions
153 +
154 + EVIDENCE ||--o{ EVIDENCE_VERSION : versions
155 +
156 + SCENARIO_VERSION ||--o{ SCENARIO_EVIDENCE_LINK : links
157 + EVIDENCE_VERSION ||--o{ SCENARIO_EVIDENCE_LINK : linked
158 +
159 + SCENARIO ||--o{ VERDICT : assessed
160 + VERDICT ||--o{ VERDICT_VERSION : versions
161 +{{/mermaid}}
162 +
163 +{{info}}
164 +All key entities are explicitly versioned here (…VERSION tables).
165 +This reflects the versioning requirements in the textual Data Model chapter.
166 +{{/info}}
167 +
168 +
169 +**Important points:**
170 +
171 +* Scenarios and Evidence are **linked via their versions**
172 + ({{code}}SCENARIO_VERSION{{/code}} and {{code}}EVIDENCE_VERSION{{/code}}).
173 +* Verdicts are **per ScenarioVersion** and stored in {{code}}VERDICT_VERSION{{/code}}.
174 +* {{code}}CLAIM_CLUSTER{{/code}} is shared across diagrams; it is shown here and in the Data Use / Review model.
175 +
176 +All version entities are immutable: once created, they are never changed, only
177 +superseded by newer versions.
178 +
179 +----
180 +
181 += 5.3 Data Use & Review ERD (expanded, versioned) =
182 +
183 +The **Data Use** model captures who does what with which versioned data:
184 +
185 +* Users (including technical users)
186 +* Roles and role assignments
187 +* Review actions on versioned entities
188 +
189 +{{comment}} Data Use ERD (Mermaid, from /Specification/Diagrams/Data Use ERD) {{/comment}}
190 +{{include document="FactHarbor.Playground.Data Use ERD Page (from Specification chat).WebHome"/}}
191 +
192 += Data Use ERD (Roles, Review & Versioned Entities) =
193 +
194 +This diagram shows how users, roles, and review actions relate to the
195 +versioned core entities.
196 +
197 +{{mermaid}}
198 +erDiagram
199 + %% Core clusters shown for context
200 + CLAIM_CLUSTER {
201 + string ClusterID PK
202 + string EmbeddingVectorRef
203 + string Theme
204 + }
205 +
206 + CLAIM {
207 + string ClaimID PK
208 + string ClusterID FK
209 + string Status
210 + datetime CreatedAt
211 + }
212 +
213 + CLAIM_VERSION {
214 + string ClaimVersionID PK
215 + string ClaimID FK
216 + string Text
217 + string ClaimType
218 + string Domain
219 + datetime CreatedAt
220 + }
221 +
222 + SCENARIO {
223 + string ScenarioID PK
224 + string ClaimID FK
225 + string Name
226 + datetime CreatedAt
227 + }
228 +
229 + SCENARIO_VERSION {
230 + string ScenarioVersionID PK
231 + string ScenarioID FK
232 + string Definitions
233 + string Assumptions
234 + string Boundaries
235 + datetime CreatedAt
236 + }
237 +
238 + EVIDENCE {
239 + string EvidenceID PK
240 + string SourceType
241 + string URL
242 + float ReliabilityScore
243 + }
244 +
245 + EVIDENCE_VERSION {
246 + string EvidenceVersionID PK
247 + string EvidenceID FK
248 + string Summary
249 + float ReliabilityScore
250 + datetime CreatedAt
251 + }
252 +
253 + VERDICT {
254 + string VerdictID PK
255 + string ScenarioID FK
256 + }
257 +
258 + VERDICT_VERSION {
259 + string VerdictVersionID PK
260 + string VerdictID FK
261 + float Verdict
262 + float Confidence
263 + string Reasoning
264 + datetime CreatedAt
265 + }
266 +
267 + %% Users and roles
268 + USER {
269 + string UserID PK
270 + string Handle
271 + string Email
272 + }
273 +
274 + TECHNICAL_USER {
275 + string UserID PK
276 + string SystemName
277 + }
278 +
279 + CONTRIBUTING_USER {
280 + string UserID PK
281 + string DisplayName
282 + }
283 +
284 + TRUSTED_CONTRIBUTOR {
285 + string UserID PK
286 + string TrustLevel
287 + }
288 +
289 + REVIEWER {
290 + string UserID PK
291 + string Domain
292 + }
293 +
294 + EXPERT {
295 + string UserID PK
296 + string ExpertiseArea
297 + }
298 +
299 + FEDERATION_NODE {
300 + string NodeID PK
301 + string Region
302 + }
303 +
304 + FEDERATION_ADMIN {
305 + string UserID PK
306 + string Permissions
307 + }
308 +
309 + REVIEW_ACTION {
310 + string ReviewActionID PK
311 + string UserID FK
312 + string TargetEntityType
313 + string TargetEntityVersionID
314 + string ActionType
315 + string Comment
316 + datetime Timestamp
317 + }
318 +
319 + %% Inheritance / specialization (modelled as relationships)
320 + USER ||--o{ TECHNICAL_USER : "is a"
321 + USER ||--o{ CONTRIBUTING_USER : "is a"
322 +
323 + CONTRIBUTING_USER ||--o{ TRUSTED_CONTRIBUTOR : "subset"
324 + CONTRIBUTING_USER ||--o{ REVIEWER : "subset"
325 + CONTRIBUTING_USER ||--o{ EXPERT : "subset"
326 +
327 + TECHNICAL_USER ||--o{ FEDERATION_NODE : "operates"
328 + TECHNICAL_USER ||--o{ FEDERATION_ADMIN : "administers"
329 +
330 + %% Review actions on versioned entities
331 + USER ||--o{ REVIEW_ACTION : performs
332 +
333 + REVIEW_ACTION }o--|| CLAIM_VERSION : reviews
334 + REVIEW_ACTION }o--|| SCENARIO_VERSION : reviews
335 + REVIEW_ACTION }o--|| EVIDENCE_VERSION : reviews
336 + REVIEW_ACTION }o--|| VERDICT_VERSION : reviews
337 +{{/mermaid}}
338 +
339 +{{info}}
340 +This diagram focuses on *who* uses and reviews *which* versioned entities.
341 +USER is the base type; TECHNICAL_USER and CONTRIBUTING_USER are specializations.
342 +Other roles (REVIEWER, EXPERT, TRUSTED_CONTRIBUTOR, FEDERATION_ADMIN, FEDERATION_NODE)
343 +are modelled as specializations or technical subtypes.
344 +{{/info}}
345 +
346 +
347 +Notes:
348 +
349 +* Most roles (READER, CONTRIBUTOR, TRUSTED_CONTRIBUTOR, REVIEWER, MODERATOR,
350 + SYSTEM_ADMIN, FEDERATION_OPERATOR, FEDERATION_ADMIN, …) are represented as rows
351 + in {{code}}ROLE{{/code}}.
352 +* {{code}}TECHNICAL_USER{{/code}} captures strictly technical accounts (API keys,
353 + node-to-node federation agents, batch jobs). All other roles can, in principle,
354 + be held by both human and technical users where appropriate.
355 +* A {{code}}READER{{/code}} normally does **not** perform REVIEW_ACTIONs, while
356 + roles like REVIEWER, TRUSTED_CONTRIBUTOR, MODERATOR, and some federation roles
357 + do.
358 +
359 +----
360 +
361 += 5.4 Versioning and re-evaluation behavior =
362 +
363 +This section ties the data model to the re-evaluation logic
364 +(described in more detail in the Versioning and Automation chapters).
365 +
366 +* When a new {{code}}EVIDENCE_VERSION{{/code}} is created:
367 +* All related {{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}} entries referencing
368 + that evidence version are candidates for re-assessment.
369 +* Related {{code}}VERDICT_VERSION{{/code}} entries may become **outdated** and
370 + are queued for re-evaluation.
371 +
372 +* When a new {{code}}SCENARIO_VERSION{{/code}} is created:
373 +* It may inherit some links from earlier scenarios, or start empty depending
374 + on the change classification (cosmetic vs. conceptual).
375 +* All verdicts for that scenario are recalculated and stored as new
376 +{{code}}VERDICT_VERSION{{/code}} entries.
377 +
378 +* REVIEW_ACTIONs are always attached to the **exact version** that was seen by
379 + the reviewer. This preserves a faithful audit trail if data later changes.
380 +
381 +* In a federated environment, nodes can choose:
382 +* which identity entities to replicate (CLAIM, SCENARIO, EVIDENCE, VERDICT)
383 +* which versioned entities to replicate (e.g. only accepted VERDICT_VERSIONs,
384 + only EVIDENCE_VERSIONs above a reliability threshold, etc.)
385 +
386 +----
387 +
388 += 5.5 Behavioral Notes =
389 +
390 +== 5.5.1 Late-Arriving Evidence ==
391 +
392 +New evidence versions can make existing verdicts **outdated** and may trigger
393 +re-evaluation cascades. This is handled by the global trigger and automation
394 +architecture (see the Versioning & Automation chapters).
395 +
396 +== 5.5.2 Scenario Evolution ==
397 +
398 +Scenario changes create new SCENARIO_VERSIONs; dependent verdicts and
399 +Scenario–Evidence links are re-assessed. Old versions remain available for
400 +historical comparison and reproducibility.
401 +
402 +== 5.5.3 Federation ==
403 +
404 +Federated nodes can replicate subsets of the graph, including:
405 +
406 +* Claims and Scenarios of local interest
407 +* Evidence metadata (without full content)
408 +* Verdict lineages used for local decision-making
409 +
410 +Federation-specific entities (such as {{code}}FEDERATION_NODE{{/code}},
411 +replication logs, and trust rules) are described in the Federation &
412 +Decentralization chapter and build on top of the core data model defined here.
413 +
414 +----
415 +
1 1  == 1. Overall analysis & review of the data model ==
2 2  
3 3  === 1.1 Strengths of the current design ===
... ... @@ -165,155 +165,3 @@
165 165  )))
166 166  * That’s fine for now; I’ll just clarify that those belong to a “Processing / AKEL” submodel, not the core logical data model.
167 167  )))
168 -
169 -= 5. Data Model =
170 -
171 -The FactHarbor data model centers on four fully versioned, immutable entities:
172 -
173 -* **Claim**
174 -* **Scenario**
175 -* **Evidence**
176 -* **Verdict**
177 -
178 -These entities form the structured **“truth landscape”** for each claim.
179 -The model is explicitly **versioned**, **traceable**, and **federation-ready**.
180 -
181 -To keep the system auditable and explainable, FactHarbor uses a consistent
182 -**identity vs. version** pattern:
183 -
184 -* Identity entities (e.g. {{code}}CLAIM{{/code}}, {{code}}SCENARIO{{/code}})
185 - define *what* something is in a stable sense.
186 -* Version entities (e.g. {{code}}CLAIM_VERSION{{/code}}, {{code}}SCENARIO_VERSION{{/code}})
187 - define *how that thing looked at a given point in time*.
188 -
189 -All reasoning (e.g. verdicts, review actions) is attached to **versions**, never to
190 -mutable identities.
191 -
192 -----
193 -
194 -= 5.1 Core entities and versioning pattern =
195 -
196 -(% class="wikitable" %)
197 -| **Logical concept** | **Identity entity** | **Version entity** | **Notes**
198 -| Claim (what people argue about) | {{code}}CLAIM{{/code}} | {{code}}CLAIM_VERSION{{/code}} | Claim text, phrasing, and metadata live in {{code}}CLAIM_VERSION{{/code}}. The identity {{code}}CLAIM{{/code}} stays stable across rephrasings.
199 -| Scenario (interpretive frame) | {{code}}SCENARIO{{/code}} | {{code}}SCENARIO_VERSION{{/code}} | A SCENARIO belongs to a CLAIM. Its versions capture evolving definitions, assumptions, and boundaries.
200 -| Evidence (source / datapoint) | {{code}}EVIDENCE{{/code}} | {{code}}EVIDENCE_VERSION{{/code}} | Identity of a source vs. specific extractions / updates over time.
201 -| Verdict (assessment) | {{code}}VERDICT{{/code}} | {{code}}VERDICT_VERSION{{/code}} | A VERDICT is defined per SCENARIO; VERDICT_VERSION captures the history of assessments.
202 -| Scenario–Evidence link | {{code}}SCENARIO_EVIDENCE_LINK{{/code}} | {{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}} | Links bind scenario versions to evidence versions with relevance & direction.
203 -| Claim cluster (semantic group) | {{code}}CLAIM_CLUSTER{{/code}} | – | Groups semantically related claims; mainly for discovery and navigation.
204 -
205 -Key design decisions:
206 -
207 -* A {{code}}CLAIM{{/code}} belongs to exactly one {{code}}CLAIM_CLUSTER{{/code}}.
208 -* A {{code}}SCENARIO{{/code}} belongs to exactly one {{code}}CLAIM{{/code}}
209 - (scenarios live at the *claim* level, not per individual phrasing).
210 -* Verdicts and Scenario–Evidence links are always attached to **versions**:
211 -* {{code}}SCENARIO_VERSION{{/code}} +
212 -{{code}}EVIDENCE_VERSION{{/code}} →
213 -{{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}}
214 -* {{code}}SCENARIO_VERSION{{/code}} →
215 -{{code}}VERDICT_VERSION{{/code}}
216 -
217 -This ensures that when a Scenario or Evidence changes, old verdicts and links
218 -remain intact as historical records and can be revisited.
219 -
220 -----
221 -
222 -= 5.2 Core Data Model ERD (expanded, versioned) =
223 -
224 -The following Mermaid ER diagram shows the main entities and their relationships.
225 -The convention is that fields ending in {{code}}Id{{/code}} are primary keys,
226 -and fields with {{code}}...IdFk{{/code}} are foreign keys.
227 -
228 -{{comment}} Core Data Model ERD (Mermaid, from /Specification/Diagrams/Data Model) {{/comment}}
229 -{{include document="FactHarbor.Playground.Core Data Model ERD Page (from Specification chat).WebHome"/}}
230 -
231 -**Important points:**
232 -
233 -* Scenarios and Evidence are **linked via their versions**
234 - ({{code}}SCENARIO_VERSION{{/code}} and {{code}}EVIDENCE_VERSION{{/code}}).
235 -* Verdicts are **per ScenarioVersion** and stored in {{code}}VERDICT_VERSION{{/code}}.
236 -* {{code}}CLAIM_CLUSTER{{/code}} is shared across diagrams; it is shown here and in the Data Use / Review model.
237 -
238 -All version entities are immutable: once created, they are never changed, only
239 -superseded by newer versions.
240 -
241 -----
242 -
243 -= 5.3 Data Use & Review ERD (expanded, versioned) =
244 -
245 -The **Data Use** model captures who does what with which versioned data:
246 -
247 -* Users (including technical users)
248 -* Roles and role assignments
249 -* Review actions on versioned entities
250 -
251 -{{comment}} Data Use ERD (Mermaid, from /Specification/Diagrams/Data Use ERD) {{/comment}}
252 -{{include document="FactHarbor.Playground.Data Use ERD Page (from Specification chat).WebHome"/}}
253 -
254 -Notes:
255 -
256 -* Most roles (READER, CONTRIBUTOR, TRUSTED_CONTRIBUTOR, REVIEWER, MODERATOR,
257 - SYSTEM_ADMIN, FEDERATION_OPERATOR, FEDERATION_ADMIN, …) are represented as rows
258 - in {{code}}ROLE{{/code}}.
259 -* {{code}}TECHNICAL_USER{{/code}} captures strictly technical accounts (API keys,
260 - node-to-node federation agents, batch jobs). All other roles can, in principle,
261 - be held by both human and technical users where appropriate.
262 -* A {{code}}READER{{/code}} normally does **not** perform REVIEW_ACTIONs, while
263 - roles like REVIEWER, TRUSTED_CONTRIBUTOR, MODERATOR, and some federation roles
264 - do.
265 -
266 -----
267 -
268 -= 5.4 Versioning and re-evaluation behavior =
269 -
270 -This section ties the data model to the re-evaluation logic
271 -(described in more detail in the Versioning and Automation chapters).
272 -
273 -* When a new {{code}}EVIDENCE_VERSION{{/code}} is created:
274 -* All related {{code}}SCENARIO_EVIDENCE_LINK_VERSION{{/code}} entries referencing
275 - that evidence version are candidates for re-assessment.
276 -* Related {{code}}VERDICT_VERSION{{/code}} entries may become **outdated** and
277 - are queued for re-evaluation.
278 -
279 -* When a new {{code}}SCENARIO_VERSION{{/code}} is created:
280 -* It may inherit some links from earlier scenarios, or start empty depending
281 - on the change classification (cosmetic vs. conceptual).
282 -* All verdicts for that scenario are recalculated and stored as new
283 -{{code}}VERDICT_VERSION{{/code}} entries.
284 -
285 -* REVIEW_ACTIONs are always attached to the **exact version** that was seen by
286 - the reviewer. This preserves a faithful audit trail if data later changes.
287 -
288 -* In a federated environment, nodes can choose:
289 -* which identity entities to replicate (CLAIM, SCENARIO, EVIDENCE, VERDICT)
290 -* which versioned entities to replicate (e.g. only accepted VERDICT_VERSIONs,
291 - only EVIDENCE_VERSIONs above a reliability threshold, etc.)
292 -
293 -----
294 -
295 -= 5.5 Behavioral Notes =
296 -
297 -== 5.5.1 Late-Arriving Evidence ==
298 -
299 -New evidence versions can make existing verdicts **outdated** and may trigger
300 -re-evaluation cascades. This is handled by the global trigger and automation
301 -architecture (see the Versioning & Automation chapters).
302 -
303 -== 5.5.2 Scenario Evolution ==
304 -
305 -Scenario changes create new SCENARIO_VERSIONs; dependent verdicts and
306 -Scenario–Evidence links are re-assessed. Old versions remain available for
307 -historical comparison and reproducibility.
308 -
309 -== 5.5.3 Federation ==
310 -
311 -Federated nodes can replicate subsets of the graph, including:
312 -
313 -* Claims and Scenarios of local interest
314 -* Evidence metadata (without full content)
315 -* Verdict lineages used for local decision-making
316 -
317 -Federation-specific entities (such as {{code}}FEDERATION_NODE{{/code}},
318 -replication logs, and trust rules) are described in the Federation &
319 -Decentralization chapter and build on top of the core data model defined here.