Review & Data Use
Version 2.7 by Robert Schaub on 2026/02/08 08:21
Review & Data Use
This page describes the Review & Data Use model, defining User roles and how review actions are logged.
1. User & Role Concepts
- USER: Base entity for all users (human or technical).
- TECHNICAL_USER: Strictly technical identities (services, federation components, background jobs).
- CONTRIBUTING_USER: Users that can contribute content (claims, scenarios, evidence).
- TRUSTED_CONTRIBUTOR: Additional trust / certification properties.
- REVIEWER: Can perform review actions on versioned entities.
- EXPERT: Reviewer with domain‑specific expertise / higher authority.
- FEDERATION_NODE: Technical entity representing a participating node in the federation.
- FEDERATION_ADMIN: Administers one or more federation nodes; not necessarily a content contributor.
2. Review Actions
The system logs every significant action:
- REVIEW_ACTION logs *who* did *what* on *which* versioned entity.
- Fields: ``ReviewActionID``, ``UserID``, ``EntityType``, ``EntityVersionID``, ``ActionType``, ``Timestamp``.
- Each entry targets a specific VERSIONED entity (e.g., ClaimVersion, ScenarioVersion).
- Claim Clusters may also be targets of review actions (e.g., curation or moderation).
3. Review & Data Use ERD
3.1 User Roles
graph TD READER[Reader] --> |Registers| CONTRIBUTOR[Contributor] CONTRIBUTOR --> |Earns Reputation| TRUSTED[Trusted Contributor
substantial reputation] CONTRIBUTOR --> |Appointed by
Governing Team| MODERATOR[Moderator] READER --> |Can| R1[Browse/Search] READER --> |Can| R2[Flag Issues] READER --> |Can| R3[Submit Claims] CONTRIBUTOR --> |Can| C1[Edit Claims] CONTRIBUTOR --> |Can| C2[Add Evidence] CONTRIBUTOR --> |Can| C3[Improve Content] TRUSTED --> |Can| T1[Approve Changes] TRUSTED --> |Can| T2[Mentor New Contributors] MODERATOR --> |Can| M1[Review Flags] MODERATOR --> |Can| M2[Hide Harmful Content] MODERATOR --> |Can| M3[Resolve Disputes] style READER fill:#e1f5ff style CONTRIBUTOR fill:#99ff99 style TRUSTED fill:#ffff99 style MODERATOR fill:#ff9999
Simplified flat role structure:
- Reader: Default role, no login required
- Contributor: Registers and earns reputation through contributions
- Trusted Contributor: substantial reputation unlocks additional permissions
- Moderator: Appointed by Governing Team, handles abuse/disputes
No hierarchy - roles represent responsibility levels, not management structure.
Target Technical Model
erDiagram
USER {
string UserID_PK
string role
int reputation
}
MODERATOR {
string ModeratorID_PK
string UserID_FK
string permissions
}
SYSTEM_SERVICE {
string ServiceID_PK
string ServiceName
string Purpose
string Status
}
AKEL {
string InstanceID_PK
string ServiceID_FK
string Version
}
BACKGROUND_SCHEDULER {
string SchedulerID_PK
string ServiceID_FK
string ScheduledTasks
}
SEARCH_INDEXER {
string IndexerID_PK
string ServiceID_FK
string LastSyncTime
}
USER ||--o| MODERATOR : appointed_as
MODERATOR ||--o{ SYSTEM_SERVICE : monitors
SYSTEM_SERVICE ||--|| AKEL : AI_processing
SYSTEM_SERVICE ||--|| BACKGROUND_SCHEDULER : periodic_tasks
SYSTEM_SERVICE ||--|| SEARCH_INDEXER : search_sync
Implementation Status
| Component | Target Purpose | Current Status |
|---|---|---|
| USER | User accounts with reputation | Not implemented (anonymous only) |
| MODERATOR | Appointed users with permissions | Not implemented |
| AKEL | AI processing engine | Implemented (Triple-Path pipeline) |
| BACKGROUND_SCHEDULER | Periodic tasks | Not implemented |
| SEARCH_INDEXER | Elasticsearch sync | Not implemented (no Elasticsearch) |
Current Implementation
v2.6.33 has only:
- AKEL pipeline for analysis
- .NET API for job persistence
- No background services
- No search indexing (uses web search only)
4. User Class Diagram
User Class Diagram
classDiagram
class BaseUser {
+view_results()
+browse()
+search()
}
class Reader {
<>
+browse()
+search()
+view_results()
}
class RegisteredUser {
+UUID id
+String username
+Role role
+Timestamp created_at
+submit_url()
+flag_issue()
+view_submission_history()
}
class UCMAdministrator {
+manage_config()
+view_audit_trail()
+activate_config_version()
+trigger_reanalysis()
+view_system_metrics()
}
class Moderator {
+review_flags()
+hide_content()
+ban_user()
}
BaseUser <|-- Reader : anonymous
BaseUser <|-- RegisteredUser : logged in
RegisteredUser <|-- UCMAdministrator : appointed
RegisteredUser <|-- Moderator : appointed
Role Permissions
| Role | Capabilities | Requirements |
|---|---|---|
| Reader (Guest) | Browse, search, view results | No login required |
| User (Registered) | Everything Reader can + submit URLs/text (rate-limited), flag content | Free account required |
| UCM Administrator | Everything User can + manage UCM config, view audit trail, trigger re-analysis | Appointed by Governing Team |
| Moderator | Everything User can + review flags, hide content, ban users | Appointed by Governing Team |
Current Implementation
- All users are anonymous Readers (no authentication system yet)
- UCM config management via CLI/direct DB access
- No moderator tooling
- No rate limiting (single-user development mode)
Design Principles
- No data editing roles — analysis outputs are immutable
- UCM Administrator improves the system through configuration, not by editing individual outputs
- Submission requires login — LLM inference and web search are not free; rate limits control costs
- Four roles: Reader (guest), User (registered), UCM Administrator (appointed), Moderator (appointed)