Consensus Dynamics Notes

From Worden
Jump to: navigation, search

This page is the free-notes part of the Consensus Dynamics Project.


Historically, this research program starts with this research proposal, which I wrote for an opening at the Santa Fe Institute.

Second is what became this page, followed by Consensus Experiments.

Lit review

Currently this is more like "literature to review"...

Collective, evolutionary and other search processes

Distributed consensus research

I believe this is somewhat different, but there may be important overlap. Need to read various stuff in the field to get an idea of what's relevant. Some random links:

Models of social process

Suggested by Jordan Ellenberg:

Group process

Movies: JD suggests Of Gods and Men. There's also Twelve Angry Men.

In social movements

Tech support for collective decisions

And lots more, I think.

Also related:

Possible avenues

Distributed computing metaphor

What can we learn from people who know a lot about distributed computing? For instance, Google uses many thousands of computers working together to divide up a search request and get the answer incredibly quickly.

For instance, imagine all the different cities' Occupy movements trying to make a national- or global-scale decision together. A good process might make the difference between doing it efficiently and effectively, and giving up in frustration.

  • A good tutorial on distributed computing:
  • Plan for failures at every point of the protocol.
    • cell phones stop working; internet connections fail; point people unreachable; facilitator unavailable; meeting place for coordinators unavailable; some groups of participants take too long to respond; disgruntled factions become uncooperative and disruptive; etc
  • Parallelization models [2]
    • Some things are easy to distribute, some are not.
      • Testing for consensus is no problem. Given a proposal: send it to every subgroup, ask them whether they have a block. If anyone says yes, there's no consensus, and if not there is. (Except for failures... what if someone doesn't answer, etc.)
      • Distributed logistics may be more difficult... SF has computer servers to spare, NY has lots of donated money, etc., who provides what resources to whom else, can include lots of things that depend on each other. Not easy to decompose into independent pieces, potentially a very hard problem. (see also: [3])
    • "Each of these problems represents a point at which multiple threads must communicate with one another, or access a shared resource." Translation: distributing a problem is difficult if the players need to communicate with each other, or if they need to access information or resources that someone else also needs to access while solving the problem.
    • "Keeping shared state to a minimum reduces total system complexity." Translation: it's best if each subgroup can do its job without needing to know anything about what's going on in the other groups.
    • Data parallelism and task parallelism. Many questions and tasks decompose into subproblems that can be done in parallel. If a question has independent subquestions, they can be attacked by different people simultaneously, and brought together at the end. But if there's one or more resources that are needed in both subtasks, you can have trouble. "Intelligent task design eliminates as many synchronization points as possible, but some will be inevitable." That is, the point where one team has to stop and get information or a resource from another team is a bottleneck that can cause delays or even deadlock.
    • Common patterns for parallelism
      • Master/Workers. Oversight person farms out tasks to others, gets the results back and integrates them.
      • Producer/Consumers. "Producers" generate tasks to be done, "consumers" step up and do them. This "subcontracting" can continue in a chain with no central integration of information.
      • Work queues. Tasks to be done are posted to a bulletin-board or similar system, where workers can claim them and return the results without interacting directly with the task's producer.
      • Note: all these "tasks" may be informational tasks, like evaluating a proposal, generating amendments, etc., rather than tasks like fundraising, outreach, etc. It's not obvious to me how that works in these contexts, but it's intriguing. Or spatial things like coordinating movement of demonstrators, somehow...
  • Implementation techniques [4]
    • Is there something to be learned from the "primitive" patterns that distributed programmers have developed?
      • fence(): pause and don't continue until everybody else has also reached this point in the processing.
      • Mutual exclusion lock: like the bathroom door, close off access to the resource while using it so it only has one user at a time. The idea that one speaker "has the floor" also fits this pattern.
    • Communication patterns:
      • one-to-many: broadcast. Facilitator does this.
        • Sometimes it is useful to have a way any one participant can send a broadcast message. Mic check!
      • many-to-one: for example, collecting all the results of a vote. See reduce, below.
      • many-to-many. Conversations that happen between assemblies. Facebook, twitter, texts, emails, etc. Many-to-many communication could conceivably be incorporated into meeting process as well, if it's a useful part of the design.
      • All-to-all messaging: "Combination of above paradigms; individual processes contribute components to a global message which reaches all group members". Interesting. I guess documents like this are under this heading. That is, not the subject matter of that document, but the creation of that document itself. There may also be ways to construct an all-to-all message without formal consensus (or in that example, voting)? Might be worth digging up examples of how this is done in computers.
  • MapReduce [5]
    • Simplifies distributed programming by handling only problems that can be broken down into a map function and a reduce function. Each node (processor... participant... subgroup...) performs the map function on its data, and then all the nodes' results are combined using the reduce function. Each map operation is completely independent of the others.
      • Example: to find out whether there are any objections to a proposal, the map function, applied to each individual, is "do you have an objection", and the reduce function is simply logical or: there are objections if any of the individuals said yes.
      • Actually, there's some more complexity in MapReduce, where it aggregates together all the map values for a given key before doing the reduce operation... might or might not be of interest to us
    • Handles failures: if a node doesn't complete its map task, just ask someone else to do that task. Additional level: if a particular piece of data causes the map to crash repeatedly, don't do that one any more. This can work around bugs in the program!
    • Thinking of things in terms of map and reduce instead of messy implementation details can free up the imagination and creativity.

