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