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.
Warning

Partially Implemented (v2.6.33) - Only AKEL system service is implemented. User system, moderators, background scheduler, and search indexer are not yet implemented.

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)