How to build a map of all problems

Some Basic Definitions and Thoughts About the Architecture of the matters.global, mapsmap and mapsDAO platform

Building a map of problems, milestones and goals in the world is a big undertaking. A few of us have decided to give it a try and so we have formed the mapsDAO. Together with matters.global initiative of the Sonophilia Foundation, the Foresight Institute, Planetary Holdings, as well as the Ocean Protocol and Protocol Labs, we are building a community to develop a protocol and applications to create a map of all problems.

Launching the mapsDAO is the continuation of our mapsmap challenge in which we asked teams to produce a version 1 of a software to create and navigate problem maps (winner: https://devpost.com/software/constellapedia). The challenge was initiated by the organizations mentioned above and you can read more about the history of the idea in one of my next blog posts.

In this article I want to talk a bit more about the actual architecture of the protocol layer and the problems we need to overcome in building the protocol and applications. I am currently writing a more detailed whitepaper, which will be ready soon.

I want to thank my colleagues at matters.global, Sonophilia Foundation and mapsDAO for discussing these ideas over the last five years. In particular I want to thank Trent McConaghy, Seda Röder, Andy Zmolek, JP Doomernik, Allison Duettmann, Eric Anderson, Amir Banifatemi and many more!

Protocol, Applications and Problem Definitions

1. The basic idea is that there is a protocol layer in which problems are defined and an applications layer that provides the interaction with the problem data.
2. While the protocol defines the way in which problems are stated, the connections between problems emerge from their specific properties (more on this below).
3. Problems are defined as lists of sets of conditions that need to evaluate to true so that the problem can be considered solved. In other words: “These are the things that need to be true so that the problem can be considered solved.” (More on the types of conditions below)
4. This basic mechanism provides for two fundamental characteristics of our platform:
   1. Problems can be linked to one another via conditions (condition a of problem x = problem y needs to be solved first).
   2. As far as conditions are computable, problems can be related to another and evaluated as part of algorithms and computations.
5. Goals and problems are really the same thing. It is possible to transform a goal expression into a problem expression. For instance, the goal expression “humanity needs to fix the climate crisis” can be expressed as “humanity hasn’t fixed the climate crisis yet”.
6. This transformation makes it possible to turn a set of goals or desires into a set of problems, which, when solved, will result in goals being reached. Whereas a goal describes a specific state that hasn’t been reached, a problem describes a state that should cease to exist. 
7. Both goals and problems have binary states. For goals these are “reached” and “not reached”. For problems they are “solved” and “not solved”. The default state is in both cases the negative form, i.e. “not reached” or “not solved.” 
8. The underlying desired state of goals and problems can be expressed as sets of conditions that make the desired state concrete. They describe the relations to other states as well as to the environment as a whole. 

Conditions, Relations and Similarity

9. Conditions are statements that can be evaluated to be either “true” or “false”. For instance, a condition for the problem “humanity has not fixed the climate crisis yet” could be that the rate of global warming equals zero. Typically, each problem will contain multiple conditions, often of different types.
10. Conditions can reference other problems, for example a condition might be that another problem is solved first (more on the relatedness of problems below). In this case, the problems are connected.
11. The state of a problem is unsolved unless all of its conditions evaluate to true.
12. The state of a problem can become “obsolete”.
13. It follows that a problem is solved only if all connected problems are solved as well. 
14. The set of connected problems forms a problem sphere.
15. The set of conditions of such a problem sphere forms a conditions space.
16. Similarity between problems can be computed via the distance between their condition sets. If two sets of conditions are identical, the problems are identical. The greater the distance between sets of conditions, the smaller the similarity between problems.
17. Similar problems form a problem cluster.
18. There are several types of conditions that can be used in defining problems. While their scope is wide, they all have one thing in common: conditions must evaluate to true or false.
    1. References to other problem states, i.e. “this other problem needs to be solved first.”
    2. Token Curated Registries (TCR):
       1. List of potential solutions needs to exist
       2. List of verified solutions needs to exist
       3. Membership in a linked TCR is mandatory
       4. Membership in a linked TCR is forbidden
    3. Oracle value needs to be a specific value or evaluate to true given a certain function.
    4. Vote of stakeholders or specified experts or public
    5. Amount of staked assets should be at least a certain threshold
    6. (Other types of conditions can be thought of of course)
19. There are several kinds of relations between problems:
    1. Problems are related via their linked pairs of conditions and problem states. This is a consequential relationship. Problem x needs to be solved before problem y can be solved.
    2. Problems are related via their solutions. Problem x can be solved with solutions that work for problem y. This is an inductive relationship.
    3. Problems are related via their problem cluster, i.e. conditions between problems are similar but not identical.

Solutions

20. In day-to-day language solutions and problems are often conflated: “If only I could do x, my problem would go away.” In more rigorous terms, solutions are actions, theoretical models, algorithms etc. that result in problems disappearing.
21. Solutions are reproducible steps that, once taken, result in positive impact, so that the problem conditions evaluate to true and the problem can be considered solved.
22. Solutions belong to specific problems. They might be applicable to more than one problem.
23. There might be more than one solution for any given problem.
24. Some solutions may only affect a subset of a given problem’s conditions. These are partial solutions.
25. A solution might work in one context, but not in all contexts. This is a sign that the problem being solved is actually two similar problems rather than one.
26. The Problem-Solution Matrix displays some interesting properties of the subsets of known-unkown pairs:

27. Thus the protocol distinguishes four types of problems:
    1. Problems that are known that have known solutions.
    2. Problems that are known that have no known solutions.
    3. Problems that are not known yet but to which a solutions is known.
    4. Problems that are not known yet but to which a solutions is not known.

Next Steps

1. Creative incentive system
2. Create smart contracts for protocol layer
3. Integrate and further develop ideas from mapsmap challenge submissions
4. Create problem sets via stakeholder groups of matters.global, Sonophilia Foundation, Foresight Institute etc.

If you are interested in our work, join the mapsDAO discord server here.