Changes for page Governance

Last modified by Robert Schaub on 2025/12/24 20:33

From 3.2 to 3.3

From version 1.1

edited by Robert Schaub
on 2025/12/11 11:34

Change comment: Imported from XAR

To version 3.2

edited by Robert Schaub
on 2025/12/16 20:25

Change comment: Update document after refactoring.

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Parent

@@ -1,1 +1,1 @@
--FactHarbor.Organisation.WebHome
++WebHome

Content

@@ -1,247 +1,278 @@
  = Governance =
--== 1. Overview ==
++FactHarbor is governed collaboratively with clear separation between **organizational policy and decisions** and **technical implementation**.
--Governance defines oversight, neutrality, ethical principles, and organisational integrity.
--It ensures that FactHarbor operates transparently, without bias, and in line with its mission.
++== Governance Structure ==
--FactHarbor is intended as a long-term public knowledge infrastructure.
--Its governance model must ensure:
++{{include reference="Test.FactHarborV09.Organisation.Diagrams.Governance Structure.WebHome"/}}
--* integrity against manipulation
--* transparency of reasoning and code
--* longevity beyond any single founder
--* sustainability via realistic financing
--* openness without compromising trust
--* legal compliance under relevant frameworks (e.g. Swiss, EU, and US law, as applicable)
++* **Governing Team** – Sets high-level policy, organizational direction, funding priorities
++* **Lead** – Coordinates execution, represents organization publicly
++* **Core Maintainers** – Technical and specification decisions, code/spec review
++* **Domain Experts** – Subject-matter authority in specialized areas
++* **Community Contributors** – Feedback, proposals, and participation in decision-making
--Governance is responsible for:
++----
--* mission alignment and ethical oversight
--* safeguarding neutrality and independence
--* defining and supervising decision processes
--* ensuring that organisational structures remain fit for purpose as the project evolves
++== Decision-Making Levels ==
--== 2. Charter ==
++=== Technical Decisions (Maintainers) ===
--*Mission (governance focus):*
--Protect neutrality, transparency, nonprofit accountability, and ethical integrity across all FactHarbor activities.
++**Scope**: Architecture, data model, AKEL configuration, quality gates, system performance
--*Legal foundation (high-level):*
--FactHarbor’s governance is designed to operate within the constraints of:
++**Process**:
++* Proposals discussed in technical forums
++* Review by core maintainers
++* Consensus-based approval
++* Breaking changes require broader community input
++* Quality gate adjustments require rationale and audit validation
--* nonprofit law and applicable registration requirements
--* licensing obligations (open-source and open-data)
--* financial reporting and transparency duties
--* data protection and information-security regulations
++**Examples**:
++* Adding new quality gate
++* Adjusting AKEL parameters
++* Modifying audit sampling algorithms
++* Database schema changes
--Details of the concrete legal form (e.g. association, foundation, other nonprofit structures) may evolve over time.
--The core commitment is that **governance must always protect the mission and public-interest character of FactHarbor.**
++=== Policy Decisions (Governing Team + Community) ===
--== 3. Governance Structure (Current Model) ==
++**Scope**: Risk tier policies, publication rules, content guidelines, ethical boundaries
--See diagram: [[Governance Structure>>FactHarbor.Organisation.Diagrams.Governance-Structure]]
++**Process**:
++* Proposal published for community feedback
++* Discussion period (recommendation: minimum 14 days for major changes)
++* Governing Team decision with community input
++* Transparency in reasoning
++* Risk tier policy changes require Expert consultation
--=== 3.1 Governing Team ===
++**Examples**:
++* Defining Tier A domains
++* Setting audit sampling rates
++* Content moderation policies
++* Community guidelines
--The **Governing Team** provides strategic oversight and ensures:
++=== Domain-Specific Decisions (Experts) ===
--* alignment with FactHarbor’s vision and mission
--* compliance with legal and ethical obligations
--* transparency of important decisions
--* resolution of escalated issues that cannot be settled at domain level
++**Scope**: Domain quality standards, source reliability in specialized fields, Tier A content validation
--The Governing Team focuses on *mission and integrity*, not micromanagement.
++**Process**:
++* Expert consensus in domain
++* Documented reasoning
++* Review by other experts
++* Escalation to Governing Team if unresolved
++* Experts set domain-specific audit criteria
--=== 3.2 Executive Lead ===
++**Examples**:
++* Medical claim evaluation standards
++* Legal citation requirements
++* Scientific methodology thresholds
++* Tier A approval criteria by domain
--The **Executive Lead**:
++----
--* coordinates the domains (Research & Development, Organisation, PR & Care & Marketing, Operations)
--* ensures coherence and consistency across domains
--* supports escalation handling and conflict resolution
--* makes sure that governance rules are applied in practice
++== AI and Human Roles in Governance ==
--In a small organisation, the Executive Lead may also hold other roles, but responsibilities must remain clearly documented.
++=== Human-Only Governance Decisions ===
--=== 3.3 Governance Steward ===
++The following can **never** be automated:
--The **Governance Steward** safeguards:
++* **Ethical boundary setting** – What content is acceptable, what harm thresholds exist
++* **Risk tier policy** – Which domains are Tier A/B/C (though AKEL can suggest)
++* **Audit system oversight** – Quality standards, sampling strategies, auditor selection
++* **Dispute resolution** – Conflicts between experts, controversial decisions
++* **Community guidelines enforcement** – Bans, suspensions, conflict mediation
++* **Organizational direction** – Mission, vision, funding priorities
--* neutrality of processes
--* transparency of decisions
--* fairness in conflict handling
--* adherence to agreed governance rules
++=== AKEL Advisory Role ===
--(% class="box infomessage" %)
--(((
--**Note:** The Governance Steward has **no strategic voting power**. Their authority is strictly limited to enforcing process fairness and the Charter rules. They act as a referee, not a captain.
--)))
++AKEL can **assist but not decide**:
--The Governance Steward is a focal point for concerns about process, fairness, or structural bias.
++* Suggest risk tier assignments (humans validate)
++* Flag content for expert review (humans decide)
++* Identify patterns in audit failures (humans adjust policy)
++* Propose quality gate refinements (maintainers approve)
++* Detect emerging topics needing new policies (Governing Team decides)
--=== 3.4 Advisory Roles ===
++=== Transparency Requirement ===
--Advisors support decision quality without having direct decision authority:
++All governance decisions must be:
++* **Documented** with reasoning
++* **Published** for community visibility
++* **Reviewable** by community members
++* **Reversible** if evidence of error or harm
--* **Legal Advisor** – legal frameworks, contracts, licenses
--* **Ethics Advisor** – ethical questions, conflicts of interest, societal impact
--* **Scientific / Domain Advisors** – topic-specific expertise (e.g. medicine, energy, statistics)
++----
--Advisors may be consulted for specific questions; their input must be documented when it materially influences decisions.
++== Audit System Governance ==
--=== 3.5 Domain Leads ===
++=== Audit Oversight Committee ===
--Each domain (R&D, Organisation, PR & Care & Marketing, Operations) may have a **Lead** who:
++**Composition**: Maintainers, Domain Experts, and Governing Team member(s)
--* owns day-to-day decisions within that domain’s boundaries
--* escalates when decisions affect other domains or the whole organisation
--* ensures that domain actions follow the agreed governance rules
++**Responsibilities**:
++* Set quality standards for audit evaluation
++* Review audit statistics and trends
++* Adjust sampling rates based on performance
++* Approve changes to audit algorithms
++* Oversee auditor selection and rotation
++* Publish transparency reports
--== 4. Governance Model & Evolution (Future / Draft Path) ==
++**Meeting Frequency**: Recommendation: Regular meetings as needed
--This section preserves important ideas from earlier governance drafts.
--It describes a **possible long-term path** and **does not override** the current small-organisation reality.
--Details may change before they are adopted in practice.
++**Reporting**: Recommendation: Periodic transparency reports to community
--=== 4.1 Stewardship Governance (Principle) ===
++=== Audit Performance Metrics ===
--FactHarbor follows a **stewardship governance** approach:
++Tracked and published:
++* Audit pass/fail rates by tier
++* Common failure patterns
++* System improvements implemented
++* Time to resolution for audit failures
++* Auditor performance (anonymized)
--* Strategic control remains with a trusted core to prevent hijacking or capture.
--* Governance is designed to protect the mission rather than maximise profit.
--* Power is exercised as a **stewardship duty** towards the public and contributors.
++=== Feedback Loop Governance ===
--=== 4.2 Startup Phase Governance (Founder-led) ===
++**Process**:
++1. Audits identify patterns in AI errors
++2. Audit Committee reviews patterns
++3. Maintainers propose technical fixes
++4. Changes tested in sandbox
++5. Community informed of improvements
++6. Deployed with monitoring
--In the early phase, governance was designed around a **founder-led model**, where:
++**Escalation**:
++* Persistent high failure rates → Pause AI publication in affected tier/domain
++* Critical errors → Immediate system review
++* Pattern of harm → Policy revision
--* the **Founder** acts as a de-facto Sole Maintainer,
-- approving merges, managing releases, and holding final authority over technical and strategic decisions;
--* a **Core Team** may be added, with multi-party approval for security-sensitive or high-risk changes;
--* a **succession mechanism** is expected to be defined before transition, for example:
-- * Founder-appointed successor, or
-- * successor ratified by a council-like body (e.g. future Governing/Steering council).
++----
--These ideas can be reused or adapted when the concrete legal and organisational structure is defined.
++== Risk Tier Policy Governance ==
--=== 4.3 Possible Non-Profit Organisation Phase (e.g. Swiss Verein) ===
++=== Risk Tier Assignment Authority ===
--Earlier drafts envisioned a transition to a **nonprofit entity** (for example, a Swiss Verein) once FactHarbor reaches sufficient maturity and community scale.
++* **AKEL**: Suggests initial tier based on domain, keywords, content analysis
++* **Moderators**: Can override AKEL for individual content
++* **Experts**: Set tier policy for their domains
++* **Governing Team**: Approve tier policy changes, resolve tier disputes
--Key ideas from that draft:
++=== Risk Tier Review Process ===
--* **Governance bodies** might include:
-- * a **Steering Council** (central decision-making and strategic oversight),
-- * **Core Maintainers** (review and merge code / specification changes),
-- * a **Security Council** (security veto, audits, and sensitive decisions).
--* The **Founder’s role after transition** could become:
-- * permanent or long-term member of the Steering Council,
-- * strategic vision holder, while decisions follow the agreed Charter.
--* An **Asset Transfer Protocol** would be required when the nonprofit is formally created, e.g.:
-- * transferring copyrights, domains, repositories, and trademarks
-- * from the Founder (or initial holder) to the nonprofit entity
-- * in a well-documented, mission-locked way.
++**Triggers for Review**:
++* Significant audit failures in a tier
++* New emerging topics or domains
++* Community flags systematic misclassification
++* Expert domain recommendations
++* Periodic policy review
--These points are preserved here as **design material for future governance work**.
--They are not yet binding and must be confirmed, adapted, or replaced when the legal form is chosen.
++**Process**:
++1. Expert domain review (identify if Tier A/B/C appropriate)
++2. Community input period (recommendation: sufficient time for feedback)
++3. Audit Committee assessment (error patterns in current tier)
++4. Governing Team decision
++5. Implementation with monitoring period
++6. Transparency report on rationale
--== 5. Decision Processes ==
++=== Current Tier Assignments (Baseline) ===
--Decisions in FactHarbor are categorized and escalated according to specific protocols to ensure efficiency, fairness, and auditability.
++**Tier A**: Medical, legal, elections, safety/security, major financial decisions
--For the full definition of decision types, escalation paths, and documentation requirements, see:
--* [[Decision Processes>>FactHarbor.Organisation.Decision-Processes]]
++**Tier B**: Complex science causality, contested policy, historical interpretation with political implications, significant economic impact
--== 6. Compliance Framework ==
++**Tier C**: Established historical facts, simple definitions, well-documented scientific consensus, basic reference info
--The Compliance Framework ensures that FactHarbor operates with legal adherence, financial transparency, and operational security.
++**Note**: These are guidelines; edge cases require expert judgment
--For details on funding principles, ledgers, and internal controls, see:
--* [[Finance & Compliance>>FactHarbor.Organisation.Finance-Compliance]]
++----
--The Governance page provides the high-level framework.
--Details are further specified in the Organisation, Finance & Compliance, and Open Source Model & Licensing pages.
++== Quality Gate Governance ==
--== 7. Core Design Goals ==
++=== Quality Gate Modification Process ===
--FactHarbor’s governance, open source model, and financing are built around a small set of long-term goals.
--They collect ideas that are now spread across Governance, Open Source Model & Licensing, Finance & Compliance, and Legal Framework.
++**Who Can Propose**: Maintainers, Experts, Audit Committee
--* **G1 – Mission first, forever**
-- The mission – clarity, transparency, and resistance to manipulation – must not be overridden by financial, political, or popularity incentives.
-- Governance and funding decisions are evaluated against this mission, not the other way round.
++**Requirements**:
++* Rationale based on audit failures or system improvements
++* Testing in sandbox environment
++* Impact assessment (false positive/negative rates)
++* Community notification before deployment
--* **G2 – Openness & Transparency**
-- The reasoning engine, data processing, and the way AI support is used should remain inspectable and explainable.
-- The current licence mix (for code, documentation, and data) is chosen to:
-- * keep core components openly usable and auditable, and
-- * make sure that any non-open pieces are clearly marked and governed.
-- For concrete licence choices, see [[Open Source Model and Licensing>>FactHarbor.Organisation.Open Source Model and Licensing]].
++**Approval**:
++* Technical changes: Maintainer consensus
++* Policy changes (e.g., new gate criteria): Governing Team approval
--* **G3 – Controlled Core, Open Contributions**
-- Anyone may propose ideas and contributions, but FactHarbor relies on:
-- * a small, trusted **Governing Team** and maintainer group for core decisions, and
-- * clearly documented contributor roles and processes.
-- This combination should keep the core coherent and safe, while still welcoming broad participation.
-- Details: [[Roles & Bodies>>FactHarbor.Organisation.Roles-Bodies]], [[Contributor Processes>>FactHarbor.Organisation.Contributor-Processes]].
++**Examples of Governed Changes**:
++* Adjusting contradiction search scope
++* Modifying source reliability thresholds
++* Adding new bubble detection patterns
++* Changing uncertainty quantification formulas
--* **G4 – Financial Sustainability without Profit Extraction**
-- FactHarbor aims to be financially sustainable without becoming profit-driven.
-- In practice this means:
-- * revenue (donations, grants, services) is reinvested into the mission,
-- * no profit is distributed,
-- * key contributors can receive fair, market-aligned salaries when funding allows and law permits.
-- Details: [[Finance & Compliance>>FactHarbor.Organisation.Finance-Compliance]].
++----
--* **G5 – Manipulation Resistance**
-- Governance and technical rules must:
-- * prevent capture by hostile actors,
-- * protect against coordinated manipulation, and
-- * safeguard the integrity of claims, scenarios, evidence, and verdicts.
-- This affects both organisational structures (who can decide what) and technical design (audit trails, moderation tools, anomaly detection).
++== Community Participation ==
--* **G6 – Legal Clarity**
-- Open source, governance, and financing must be:
-- * legally defensible,
-- * compatible with relevant jurisdictions (e.g. Swiss, EU, US), and
-- * understandable for non-lawyers who need to work with the rules.
-- Details: [[Legal Framework>>FactHarbor.Organisation.Legal-Framework]].
++=== Open Discussion Forums ===
--These goals do not override more detailed rules on the subpages; they summarise the direction that Governance, Licensing, Finance & Compliance, and Legal Framework should remain aligned with.
++* Technical proposals (maintainer-led)
++* Policy proposals (Governing Team-led)
++* Domain-specific discussions (Expert-led)
++* Audit findings and improvements (Audit Committee-led)
--== 8. AI, Transparency and Integrity (AKEL) ==
++=== Proposal Mechanism ===
--Because FactHarbor deals with **truth-adjacent reasoning**, any use of AI must meet higher transparency and integrity requirements.
++Anyone can propose:
++1. Submit proposal with rationale
++2. Community discussion (recommendation: minimum timeframe for feedback)
++3. Relevant authority reviews (Maintainers/Governing Team/Experts)
++4. Decision with documented reasoning
++5. Implementation (if approved)
--* The **AI Knowledge Extraction Layer (AKEL)** is treated as part of the open core design.
-- Its purpose is to assist humans in extracting, organising, and updating knowledge – not to replace human judgement.
--* Where possible, AKEL should rely on **open models** or models whose behaviour can be reasonably inspected and documented.
--* When **proprietary or external AI services** are used:
-- * this must be **clearly disclosed** to users at the point of use (e.g. in UI hints or context help),
-- * the system indicates **why** this model or service is used, and
-- * the core logic (how outputs are integrated, evaluated, and stored) remains open and auditable.
--* AI outputs are treated as **proposals**, not as final verdicts.
-- Human review and governance rules decide what becomes part of the official knowledge base.
++=== Transparency ===
--Licensing details related to AKEL and the core protocol are described in
--[[Open Source Model and Licensing>>FactHarbor.Organisation.Open Source Model and Licensing]],
--and the technical design is specified in the main [[Specification>>FactHarbor.Specification]].
++* All decisions documented in public wiki
++* Audit statistics published periodically
++* Governing Team meeting minutes published
++* Expert recommendations documented
++* Community feedback acknowledged
--== 9. Evidence Openness ==
++----
--FactHarbor’s mission depends on **open evidence practices**. The core rules are:
++== Dispute Resolution ==
--* **No hidden evidence**
-- Evidence used in published reasoning should be accessible, or the limitations clearly documented (for example when data is confidential or privacy-relevant).
++=== Conflict Between Experts ===
--* **No silent corrections**
-- If a published statement is corrected, there must be a visible note or changelog entry explaining what changed and why.
++1. Experts attempt consensus
++2. If unresolved, escalate to Governing Team
++3. Governing Team appoints neutral expert panel
++4. Panel recommendation
++5. Governing Team decision (final)
--* **Versioned and traceable**
-- Evidence collections, datasets, and key reasoning artefacts should be versioned.
-- It should be possible to reconstruct “what the project believed at time X”.
++=== Conflict Between Maintainers ===
--* **Independence and conflicts of interest**
-- Potential conflicts (for example funding, affiliations, roles) should be documented so users can judge possible biases.
++1. Discussion in maintainer forum
++2. Attempt consensus
++3. If unresolved, Lead makes decision
++4. Community informed of reasoning
++=== User Appeals ===
++
++Users can appeal:
++* Content rejection decisions
++* Risk tier assignments
++* Audit outcomes
++* Moderation actions
++
++**Process**:
++1. Submit appeal with evidence
++2. Reviewed by independent moderator/expert
++3. Decision with reasoning
++4. Final appeal to Governing Team (if warranted)
++
++----
++
++== Related Pages ==
++
++* [[AKEL (AI Knowledge Extraction Layer)>>FactHarbor.Specification.AI Knowledge Extraction Layer (AKEL).WebHome]]
++* [[Automation>>FactHarbor.Specification.Automation.WebHome]]
++* [[Requirements (Roles)>>FactHarbor.Specification.Requirements.WebHome]]
++* [[Organisational Model>>FactHarbor.Organisation.Organisational-Model]]
++

Changes for page Governance

Summary

Details

Applications

Navigation

Need help?