How We Might Decide: An Alternative

“Blinap” is the name for a new kind of population-scale democratic decision system. (The term is a portmanteau constructed from “BLind INdependent APpraisal”.)

Blinap’s characteristics include the following:

Proposal Filters

Key ingredients of the Blinap system include its proposal filters. A proposal filter has these parts:

Filter questions are like those that might be asked in an environmental impact statement: Does it impact an endangered species? Does it pollute the water? Does it increase noise? Each question will affect the decision outcome according to the instructions attached to the response that the appraiser gives to the question.

As with the questions of an environmental impact statement, the filters must be “objective enough.” The measure of “objective enough” is that multiple appraisers that independently apply the question to a particular new proposal will reliably arrive at the same answer. If the appraisers do not reliably arrive at the same answer, then the question is too subjective to be of use.

The requirement that proposal filters must be “objective enough” may put limits on the kinds of proposals that Blinap can handle. For example, it might prove very difficult to formulate acceptable filters to apply to proposals that attempt to allocate funds in the arts and entertainment field. And it also might sometimes prove difficult to formulate filters that apply concepts such as fairness or justice. The filters would need to somehow squeeze the subjectivity out, leaving only objectively measurable residues. (Some may see this as a feature rather than a bug, in a decision system intended to bridge among strangers who have no basis for trusting one another.) As Blinap is tested across a broad range of proposals in the Lab, we will discover the extent to which this limitation is problematic in practice.

Decision Process Flows

Blinap has two primary sub-processes (tracks) that run in parallel: the “anybody can object” track and the “appraise the proposal” track. These tracks produce inputs to the software program that will decide the fate of the proposal.

Informally, there may also be any number of “side-tracks” through which decision participants interact, and proposing teams themselves will internally be arenas for interaction.

— Track: Anybody Can Object

New proposals (including proposed objections) are collected through an online interactive process.

After a new proposal is submitted, anyone can propose an objection to it.

The objection will itself pass through the full Blinap process (which means that anyone can propose an objection to the objection).

Any number of objections to the original proposal may be proposed. Any number of objections to each objection may be proposed. There is no formal bottom to this proposal recursion.

The important element is that each objection passes through the Blinap process — which establishes whether it is an acceptable objection. Acceptable objections should be and are effective at any depth of recursion.

Proposing to Blinap is a team project that ends at the point the “submit” button is clicked. The work of proposing does not formally involve interacting with anybody outside of the proposing team. The only interaction is with the software wizard that collects the proposal.

— Track: Appraise the Proposal

After a new proposal has been submitted, software then selects three appraiser teams from a large (eventually global) pool of such teams.

(The features and priorities of that selection software — and the software code itself — will be proposed to Blinap. Successfully proposing how that selection software will operate is a core part of initializing the Blinap system.)

The appraiser teams work independently. Their work includes running the proposal through a set of proposal filters (a checklist). They have three days to finish and submit the appraisal.

This process of filtering the proposal is actually a well-known and widely-used pattern. High-stakes professions (airline pilots and crews, nuclear plant operators, physicians, operating rooms, intensive care units) use checklists to reduce errors due to cognitive biases, failed heuristics, memory lapses, prejudiced intuitions, and other such mental infelicities.

Blinap adds enhancements to the basic checklist pattern. Since it is possible for mistakes and “gaming the system” answers to occur even when using a checklist, the appraise track has three appraiser teams (who do not know one another) independently apply the checklist, and then compares their answers.

In addition to this safeguard, the appraisals are published after they have been submitted, enabling anyone interested to examine them and to object if it seems that all three appraiser teams may have erred together on an answer.

Through this process, each new proposal is systematically and professionally examined from all relevant perspectives.

— Compare the Appraisals

At the point that the three appraisals have been received, software compares the answers given to the filter questions. If there are answers that do not match (perhaps indicating that the question was somehow not “objective enough”), an investigation is triggered that will attempt to determine specifically why different appraiser teams gave differing answers to the same question.

At its conclusion, the investigation will propose (to Blinap) findings and recommendations aimed at reducing the likelihood of future failures to match.

The recommendations may then be implemented, after which the decision process for the proposal will be restarted with new appraiser teams. (This is potentially a loop. Some proposals that face proposal filters that repeatedly produce failures to match may have difficulty making it past this loop. The investigations may recommend replacing those filters with more objective ones, or improving the training that appraiser teams have available for those filters, or reducing the ratings of teams that give answers that fail to match in certain ways.)

If all answers match across the three appraisals, the three appraisals are resolved into a single appraisal that then becomes input to the software program that will decide the fate of the proposal.

— Decide Proposal Fate

Upon receiving the resolved (combined) appraisal, the software program that will decide first comes to a preliminary pass/fail decision for the proposal that was appraised.

If the preliminary decision is “fail”, that is the final decision.

If the preliminary decision is “pass”, and if no objections to the proposal have been registered, then “pass” becomes the final decision.

But if objections to the proposal have been registered, then the “pass” becomes “wait”, and the software waits for all of the objection recursions to play out.

If any objection to the proposal succeeds, then the “wait” becomes “fail”.

Otherwise (at the point that all of the objections to the proposal have failed), the “wait” becomes “pass”.

— Side-Channel Tracks

When a new proposal is submitted, notifications go out to all members who have expressed a wish to receive it.

(Members can set up software “proposal magnets” that will determine which sorts of notifications they will receive and which they will not, by comparing the criteria in the magnet to the properties in the proposal profile. Setting up this notification system through successfully proposing its features and code to Blinap is another core part of initializing the Blinap system.)

Within interested communities, notifications of relevant new proposals may be “breaking news” events. It will be a simple matter to set up side-channels that enable informal contact among interested parties regarding the new proposal.

(All notifications received from the Blinap system will be immediately and meaningfully "actionable" by all recipients. This is in contrast to the news reports we are offered in our existing society. When we are informed (for example) that a container ship has knocked down a bridge in Baltimore, there is nothing that the vast majority of recipients can meaningfully do in response to having received that information. The Blinap system does not waste the focus of the population in that way.)

Most of the “bridging” sort of work and debating and such will probably occur within those interested communities through those informal channels.

— Proposing Team Track

In the case where a proposal is submitted, and objections to it are submitted in response, and the objections successfully pass (which fails the original proposal), often the most effective and efficient way to come up with a new proposal that will not trigger those objections will be for the proposer and objectors to form themselves into a team, which will then come up with that new proposal.

Forming that team will put all the right people in the same room together and assures that the new proposal will be acceptable to both the original proposer and the objectors.

And also, after all of the informal debate and collaboration within the team has reached conclusion, that conclusion will need to be successfully proposed to Blinap in order to become effective. (There are no smoke-filled rooms in the Blinap system whose occupants are empowered to directly make public matter decisions privately, behind closed doors.)

Where Do Proposal Filters Come From?

The purpose of the “anybody can object” track is to enable objecting to a proposal that the objecting team thinks should have failed on the appraisal track.

Thus, whenever a one-off objection to a particular proposal succeeds, some team should sit down and do the work of formulating a proposal filter that “generalizes” the one-off objection.

If the proposal-of-filter succeeds (and if the filter is well constructed), no one will ever need to make that particular sort of one-off objection again: the appraisal track will get it right the first time.

Over time, as more and more successful objections are turned into successfully proposed proposal filters, there will be progressively less need for anyone to propose one-off objections.

The work of initializing Blinap will include formulating (through an intersubjective, dialogical process) the foundational proposal filters that will operationally define what is not acceptable to the community that performs the initialization, across all proposal types.