Changes for page Governance

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

From 3.2 to 3.1

From version 3.1

edited by Robert Schaub
on 2025/12/15 16:56

Change comment: Imported from XAR

To version 1.1

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

Change comment: Imported from XAR

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -1,278 +1,247 @@
  = Governance =
--FactHarbor is governed collaboratively with clear separation between **organizational policy and decisions** and **technical implementation**.
++== 1. Overview ==
--== Governance Structure ==
++Governance defines oversight, neutrality, ethical principles, and organisational integrity.
++It ensures that FactHarbor operates transparently, without bias, and in line with its mission.
--{{include reference="Test.FactHarborV09.Organisation.Diagrams.Governance Structure.WebHome"/}}
++FactHarbor is intended as a long-term public knowledge infrastructure.
++Its governance model must ensure:
--* **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
++* 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)
------
++Governance is responsible for:
--== Decision-Making Levels ==
++* 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
--=== Technical Decisions (Maintainers) ===
++== 2. Charter ==
--**Scope**: Architecture, data model, AKEL configuration, quality gates, system performance
++*Mission (governance focus):*
++Protect neutrality, transparency, nonprofit accountability, and ethical integrity across all FactHarbor activities.
--**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
++*Legal foundation (high-level):*
++FactHarbor’s governance is designed to operate within the constraints of:
--**Examples**:
--* Adding new quality gate
--* Adjusting AKEL parameters
--* Modifying audit sampling algorithms
--* Database schema changes
++* nonprofit law and applicable registration requirements
++* licensing obligations (open-source and open-data)
++* financial reporting and transparency duties
++* data protection and information-security regulations
--=== Policy Decisions (Governing Team + Community) ===
++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.**
--**Scope**: Risk tier policies, publication rules, content guidelines, ethical boundaries
++== 3. Governance Structure (Current Model) ==
--**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
++See diagram: [[Governance Structure>>FactHarbor.Organisation.Diagrams.Governance-Structure]]
--**Examples**:
--* Defining Tier A domains
--* Setting audit sampling rates
--* Content moderation policies
--* Community guidelines
++=== 3.1 Governing Team ===
--=== Domain-Specific Decisions (Experts) ===
++The **Governing Team** provides strategic oversight and ensures:
--**Scope**: Domain quality standards, source reliability in specialized fields, Tier A content validation
++* 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
--**Process**:
--* Expert consensus in domain
--* Documented reasoning
--* Review by other experts
--* Escalation to Governing Team if unresolved
--* Experts set domain-specific audit criteria
++The Governing Team focuses on *mission and integrity*, not micromanagement.
--**Examples**:
--* Medical claim evaluation standards
--* Legal citation requirements
--* Scientific methodology thresholds
--* Tier A approval criteria by domain
++=== 3.2 Executive Lead ===
------
++The **Executive Lead**:
--== AI and Human Roles in Governance ==
++* 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
--=== Human-Only Governance Decisions ===
++In a small organisation, the Executive Lead may also hold other roles, but responsibilities must remain clearly documented.
--The following can **never** be automated:
++=== 3.3 Governance Steward ===
--* **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
++The **Governance Steward** safeguards:
--=== AKEL Advisory Role ===
++* neutrality of processes
++* transparency of decisions
++* fairness in conflict handling
++* adherence to agreed governance rules
--AKEL can **assist but not decide**:
++(% 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.
++)))
--* 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)
++The Governance Steward is a focal point for concerns about process, fairness, or structural bias.
--=== Transparency Requirement ===
++=== 3.4 Advisory Roles ===
--All governance decisions must be:
--* **Documented** with reasoning
--* **Published** for community visibility
--* **Reviewable** by community members
--* **Reversible** if evidence of error or harm
++Advisors support decision quality without having direct decision authority:
------
++* **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)
--== Audit System Governance ==
++Advisors may be consulted for specific questions; their input must be documented when it materially influences decisions.
--=== Audit Oversight Committee ===
++=== 3.5 Domain Leads ===
--**Composition**: Maintainers, Domain Experts, and Governing Team member(s)
++Each domain (R&D, Organisation, PR & Care & Marketing, Operations) may have a **Lead** who:
--**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
++* 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
--**Meeting Frequency**: Recommendation: Regular meetings as needed
++== 4. Governance Model & Evolution (Future / Draft Path) ==
--**Reporting**: Recommendation: Periodic transparency reports to community
++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.
--=== Audit Performance Metrics ===
++=== 4.1 Stewardship Governance (Principle) ===
--Tracked and published:
--* Audit pass/fail rates by tier
--* Common failure patterns
--* System improvements implemented
--* Time to resolution for audit failures
--* Auditor performance (anonymized)
++FactHarbor follows a **stewardship governance** approach:
--=== Feedback Loop Governance ===
++* 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.
--**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
++=== 4.2 Startup Phase Governance (Founder-led) ===
--**Escalation**:
--* Persistent high failure rates → Pause AI publication in affected tier/domain
--* Critical errors → Immediate system review
--* Pattern of harm → Policy revision
++In the early phase, governance was designed around a **founder-led model**, where:
------
++* 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).
--== Risk Tier Policy Governance ==
++These ideas can be reused or adapted when the concrete legal and organisational structure is defined.
--=== Risk Tier Assignment Authority ===
++=== 4.3 Possible Non-Profit Organisation Phase (e.g. Swiss Verein) ===
--* **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
++Earlier drafts envisioned a transition to a **nonprofit entity** (for example, a Swiss Verein) once FactHarbor reaches sufficient maturity and community scale.
--=== Risk Tier Review Process ===
++Key ideas from that draft:
--**Triggers for Review**:
--* Significant audit failures in a tier
--* New emerging topics or domains
--* Community flags systematic misclassification
--* Expert domain recommendations
--* Periodic policy review
++* **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.
--**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
++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.
--=== Current Tier Assignments (Baseline) ===
++== 5. Decision Processes ==
--**Tier A**: Medical, legal, elections, safety/security, major financial decisions
++Decisions in FactHarbor are categorized and escalated according to specific protocols to ensure efficiency, fairness, and auditability.
--**Tier B**: Complex science causality, contested policy, historical interpretation with political implications, significant economic impact
++For the full definition of decision types, escalation paths, and documentation requirements, see:
++* [[Decision Processes>>FactHarbor.Organisation.Decision-Processes]]
--**Tier C**: Established historical facts, simple definitions, well-documented scientific consensus, basic reference info
++== 6. Compliance Framework ==
--**Note**: These are guidelines; edge cases require expert judgment
++The Compliance Framework ensures that FactHarbor operates with legal adherence, financial transparency, and operational security.
------
++For details on funding principles, ledgers, and internal controls, see:
++* [[Finance & Compliance>>FactHarbor.Organisation.Finance-Compliance]]
--== Quality Gate Governance ==
++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 Modification Process ===
++== 7. Core Design Goals ==
--**Who Can Propose**: Maintainers, Experts, Audit Committee
++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.
--**Requirements**:
--* Rationale based on audit failures or system improvements
--* Testing in sandbox environment
--* Impact assessment (false positive/negative rates)
--* Community notification before deployment
++* **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.
--**Approval**:
--* Technical changes: Maintainer consensus
--* Policy changes (e.g., new gate criteria): Governing Team approval
++* **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]].
--**Examples of Governed Changes**:
--* Adjusting contradiction search scope
--* Modifying source reliability thresholds
--* Adding new bubble detection patterns
--* Changing uncertainty quantification formulas
++* **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]].
------
++* **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]].
--== Community Participation ==
++* **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).
--=== Open Discussion Forums ===
++* **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]].
--* Technical proposals (maintainer-led)
--* Policy proposals (Governing Team-led)
--* Domain-specific discussions (Expert-led)
--* Audit findings and improvements (Audit Committee-led)
++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.
--=== Proposal Mechanism ===
++== 8. AI, Transparency and Integrity (AKEL) ==
--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)
++Because FactHarbor deals with **truth-adjacent reasoning**, any use of AI must meet higher transparency and integrity requirements.
--=== Transparency ===
++* 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.
--* All decisions documented in public wiki
--* Audit statistics published periodically
--* Governing Team meeting minutes published
--* Expert recommendations documented
--* Community feedback acknowledged
++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]].
------
++== 9. Evidence Openness ==
--== Dispute Resolution ==
++FactHarbor’s mission depends on **open evidence practices**. The core rules are:
--=== Conflict Between Experts ===
++* **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).
--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)
++* **No silent corrections**
++ If a published statement is corrected, there must be a visible note or changelog entry explaining what changed and why.
--=== Conflict Between Maintainers ===
++* **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”.
--1. Discussion in maintainer forum
--2. Attempt consensus
--3. If unresolved, Lead makes decision
--4. Community informed of reasoning
++* **Independence and conflicts of interest**
++ Potential conflicts (for example funding, affiliations, roles) should be documented so users can judge possible biases.
--=== 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?