What group-deliberation tasks are naturally parallel?

  • Again, testing for consensus fits the MapReduce mold easily.
  • Collecting concerns, or proposed amendments, can be a MapReduce. For example, break into small groups, brainstorm, and collect the ideas raised by people in your group (map). Then collect and combine all the lists (reduce).
  • So there could be a series of map/reduce phases: present a proposal and find out whether people like it; generate new proposals; find out how people like those...
  • If people's focus is good enough, it would be possible to send out multiple propositions for evaluation at the same time, i.e. break into small groups and collect everyone's opinions about each of these 5 proposals... that could be impractical but I can certainly imagine it.
  • All this becomes less theoretical and more urgent if we imagine a large-scale process involving multiple assemblies in different parts of the continent, all trying to come to agreement together. It might seem ludicrous to even imagine trying for true consensus on such a scale (as opposed to using a 90% supermajority vote, say), but imagine how heartening it would be if we had a good enough process that we could do it and succeed!

Constraint satisfaction

See Consensus Dynamics Notes/Constraint Satisfaction.

Minimum value question

  • if the goal is to find something that minimally satisfies all, it's probably best to focus only on the people who aren't satisfied, not the people who are. Devise facilitation strategy to look at that directly, maybe do some math about it?
  • Actually let's take that one step further. Minimum value hypothesis: if everyone agrees that the goal is to find something that's acceptable to all, then everybody is searching together for a point that's acceptably high on the landscape of minimum fitness values. How useful is it to do a simple search algorithm on that landscape? That is, just optimize the function fmin(x)=min{fi(x) for all i}. It would be worth trying this, to compare to other facilitation algorithms.
    • That is, imagine an especially difficult person who wants to please everyone. If I am that person, then my opinion of any given proposal is equal to the worst opinion anyone else has about it. Now how will I find a proposal that satisfies me? (So the m.v.h. could also be called the "worst-teammate-ever method".)
      • However, it might be that the team can do better by taking into account the perceptions of people other than the one who's currently blocking.
    • How do the bumpiness and other characteristics of this landscape relate to the landscapes it's made from? What kind of search process is best for it?
    • There ought to be analogous reduced landscapes for other objectives - for instance, the Influents algorithm considers both the mean and spread of values for each possibility.
    • also, this suggests a related question: what is the probability that there's no way to satisfy everyone? does it have a simple, meaningful form?

Use examples

Contributed by elizaBeth Simpson:

  • It would be very good to illustrate the model with a simple example or two, like for instance a family buying a car, with various considerations, price, size, etc., and different ways of valuing them.
  • This would also be a really good way to validate the model results, since it's not obvious whether conclusions drawn from the Boolean hypercube model would generalize to an example like this.
  • Note the pizza example is a response to this.

Pizza example

This has its own page: Consensus Dynamics Notes/Pizza.

Issues vs. Proposals

The simulations I ran in July 2011 were based on the idea of dealing with a series of proposals:

  • proposal → friendly amendment → amended proposal → friendly amendment → ... → ultimately consense or give up.

I think this may have been loosely inspired by my notes from Butler and Rothstein's book on formal consensus process, including this diagram:

Loading WorkingWiki file "butler-rothstein-diagram.html" dynamically. If it doesn't load, click to view the page statically.

This diagram begins with a proposal, and ends with a decision whether to adopt the proposal. [In the July modeling I chose to simplify all this pretty drastically by not developing a way to model "concerns" except by having model agents say "I don't like the proposal as it is, let's change it to this similar one." See below for more on "concerns."]

