Defining the Constitution
The "Constitution"also called “codex” is a set of “organizational source code” that provides the fundamental underlying programming (the “platform beneath the platform”) of Cosmos. There would be Constitutional code enabling core functionality in social, economic, and technological systems. “Code” is literally what it is called in the domain of technological programming—like the “extensible core” of an Open Source application, with additional modules and plug-ins encouraged. The same principle goes, although it’s instead called “codex,” for the organizational rules governing acceptable behaviors among both the capital flows and the human beings (users) leveraging the Cosmos platform.
The “Constitutional” code is core: all fall under it and it is not optional (in contrast with the Playbook, which is a vast set of optional templates for processes and activities in Cosmos that users may choose to adopt/adapt). The Constitution is much like the legal bylaws of the organization, and may indeed be structured similarly. Fun fact: if you look at the Design Principles: Community/Social for an analysis on how the core principles might be enacted/interpreted by the community/social sphere, those are pointing to some potential universal standards for how we engage with each other (a kind of proto “code of conduct”!)
Constitutional Algorithms are “rules of the game” (er, platform) that would be baked into the foundation of Cosmos. These would be difficult to change (requiring a super-majority of members or other such high bar).
For Cosmos to have a strong start, we should be clear on what we think are our “incontrivertible tenets” early on, but expect to amend and modify them based on users feedback. We should also strive for a small Constitution and a big Playbook—allowing for as much user autonomy and experimentation as possible, with “just enough structure” to protect the integrity of the people and platform engaged. Playbook algorithms are able to become adopted into the Constitutional code, and in-retrospect-overdone Constitutional code may be converted to Playbook material as well.
Gamified: Member Power/Governance Levels In Cosmos
Members have the ultimate power to define triggers and threshholds …eventually. At first a leadership cohort holds concentrated power to make decisions. This is purely do to organic iniquities and disparities in the levels of attention members will put on the task of proper governance (see Spectrum of Engagement) as well as the degree of generalized and specialized learning it requires to responsibly “steer” the large and complex Cosmos project. As Cosmos grows its capacity to self-organize, and the community “levels up” in knowledge and skill, this stewardship cohort will hand over power progressively, as defined through “levels” and terms for each power re-distribution (more on this in Leveling Up). A transparent, highly motivated and highly accountable subgroup or team of experts, through garnering community feedback, and potentially with the assistance of computer programs, may determine and implement Cosmos’ initial “Constitutional” formulas and ensure their systemic functionality (perhaps using computer modeling and simulations). An AI may assist with keeping the system at the Constitutional level properly calibrated and self-aware (or at least alerting when critical complications are immanent), but members have the ultimate power to change any systems by editing the algorithms.
Changing the Constitution (Member Governance)
As mentioned elsewhere, users have a great deal of autonomy to “dial in” their experience on the platform, but the outer constraints of those experiences are set by the collective. To change those macro-settings, a governance process would need to be undertaken. These would require widespread (and a high threshhold for) buy-in from the community for adoption because the risk to the entire system is increased.
However, imagine this: members can propose (and staff/board can set) threshholds for system-wide change to a Constitutional algorithm, presented to the entire membership in a gamified manner. For instance, “Once we reach 900,000 members, the standard portion of ALL members’ fees that convert to LC upon member dues payment increases 10%!” (E.g. say 75% is retained and 25% converts to LC: then, at this threshhold, 35% would become LC [resulting in more fun for users!]) As a collective, this setup would encourage members to be creative in defining what creates value at the macro-level too , and to experiment with making system-wide changes and calculating as well as evaluating the outcomes of those choices. That is to say: managerial level training, through gamified play, emerges over the course of the users’ experience. [Suggested reading: The Great Game of Business. Large employee-owned firms have increasingly been using techniques of “gamifying” the complexities of owning and managing a business to make it accessible and engaging for all.]
Members exercise governance to modify the constitutional algorithms (or, perhaps more commonly, to “veto” something put in place by executive leadership or that is outdated) per the cooperative “one member one vote” model. (Day-to-day decision-making and operational management is handled by an empowered executive team.)
In addition to membership, there is allocation of resources. Each member gets to play with how resources are allocated through the platform, via their conversation/sweat equity participation, their LC, and their C>. Allocation is the fun and primary “visionary-expressive” game that members play daily, whereas membership-wide governance is reserved for rare & serious matters. And even so, there will be opportunities to make a “great game” out of platform-wide rule changes, consistent with gamification norms that users will be accustomed to.
Financial Transparency and Member Control
Picture a spreadsheet visualization wherein money invested through a given portal or into a given “bucket” flows, like water, down an org-defined set of rules to settle into specific funds within the organization. For example:
Say Cosmos (the exec team, with consent of the membership) has identified this formula:
- First, any money received should go into covering operational overhead.
- Following that, 25% of any money coming in should go to salaries, and 75% to legal start-up costs.
- There would be nested sets of rules for each nested bucket. For instance, in the salaries pool, you might have further rules, e.g.:
- Any salary money goes to Marco first until his full salary for a month is paid
- Caroline salary gets 20% of new income after Marco IF legal fund is filled
- M + C salaries get covered 3 months out before any other workers’ salaries are paid out, etc.
- _ _
- The legal fund cuts off at $10,000 for this phase. Representing like a stopper on a keg, no more money can go into that bucket, and so it follows the algorithm as to where to go next…
- Next, any money would go to filling up three months of all core salaries.
- Next… Etc.
- ULTIMATELY it would flow into the open “projects pool” which can be withdrawn from and allocated to specific initiatives enhancing Cosmos.
Once certain sub-buckets fill up, they’d overflow into subsequent months, allowing for the cost of some items to accumulate upfront. This would all be “animated” by a set of transparent formulas and rules (and using formulas, could probably even be built in Excel [see Cobudget and Open Collective]). So if $1K goes in, algorithms would earmark those funds instantly into the appropriate buckets. All members have the option to see and critique/engage with the rules governing the entire system or parts of it, but only those with tangible concern the pool may actually affect/alter the rules. This is accommodated through authentication permissions, which are mutually validated by peers in the system.
According to need, each bucket might have its own governance rules (e.g., the final “projects pool” bucket might require a project to attain 70% of its financing goal independently before receiving $ from this pool; payouts may be capped; members may be required to vote to authorize any disbursements OR to vote on a general budget for the period and then automate what gets paid out from it, etc.) AND management rules (e.g. only the authenticated worker is allowed to draw their funds each period; only a department manager is allowed to authorize payouts from that pot, etc.).
On total transparency: If we set this up, then everyone knows where their $ is going and our priorities are 100% explicit. We hypothesize that this will incentivize people to give more and give generously—the “game” being to instantly see the impact you’re having on personally or collectively desired initiatives.
Notwithstanding the ideal of pure transparency, access to handling or even viewing certain protocols may be deemed as sensitive intellectual property that, if widely published, could make Cosmos vulnerable to attacks. In these cases, information may be restricted to certain highly trusted and mutually authenticated members. Methods of security culture that yet ensure accountability (such as oversight councils, whistleblower protections, etc.) may be used. (They say imitation is the highest form of flattery, and we surely want as many earnest and aligned heads, hearts and hands as possible working on our common dilemmas. BUT nefarious imitation [attempting to privatize and profit from our intellectual and creative capital pouring into Cosmos] could cost resources and potential members if our model is mimicked by others for less auspicious, less authentic purposes.)