Because eco^2 is an unbounded non-group, there is no place for money. Money is held in individual and relative accounts between individuals. The structure of the eco^2 entity is a snapshot of concurrent, live, mttp contracts. There is no “pot” of money, no “capital”, but a specific network of money held between individuals as guarantees, and flowing between individuals to honour mttp contracts. Because of the discrete quanta of mttp, the overal structure of eco^2 is as dynamic as a cyclone with no money at its centre or aggregating at the “top”, as we find in current economic objects like companies or governments.
A system to track the mttp contracts, both fixed and fluid money, is essential as eco^2 scales up. The tracking of subjective enumeration using a variation of the google page rank is essential for the qualitative distribution of surplus. And integration of the lower scales of mttp into social media platforms, so that the g+1 or fb “like” means +1p/10p/£1, is a midterm objective.
The Confluence Model is a social utility defined by a minimal set of simultaneous systems which enables people to collaborate in a non-managed way. It runs on three simultaneous systems: the intentions system, the coupling system and the conditions system. There is a fourth system which runs in the real world in the mind of the user, the realtimeOS.
The Intentions System allows users to write down what they are intending to do with respect to a specific objective. Everything is future orientated, with only 1/3 of a user’s time taken to report on the results, eg of a meeting. Like a flock of birds seen from the perspective of a single member, one can see what neighbours are doing, whether in the same company or friends or notables, and thus it is possible to plan ahead based on what other people are doing without actively contacting them. This makes the entire system more efficient.
The Coupling System enables people to connect with one another in a more substantial manner. That is, if there are 20 people aligned to a particular objective and only a team of 5 is needed, the collective of 20 self-sorts through “value sets” of mutually accepted personality questionnaires. For example, one individual believes the team must consist of a plant, a decider, a finisher, etc, while another person might need to check on specific skill sets, programming language, contact network, etc. People thus choose their teams relative to their own value set, and “ideal” groups are implied by those individuals who fit several such value sets. A prospective team meet, or participate in some single task to see if the team gels, and if this works, the individuals commit to achieving the objective. Multiple teams may be generated, as well as vaguely bounded teams, with a range of 5 to 7 members, depending on who is talked to. What matters is that results will define who the actual team was.
The Conditions System enables individuals to record what they believe to be the contingent factors that are informing their decisions. This might be by sharing information, pointing at various website articles or videos, but minimally it consists of conditional statements describing the conditions the person finds themselves in: IF certain conditions are met THEN the person can do something. This allows participants to overcome other people’s limiting factors, sui generis. Instead of discussing, and asking for help, things which slow down collaboration rather than speed it up, users can just help one another out effortlessly.
The realtimeOS consists of a bunch of heuristics to make best use of the computer system. Most users will be invited in, and hopefully in terms of manifesting a realworld application. The tool is therefore evaluated in situ; users will not judge whether the tool is good or not, but whether their realworld objective is realised. If it is, then the tool works. Period.