I've also had the experience of being in various groups that use some version of formal consensus in which there's a boilerplate agenda something very much like "Introductions; working group reportbacks; possible special presentation; proposals; announcements and closing." That is, the only collective decision making takes the form of receiving a proposal and deciding what to do with it. In my experience in various groups, and I don't know how widespread this is, you're not allowed to make counterproposals while a proposal is on the table, or any other suggestions except in the form of concerns or friendly amendments. A decision has to be reached whether to block, postpone, or adopt the proposal (with or without amendments) before other things, including other proposals, can be discussed.

There is a fundamental asymmetry hidden in this: people are always allowed to bring proposals (room on the agenda permitting), while blocking is strongly discouraged. This means that a proposal that's not necessarily an improvement over the status quo for most people can still be adopted, and if there are several courses of action that are all acceptable enough to avoid being blocked, the first one proposed is likely to be adopted even if others are significantly better. [I have had citations about this in the past, but am having trouble finding them.]

Also, on a more positive note, in thinking about the general idea of looking for a good solution to a problem - i.e. a mutually acceptable location in the space of possible proposals for a given problem domain - I came to find this idea limiting. Wouldn't it be better in some circumstances to say, "Let's take a certain amount of time to talk about a certain issue, and see whether there's anything we'd like to do about it"? We could start by trying to clarify what we know about the issue, make sure we agree that there's a problem to be addressed, lay out multiple possible proposals and find out what people think about them, and then see whether an answer has emerged, or whether there's a need to pick out particular proposals and discuss them.

This seems more like what Tom Atlee describes here, and it's more like this diagram from Peter Gelderloos's book:

Loading WorkingWiki file "gelderloos-diagram.html" dynamically. If it doesn't load, click to view the page statically.

Like I wrote in my plan for March, I want to reconceive the simulation model so that it can include things like brainstorming and comparing multiple proposals, not just considering a single proposal at a time. Maybe I'll try asking what's the simplest possible extension of the model that can include brainstorming, to see how far it gets me. I'm curious whether that will reveal that brainstorming is at one end of a certain spectrum (I don't know what spectrum, yet), with taking one proposal at a time at the other end, and if so it'll be interesting to see what lies in between the two ends of that spectrum.

Modeling issues involved in this

In the July models, when I was only considering what to do with a model, I had the issue of how to formalize what a concern is. In my model, proposals were just anonymous points in a big space, and you could really just say how much you do or don't like one of them, and propose another one in its place: there's no way to say what you don't like about it. That requires some kind of language for talking about the proposal, or another way to look at it might be a way of naming sets of proposals and not just single points in the space. For instance, when I say, "I don't want to get the onion, mushroom and tomato pizza because I don't want onion", I'm saying that all the possible pizzas that include onion are, uh, off the table - which helps the process along quite a lot because it rules out a big chunk of the search space.

In the Gelderloos diagram something analogous is happening earlier in the cycle: first there's a cycle involving brainstorming that produces an "idea", then there's a cycle about "how [the] idea will take shape", which produces a "proposal" that has general support, and then there's a cycle involving concerns and friendly amendments that ends with consensus or failure to reach consensus. It might be safe to say these "proposals" are single points in the search space. They come at the end of a narrowing-down process, and the earlier phases deal with something more general: it seems like an "idea" is a lot like "let's get onions on our pizza", i.e. it corresponds to a whole region of the search space - all the different combinations that include onions - very much like concerns, or their counterparts, the "pros" of "pros and cons". This could be described as working with subsets of the search space, or, probably more usefully, characteristics of proposals that are wanted or unwanted. [As an aside, Gelderloos's three-phase diagram could probably be generalized to a simpler idea of narrowing down without discrete phases, starting with broad brush strokes (is group support behind a particular idea or approach) and then narrowing in more and more until there's an actual concrete plan for what to do. This might be worth exploring.]

It seems like I really need a clear way to handle this subset issue. Other issues have been emerging as well, which I might write up separately: what difference does it make that people don't change their point of view from listening to each other; what difference does it make that people don't consider "the good of the group" as well as their own desires, for instance wanting to come to agreement quickly or to avoid conflict; and are people likely to use strategy to get more desirable outcomes for themselves, not just something they're willing to accept.


