Gov/en/Portal:Meta/Content-Versioning

💡 In simple words: In simple words: this page explains how WikiDeal saves every old version of a page, so you can always see what changed and go back if needed.

⚠️ Not yet approved. This page describes a proposal that is still under community review. It is documented here so it can be discussed, improved and endorsed.

🔒 Admin view: Core page — editable by administrators only. All translations are AI-generated from validated English source.

Content Versioning & Fork Prevention

Content Governance

Status	🔒 Core (Admin only)
Language source	English (canonical)
Translation	AI-assisted, admin-validated
Extension	FlaggedRevs
Fork policy	One contract per use case
Review	Majority endorser vote
Last revision	April 2026

Contents

Content versioning and fork prevention are priority concerns for the healthy maintenance of WikiDeal's wiki. Two key mechanisms ensure consistency across languages and jurisdictions: a multilingual translation workflow governed by admin validation and AI assistance, and a two-level contract architecture that separates generic models from jurisdiction-specific adaptations. Together, these mechanisms prevent divergence, maintain a single source of truth, and protect the legal integrity of all published content.

1. Multilingual Translation Workflow (Core Pages)

All Core wiki pages follow a strict, sequential translation workflow to ensure that no language version drifts from the canonical English source. The workflow is as follows:

1. Exclusive English editing: Core pages are edited exclusively in English. No direct modifications to translated versions are permitted. This is enforced at the access level: only administrators can edit Core pages, and translations are treated as read-only derivatives.
2. Admin validation via FlaggedRevs: Once an edit is made, an authorized administrator reviews and validates the modification using the FlaggedRevs extension. Unvalidated revisions do not propagate to translated versions.
3. AI assistant is alerted: Once a revision is flagged as validated, the WikiDeal AI assistant is alerted — either through a daily scheduled check or a real-time notification hook — that new content is ready for translation.
4. Automatic multilingual translation: The AI assistant automatically translates the validated English content into all supported languages. Translations are generated in full, not incrementally, to prevent partial or inconsistent states.
5. Publication under AI Disclaimer: All translated versions are published with the standard indicating that the content was machine-translated from the English source and has not received independent human validation in the target language.

Key principle: All language versions of Core content remain synchronized with the English source. No Core content can be modified in a non-English language directly — all changes flow from the English source. This prevents the accumulation of "translation drift" that afflicts many multilingual wikis.

2. Contract Architecture — Generic + Specific

WikiDeal contracts follow a deliberate two-level architecture designed to balance universal applicability with local adaptability.

Level 1 🏛️ Generic Contract — The Model

The Generic Contract is the foundational template that applies across all jurisdictions. It is the authoritative source from which all Specific Contracts derive.

• Contains all clauses common to every jurisdiction and use case
• Edited by admins only — no community editing permitted at this level
• When a creative clause is added that improves flexibility for both parties (e.g., a new dispute resolution mechanism), it is propagated to all Specific Contracts via AI assistance
• Acts as the single legal and conceptual source of truth
• Changes to the Generic Contract trigger automatic notification to all Specific Contract endorsers

Level 2 📍 Specific Contract — Jurisdiction-Adapted

Specific Contracts adapt the Generic Contract's clauses to the requirements of a particular jurisdiction, community, or legal context.

• A completely separate page from the Generic Contract — not a sub-page or fork
• Contains jurisdiction-specific elements: local currency, legal references, regulatory requirements, cultural norms
• Managed by the endorsers of that specific contract, not by the central admin team
• When the Generic Contract is updated, endorsers of each Specific Contract receive alerts and must act
• A majority vote of active endorsers is required to validate or reject the update
• Reminder alerts continue until validation or rejection is formally recorded

This two-level architecture allows WikiDeal to maintain a coherent global framework while respecting local legal and cultural realities — without creating an unmanageable proliferation of independent contracts.

3. Fork Prevention Strategy

WikiDeal's governance actively discourages content forks. The principle is clear: one contract per use case per jurisdiction.

⚠️ Fork warning: A "fork" in this context means the creation of a competing or parallel version of an existing contract or Core page without going through the established review process. Forks fragment the community, dilute legal clarity, and undermine the endorsement system.

