Wiki source code of Requirements
Version 6.1 by Robert Schaub on 2025/12/14 18:59
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | = Requirements = |
| 2 | |||
| |
6.1 | 3 | This page defines **Roles**, **Responsibilities**, and **Rules** for contributors and users of FactHarbor. |
| |
1.1 | 4 | |
| |
6.1 | 5 | == Roles == |
| |
1.1 | 6 | |
| |
6.1 | 7 | === Contributor === |
| |
1.1 | 8 | |
| |
6.1 | 9 | **Who**: Anyone (logged in or anonymous). |
| |
1.1 | 10 | |
| |
6.1 | 11 | **Can**: |
| 12 | * Submit claims | ||
| 13 | * Submit evidence | ||
| 14 | * Provide feedback | ||
| 15 | * Suggest scenarios | ||
| 16 | * Flag content for review | ||
| 17 | * Request human review of AI-generated content | ||
| |
1.1 | 18 | |
| |
6.1 | 19 | **Cannot**: |
| 20 | * Publish or mark content as "reviewed" or "approved" | ||
| 21 | * Override expert or maintainer decisions | ||
| 22 | * Directly modify AKEL or quality gate configurations | ||
| |
1.1 | 23 | |
| |
6.1 | 24 | === Reviewer === |
| |
1.1 | 25 | |
| |
6.1 | 26 | **Who**: Trusted community members, appointed by maintainers. |
| |
1.1 | 27 | |
| |
6.1 | 28 | **Can**: |
| 29 | * Review contributions from Contributors and AKEL drafts | ||
| 30 | * Validate AI-generated content (Mode 2 → Mode 3 transition) | ||
| 31 | * Edit claims, scenarios, and evidence | ||
| 32 | * Add clarifications or warnings | ||
| 33 | * Change content status: `draft` → `in review` → `published` / `rejected` | ||
| 34 | * Approve or reject **Tier B and C** content for "Human-Reviewed" status | ||
| 35 | * Flag content for expert review | ||
| 36 | * Participate in audit sampling | ||
| |
1.1 | 37 | |
| |
6.1 | 38 | **Cannot**: |
| 39 | * Approve Tier A content for "Human-Reviewed" status (requires Expert) | ||
| 40 | * Change governance rules | ||
| 41 | * Unilaterally change expert conclusions without process | ||
| 42 | * Bypass quality gates | ||
| |
1.1 | 43 | |
| |
6.1 | 44 | **Note on AI-Drafted Content**: |
| 45 | * Reviewers can validate AI-generated content (Mode 2) to promote it to "Human-Reviewed" (Mode 3) | ||
| 46 | * For Tier B and C, Reviewers have approval authority | ||
| 47 | * For Tier A, only Experts can grant "Human-Reviewed" status | ||
| |
1.1 | 48 | |
| |
6.1 | 49 | === Expert (Domain-Specific) === |
| |
1.1 | 50 | |
| |
6.1 | 51 | **Who**: Subject-matter specialists in specific domains (medicine, law, science, etc.). |
| |
1.1 | 52 | |
| |
6.1 | 53 | **Can**: |
| 54 | * Everything a Reviewer can do | ||
| 55 | * **Final authority** on Tier A content "Human-Reviewed" status | ||
| 56 | * Validate complex or controversial claims in their domain | ||
| 57 | * Define domain-specific quality standards | ||
| 58 | * Set reliability thresholds for domain sources | ||
| 59 | * Participate in risk tier assignment review | ||
| 60 | * Override AKEL suggestions in their domain (with documentation) | ||
| |
1.1 | 61 | |
| |
6.1 | 62 | **Cannot**: |
| 63 | * Change platform governance policies | ||
| 64 | * Approve content outside their expertise domain | ||
| 65 | * Bypass technical quality gates (but can flag for adjustment) | ||
| |
1.1 | 66 | |
| |
6.1 | 67 | **Specialization**: |
| 68 | * Experts are domain-specific (e.g., "Medical Expert", "Legal Expert", "Climate Science Expert") | ||
| 69 | * Cross-domain claims may require multiple expert reviews | ||
| |
1.1 | 70 | |
| |
6.1 | 71 | === Auditor === |
| |
1.1 | 72 | |
| |
6.1 | 73 | **Who**: Reviewers or Experts assigned to sampling audit duties. |
| |
1.1 | 74 | |
| |
6.1 | 75 | **Can**: |
| 76 | * Review sampled AI-generated content against quality standards | ||
| 77 | * Validate quality gate enforcement | ||
| 78 | * Identify patterns in AI errors or hallucinations | ||
| 79 | * Provide feedback for system improvement | ||
| 80 | * Flag content for immediate review if errors found | ||
| 81 | * Contribute to audit statistics and transparency reports | ||
| |
1.1 | 82 | |
| |
6.1 | 83 | **Cannot**: |
| 84 | * Change audit sampling algorithms (maintainer responsibility) | ||
| 85 | * Bypass normal review workflows | ||
| 86 | * Audit content they personally created | ||
| |
1.1 | 87 | |
| |
6.1 | 88 | **Selection**: |
| 89 | * Auditors selected based on domain expertise and review quality | ||
| 90 | * Rotation to prevent audit fatigue | ||
| 91 | * Stratified assignment (Tier A auditors need higher expertise) | ||
| |
1.1 | 92 | |
| |
6.1 | 93 | **Audit Focus**: |
| 94 | * Tier A: Recommendation 30-50% sampling rate, expert auditors | ||
| 95 | * Tier B: Recommendation 10-20% sampling rate, reviewer/expert auditors | ||
| 96 | * Tier C: Recommendation 5-10% sampling rate, reviewer auditors | ||
| |
5.1 | 97 | |
| |
6.1 | 98 | === Moderator === |
| |
5.1 | 99 | |
| |
6.1 | 100 | **Who**: Maintainers or trusted long-term contributors. |
| |
5.1 | 101 | |
| |
6.1 | 102 | **Can**: |
| 103 | * All Reviewer and Expert capabilities (cross-domain) | ||
| 104 | * Manage user accounts and permissions | ||
| 105 | * Handle disputes and conflicts | ||
| 106 | * Enforce community guidelines | ||
| 107 | * Suspend or ban abusive users | ||
| 108 | * Finalize publication status for sensitive content | ||
| 109 | * Review and adjust risk tier assignments | ||
| 110 | * Oversee audit system performance | ||
| |
5.1 | 111 | |
| |
6.1 | 112 | **Cannot**: |
| 113 | * Change core data model or architecture | ||
| 114 | * Override technical system constraints | ||
| 115 | * Make unilateral governance decisions without consensus | ||
| |
5.1 | 116 | |
| |
6.1 | 117 | === Maintainer === |
| |
5.1 | 118 | |
| |
6.1 | 119 | **Who**: Core team members responsible for the platform. |
| |
5.1 | 120 | |
| |
6.1 | 121 | **Can**: |
| 122 | * All Moderator capabilities | ||
| 123 | * Change data model, architecture, and technical systems | ||
| 124 | * Configure quality gates and AKEL parameters | ||
| 125 | * Adjust audit sampling algorithms | ||
| 126 | * Set and modify risk tier policies | ||
| 127 | * Make platform-wide governance decisions | ||
| 128 | * Access and modify backend systems | ||
| 129 | * Deploy updates and fixes | ||
| 130 | * Grant and revoke roles | ||
| |
5.1 | 131 | |
| |
6.1 | 132 | **Governance**: |
| 133 | * Maintainers operate under organizational governance rules | ||
| 134 | * Major policy changes require Governing Team approval | ||
| 135 | * Technical decisions made collaboratively | ||
| |
5.1 | 136 | |
| 137 | ---- | ||
| 138 | |||
| |
6.1 | 139 | == Content Publication States == |
| |
5.1 | 140 | |
| |
6.1 | 141 | === Mode 1: Draft === |
| 142 | * Not visible to public | ||
| 143 | * Visible to contributor and reviewers | ||
| 144 | * Can be edited by contributor or reviewers | ||
| 145 | * Default state for failed quality gates | ||
| |
5.1 | 146 | |
| |
6.1 | 147 | === Mode 2: AI-Generated (Published) === |
| 148 | * **Public** and visible to all users | ||
| 149 | * Clearly labeled as "AI-Generated, Awaiting Human Review" | ||
| 150 | * Passed all automated quality gates | ||
| 151 | * Risk tier displayed (A/B/C) | ||
| 152 | * Users can: | ||
| 153 | ** Read and use content | ||
| 154 | ** Request human review | ||
| 155 | ** Flag for expert attention | ||
| 156 | * Subject to sampling audits | ||
| 157 | * Can be promoted to Mode 3 by reviewer/expert validation | ||
| |
5.1 | 158 | |
| |
6.1 | 159 | === Mode 3: Human-Reviewed (Published) === |
| 160 | * **Public** and visible to all users | ||
| 161 | * Labeled as "Human-Reviewed" with reviewer/expert attribution | ||
| 162 | * Passed quality gates + human validation | ||
| 163 | * Highest trust level | ||
| 164 | * For Tier A, requires Expert approval | ||
| 165 | * For Tier B/C, Reviewer approval sufficient | ||
| |
5.1 | 166 | |
| |
6.1 | 167 | === Rejected === |
| 168 | * Not visible to public | ||
| 169 | * Visible to contributor with rejection reason | ||
| 170 | * Can be resubmitted after addressing issues | ||
| 171 | * Rejection logged for transparency | ||
| |
5.1 | 172 | |
| 173 | ---- | ||
| 174 | |||
| |
6.1 | 175 | == Contribution Rules == |
| |
5.1 | 176 | |
| |
6.1 | 177 | === All Contributors Must: === |
| 178 | * Provide sources for claims | ||
| 179 | * Use clear, neutral language | ||
| 180 | * Avoid personal attacks or insults | ||
| 181 | * Respect intellectual property (cite sources) | ||
| 182 | * Accept community feedback gracefully | ||
| |
5.1 | 183 | |
| |
6.1 | 184 | === AKEL (AI) Must: === |
| 185 | * Mark all outputs with `AuthorType = AI` | ||
| 186 | * Pass quality gates before Mode 2 publication | ||
| 187 | * Perform mandatory contradiction search | ||
| 188 | * Disclose confidence levels and uncertainty | ||
| 189 | * Provide traceable reasoning chains | ||
| 190 | * Flag potential bubbles or echo chambers | ||
| 191 | * Submit to audit sampling | ||
| |
5.1 | 192 | |
| |
6.1 | 193 | === Reviewers Must: === |
| 194 | * Be impartial and evidence-based | ||
| 195 | * Document reasoning for decisions | ||
| 196 | * Escalate to experts when appropriate | ||
| 197 | * Participate in audits when assigned | ||
| 198 | * Provide constructive feedback | ||
| |
5.1 | 199 | |
| |
6.1 | 200 | === Experts Must: === |
| 201 | * Stay within domain expertise | ||
| 202 | * Disclose conflicts of interest | ||
| 203 | * Document specialized terminology | ||
| 204 | * Provide reasoning for domain-specific decisions | ||
| 205 | * Participate in Tier A audits | ||
| |
5.1 | 206 | |
| 207 | ---- | ||
| 208 | |||
| |
6.1 | 209 | == Quality Standards == |
| |
5.1 | 210 | |
| |
6.1 | 211 | === Source Requirements === |
| 212 | * Primary sources preferred over secondary | ||
| 213 | * Publication date and author must be identifiable | ||
| 214 | * Sources must be accessible (not paywalled when possible) | ||
| 215 | * Contradictory sources must be acknowledged | ||
| 216 | * Echo chamber sources must be flagged | ||
| |
5.1 | 217 | |
| |
6.1 | 218 | === Claim Requirements === |
| 219 | * Falsifiable or evaluable | ||
| 220 | * Clear definitions of key terms | ||
| 221 | * Boundaries and scope stated | ||
| 222 | * Assumptions made explicit | ||
| 223 | * Uncertainty acknowledged | ||
| |
5.1 | 224 | |
| |
6.1 | 225 | === Evidence Requirements === |
| 226 | * Relevant to the claim and scenario | ||
| 227 | * Reliability assessment provided | ||
| 228 | * Methodology described (for studies) | ||
| 229 | * Limitations noted | ||
| 230 | * Conflicting evidence acknowledged | ||
| |
5.1 | 231 | |
| 232 | ---- | ||
| 233 | |||
| |
6.1 | 234 | == Risk Tier Assignment == |
| |
5.1 | 235 | |
| |
6.1 | 236 | **Automated (AKEL)**: Initial tier suggested based on domain, keywords, impact |
| 237 | **Human Validation**: Moderators or Experts can override AKEL suggestions | ||
| 238 | **Review**: Risk tiers periodically reviewed based on audit outcomes | ||
| |
5.1 | 239 | |
| |
6.1 | 240 | **Tier A Indicators**: |
| 241 | * Medical diagnosis or treatment advice | ||
| 242 | * Legal interpretation or advice | ||
| 243 | * Election or voting information | ||
| 244 | * Safety or security sensitive | ||
| 245 | * Major financial decisions | ||
| 246 | * Potential for significant harm | ||
| |
5.1 | 247 | |
| |
6.1 | 248 | **Tier B Indicators**: |
| 249 | * Complex scientific causality | ||
| 250 | * Contested policy domains | ||
| 251 | * Historical interpretation with political implications | ||
| 252 | * Significant economic impact claims | ||
| |
5.1 | 253 | |
| |
6.1 | 254 | **Tier C Indicators**: |
| 255 | * Established historical facts | ||
| 256 | * Simple definitions | ||
| 257 | * Well-documented scientific consensus | ||
| 258 | * Basic reference information | ||
| |
5.1 | 259 | |
| 260 | ---- | ||
| 261 | |||
| |
6.1 | 262 | == Related Pages == |
| |
5.1 | 263 | |
| |
6.1 | 264 | * [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] |
| 265 | * [[Automation>>FactHarbor.Specification.Automation.WebHome]] | ||
| 266 | * [[Workflows>>FactHarbor.Specification.Workflows.WebHome]] | ||
| 267 | * [[Governance>>FactHarbor.Organisation.Governance]] | ||
| |
5.1 | 268 |