What's the difference between strategy and tactics? I have the idea that consensus meetings' proposals tend to be about tactics, and can get hung up on differences about strategy. Whereas deliberation about strategy takes years or longer, and happens in informal discussions, publications, etc., not meetings. Is this true?

  • This question may overlap in some way with NVC theory of strategies and underlying needs.

On Nonviolent Communication and seeking consensus

David Montgomery writes:

Hi Lee,

I'm not imagining how something like this would go
into a simulation, and you may already know this,
but I figured it still wouldn't hurt to share.

At a high level, the NVC approach to this is as

 * Get all the needs on the table.  That is, translate
   whatever strategies are up for different participants
   into the deeper, more universally held needs, until
   all participants agree that if these needs were met,
   they would be satisified.  This usually happens as
   a combination of identification of their own needs by
   individual participants, and guessing by others.

   In NVC theory, at the level of needs, there isn't
   conflict anymore.  But there's still a question of 
   coming up with a strategy to address these needs.

 *  NVC holds that when people see each other's 
    humanity, and are connected at the level of needs,
    a  tremendous creativity is released to generate 
    solutions that will meet all or most of the needs.
    The idea is that needs can be met in a great 
    variety of ways, some of which will be compatible,
    even when the strategies that have come to mind
    first are in conflict.  More space, more degrees of 

It's not much of an algorithm/process.  But I think
the key insight is actually effective in many situations.


Notes from Greece

From a friendly source on the Diaspora* network, who wants to be anonymous.


Is this your project? I'd like to make a clarification. Greece (and as far as I know Spain too, but I can be really certain about Greece) didn't use a consensus democracy. There was public speaking before the assembly were you could convince the people about your views and then there was voting on proposals based on these views but the process wasn't repeated ad infinitum. After some proposals were rejected they didn't come up again.


Forgot to say, it didn't use consensus democracy, it used the Athenian direct democracy model.


Thank you! Do you have links to a good description of the Greeks' process? It sounds somewhat like the 90% supermajority voting that OccupyOakland is using. In the theoretical work I'm most interested in consensus but I'm also interested in the differences and I want to correct my descriptions if needed.


Also can I just say, I posted this thing just now on facebook, g+, twitter and here, and people click "like" or whatever but only here do I get a serious, meaningful response from people I don't even know


I almost didn't see that you responded, the notification system is still buggy. I'll look if there is anything already officially translated about the process and I'll let you know. Yes, diaspora is quite the intellectual place it seems :)


Thanks! I'll check back later, I'm off to the plaza, where someone from the MST in Brazil is speaking to the occupiers and then there's a solidarity march for the Egyptian movement... so much great stuff to keep up with!


Unfortunately it appears as though the site that was holding most of the translated texts is down.

The structure of the Syntagma sq. public assembly was/is rather complex. There are three main parts. The people that constitute the assembly itself who decide everything and speak, the coordination committee which handles administrative issues, and the thematic groups who deal with specific issues and then present their work to the general assembly and ask for validation through voting.

The administrative committee is chosen randomly from the crowd of the assembly or rather from a pool of volunteers, and I think it was supposed to change every 3 or 4 days. It's main purpose was to coordinate the speaking and voting process.

To speak to the assembly people had to pick numbered tickets and then numbers were chosen randomly through a lot. Each speaker had about 2 to 5 minutes due to time constraints. To vote on an issue, written proposals were given beforehand to the coordination committee. At some point during each meeting, the coordinator would read the proposals and the people would vote on each one by raising hands. Some times, people would object and the voting would be repeated. Three kinds of votes were allowed, for, against and blanks (white votes). Texts that represented the views of the assembly would be read paragraph by paragraph to the assembly and each paragraph would be voted on. I found a translated example of this process here.

If you need more details about the process feel free to tell me. I will continue looking for translations in the mean time.


The random functions are a method taken directly from the ancient Athenian democracy. Public servants and administrators were chosen randomly and didn't have any power at all. They were considered employees of the citizens and they had to give a full account of their actions at the end of their terms.

In the modern Athenian assemblies they kept the random method but changed it to fit the current situation.


This is great, thank you! I would guess that as a stochastic process the random sampling would work quite well to reproduce the decisions that would get made by taking a much longer time to include everybody - but that it doesn't work so well at creating the sense of "buy-in" that comes with actually being included. The voting on each paragraph seems more weird to me - I will have to learn more about it. It doesn't make sense to adopt only some paragraphs of a coherent document, so there must be something different from that going on - like maybe they will go back knowing which paragraphs passed and produce a new document to propose...


