Wiki source code of Governance
Last modified by Robert Schaub on 2026/02/08 21:21
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | = Governance = | ||
| 2 | |||
| 3 | FactHarbor is governed collaboratively with clear separation between **organizational policy and decisions** and **technical implementation**. | ||
| 4 | |||
| 5 | == 1. Governance Structure == | ||
| 6 | |||
| 7 | {{include reference="Archive.FactHarbor.Organisation.Diagrams.Governance Structure.WebHome"/}} | ||
| 8 | |||
| 9 | * **Governing Team** – Sets high-level policy, organizational direction, funding priorities | ||
| 10 | * **Lead** – Coordinates execution, represents organization publicly | ||
| 11 | * **Core Maintainers** – Technical and specification decisions, code/spec review | ||
| 12 | * **Domain Experts** – Subject-matter authority in specialized areas | ||
| 13 | * **Community Contributors** – Feedback, proposals, and participation in decision-making | ||
| 14 | |||
| 15 | == 2. Decision-Making Levels == | ||
| 16 | |||
| 17 | === 2.1 Technical Decisions (Maintainers) === | ||
| 18 | |||
| 19 | **Scope**: Architecture, data model, AKEL configuration, quality gates, system performance | ||
| 20 | |||
| 21 | **Process**: | ||
| 22 | |||
| 23 | * Proposals discussed in technical forums | ||
| 24 | * Review by core maintainers | ||
| 25 | * Consensus-based approval | ||
| 26 | * Breaking changes require broader community input | ||
| 27 | * Quality gate adjustments require rationale and audit validation | ||
| 28 | |||
| 29 | **Examples**: | ||
| 30 | |||
| 31 | * Adding new quality gate | ||
| 32 | * Adjusting AKEL parameters | ||
| 33 | * Modifying audit sampling algorithms | ||
| 34 | * Database schema changes | ||
| 35 | |||
| 36 | === 2.2 Policy Decisions (Governing Team + Community) === | ||
| 37 | |||
| 38 | **Scope**: Risk tier policies, publication rules, content guidelines, ethical boundaries | ||
| 39 | |||
| 40 | **Process**: | ||
| 41 | |||
| 42 | * Proposal published for community feedback | ||
| 43 | * Discussion period (recommendation: minimum 14 days for major changes) | ||
| 44 | * Governing Team decision with community input | ||
| 45 | * Transparency in reasoning | ||
| 46 | * Risk tier policy changes require Expert consultation | ||
| 47 | |||
| 48 | **Examples**: | ||
| 49 | |||
| 50 | * Defining Tier A domains | ||
| 51 | * Setting audit sampling rates | ||
| 52 | * Content moderation policies | ||
| 53 | * Community guidelines | ||
| 54 | |||
| 55 | === 2.3 Domain-Specific Decisions (Experts) === | ||
| 56 | |||
| 57 | **Scope**: Domain quality standards, source reliability in specialized fields, Tier A content validation | ||
| 58 | |||
| 59 | **Process**: | ||
| 60 | |||
| 61 | * Expert consensus in domain | ||
| 62 | * Documented reasoning | ||
| 63 | * Review by other experts | ||
| 64 | * Escalation to Governing Team if unresolved | ||
| 65 | * Experts set domain-specific audit criteria | ||
| 66 | |||
| 67 | **Examples**: | ||
| 68 | |||
| 69 | * Medical claim evaluation standards | ||
| 70 | * Legal citation requirements | ||
| 71 | * Scientific methodology thresholds | ||
| 72 | * Tier A approval criteria by domain | ||
| 73 | |||
| 74 | == 3. AI and Human Roles in Governance == | ||
| 75 | |||
| 76 | === 3.1 Human-Only Governance Decisions === | ||
| 77 | |||
| 78 | The following can **never** be automated: | ||
| 79 | |||
| 80 | * **Ethical boundary setting** – What content is acceptable, what harm thresholds exist | ||
| 81 | * **Risk tier policy** – Which domains are Tier A/B/C (though AKEL can suggest) | ||
| 82 | * **Audit system oversight** – Quality standards, sampling strategies, auditor selection | ||
| 83 | * **Dispute resolution** – Conflicts between experts, controversial decisions | ||
| 84 | * **Community guidelines enforcement** – Bans, suspensions, conflict mediation | ||
| 85 | * **Organizational direction** – Mission, vision, funding priorities | ||
| 86 | |||
| 87 | === 3.2 AKEL Advisory Role === | ||
| 88 | |||
| 89 | AKEL can **assist but not decide**: | ||
| 90 | |||
| 91 | * Suggest risk tier assignments (humans validate) | ||
| 92 | * Flag content for expert review (humans decide) | ||
| 93 | * Identify patterns in audit failures (humans adjust policy) | ||
| 94 | * Propose quality gate refinements (maintainers approve) | ||
| 95 | * Detect emerging topics needing new policies (Governing Team decides) | ||
| 96 | |||
| 97 | === 3.3 Transparency Requirement === | ||
| 98 | |||
| 99 | All governance decisions must be: | ||
| 100 | |||
| 101 | * **Documented** with reasoning | ||
| 102 | * **Published** for community visibility | ||
| 103 | * **Reviewable** by community members | ||
| 104 | * **Reversible** if evidence of error or harm | ||
| 105 | |||
| 106 | == 4. Audit System Governance == | ||
| 107 | |||
| 108 | === 4.1 Audit Oversight Committee === | ||
| 109 | |||
| 110 | **Composition**: Maintainers, Domain Experts, and Governing Team member(s) | ||
| 111 | |||
| 112 | **Responsibilities**: | ||
| 113 | |||
| 114 | * Set quality standards for audit evaluation | ||
| 115 | * Review audit statistics and trends | ||
| 116 | * Adjust sampling rates based on performance | ||
| 117 | * Approve changes to audit algorithms | ||
| 118 | * Oversee auditor selection and rotation | ||
| 119 | * Publish transparency reports | ||
| 120 | |||
| 121 | **Meeting Frequency**: Recommendation: Regular meetings as needed | ||
| 122 | |||
| 123 | **Reporting**: Recommendation: Periodic transparency reports to community | ||
| 124 | |||
| 125 | === 4.2 Audit Performance Metrics === | ||
| 126 | |||
| 127 | Tracked and published: | ||
| 128 | |||
| 129 | * Audit pass/fail rates by tier | ||
| 130 | * Common failure patterns | ||
| 131 | * System improvements implemented | ||
| 132 | * Time to resolution for audit failures | ||
| 133 | * Auditor performance (anonymized) | ||
| 134 | |||
| 135 | === 4.3 Feedback Loop Governance === | ||
| 136 | |||
| 137 | **Process**: | ||
| 138 | |||
| 139 | 1. Audits identify patterns in AI errors | ||
| 140 | 2. Audit Committee reviews patterns | ||
| 141 | 3. Maintainers propose technical fixes | ||
| 142 | 4. Changes tested in sandbox | ||
| 143 | 5. Community informed of improvements | ||
| 144 | 6. Deployed with monitoring | ||
| 145 | |||
| 146 | **Escalation**: | ||
| 147 | |||
| 148 | * Persistent high failure rates → Pause AI publication in affected tier/domain | ||
| 149 | * Critical errors → Immediate system review | ||
| 150 | * Pattern of harm → Policy revision | ||
| 151 | |||
| 152 | == 5. Risk tier Policy Governance == | ||
| 153 | |||
| 154 | === 5.1 Risk Tier Assignment Authority === | ||
| 155 | |||
| 156 | * **AKEL**: Suggests initial tier based on domain, keywords, content analysis | ||
| 157 | * **Moderators**: Can override AKEL for individual content | ||
| 158 | * **Experts**: Set tier policy for their domains | ||
| 159 | * **Governing Team**: Approve tier policy changes, resolve tier disputes | ||
| 160 | |||
| 161 | === 5.2 Risk Tier Review Process === | ||
| 162 | |||
| 163 | **Triggers for Review**: | ||
| 164 | |||
| 165 | * Significant audit failures in a tier | ||
| 166 | * New emerging topics or domains | ||
| 167 | * Community flags systematic misclassification | ||
| 168 | * Expert domain recommendations | ||
| 169 | * Periodic policy review | ||
| 170 | |||
| 171 | **Process**: | ||
| 172 | |||
| 173 | 1. Expert domain review (identify if Tier A/B/C appropriate) | ||
| 174 | 2. Community input period (recommendation: sufficient time for feedback) | ||
| 175 | 3. Audit Committee assessment (error patterns in current tier) | ||
| 176 | 4. Governing Team decision | ||
| 177 | 5. Implementation with monitoring period | ||
| 178 | 6. Transparency report on rationale | ||
| 179 | |||
| 180 | === 5.3 Current Tier Assignments (Baseline) === | ||
| 181 | |||
| 182 | **Tier A**: Medical, legal, elections, safety/security, major financial decisions | ||
| 183 | |||
| 184 | **Tier B**: Complex science causality, contested policy, historical interpretation with political implications, significant economic impact | ||
| 185 | |||
| 186 | **Tier C**: Established historical facts, simple definitions, well-documented scientific consensus, basic reference info | ||
| 187 | |||
| 188 | **Note**: These are guidelines; edge cases require expert judgment | ||
| 189 | |||
| 190 | |||
| 191 | == 6. Quality Gate Governance == | ||
| 192 | |||
| 193 | === 6.1 Quality Gate Modification Process === | ||
| 194 | |||
| 195 | **Who Can Propose**: Maintainers, Experts, Audit Committee | ||
| 196 | |||
| 197 | **Requirements**: | ||
| 198 | |||
| 199 | * Rationale based on audit failures or system improvements | ||
| 200 | * Testing in sandbox environment | ||
| 201 | * Impact assessment (false positive/negative rates) | ||
| 202 | * Community notification before deployment | ||
| 203 | |||
| 204 | **Approval**: | ||
| 205 | |||
| 206 | * Technical changes: Maintainer consensus | ||
| 207 | * Policy changes (e.g., new gate criteria): Governing Team approval | ||
| 208 | |||
| 209 | **Examples of Governed Changes**: | ||
| 210 | |||
| 211 | * Adjusting contradiction search scope | ||
| 212 | * Modifying source reliability thresholds | ||
| 213 | * Adding new bubble detection patterns | ||
| 214 | * Changing uncertainty quantification formulas | ||
| 215 | |||
| 216 | == 7. Community Participation == | ||
| 217 | |||
| 218 | === 7.1 Open Discussion Forums === | ||
| 219 | |||
| 220 | * Technical proposals (maintainer-led) | ||
| 221 | * Policy proposals (Governing Team-led) | ||
| 222 | * Domain-specific discussions (Expert-led) | ||
| 223 | * Audit findings and improvements (Audit Committee-led) | ||
| 224 | |||
| 225 | === 7.2 Proposal Mechanism === | ||
| 226 | |||
| 227 | Anyone can propose: | ||
| 228 | |||
| 229 | 1. Submit proposal with rationale | ||
| 230 | 2. Community discussion (recommendation: minimum timeframe for feedback) | ||
| 231 | 3. Relevant authority reviews (Maintainers/Governing Team/Experts) | ||
| 232 | 4. Decision with documented reasoning | ||
| 233 | 5. Implementation (if approved) | ||
| 234 | |||
| 235 | === 7.3 Transparency === | ||
| 236 | |||
| 237 | * All decisions documented in public wiki | ||
| 238 | * Audit statistics published periodically | ||
| 239 | * Governing Team meeting minutes published | ||
| 240 | * Expert recommendations documented | ||
| 241 | * Community feedback acknowledged | ||
| 242 | |||
| 243 | == 8. Dispute Resolution == | ||
| 244 | |||
| 245 | === 8.1 Conflict Between Experts === | ||
| 246 | |||
| 247 | 1. Experts attempt consensus | ||
| 248 | 2. If unresolved, escalate to Governing Team | ||
| 249 | 3. Governing Team appoints neutral expert panel | ||
| 250 | 4. Panel recommendation | ||
| 251 | 5. Governing Team decision (final) | ||
| 252 | |||
| 253 | === 8.2 Conflict Between Maintainers === | ||
| 254 | |||
| 255 | 1. Discussion in maintainer forum | ||
| 256 | 2. Attempt consensus | ||
| 257 | 3. If unresolved, Lead makes decision | ||
| 258 | 4. Community informed of reasoning | ||
| 259 | |||
| 260 | === 8.3 User Appeals === | ||
| 261 | |||
| 262 | Users can appeal: | ||
| 263 | |||
| 264 | * Content rejection decisions | ||
| 265 | * Risk tier assignments | ||
| 266 | * Audit outcomes | ||
| 267 | * Moderation actions | ||
| 268 | |||
| 269 | **Process**: | ||
| 270 | |||
| 271 | 1. Submit appeal with evidence | ||
| 272 | 2. Reviewed by independent moderator/expert | ||
| 273 | 3. Decision with reasoning | ||
| 274 | 4. Final appeal to Governing Team (if warranted) | ||
| 275 | |||
| 276 | == 9. Related Pages == | ||
| 277 | |||
| 278 | * [[AKEL (AI Knowledge Extraction Layer)>>Archive.FactHarbor 2026\.01\.20.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]] | ||
| 279 | * [[Automation>>Archive.FactHarbor 2026\.01\.20.Specification.Automation.WebHome]] | ||
| 280 | * [[Requirements (Roles)>>Archive.FactHarbor 2026\.01\.20.Specification.Requirements.WebHome]] | ||
| 281 | * [[Organisational Model>>FactHarbor.Organisation.Organisational-Model]] |