Wiki source code of User Class Diagram
Version 4.5 by Robert Schaub on 2025/12/24 20:32
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | **User Class Diagram** |
| 2 | |||
| |
4.1 | 3 | This diagram shows the user role hierarchy in FactHarbor v0.9.1, with corrected inheritance. |
| |
3.1 | 4 | |
| |
4.1 | 5 | == Critical: Corrected Inheritance == |
| |
1.1 | 6 | |
| |
4.1 | 7 | **IMPORTANT CORRECTION**: |
| |
4.2 | 8 | |
| |
4.1 | 9 | * Moderator derives from **Reviewer** (NOT from Expert) |
| 10 | * Maintainer derives from **Contributor** (NOT from Reviewer or Moderator) | ||
| |
1.1 | 11 | |
| |
4.1 | 12 | **Two Independent Tracks from Contributor**: |
| 13 | |||
| 14 | **Content Track**: Contributor → Reviewer → (Auditor | Expert | Moderator) | ||
| |
4.2 | 15 | |
| |
4.1 | 16 | * Focus: Content quality, validation, community management |
| 17 | * Skills: Domain expertise, review, moderation | ||
| 18 | |||
| 19 | **Technical Track**: Contributor → Maintainer | ||
| |
4.2 | 20 | |
| |
4.1 | 21 | * Focus: System operations, configuration, deployment |
| 22 | * Skills: DevOps, system administration, technical configuration | ||
| 23 | * **Independent from content review** - Maintainers don't need review skills | ||
| 24 | |||
| 25 | **System Track**: Reader → Technical User | ||
| |
4.2 | 26 | |
| |
4.1 | 27 | * Not human users - automated processes |
| 28 | * Examples: AKEL instances, sync bots, monitors | ||
| 29 | * Managed by Maintainers | ||
| 30 | |||
| |
3.1 | 31 | == Role Hierarchy Explanation == |
| 32 | |||
| 33 | **Base: Reader** | ||
| |
4.2 | 34 | |
| |
3.1 | 35 | * Anyone, no login required |
| 36 | * Foundation for all other roles | ||
| 37 | * Can browse, search, compare, flag, and **automatically submit claims** | ||
| 38 | |||
| |
4.1 | 39 | **Technical User** (system type, extends Reader) |
| |
4.2 | 40 | |
| |
4.1 | 41 | * **Not human users** - automated system processes |
| 42 | * Examples: AKEL instances, federation sync bots, backup services, monitoring | ||
| 43 | * Can perform automated operations | ||
| 44 | * AKEL is primary implementation of Technical User pattern | ||
| 45 | |||
| |
3.1 | 46 | **Contributor** (extends Reader) |
| |
4.2 | 47 | |
| |
4.1 | 48 | * Registered human users |
| |
3.1 | 49 | * Can submit evidence, propose scenarios, participate in discussions |
| 50 | * All Reader capabilities plus contribution rights | ||
| |
4.1 | 51 | * **Two-way branching**: Can become Reviewer (content track) or Maintainer (technical track) |
| |
3.1 | 52 | |
| |
4.1 | 53 | **Reviewer** (is-a Contributor - Content Track) |
| |
4.2 | 54 | |
| |
4.1 | 55 | * Trusted community members on **content track** |
| |
3.1 | 56 | * Can review and approve content |
| 57 | * Can validate AI-generated content (Mode 2 → Mode 3 for Tier B/C) | ||
| 58 | * Participates in audit sampling | ||
| |
4.1 | 59 | * **Three-way branching**: Can specialize as Auditor, Expert, or Moderator |
| |
3.1 | 60 | |
| |
4.1 | 61 | **Maintainer** (is-a Contributor - Technical Track) |
| |
4.2 | 62 | |
| |
4.1 | 63 | * Core technical team members on **technical track** |
| 64 | * System configuration and deployment authority | ||
| 65 | * Does NOT require review skills | ||
| 66 | * Manages Technical Users (creates AKEL instances, sync bots, etc.) | ||
| 67 | * **Independent from content review hierarchy** | ||
| 68 | |||
| 69 | **Specialized Reviewer Roles**: | ||
| 70 | |||
| 71 | **Auditor** (specialized Reviewer - QA track) | ||
| |
4.2 | 72 | |
| |
4.1 | 73 | * Dedicated quality assurance role |
| |
3.1 | 74 | * Reviews sampled AI-generated content |
| 75 | * Validates quality gate enforcement | ||
| 76 | * Provides feedback for system improvement | ||
| 77 | |||
| |
4.1 | 78 | **Expert** (specialized Reviewer - domain track) |
| |
4.2 | 79 | |
| |
4.1 | 80 | * Subject matter specialists |
| 81 | * Final authority for Tier A content in their domain | ||
| |
3.1 | 82 | * Can define domain-specific standards |
| 83 | * Required for Tier A "Human-Reviewed" status | ||
| 84 | |||
| |
4.1 | 85 | **Moderator** (specialized Reviewer - process track) |
| |
4.2 | 86 | |
| |
4.1 | 87 | * Community management focus |
| |
3.1 | 88 | * Handles abuse and disputes |
| 89 | * Manages users and permissions | ||
| 90 | * Oversees audit system | ||
| |
4.1 | 91 | * **Independent from domain expertise and technical operations** |
| |
3.1 | 92 | |
| |
4.1 | 93 | **AKEL** (Technical User implementation) |
| |
4.2 | 94 | |
| |
4.1 | 95 | * AI system implementing Technical User interface |
| |
3.1 | 96 | * Creates drafts for Contributor review |
| |
4.1 | 97 | * Subject to Auditor oversight |
| |
3.1 | 98 | * Never bypasses human authority |
| 99 | |||
| 100 | == Key Design Principles == | ||
| 101 | |||
| |
4.1 | 102 | **Why Maintainer derives from Contributor (not Reviewer)**: |
| |
4.2 | 103 | |
| |
4.1 | 104 | * **Different skill set**: Technical operations ≠ Content review |
| 105 | * **Separation of concerns**: Technical authority independent from editorial authority | ||
| 106 | * **Flexibility**: Can have technical experts without review experience | ||
| 107 | * **Realistic**: System admin skills and content review skills are distinct | ||
| 108 | * **Cleaner**: Maintainer manages Technical Users (including AKEL) - natural fit on technical track | ||
| 109 | |||
| 110 | **Why Moderator derives from Reviewer (not Expert)**: | ||
| |
4.2 | 111 | |
| |
4.1 | 112 | * Moderators handle **process** (community management, disputes) not **domain expertise** |
| 113 | * Experts focus on **subject matter** (medical, legal, scientific validation) | ||
| 114 | * Allows independent oversight of content quality (Experts) vs community behavior (Moderators) | ||
| 115 | * Moderators don't need domain expertise to handle community issues | ||
| 116 | |||
| 117 | **Technical User Pattern**: | ||
| |
4.2 | 118 | |
| |
4.1 | 119 | * **Purpose**: Represents automated system processes |
| 120 | * **Examples**: AKEL (AI processing), Federation sync bots, Scheduled audit tasks, Backup services, Monitoring systems, API integrations | ||
| 121 | * **Managed by**: Maintainers create and configure Technical Users | ||
| 122 | * **Authority**: Limited to programmatic operations, no human-level decisions | ||
| 123 | |||
| |
3.1 | 124 | **Progressive Trust**: |
| |
4.2 | 125 | |
| |
4.1 | 126 | * Reader → Contributor (registration) |
| 127 | * Contributor → Reviewer (content track) OR Maintainer (technical track) | ||
| 128 | * Reviewer → Auditor/Expert/Moderator (specializations) | ||
| 129 | * All appointments based on demonstrated competence | ||
| |
3.1 | 130 | |
| 131 | **Human Authority**: | ||
| |
4.2 | 132 | |
| |
4.1 | 133 | * Technical Users assist but don't make human-level decisions |
| 134 | * Human Reviewers validate AI outputs | ||
| |
3.1 | 135 | * Experts have final say on Tier A content |
| |
4.1 | 136 | * Moderators have final say on community matters |
| 137 | * Maintainers have final say on technical configuration | ||
| |
3.1 | 138 | |
| |
4.2 | 139 | {{include reference="FactHarbor.Archive.FactHarbor V0\.9\.23 Lost Data.Specification.Diagrams.User Class Diagram_Mermaid.WebHome"}}{{/include}} |