• Multiple linguistic formulations may co-exist (e.g., a formal legal version and a plain-language summary) — but the legal substance must be identical across all formulations.
• The distinction between Generic and Specific contracts is the primary mechanism for preventing unnecessary forks: local needs are accommodated within the Specific Contract layer, not by creating new Generic templates.
• If a fork is proposed, it must go through an process for community evaluation. The Open Call allows the community to assess whether the proposed fork addresses a genuinely unmet need or whether the existing architecture can accommodate it.
• The Generic Contract is the single source of truth — Specific Contracts inherit from it and must not contradict its core provisions.
• Conflicts between Specific Contracts and the Generic Contract are resolved in favour of the Generic Contract unless an explicit jurisdiction-specific override has been formally approved.

4. Admin vs. Editor Rights

WikiDeal distinguishes sharply between two classes of contributors: administrators, who bear responsibility for the platform's structural and legal integrity, and registered editors, who can contribute to use-case and community content.

🔒 Admin Only	✏️ Any Registered Editor
Core pages (governance, concepts, Commissions, licensing)	Use Case pages (babysitting, separation, fundraising…)
Official Glossary	Talk / Discussion pages
Bonding Curve / Boost / Credits (fundamental mechanisms)	Open Call proposals
Template:AI Disclaimer	Jurisdiction-specific contracts
Category creation	Modifications to existing contracts (with endorser approval)
Innovations table (25 innovations)	User Group profiles
Fiscal Report / Funding Contract	Experience reports / testimonials
Core translated pages (auto-sync multilingual)	Localized marketplace content
Navigation structure	Personal user pages

This separation ensures that the platform's foundational architecture — which has legal, financial, and governance implications — cannot be modified without administrative oversight, while still enabling broad community participation in content creation and adaptation.

5. Anonymous Editing Policy

WikiDeal does not allow anonymous editing. This is a deliberate departure from the practices of general-purpose wikis such as Wikipedia, and reflects the fundamentally different context of a legally-oriented, endorsement-based platform.

The Wikimedia Foundation, which operates Wikipedia, has articulated the rationale for allowing anonymous editing:

"Anonymous editing lowers the barrier to entry and allows anyone to fix errors without creating an account." — Wikimedia Foundation (meta.wikimedia.org/wiki/Anonymous_users) However, WikiDeal's context differs from an encyclopedia in three critical ways:

• Contracts have legal weight → accountability is essential. A clause in a babysitting contract or a financial instrument has real-world legal consequences; anonymous authorship creates unacceptable ambiguity.
• Endorsement requires identity → anonymous endorsement is meaningless. The endorsement system — the mechanism by which WikiDeal contracts gain legitimacy — depends entirely on knowing who endorses a given version.
• Quality comes from verified expertise, not volume of contributions → unlike an encyclopedia where errors are corrected through mass participation, WikiDeal's contract quality depends on specific expertise (legal, financial, sector-specific) that must be traceable to identifiable contributors.

Additionally, the reputation tracking system — which assigns credibility scores based on endorsement history, contribution quality, and community feedback — requires persistent identity to function. Anonymous contributions cannot be tracked, rewarded, or penalized.

6. Exception: Whistleblower Observatory

🛡️ Whistleblower Exception: A dedicated observatory for freedom of expression and whistleblowers will include protected anonymous submission forms. This is a separate mechanism from wiki editing and follows specific data protection protocols, including technical anonymization measures and legal review of submissions before publication.

The Whistleblower Observatory is designed to protect individuals who need to report issues of public interest — including potential legal violations, governance failures, or safety concerns — without exposing themselves to retaliation. It operates under a distinct policy framework and is explicitly not subject to the general "no anonymous editing" rule that governs the rest of the wiki.

Submissions to the Whistleblower Observatory are reviewed by designated administrators before publication and are never directly merged into the main wiki content without editorial transformation.

See also: FlaggedRevs Extension Wikimedia: Anonymous Users Policy

📢 Open Call — Improve This Page

This governance page was drafted by the WikiDeal team and formalized with AI assistance. It is open to community review. If you believe the content versioning or fork prevention mechanisms described here could be improved, you are invited to submit a proposal via Open Call.

Proposals are evaluated by the community and, if accepted by majority vote, can lead to modifications of this Core page (via admin implementation).