Sometime soon I'll copy these notes over to my research wiki. Do you want to be credited? If so, please tell me what name or handle to use to identify you...


It depends on what part you are talking about. In choosing members for the coordination committee, random sampling is used because it provides the greatest level of equality. With a randomly chosen coordinator you avoid any sort of crony-ism, favoritism etc. People accept this because being a coordinator is (and should be) a burden, not something to actually strive for.

In picking speakers, randomness is chosen because there wasn't enough time for everybody and there were too many prospective speakers. The only just system for picking who would speak and who would not (because a lot of people didn't get a chance to speak at the assembly at all) is by drawing lots.

The effect on the people, as far as I can tell (subjectively) was to try and make the best use of their time slot, since it was essentially rare to get to speak to the assembly. In actuality, if someone didn't have time to speak to the assembly but had an important thing to say, usually gave a written proposal to the coordinators and it went to a vote immediately.

The text that was voted on, changed on the spot by yelling different proposals. The coordinator would put the new proposals in a vote immediately. Sometimes, a text went back for complete redrafting etc. It was a very fluid process and the most importance was placed in maintaining absolute power to the assembly and not the thematic groups.

I'd prefer not to be credited, I didn't create up the assembly process and it is in a way my duty as someone who took part in it, to spread the knowledge about it. You could just use a random letter to signify that it is a particular source though.

If I find any more data I will send it over.

By the way, the repeating of each phrase that happens in Wall street, never happened in Greece.


Yes, the repeating was a strategy for having to meet without any loudspeakers, then became a symbol of the movement. I definitely want to research the specific processes in the Greek movement (we should obviously look to them to teach us about democracy!), and I'm sure the Spanish activists have made important innovations as well. I would add about randomness that it might provides the greatest level of equality outside of including every single person, which is not an option in a large group because it's too inefficient.


The original Athenian democracy had some very smart safeguards against corruption, resurgence of oligarchy etc. and that was essentially the blueprint for what the modern general assemblies did. A reason for their success is that the Greeks grow up with with a very positive image of the ancient Athenian democracy, due to their schooling. Hence, having an example that worked gives a lot of confidence to those that try to recreate it. Another thing that I personally find very interesting is the Pericles network. The Pericles network was a research project developed at the polytechnic university of Athens and it consisted of decentralized computer nodes that would make direct voting on issues by the people possible. They had a working prototype too but it was rejected by the government in the 90s because they deemed that the "people were not ready for this yet". This was supposed to be an adjunct to parliamentary democracy, but I think it can replace it completely with enough tweaks.

If you are interested about this you can visit the homepage although unfortunately, it is all in Greek and google translator may not be of much help due to the vocabulary used. The only document I found in English that describes the system is this.

Lessons from voting

[Contributed by JD]

If we assume:

  • People's opinions don't change through deliberation
  • Information is exchanged efficiently
  • The space can be explored efficiently
  • There is no option agreeable to all
  • We have to reach a decision

We move the problem to the world of classic voting theory (see argument below). Even if we don't make this assumption, voting theory has something to teach us about this problem.


If we accept the assumptions, then we can assign a voting order (and/or voting weights) for each person across the whole list of possible alternatives. This is exactly the problem that classic voting theory is meant to address.

I don't necessarily agree: classic voting theory seeks a way to find the best alternative. When our individuals agree to allow something acceptable but supoptimal, I think we are looking at a different problem. Anyway, in this project, I want to shift the focus from voting to searching in a big space. -LW


Arrow's theorem applies: there is no algorithm that produces an uncontroversial optimum in all cases. It might be good to evaluate whether a "Condorcet solution" exists; if not, there may be a need to choose between various complicated heuristics.

If an optimum is desired: again, finding an optimum is not the focus of this project. -LW

These concerns seem to generalize to the broader problem; we should be on the alert for signatures of possible "voting paradoxes" (or the opposite, "Condorcet solutions") even in the absence of complete information, and we have to think about what heuristics we might be implicitly applying.

This could be - "Rock, paper, scissors" situations for instance. How do they affect these processes. -LW

Progressive stack

