3. The Pensieve Mechanism and Penseive Knowledge Base Design
The Pensieve Mechanism fundamentally operates as a social technology, realising collaborative editing and collective ownership through distributed, peer-to-peer protocols. These protocols are underpinned by a contribution-based consensus mechanism, focusing not on the specifics of the technology that facilitates decentralisation in storage and communication, but rather on a consensus mechanism that eliminates the need for central management of the knowledge base.
The distributed and peer-to-peer solutions employed may evolve over time. Provided these infrastructural choices maintain legitimacy and align with the principles discussed, they serve merely as tools to achieve the desired outcomes.
3.1 Technological Infrastructure and Components
This paper concentrates on introducing the consensus mechanism that characterises a Pensieve knowledge base. It is not intended as a comprehensive guide for constructing such a knowledge base using specific tools. Therefore, this section merely provides an overview of the various components required when implementing a Pensieve knowledge base:
Decentralised Storage and Blockchain-enabled Immutable and Transparent Records:
Data Integrity. Blockchain's design ensures that once data has been added to the ledger, it cannot be changed, making it a reliable source of information. Data is stored across a distributed network of nodes to enhance data redundancy and reduce risks of data loss.
Security. This record immutability is crucial for trust and security, distinguishing it from other types of knowledge bases where data can be more easily modified and lost without disclosure.
Traceability. This also ensures that contributors have a clear history of edits and that the information is tamper-resistant.
Decentralised Identity and Reputation:
Identity Verification: Mechanisms that allow users to control their identity and personal data securely without relying on centralised operators.
Access Control: Uses blockchain to manage permissions for who can access and contribute to the knowledge base.
Immutable Reputation: reputations can be recorded in blockchain in a manner that is nearly impossible to alter or falsify, providing a permanent and verifiable record of interactions or transactions.
Transparent Decentralised Consensus:
Consensus: Blockchains use various consensus mechanisms to agree on the validity of transactions. They ensure that all participants in the network agree on the current state of the ledger, without needing a central authority.
Tokenisation: Blockchain enables the use of tokens, which can serve multiple purposes such as incentivising contributions, facilitating transactions, or representing ownership and rights within the system. This can encourage a more active and engaged community by rewarding participants for their contributions with tangible benefits
Automated Enforcement: Contracts that automatically execute, control, or document legally relevant events according to the terms of a contract or an agreement encoded within them.
Knowledge embedded.Smart contracts themselves are a form of knowledge or logic embedded within the blockchain and are instrumental to the execution of collaborative editing protocols and Pensieve Consensus.
Community Governance:
Collective decision-making: Involves the community in decision-making processes through mechanisms such as decentralised autonomous organisations (DAOs) or voting systems to manage updates, changes, and rules within the knowledge base.
Collective ownership: Leverages multi-signature mechanisms or DAOs to collectively manage assets and accesses.
Security Protocols:
Cryptography: Utilises cryptographic methods to secure transactions and protect data.
Privacy Enhancements: Cryptographic technologies, such as zero-knowledge proofs (ZKPs), ensure data and user privacy while allowing for verification and proof in discourse.
3.2 Data Structure
The Pensieve knowledge base employs a structured and layered approach to data organisation, limited to just “Pages” and “Items.” This design ensures the knowledge base remains organised and technologically scalable, promoting a uniform approach to content management. This facilitates easier content appending and maintenance. Additionally, it enhances communication by providing context and fostering community consensus on relevance, making it easier for users to browse and understand the information.
Basic Units (Data Entry/Knowledge): “Item” as a Basic Unit.
In this structured framework, each Item is predefined to ensure consistency and standardisation across the knowledge base. Items are the individual units of knowledge within the Pensieve framework.
Each Item represents a piece of information or a data entry that relates to the broader topic defined by its Page. Items are the fundamental building blocks of the knowledge base, akin to paragraphs or bullet points in a document.
Each Item has “Item Title”, “Item description” that explains the Item and its purpose, and its required fields and types of data, “technical validation rules” among other data requirements.
Nested Units (Context/Topic):The knowledge base should be organised with a pre-determined range of topics and a set of Items that support each topic, forming the framework of a “Page".
Each Page serves as a context or topic under which related data entries (Items) are organised. A Page organises multiple Items under a unified topic, allowing users to digest a full spectrum of related knowledge efficiently.This hierarchical structure ensures that all data is contextualised, making the knowledge base more navigable and meaningful. Pages can be thought of as chapters or sections within a larger document, each dedicated to a specific subject or theme. In a Pensieve knowledge base, every topic shares the same requirements for information.
For each Page, the same set of Items is required, and contributions can be made to these Items. This uniform structure across topics helps maintain consistency and comprehensiveness in the knowledge base. The design of Pages can vary, adapting to the most effective format for displaying interconnected Items, whether that be in textual, graphical, or tabulated forms.
Weight (Importance of Item): In addition to the property constraints required that is expected in a regular database, each Item in a Page is initially assigned its default weight according to the purpose and significance of the Item, termed “ItemWeight”, which quantifies its relative importance within framework of the Items within a Page in the knowledge base.
The importance of an Item, or its ItemWeight, is then dynamically influenced by community interactions such as stakes or credits that validate its truthfulness or relevance.
This evolving ItemWeight acts as a measure of consensus and credibility, ensuring that significant information is given prominence and protected against casual or malicious edits: The more stakes or credits involved in the discussion and voting, the more it leads to an increased ItemWeight, the more stakes and consensus it requires for users to prove for the next update.
3.3 Pensieve Consensus: Dynamic On-Going Governance over Data
3.3.1 Genesis Creation
Item Submission (Submission). Content submission involves adding data to the Items required by a Page in a knowledge base.
Note of Reference. The submission can optionally be accompanied by a note that includes a reference link or a comment that supports the claim of the submission. The note is so that submissions are considered together with evidence and opinions provided by the initial supporters, laying foundations for open discourse and collaboration on the Item.
Essential Items Set. To begin creating a new Page within the knowledge base, a specific subset of data entries, termed the Essential Items Set, is mandatory to be filled out first. This set, selected from a comprehensive list of Items predetermined for Page, defines the minimum data needed for the community to assess and approve a new Page proposal. This requirement ensures that when a Page is eventually published in the database, all submitted content meets a basic standard of completeness and relevance. It also allows the Page to be publicly accessible before all content defined by the Page’s Item scope is fully completed.
Genesis Verification. This process involves community verification to ensure that every new Item in the Essential Item Set’s content is not only believed to be true and accurate but also valuable. All Items of a Page, including the Essential Item Set must meet a set threshold of support from community, indicated by the vote count of other contributors’ Contribution Points. (Detailed vote count method is explained in the following section.)
GenesisQuorum. The specific threshold—how many stakes (i.e credits, Contribution Points in the ECF Platform) must support a submission for it to pass verification and be published—is set into the GenesisQuorum. It is set to start at least the same amount of ItemWeight, which will call for same amount of Contribution Points from community need to match the importance before it can be logged into database. This is a value that can be governed by community and it controls the difficulty of new content generation.
GenesisQuorum's parameters can also be added as needed. Before a Page is officially created, the first Page Proposal that meets the threshold with all Essential Items is published as the Page's Genesis Version. Subsequently, for any additional Items awaiting data contributions, the first submission that surpasses the GenesisQuorum threshold is recognised and published as the genesis version for that Item.
During the Genesis Verification of a pending Page, other contributors have the opportunity to compete by submitting alternative versions of the project Page. These versions are subjected to community verification alongside any previously submitted drafts. The first submission that meets the GenesisQuorum threshold is established as the genesis version of the project Page, and its creator is awarded the GenesisReward. This process ensures that the most thoroughly vetted and community-approved content is selected. Once a Page is published, all other Items for the Page follow the same method of Genesis Verification to get published into the Page.
Contribution Points. It is a form of reward allocated to contributors who successfully complete the initial publication of an Item or a Page in the knowledge base. When a contributor completes a genesis submission, they receive Contribution Points through a process known as the Genesis Reward.
GenesisReward. Each Item on a project Page comes with an inherent ItemWeight, which are pre-determined properties of an Item, and it equals to the same amount that is given as the Genesis Reward to users once the Items have passed the Genesis Verification’s threshold and are published. The ItemWeight should be determined by the importance and difficulty of obtaining the information, equaling the initial ItemWeight. This reward system incentivises the contribution of valuable and challenging information.
The ZeroToOne Reward is designed to balance the need for rapid content creation with the goal of maintaining high-quality contributions by ensuring fair and inclusive participation.
It constitutes a variable portion of the Genesis Reward, ranging from zero to the full amount of the Genesis Reward. Users earn a ZeroToOne Reward when they propose an Item that has not yet received any submissions. Subsequently, the remainder of the Genesis Reward (the difference between the Genesis Reward and the ZeroToOne Reward) is awarded to the user who successfully completes the genesis verification and publishes the Item
The ZeroToOne Reward adjusts the incentive level for content creation. By offering a significant portion of the total Genesis Reward for proposing new Items, it can expedite the production of content. However, while this reward structure encourages rapid content creation, it also highlights the need for maintaining content quality. Increased incentives may lead to hastily made contributions, potentially compromising the quality of the knowledge base.
Furthermore, the ZeroToOne Reward ensures an equitable platform for all contributors, irrespective of their pre-existing governance rights within the knowledge base. This reward mechanism promotes inclusivity and broad participation by distributing Contribution Points without requiring prior verified knowledge of the contributors. By distributing Contribution Points without requiring prior verified knowledge of the contributors, the ZeroToOne Reward allows the Pensieve knowledge base to operate on a principle of zero knowledge about users from day one, promoting inclusivity and broad participation.
ItemWeight. All Items on a Page to be filled out by community users are pre-set with an ItemWeight according to the importance of the Item with transparent rules that are subject to community governance. ItemWeight represents the significance of an Item within the community, influenced by the volume of stakes and credits supporting the Item's veracity. As the community validates an Item through support, its ItemWeight increases, setting a higher threshold for future changes. This process ensures that only submissions with substantial community endorsement can modify existing Items, thus maintaining data integrity. (The mechanism is detailed in the following section.)
The principles behind the design are the following:
Incentivised Desirable Contribution:
Bounty Incentive. The same number of amount of Contribution Points is given to acknowledge the users’ contribution in providing information and contribute to the community’s knowledge base.
Depending on adoption strategy, the platform could also adopt “Demand-based Pricing”, where less Contribution Points will be given to the same Items in later stage for example, in that the bounty amount decreases as the adoption of platform increases.
Gauge of Importance.
Starting Differently. Some Items can always have a higher starting ItemWeight either due to their intrinsic value perceived higher than other items or the difficulty to acquire the knowledge making it more valuable, or simply because they are the most defining and sensitive information for a topic and thus require more attention before its publication. ItemWeight of Item is designed to reflect its importance in relevance to all other Items in a Page.
Dynamic Update. The ItemWeight is dynamically reflected by the credibility of the users engaged in discussion and modifications. As will be explained in Section 3.3.2, ItemWeight increases when events such as support and CDR occur, indicating the attention and importance given to the perceived valuable information. With the ongoing process of verification and community governance over time, the higher the ItemWeight, the more important the information is.
Barrier against spamming. The higher the percentage of the stakes against whole circulation are supporting an item, the more the Item is considered close to correctness and referential. At any point, a user needs to have or gather the same amount of the credits or stakes in order to modify an Item’s content by submitting an update, so for instance, when an Item has received gained credits through users’ voting after and ItemWeigh to which has gone very high, it becomes harder for users to update the current version without a bigger support from community or a high credibility earned themselves.
Item and Page Creation Summary. Upon fulfilling the Essential Items Set, a user initiates the publication of a new pending Page and receives the ZeroToOne Reward from all the Items in the Essential Items Set. This completed Page is then placed in a queue for launch, where it awaits further verification by other users or faces competition from alternate proposals for the Essential Items Set.
Community endorsement and verification enable the Page to be listed in the official index, a process termed "Publishing Page." Subsequently, any remaining GenesisReward from all successfully published Items is awarded to the creator of the published Page. Concurrently, competing submissions for the Items are queued for ongoing competition, ensuring a continuous refinement and enhancement of content detailed in the next section. All other Items of the Page follows the same steps to be published after the successful publication of a Page.
3.3.2 Update an Item: Regular On-Going Dynamic Governance
The Pensieve knowledge base dynamically mirrors the collective intellect of its contributors. Each submission for any Item is in the ongoing competition with other submissions supported and users in the community. The content that garners the most support is displayed prominently, reflecting the prevailing consensus at any given time.
Submission to a published Item. Published Items on the Page are subject to updates due to factors of invalidity or obsolescence. Users can select any Item that requires updating or correction, check if there are already submitted updates in the queue to support, or initiate a new submission themselves. This process ensures that the content remains accurate and current. Submissions are continually in competition to become the top as sources of truth, reflecting the evolving collective understanding. As a result, they remain in continuous circulation, constantly open to new support and revisions.
Update Trigger. An Item is updated immediately when the submitted entry is done by a user whose Contribution Points is more than the ItemWeight of the Item the user intends to update, or if the submission has gained support of enough Contribution Points from other users. This process is a dynamic on-going governance over content displayed by the platform, which means at any given point, an entry in the queue or an entry that is newly submitted can gain supporting votes that surmount the current version’s ItemWeight, and become displayed. In the meantime, the value ItemWeight of the updated Item is replaced by the sum of the current supporters’ platformWeight.
Supporting an Item. When users support an Item, they technically execute this action by allocating their Contribution Points as votes to endorse a particular version of the Item for display. This support can be aimed at promoting a new version to replace the existing one or defending the current version against replacement. It is important to note that the count of supporting votes is based on the value of the Contribution Points at the time the support action is taken. The vote count does not increase automatically if the supporting users accrue more points or knowledge later. For any Item on a project Page, users can only support one submission at a time. Once support is given, the Contribution Points are counted towards the supported version until the user decides to either support a different submission or withdraw their support entirely.
Vote Count. During the genesis verification process, users endorse their own submissions by allocating their Contribution Points as supporting votes. As the community engages to validate these submissions, they cast votes using their own Contribution Points, effectively transferring these credits to the submission they support as votes. The submission that passes the GenesisQuorum first with highest accumulatedContribution Points will be the Item that sets the data of the Item for the first Tim, then set the new ItemWeight for the Item with the sum of Contributions Points involved. The updated ItemWeight will then become the requirements of the next update’s supporting vote count. It is important to note that once established, ItemWeight can only increase, even if the submission that originally elevated the ItemWeight will lose support later. This ensures that the Item's status of prominence is preserved despite fluctuations in community backing.
Item Update Process Summary. An Item is updated immediately when a submission is made by a user whose Contribution Points exceed the ItemWeight of the Item they intend to update, or when the submission secures sufficient PlatformWeight support from other users. This dynamic governance mechanism ensures that content displayed by the platform is continuously overseen. Whenever an entry in the queue or a new submission gathers enough support to surpass the current version’s ItemWeight, it will be displayed. Concurrently, the ItemWeight of the updated Item is recalculated to reflect the sum of the current supporters’ platformWeight, thereby ensuring the most supported and validated content is always visible.
ItemWeight Summary.
To calculate ItemWeight, these components are considered:
Genesis Reward: This is a fixed value given to an Item initially.
Voters’ Contribution Points: These are the points accumulated from individual voters supporting a version of an Item.
Dynamic Updates: The ItemWeight will increase as more votes contribute, but it can be replaced if another version receives more Contribution Points.
Dynamic ItemWeight Calculation. There is also a dynamic aspect where ItemWeight can be replaced if another version of the Item receives more voter Contribution Points. This means that there needs to be a check against other versions:
# Initial parameters
genesis_reward = G # Fixed value given to an Item initially
initial_value = genesis_reward # Initial value set at genesis reward
contribution_points = [C1, C2, ..., Cn] # Contribution points from individual voters
total_voters = n # Total number of voters
current_item_weight = initial_value # Current weight of the Item
threshold = genesis_reward # Initial threshold value
# Function to calculate the dynamic ItemWeight
def calculate_item_weight(contribution_points, initial_value, threshold):
total_contribution = sum(contribution_points)
if total_contribution > threshold:
return total_contribution
else:
return initial_value
# Update current item weight based on contribution points
current_item_weight = calculate_item_weight(contribution_points, initial_value, threshold)
# Function to compare and update ItemWeight against another version
def compare_and_update_weight(current_weight, new_contribution_points, threshold):
new_total_contribution = sum(new_contribution_points)
if new_total_contribution > threshold:
return new_total_contribution
else:
return current_weight
# Example usage
other_version_contribution_points = [C1_other, C2_other, ..., Cm_other]
new_item_weight = compare_and_update_weight(current_item_weight, other_version_contribution_points, threshold)
# Output the results
print(f"Current Item Weight: {current_item_weight}")
print(f"New Item Weight: {new_item_weight}")3.3.3 Community Dispute Resolution (CDR)
In the section on the ongoing dynamic governance module of the Pensieve Mechanism, the knowledge base can be said to have achieved its intended functions and goals. However, as the scale of the knowledge base expands, we predict that the need for faster resolution and increased contribution would become apparent. To address this, introducing a new dimension —economic incentives to the system is essential. These incentives will play a crucial role in the dispute resolution mechanism, enhancing engagement and efficiency by rewarding active and effective participation within the knowledge base.
Overview. The Community Dispute Resolution (CDR) mechanism is designed to balance the influence of long-standing users with new, highly motivated participants, ensuring that fresh perspectives can update or contest existing content. This mechanism is vital for resolving disputes when standard editing and updates lead to continuous content revisions, which can burden the platform and confuse users. It allows for the commitment of greater material stakes, signalling strong conviction in a submission and encouraging broader community participation to establish a consensus on controversial submissions. The mechanism of CDR sets higher threshold for opposing submissions in the future.
The CDR process is designed based on mechanisms such as in Reality.eth, where participants bet on the success of an Item's version within a specified time. Unlike Reality.eth, where the question proposer is external, the CDR here is community-driven, guided by predefined questions relevant to the database’s context and objectives.
CDR allows a faster intervention, and empowers users who just begin on the platform, but are strongly motivated to modify a version and to gain support for changing information perceived important. CDR ensures a path when discourse and on-going governance rules cannot reconcile disputes.
1. Triggering Community Dispute Resolution
Initiation. To trigger CDR, a user selects an Item for resolution, stakes an amount equal to the CDRTicket, and submits a version of the Item to the queue. This is typically done by users who lack sufficient Contribution Points to amend an Item directly, though it can also serve strategic purposes such as setting the current winning version of the Item with a higher threshold against future modifications.
PlatformStake. The stakes that is admissible in the mechanism should in theory be stakes related to the success of the knowledge base according to the community’s goals. While CDR's methodology allows any blockchain assets that can be executed by smart contracts for redistribution, it is recommended to introduce a unit that represents both financial rights and partial governance rights. This approach aligns personal financial interests with the integrity of the collective knowledge base, which is essential for the verification of knowledge.
CDRTicket. This is the cost to file a dispute, calculated as a percentage of the current ItemWeight. If the initiating stake by user falls short of the CDRTicket, the user can seek additional support from the community to reach the necessary amount (such as crowdfunding for CDRTicket). Supporters then share in the potential gains or losses from the CDR outcome.
Process Abortion. If a CDR initiator withdraws their stake, the CDR process is aborted, and all staked amounts are returned to the participants.
2. Community Dispute Resolution Process
Initiation. The CDR process begins once the required CDRTicket amount is pooled. The Item is then prioritised in the community CDR queue for review and discussion, pausing regular governance updates of the Item in dispute until the CDR is resolved.
CDRPeriod. The duration of be a fixed period or vary proportionally to the ItemWeight (based on the Item’s significance and controversy level).
CDR Vote Count. Votes are calculated by multiplying users' Contribution Points by their PlatformStake. This dual consideration evaluates a user’s history and engagement on the platform (Contribution Points) and their commitment to resolving current disputes for the benefits of the knowledge base (PlatformStake), ensuring that those with a vested interest and relevant experience influence the outcome.
PlatformWeight is a user’s Contribution Points times the user’s PlatformStakes that the user placed into the CDR process for backing a version.
CDR Validity Threshold. For a resolution process to be valid, the sum of the Contribution Points put behind all versions in competition during the CDRPeriod must reach a minimum participation threshold— set at twice the ItemWeight. If this threshold is not met by the end of the CDRPeriod, the process is deemed unsuccessful, and all stakes are refunded.
2.1 Duel CDR
Duel CDR is the contest between the version proposed by the user who initiated the CDR and the current displayed version. Voting options include the Challenger (CDR initiator)’s submission, the current winning version before CDR starts, and "Neither works." Participants must stake a chosen amount to support a version, ensuring that only the most supported version is displayed.
Majority Win Outcome. If either version secures 50% of the votes:
Content Governance: The Item is updated to the version that received the majority of votes.
Stake Redistribution: CDRStake Division. Users who supported the winning version receive the stakes from the supporters of the losing version: if the challenger's version wins, a ChallengerShare (initially set at 20%) of the sum of opposing stakes is distributed among those who contributed to the CDRTicket, with the remaining stakes divided among all supporters of the winning version. Conversely, if the defender's version wins, the stakes from the Challenger's side are distributed proportionately among the defenders. (Stakes placed on the "neither works" option are not involved in the distribution.)
CDRTicket: returned proportionately to its contributors. Depending on the tech stack of choice, CDRTicket may evolve to include covering technical costs associated with the CDR process (such as fees for smart contract setup).
ItemWeight: updated to reflect the sum of the Contribution Points of all users that supported the version.
Regular Governance resumes: the lost submission is queued as one contending submission when the CDR process concludes, inheriting all Contribution Points behind it during the CDR Process.
“Neither Works” Outcome. If over 50% of votes favour the "neither works" option, indicating strong community rejection of both available versions:
Content governance: the Item's information needs to be re-established through the Genesis Submission and This includes undergoing the genesis verification process with an updated ItemWeight and associated rewards.
Stake Redistribution: No settlement of stakes needs to happen. All stakes are given back to participants.
CDRTicket: placed as GenesisReward for the Item that needs to go through Genesis Verification again to have content published.
ItemWeight: updated to the value of the sum of the Contribution Points of all users that supported “Neither works” option. This adjustment requires the new and existing submissions to gather more support than previous ensuring it achieves even broader community backing to pass the verification process.
Minority Win Outcome. If no version achieves a majority (50%) of the votes (PlatformWeight) within the CDRPeriod:
The CDR process defaults back to the rules of “Regular Ongoing Governance” (section 3.3.2). This means the platform will endorse the option that secures the most Contribution Points, including those from previous supporters who did not participate in the CDR.
If the "neither works" option should receive more support than the other two competing versions, and the sum of Contribution Points backing this option exceeds the current ItemWeight, then Item clearance and reward allocation happens, the CDR settlement follows the situation of “Neither Works” Outcome above.
2.2 Melee CDR
After the CDR process is initiated by placing a CDRTicket, the vote collection phase is open to new submissions of Item to join the CDR process. This strategy capitalises on the heightened community attention, interest and incentive to evaluate competing versions, allowing for comprehensive resolution of disputes by considering all relevant submissions simultaneously. For a version to join the on-going CDR, new CDRTickets need to be placed. The voting options are expanded to include these new submissions once backed by CDRTickets, resetting the CDRPeriod for including new entries.
In scenarios where there are more than two contended versions, including the "None works" option, all submitted versions are put to a vote. The following settlement applys:
Majority Win Outcome. If any submission garners over 50% support:
Content Governance: Winning version becomes the final version post-CDR.
Stake Redistribution: Supporters of the winning submission then divide the stakes from all other versions according to the CDRStake Division mechanism (excluding stakes behind “none works”).
If "None works" receives a majority vote, leading to the Item being reset. The GenesisReward for the next version is then funded by all the CDRTickets. The Item's ItemWeight is recalculated to reflect the total Contribution Points of all participants.
Minority Win. If no submission achieves over 50% support by the end of the CDRPeriod,
Top two supported options, including "none works," proceed to a second voting round with the rules of Dual CDR, the two-submission CDR process. During this period.
No new submissions can enter a CDRTicket.
At the start of this second round, stakes from eliminated versions default to "neither works." Participants can switch their support to any remaining option or opt out by withdrawing their stakes. The resolution and stake redistribution rules from the Duel CDR apply, as also is the ItemWeight updated based on the Contribution Points from this final round of voting.
Note. ItemWeight’s update follows the principles of considering supportes’ Contribution Points and community attention intensity. Thus the CDR Process described above can also adoption 2 other calculation methods that either enlarges the gap further between the winning version at the end of the CDR process and competing versions, rewarding winner’s version with higher threshold or adopting Regular On-going Governance’s method without accelerating the discrepancy:
To increase the disparity between winning version and previous version, by adding the newly gained support (all historical participants’ ItemWeight) to the current ItemWeight of the Item, as opposed to merely replacing the value of ItemWeight with the leading and displaying version’s supporters’ ItemWeight.
To discourage CDR created ItemWeight advantage for the winning version, the ItemWeight update can just follow Regular On-going Governance by adopting the winning version’s supporters’ Contribution Points.
The Algorithm may evolve to either include other values that indicate legitimacy such as holding time of the two values, or add threshold to which users get to participate.
These calculations can be either tested and chosen to implement by community governance or provided as different types of CDR for CDR initiator to evaluate the outcome themselves.
3.4 Decentralised Governance over the Knowledge Base
Managing and structuring information within a knowledge base or educational framework involves several key activities. Pensieve knowledge base’s framework primarily deals with:
Validation and verification (ensuring the accuracy and authenticity of the information);
Access Control (defining permissions for who can edit, or contribute to the knowledge base);
Preservation and Archival (Implementing strategies for long-term preservation of content)
Metadata Assignment (Adding descriptive details to enhance search-ability and usability);
User interface design (Creating flows that empower user interaction and accessibility.);
Pensieve Mechanism focuses on content generation and validation. Users gain the legitimacy to edit and verify content in the community knowledge base through their contributions of content. This process presumes that contributors develop a vested interest in the knowledge base as a shared asset, motivated by the time and work they have invested in it.
However, community governance also encompasses additional responsibilities crucial for defining and valuing certain knowledge within a knowledge base or educational framework. This part of the work can be summarised as “knowledge curation”. Specifically, the community must also determine what constitutes relevant and valid knowledge to be stored and shared, understand why it is important and relevant, and assess its significance. These governance tasks are essential for maintaining a structured and effective knowledge management system:
Contextualisation: Placing information within a proper context to enhance understanding and relevance. In the Pensieve knowledge base’ s framework, it is to define what are the relevant Items that should be included in a Page, and provide justifications where needed
Assigning Weight: Determining the importance or relevance of information to prioritise content effectively. In the Pensieve knowledge base’ s framework, it is to define the Item weight of an Item before it is rolled out to community’s participation.
Curation of Knowledge: Selecting, organising, ordering and managing information to maintain high-quality, relevant content.
Classification and Taxonomy Development: Organising information into categories and subcategories based on a systematic classification system.
Our position is that such points should not be transferable across different areas of contribution. Legitimacy earned in one aspect of the platform does not necessarily translate to expertise in another. Therefore, the scope of where and how Contribution Points can be applied ought to be carefully limited. In Pensieve, Contribution Points are awarded for sharing knowledge that has been verified by the community, thereby granting contributors influence within the knowledge base. However, if recognition of additional types of contributions is desired, it should be specific to the domains where the contributors have demonstrated relevant expertise.
The process of creation and modification of the information is a process of community coordination based on individual input and opinions. The platform needs to focus on being inclusive and open to all, while it must give more weight to those who have more knowledge and experience in the subject and those whose interests are aligned with the platform, both of which constitute the legitimacy of a user on the platform and are adopted as measures when users participate in the governance process in content governance and platform governance, separately or in combination.
Just as CDR explained in Section 3.3.3 requires another dimension of incentive and stake with immediate consequences, the governance over community’s consensus on what is knowledge and what is important knowledge requires human participation and aligned interest with the knowledge base. In the meantime, a variety of vote count methods can be experimented to find the best suit (quadratic voting, conviction voting, and etc.).
The operational sustainability of a knowledge base, such as the need to govern treasury when revenue is generated by this collective work, also calls for a proof of governance legitimacy that is more than work but share risks.
3.5 Limitations
This paper acknowledges its limitation in proposing a universal governance model suitable for all knowledge bases and communities, because the attempt to define a universal model would contradict the fundamental aim of the design: to enable communities to independently define and govern their own knowledge structures. For the purpose of creating a minimal viable product, it is possible that Contribution Points alone might suffice as a token in the reputation system for curating knowledge. The Pensieve mechanism facilitates community collaboration on Items and ItemWeight update using Contribution Points. However, we argue that financial incentives are crucial for genuine real human engagement in generating and validating content. Therefore, a mixed governance model incorporating both reputational assets (Contribution Points) and financial stakes (PlatformStake) is recommended for making significant governance decisions. This approach is tested in the ECF.network, aiming to explore effective solutions through experimentation and iteration based on the Pensieve framework.
With existing tools and leveraging Pensieve voting models, the basic principles behind the design of the decentralised curation governance or operational governance are following:
Transparent: Governance should be open and accurately communicating information about activities, funding and decision-making process.
Open and engaging: should empower all relevant stake holders to participate in decision-making.
Adopting Evaluation and Performance Metrics: With clear goals of the knowledge base, use of specific metrics to measure the effectiveness and efficiency of the performance of the platform
Complaint and Redress: encourage open discourse in governance and in the display of the knowledge base where comments, flagging content, suggestion of Items are open and frictionless for the development of the knowledge base and how well the organisation’s actions align with its stated mission and goals.
3.6 Artificial Intelligence Integration and Risk Management
If AI’s generated content takes over a Pensieve knowledge base, there are several potential risks to consider:
Bias and Errors: inherited and amplified bias, cyberattack compromised data could skew the knowledge base towards certain viewpoints or misinformation.
Transparency and Explainability: AI-driven decisions can sometimes be opaque, making it difficult for users to understand how information was curated or prioritised.
Dependence and Autonomy. Over-reliance on AI might reduce human oversight and critical thinking, potentially leading to errors or ethical oversights going unchecked.
Dynamic and Contextual Adaptation: AI might struggle to adapt to new contexts or evolving information landscapes without continuous updates and human intervention.
AI’ s participation is an indispensable part of any knowledge work in today’s world. To give rise to heavily human-contributed knowledge base leveraging Pensive’s incentive mechanisms is half of Pensieve Paper mission, while the other half is to for Pensieve knowledge base to work with AI for empowerment while battling risks.
For risks #1 and #2, a biased language model can be compared to a misinformed individual. Likewise, an AI system that has been compromised to produce false information is not much different from a person who deliberately spreads deceit, and a confused person submitting intuitions and opinions cannot explain well how conclusions are reached. The adjustment of to add identity and access verification component would only make an instinctive but inefficient measure.
For risk #3, Dependence of AI and its efficiency in retrieving knowledge poses tangible risks that Pensieve needs to address.
AI empowered accounts may have much more unfalsifiable information to get community support (or that of other AI empowered accounts) and thus gaining Contribution Points and stakes in a much faster way, with which they gain inequitable advantage in content governance for future. Though that is not inherently contradictory to Pensieve’s merit-based governance principle, but it can be unfair to groups of users that do not have technical advantages and can lead to assimilation of ideas if users are heavily depending on AI systems to generate submission contents for empty Items.
AI consensus. The pensieve knowledge base with these dynamics might evolve to be close to a replica with reorganisation of existing data in the a dominant and popular language model. There is value to it, to understand the consensus among AI systems with evidence provided for supporting the submissions. This makes it essential for community to be encouraged to share transparently and honestly the source of information, because not penalising, or differentiating contributor’s answers from AI’s assistance in fact helps community analyse bias and inaccuracies in AI systems used by contributors. The potential of Pensieve is better realised when it is not something a few researchers can conduct independently with existing language models’ help.
Most of the time, it is imaginable that it will be a mix of both human and AI contribution in the Pensieve knowledge base, and if AI empowered accounts populate content way faster than humans, it might pour bias into a knowledge base unchecked. The solution is to raise stakes (Contribution Points and PlatformStake) for those content that can not be found on the Internet (difficulty is translated into the amount of ItemWeight and Genesis Reward) humans can answer and actions only humans can take, such as those that involve motivations and economic incentives. In the Pensieve mechanism, CDR process is a human-empowering mechanism that incentivises truth seeking with a tangible economic stake involved. This way, high-staked, value-represented, social verification-involved knowledge inputs are more likely to come back to human supervision.
The voting mechanism for high-stake Items can also integrate those that require stakes to be submit in the first place. This method will increase friction of contribution, but it can be an effective tool to be used down the road for mitigating risks.
For risk #4 on AI’s issue with late or no adaptation to new context, it is in fact a reason that serves our purposes of balancing the dependency on AI. An infinitely expansive knowledge base will empower users and language models that keep up with new information, and they will, together, outweigh existing heavy-weight contributors when new Items or structure is updated to the knowledge base and when as the world evolves, knowledge evolves.
Summary.
In knowledge base’s content governance. If the reality that AI systems generally lack desires or intentions stays true, and that they do not have inherent motivations to harm or deceive, and concerns about AI causing harm typically arise not from any volition on the part of the AI itself, then introduction of financial incentive and cost will play a major role in risk mitigation: When the growth and usage of the platform is aligned with users’ stake appreciation, there’s extra benefits in getting involved in CDR and operational governance to make sure the knowledge base aligns with the purpose of the community’s goals and its own functional purposes.
In where community’s own governance discretion applies, these are areas to look into with experimentation:
Apply cost, such as transaction and storage cost to enhance intentions behind actions taken.
Communities need to be cautious and rigorous in its distribution of PlatformStake beyond the methods of content generation rewards.
The reward distributed to unvalidated contribution (Genesis Zero-to-one Reward) should be limited.
Privacy-preserved humanhood verification can be considered in PlatformStake distribution and in general with framework and operation governance
Ensuring AI operates safely aligned with communities’ goals and knowledge base’s design purpose of the involves rigorous testing and ongoing monitoring to prevent and mitigate risks with more case studies.
Last updated