Purposefully place meaningful signs into the environment,
for others to pick up and add to their imagination,
and possibly change their behavior because of it.
Take a traffic light as an example:🚦
We placed this thing into the environment so human drivers see it, interpret meaning into it, and adapt their behavior accordingly.
If the light is red, stop. If the light is green go.
So this meaningful traffic light practically orchestrated coordination across multiple individuals, while each individual follows their own decision process.
So it seems we already are collectively intelligent. But not in a digital-native manner.
This documents outlines how digital-native collective intelligence could be structured, and attempts to formalize and implement the necessary protocol to live it out.
What are we even building? A new mental framework to do social coordination in, p 8000 lus the technical infrastructure that supports its usage.
Using it must coordinate towards a future reality that humans like. While the humans themselves are deciding on what they like and don't like.
The system shall allow everybody to express their world views and values in a non-discriminatory manner, while having an optimization process that does not inherently prioritize one human over another by default. Prioritization of humans over other humans must be an emerging property from human values and the current state of reality.
The act of valuing other peoples values creates morals. The act of valuing other peoples actions creates
A key fact to deal with is that whatever social contract humans declare to enter, their decisions are never controlled directly. Social contracts only ever influence the behavior of humans indirectly, usually be modelling sanctions and incentives that are conditioned on whether people follow through with their actions as declared in the contract or not.
Furthermore, aligning on a shared virtual state may be part of the solution, but it is not the end goal. Really it is about shaping reality the way we like it, where pretty much all preceived human value is found in reality and not on some shared ledger. The bits in the network are just the means to get to a better reality.
Note: Adequate coordination mechanisms already exist, but not formalized so they can easily be managed in hypertext
This system is not meant to be a replacement for existing social contracts, but rather a supplement to them. It serves as a common framework to define new and existing coordination mechanisms in, and offers an accounting infrastructure to operate organizations at a global scale.
This document defines concepts one after another, gradually building up to both a technical and social architecture of collective intelligence.
After the architecture is defined, we further lay out the roadmap of getting humanity to actually use it as the default way of facilitating social coordination.
First, consider the sensory-motor cycle:
graph LR
A["🌍 Reality"] -->|observe| B["👀 Percepts"]
B -->|interpret| C["🧠 Imagination"]
C -->|decide| D["👋 Intervention"]
D -->|act| A
This diagram represents the sensory-motor cycle in a clear and concise manner using emojis to illustrate the different components. The flow of information is indicated by the arrows between each component, with the cycle starting and ending with the external environment or 🌍 Reality. Here's a breakdown of each component:
- 🌍 Reality: represents the external environment, which provides the sensory inputs that drive the sensory-motor cycle.
- 👀 Percepts: represents the perception of sensory inputs, which are processed by the brain to create percepts.
- 🧠 Imagination: represents the cognitive processing of percepts, which leads to the formation of mental representations and imagination.
- 👋 Intervention: represents the motor output or interventions generated based on the cognitive processing of percepts and imagination.
- The arrows between each component represent the flow of information, starting with the observation of sensory inputs, followed by their interpretation and cognitive processing, leading to the generation of motor output and ultimately resulting in a change in the external environment.
In case you are a human reader, you may have noticed that you operate within a sensory-motor cycle yourself. You have senses like eyes and ears to observe the world around you, a brain to interpret and process the information you receive, and a body to act upon your thoughts and feelings, ultimately shaping the world around you.
And you already have an optimization goal: Interpreting percepts in a way that helps you to decide on actions that shape the world around you in a way that leads to more preceived value in future observations.
Here a version of the sensory-motor diagram adapted to machines:
graph LR
A["📥"] -->|receive| B["🖹 Incoming Message"]
B -->|interpret| C["🌐 Scene"]
C -->|decide| D["🦾 Intervention"]
D -->|express| E["🖹 Outgoing Message"]
E -->|send| F["📤"]
This version of the sensory-motor diagram adapted to machines represents a simplified model of how a computer system receives and processes messages from other computers through network protocols.
- 📥: represents the source of received messages from other computers, communicated via a networking protocol.
- 🖹 Incoming Message: represents the the application-specific part of the message received, as defined by the networking protocol used.
- 🌐 Scene: represents the abstract representation of what was expressed in the messages, resulting in a virtual representation of the context or situation.
- 🦾 Intervention: represents the decision of the computer system, based on user-defined rules that map the abstract scene to a decision about what to do.
- 🖹 Outgoing Message: represents the message that executes the intervention that has been decided on if sent.
- 📤: represents the destination of the newly built message which should pick it up, intertret, and have the expected causal effect.
Next up, we will create software modules that implement all parts of this sensory-motor cycle.
Each module comes with interface types used by semantic engineers to define domain-specific logic in.
Furthermore, each module can be hosted on a computer system, with the modules behavior being triggered by incoming messages. It may produce persistet data structures and emits messages to be routed to other module instances.
The module Observer Group is responsible for observing the world and emitting according observations.
Observers define how new information is sourced from external systems. Implementations maintain the required network connections with external computer systems.
Observers are implemented via Sdk.IObserver<'Percept>, where 'Percept is a domain-specific type that represents the newly observed information.
[<IsReadOnly; Struct>]
type Observation<'Percept> = {
Percepts: 'Percept array
}
type IObserver<'Percept> =
abstract member Observations : IAsyncEnumerable<Observation<'Percept>>An Observation<'Percept> represents an atomic appearance of sensory information. Atomic meaning that the observation appeared at a singular instant, the same point in time.
It carries one or more Percepts, which is a typed representation of the newly observed information.
On initialization, the modules takes one or more Sdk.IObserver<'Percept>-instances of possibly different 'Percepts, and starts pulling Sdk.Observation<'Percept> from all of them via member Observations and processes them sequentially in the order they appear:
- Capture current timestamp as of the Runtime Clock
- Serialize observation into
DataModel.CapturedObservation - Append new node the this modules Observation Sequence:
DataModel.ObservationSessionSequenceHead - Emit message
NewObservationlinking the newestDataModel.ObservationSessionSequenceHead.
This module produces a linked list DataModel.ObservationSequenceHead containing all observations made during the runtime of the module. Every time a new observation is captured, a new node is added to the list, linking to the previous node.
type CapturedObservation = {
At: DateTime
PerceptType: System.Type
Observation: ContentId // Sdk.Observation<'Percept>
}
type ObservationSequenceHead =
| Beginning
| Happening of Node:ObservationSequenceNode
and ObservationSequenceNode = {
Previous: ContentId<ObservationSequenceHead>
Observation: ContentId<CapturedObservation>
}type NewObservation = {
LatestObservations: ContentId<ObservationSequenceHead>
}The Observation Pool is responsible for aggregating observations from multiple Observer Groups which are potentially distributed in space and operated by different people.
By aggregating observations, it converges to an ordered sequence of observations which is called a Perspective Sequence.
This module does not have a domain interface. No domain-specific logic is required for its operations.
This module maintains a reference to an DataModel.ObservationPool with the most unique DataModel.CapturedObservations included.
It is merging observations from multiples observation groups distributed thrughout space into a temporally ordered sequence.
A: Whenever a message NewObservation is received:
- Received
DataModel.CapturedObservationsis merged into the latestDataModel.ObservationPool. - If
DataModel.ObservationPoolchanged, emit messageNewPerspectivelinking the newest Observation Pool.
B: Whenever a message NewPerspective is received:
- Received
DataModel.ObservationPoolis merged into the latestDataModel.ObservationPool. - If
DataModel.ObservationPoolchanged, emit messageNewPerspectivelinking the newest Observation Pool.
First, there is a linked list Perspective Sequence (DataModel.PerspectiveSequenceHead) that specifies a temporal order among observations originating from multiple Observation Sequences (DataModel.ObservationSequenceHead).
Second, there is an Observation Pool (DataModel.ObservationPool) that is used to reference all available observations made within the system instance. It is a CRDT (conflict-free replicated data type) which makes it easy to gossip around and merge with other versions of the same data structure.
type PerspectiveSequenceHead =
| Beginning
| Happening of Node:PerspectiveSequenceNode
and PerspectiveSequenceNode = {
Previous: ContentId<PerspectiveSequenceHead>
LatestObservation: ContentId<ObservationSequenceHead>
}
type ObservationPool = {
AggregatePerspective: ContentId<PerspectiveSequenceHead>
DroppedPerspectives: ContentId<PerspectiveSequenceHead> Set
}In the current implementation, the Runtime Clock just captures the host computers clock and trust it to be accurate. Perspective Sequences are then re-ordered according to those timestamps.
In a decentralized system, such a re-ordering would allow an attacker to insert an observation at an arbitrary point in time.
To prevent this, the system implements a common clock that is not controlled by any single party. This is achieved by using a Merkle Clock, as other CRDTs already proven this to work.
- Protocol Labs put out a paper "Merkle-CRDTs Merkle-DAGs meet CRDTs"
- Pail is a mutable key-value store that orders mutations via a Merkle Clock. Alan Shaw even created a Merkle Clock as a Service.
- The Convex Protocol uses a CRDT for convergent consensus, practically being a Merkle Clock.
Executes a user-defined strategy on every new piece of information that arrives, i.e. on every new observation. Those new observations either come from own Observer Groups or from Observation Pool gossip.
On a technical level, a Strategy is a pure function that maps a given situation to a Decision about what to do in that moment.
type ActionInitiation = {
Action: obj
Type: System.Type
}
type Decision =
| Inaction
| Initiate of Initiatives:ActionInitiation array
type Strategy =
Reflection -> Scene -> DecisionThat computation takes as input:
- a given
Scenethat represents reality - a
Reflectionof the strategies past decisions
with Scene being accessed via Sdk.ISceneQueries and Reflection being accessed via Sdk.IReflectionQueries, where both interfaces represent an abstraction of the underlying data structures.
Whenever a message NewPerspective is received:
- It is merged with the latest observation pool from memory.
- If the merge produced a new perspective:
- Run the Strategy on all newly sequenced observations
- Emit message
NewDecisionfor every non-inaction-decision, linking the newest decision index CRDT.
type ActionInitiation = {
ActionType: System.Type
ActionCid: ContentId // CID of type this.ActionType
}
type ActionSet = {
Initiations: ActionInitiation array
}
type DecisionSequenceHead =
| Start
| Initiative of Node:DecisionSequenceNode
and DecisionSequenceNode = {
Previous: ContentId<DecisionSequenceHead>
ActionSet: ContentId<ActionSet>
}Referencing the whole Decision Sequence makes NewDecision-messages idempotent and more tolerant to network faults, where each distinct Decision has a uniqe content address and later messages carry all decisions of possibly dropped messages.
type NewDecision = {
LatestDecision: ContentId<DecisionSequenceHead>
}Some decisions are executed in the virtual only. For example, a decision to interact with a certain smart contract is executed by signing and broadcasting the desirable transaction to a blockchain network. This module is responsible for executing such actions.
Brokers handle all communication with external systems to execute actions that expectedly result in a desired effect.
Brokers are implemented via Sdk.IBroker<'Action>:
type IBroker<'Action> =
abstract member Execute : 'Action -> TaskAny given IBroker<'Action>-instance can be instructed to execute its action by calling Execute and passing an instance of its 'Action-type. The Broker then sends according network IO to the related external computer networks, essentially executing the requested Action.
The module listens to NewDecision messages. Each such message references an Action Set (DataModel.ActionSet), which contains one or more Action Initiations (DataModel.ActionInitiation).
For each received Action Initiation, execute the following procedure:
- Capture current timestamp as of the Runtime Clock as execution start timestamp.
- Route
'Action-instance to matchingIBroker<'Action>and wait for completion. - Build new node in this instantiations Execution Sequence:
DataModel.ExecutionSequenceHead. - Emit message
ActionExecutedlinking the newest Execution Sequence.
type ActionExecutionTrace =
| Success of trace: byte[] option
| Error of ``exception``: string option
type ActionExecutionResult = {
Trace: ActionExecutionTrace
InitiationTimestamp: DateTime
CompletionTimestamp: DateTime
}
type ExecutionSequenceHead =
| Start
| Execution of Node:ExecutionSequenceNode
and ExecutionSequenceNode = {
Previous: ContentId<ExecutionSequenceHead>
Action: ActionInitiation
}type ActionExecuted = {
LatestActionExecution: ContentId<ExecutionSequenceHead>
}- Observation Pool
- Action Execution Traces
- Declared Strategy Merge
- Common Merkle Clock
In addition to the executable strategies executed as part of the users sensory-motor cycle, a declared strategy is shared in the public network. That declaration is used to coordinate with other subjects in the network.
type ConditionalAction = {
Condition: Scene -> bool
Action: Scene -> Decision
}
type DeclaredStrategy =
DeclaredStrategy of ConditionalAction listIt explicitly represents an ordered list of conditional actions. Practically a big "if-else" statement which is executed top to bottom, with each case returning a Sdk.Decision.
An Ask is an expression of desire that is shared within the network. It is defined as a boolean predicate that depends solely on a Scene.
type Fulfillment = Fulfilled | Unfulfilled
type Ask = Scene -> FulfillmentAn Ask is considered filled if the current moments Scene of the asking user satisfies the predicate.
An Ask is active until its cancellation policy is triggered.
The structure of the declared strategy is chosen so to make it straight forward to communicate changes to other peoples strategy by making a Proposal.
This structure allows to easily construct proposals to change a given strategy. Those proposals define removals of conditional actions from the strategy, and additions of conditional actions to the strategy.
type StrategyProposal = {
Added: ContentId<ConditionalAction> list
Removed: ContentId<ConditionalAction> list
}Given one or more models of the world and the current situation:
- What events could possibly happen in the future, according to the model?
- What events are likely to happen in the future, according to the model?
- How does a given Action change the likelihood of future events, according to the model?
The expected probability distribution is the measure of risk on the economy.
Place bets in prediction markets about future observations.
They bet in terms of world models as defined by Scientists, and bet on characteristics if a future Scene that reflects reality.
Markets are cash-settled, in a scalar unit of value, allowing it to be a hedge for risks.
World models already give out probability distributions. Prediction/Actualization markets add two aspects:
- Liquidity to hedge risks. Useful for coordination.
- Different odds than the world model, indicating that the model may be wrong
If perspectives and values of different humans lead to different ideal actions
non-conflicting = (1) not causaly linked in any relevant way, as determined by all parties involved, or (2) alignment on the same ideal action, as determined by all parties involved (whereas each party might have a different expectation about what future events will happen after executing those actions, but that form of disagreement is fine because there is no conflict about what to do).
Decentralization: Semantically computable & interoperable representation of reference phrases via IEML
Come up and formalize useful models to reason about the world. That includes:
- Idetify useful reference phrases
- Define Interpreters that map Observations to References
- Define simulations for inaction- and action-scenarios.
Design and operate coordination schemes.
Formalize Observers, Percepts, Interpretation, Strategy Templates, Brokers, and Actions.
Actually make people use the Strategy Templates in a way that provides value.
Monitor quality of service, push hot fixes and updates where necessary.
Specify your values, your Minimum Viable Life (MVL), debug your values, place asks, inspect offers, declare strategies, execute actions as commited.
Here is the list of important technologies to implement this system. Make sure to read up on them to see why the system is constructed like it is and why it might work.
- IEML: Information Economy MetaLanguage
- HGTP: Hypergraph Transfer Protocol
- Cuelang
- Merkle Clocks: "Merkle-CRDTs: Merkle-DAGs meet CRDTs"
- CRDTs (Conflict-free replicated data types)
- Pail is a mutable key-value store that orders mutations via a Merkle Clock. Alan Shaw even created a Merkle Clock as a Service.
- The Convex Protocol uses a CRDT for convergent consensus, practically being a Merkle Clock.
- Category Theory
- Algebraic Tolology
- Non-Commutative Geometry (Alain Connes)