I'm becoming more interested in what to do when an issue is identified, as opposed to when a proposal is made (a proposal is one thing a group can do when there's an issue). So I'm thinking about the stuff that happens before a proposal is brought up. In that phase there's generally a facilitated discussion, or else informal discussion outside of the frame of the meeting. Facilitated discussion can include small-group breakouts, brainstorming, bringing up more or less structured questions, and various other techniques. It often involves keeping a stack of people waiting to speak, in the interest of fairly allocating the right to be heard. Many groups use a progressive stack, in which people whose voices might often be silenced or underacknowledged are given preferential access to the stack. I find myself wondering whether there's anything to be gained by thinking about the different ways a progressive stack could be designed, and what difference it would make.

Computer scientists know a lot about keeping track of items to be dealt with. Generally they are kept in either a stack or a queue. Ironically, the stack we're discussing here is clearly a queue. A stack is "last-in-first-out", like ones mental list of digressions in a conversation; when you finish a digression you return to the most recent thread of the conversation, and from there out to the next most recent, and if you're especially good at it you end up all the way back at the topic you started with. A queue, on the other hand, is the kind of thing we get into at the grocery store, where you start at the back and get to the front after all the earlier people are done: "first-in-first-out".

There's a huge body of research on queueing theory, which could conceivably have something to contribute to this question of how to combine justice and efficacy in facilitated meetings. Queueing theory is mostly about commercial problems like how many checkout lines to open at a given time in a store, and the design of the boarding process for airplanes ("Now boarding all passengers in group 3") to get all the passengers into their seats as quickly as possible. I think it's also important in designing the scheduling strategies that computers use to keep large numbers of programs running at the same time on a single processing chip and taking turns using the hard disk, network card, and so forth. But the theory is general and can be applied to many things.

Without going off and reading any of the literature, I'm seeing this as a design question in which we imagine evaluating various candidate designs (you could say anyone belonging to certain groups speaks before anyone who doesn't, or you could reserve a certain number of slots, or someone could propose that actually just keeping a straight stack without making any distinctions works best). You have to evaluate a given design in terms of certain objectives, so what would they be? Making space in which people can be heard when they haven't had the opportunity often is a good in itself, so that can be considered an objective, but it can also be that hearing a greater diversity of perspectives helps the entire group make better decisions, and other advantages or disadvantages might also be proposed. The second issue is that in order to evaluate a design in terms of any objective, you have to have some estimate of what will happen given that design, which means you have to have some scenario of who is present in the meeting, who will speak under what circumstances, and what kind of things they're likely to contribute.

The question of who is likely to contribute what under what circumstances seems to be a particularly basic one - what do we know about the idea that some people are less likely to contribute than others in a seemingly "fair" system where everyone is treated equally? How specific can we be about it? How much less likely is one to contribute? Without information like that, it's hard to guess what kind of impact particular interventions will have. Of course, information like that is very hard to come by, so most likely questions like this can only be addressed in very general terms by using hypothetical possibilities and maybe a small number of experiments and studies of actual groups. A well-founded approach to this, if there is one, would probably be to make very simple, qualitative assumptions and see whether there are any very general patterns that hold over a large range of specific situations.


Here's an idea, borrowed from the satisfiability problem.

Say the problem is to find a proposition that is a combination of various things, like "A and B and not G". Each participant has a set of requirements, for instance, "not C and not D and F and not H", or a more complex combination of possibilities. Now when a proposal is on the table, a given participant can say, "well, I don't like it because I don't want H. How about if we get rid of H and include G instead, because I would like that better." Then the others can evaluate whether they would like that better.

So the search space is the same as for the satisfiability problem, and the search heuristic is something like the suggestion there: flip some letters on and off and find a better proposition.

But does this really get at the idea of concerns?

... note, a more extended model might have participants have some kind of higher level? Like "I want a certain kind of outcome... that can be satisfied by 'A and C and not K' or by 'B and not D and not E'..." Then the interactions would be more complicated, like you might think your concern is that C and not K are satisfied but not A, but actually a better way is to try to satisfy the other criterion...

Misc to-do items

  • effect of pickiness of individuals (utility watermark).
  • maybe a simpler comparison:
    • n people working independently vs.
    • n people each generating a proposal and then voting vs.
    • n people searching together in some simple way:
    • Compare mean fitness of outcome, how satisfied each person is.
  • replicate Scott Page's main result?
    • Can I generate something similar but different to Page's? Like, look at the benefit of having people with somewhat different valuations, as opposed to the same valuation but different search heuristics
  • compare generating proposals in meeting vs. between meetings - all-to-all vs peer-to-peer communication
  • diversity in watermark, ruggedness, inter-individual correlation?
  • network structure, processes for large groups where all-to-all communication is impractical


