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: Contributor 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.

Technical & System Users
This diagram shows Technical Users (system processes like AKEL, sync bots, monitors) and their management by Moderators.

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"

Simplified technical model:

• USER: Standard users (Reader/Contributor based on reputation)
• MODERATOR: Appointed users with moderation permissions
• SYSTEM_SERVICE: Automated background services
• AKEL: AI processing engine
• BACKGROUND_SCHEDULER: Quality metrics, source updates, cleanup
• SEARCH_INDEXER: Elasticsearch synchronization
  Removed (no longer in simplified model):

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)