Notes on formal consensus process, from Butler/Rothstein's book


In the consensus process, only proposals which intend to accomplish the common
purpose are considered.
  • Present proposal or issue
  • General discussion
  • Test for consensus

If no consensus:

  • Identify participants' concerns
  • Seek resolution for concerns
    • Questions to clarify concerns
    • Produce modified proposal
  • Possible stand-asides or blocks
  • Test for consensus

Possibly: use brainstorming technique to collect concerns, then group them before discussion/resolution begins on the grouped concerns.

Possibly: Break out into small groups.

Another description

Another description of the project that I wrote for an email and didn't use:

Making a decision together is obviously a fundamental human activity and it may seem perverse to think of it in terms of math. In fact thinking of it in terms of math may risk certain kinds of perversity (in the bad sense) - for instance, the risk of seeing the process as mechanical and losing compassion for the people we interact with, or imagining a need to surrender control to a cadre of technocratic nerds. But I think it's possible to evade those risks and use some powerful tools we have at our disposal to learn something useful.

Previously I've done research relating to evolution and emergence of cooperation in ecological communities. These problems have something in common with the business of making a decision together, if you look at it a certain way: there are many possibilities and we want to know how and when the good possibilities get selected. In the case of decision making, it looks like this.

There is a group of people facing a problem, issue, or opportunity, and seeking to decide what to do. There is a range of possibilities and the group has to choose one. Generally you don't know what all the possibilities are, so there's a process of exploration as well as evaluation. Different people have different opinions of what's a good choice, and different people come up with different possibilities. This is why they need to talk to each other, to combine their ideas and ask each other what they will accept.

Given all that, we wonder what's a good process, that is, what pattern of communication is likely to help the group come up with a decision that is agreeable to as many people as possible. This is partly a question of how to make a choice among a small number of known proposals, and partly a question of how to generate good proposals by building on each other's ideas. It includes how can group members behave to help the whole group's process, and what kind of facilitation gets the good outcomes.


Consensus process is used when there is an issue. Maybe an issue is a search problem, like "find an proposal that everyone agrees can address this particular set of desires."

  • We can model that as "find a location in this search space that satisfies each participant's requirements".
  • Each person's requirements are different — that is, each person has a different function for evaluating members of the search space.

So: say our search space is Σ, and each person i has a valuation function ϕi, so that for a given proposal xΣ, each person either likes or dislikes it: ϕi(x).

Then: what is a concern?

  • If I'm a participant, and the proposal doesn't make my threshold, the concern is a reason why it doesn't. That requires the fitness function to have some kind of structure, by which I can say improving the proposal in a certain way will satisfy me better.

Given what is a concern, what is a way to resolve it?

  • A new proposal, I guess.

Do we connect this to Scott Page's models? In his case we share a fitness function but use different heuristics (which is connected to having different landscape topologies). The heuristics are important. We may want to use that as well.

It's pretty much like this: given a proposal xΣ, person i can go from there to a few modifications of the proposal: {y1,,yn}. A different person would propose a different set of modifications. We have a round of proposed modifications, and people evaluate each other's suggestions, and if one of them is good, we test that one for consensus and concerns. This is the same as Page's model, I think, but it's different when people have different valuations ϕi.

That's a model worth investigating. But also what about concerns?


  • effectiveness of Constraints vs Goals as in Larry Richards' papers
  • Maybe a proposal can be a schema like in John Holland's models - a subspace of the domain like 1011010********01, where the * positions are unspecified. Then a concern might be like, I don't like 10110100010001101, do you have a better example? This could work well with the SAT framework...

Model development process?

Here's a nice-looking document on how to develop your model: Maybe it's useful. I'm thinking of using Netlogo to code up the model. Update: No, I'm not, I wrote it in C++.

Step 3, Hypothesis Building:

  • What is the environment?
    • Strictly, there isn't one. A meeting room that doesn't need to be modeled. A collection of model people.
  • Who are the agents?
      • The people seeking consensus. Some number N of them. They won't arrive or leave during the process (or will they?).
    • Variables?
    • Characteristics?
      • What's this mean?
    • Rules?
      • What's this mean?
  • What are the relationships?
    • No spatial landscape or network, just an all-to-all interaction.
  • What are the rules?

Steps 5 and 6 look like a useful framework for testing and analyzing the model.