Software Architecture For A New Economic System

(A plausible-idea / engineering-fiction)

Harrison Ainsworth

http://www.hxa.name/
hxa7241+articles (ατ) googlemail (dοτ) com

2013-02-03

Introduction

To design an economic system one must capture the basics. They are not money/markets/exchange. They are: what is wanted, and what is available. The essence of this architecture is to discretise those, and assemble them into a parallel computation. The result is market-like in being distributed/decentralised, but does not involve trade in the normal sense. It is about measurement and search of a changing network. And this is intended and outlined for current information technology, with a little ambitiousness.

This is a software architecture – a rough, high-level description – for a general economic system: an informational structure/means for organising cooperation. At this level it is as much a way of beginning to use software ideas to think more clearly about the problem as it is a plan of a solution. It delineates the main technical and usable forms, and crystallises the subject activity toward a unified software artefact. (Or if you think this is all silly, just consider it a kind of ‘engineering fiction’.)

The psychological aspect of economics is not considered (nor is the physical); this is only about information/computation structure. Addition of those other aspects is not prevented, but separating them off helps to clarify the informational features and limits. (But is economics not inseparably psychological? Is music not inseparably emotional? But to build an audio codec you separate out the logical, the mathematical/computational structure. The intent is the same here.)

2000 words (15 minutes)

Contents

Architecture

Comment

Architecture

Signals

What is the key basic data structure, or data object, here? (This is a good way to start because a data structure/object is the most abstract, most broad, way to try to capture the problem and solution.)

It is: Offers and Requests. These are the same structure but with a flag to indicate which. They are effectively a kind of ‘description’ of Goods, including particularly a space-time location(/region).

Why these? They express the most general basic formulation of economic concern: supply and demand. Various Goods are both available and wanted to various degrees, and an economic system must distribute them optimally. We could call Offers and Requestsecoms’: they are EConomic atOMs. They are the fundamental distinctive elements on which the system is built.

Offers and Requests discretise the ‘occurrence’ of supply and demand: they allow supply and demand to be handled as discrete (hence computationally amenable) events.

And since Offers and Requests plug together – offers can fit requests and requests fit offers – they can form a completely connected network. This then implies that anyone's or anything's Offers and Requests are not endpoints: each thing's offers are dependent on their requests, and vice-versa, as will be seen later.

Supplement

Not just people, but things propose Offers and Requests. A robot car can Offer a journey from Woodford Green to South Woodford, and might also Request a replacement tyre.

Goods

The second basic data object is Goods. These are references or ‘descriptions’ of resources, services, activities – anything that can be subject to Offers and Requests.

For the scope of this design they are wholly abstract: all that is needed is to be able to distinguish different Goods. This is enough for them to discretise the ‘kinds’ of supply and demand: so supply and demand can be about different kinds of things.

Though they are abstract the network of Offers and Requests can give them a constructive sense. If a Good has both Offers and Requests, its Offers are dependent on its Requests. For example a final delivered thing depends on a boxed-thing and parcel-delivery; and that boxed-thing depends on a thing and a box.

The way that Offers, Requests, and Goods can be combined answers the second basic question: what is the overall algorithmic intent here? To enable cooperation – to split up and coordinate work across a group. The economy becomes a parallel functional computation, described by the dependencies between sub-parts.

Supplement

The content of Offers and Requests depends in the end on the actual features of Goods: one can request an LED light only because there are such lights. So there is a whole world of known/findable information that the economic system uses but is not the job of this architecture to define.

Measures

The basic implementational data object is Currents. This is a measure of the simplest network relations of Offers, Requests, and Goods. From Currents can be built other more important Measures.

Offers successfully delivered to Requests add to Current between the two, distinguished by different kinds of Goods involved.

Currents discretise the recent ‘state’ of supply and demand: they express the strength/width of flow between the two in one place in the network. This is most like the normal behaviour of money – but Currents are the basis for deliberate and more general and discerning measurement.

Easiest of the secondary Measures that could be built from Currents might be something like reputation.

If a Good (including persons) delivers on an Offer, that increases its related supply-reputation. And if a Good takes delivery of a Request, that decreases its related demand-reputation. If you only request a kind of thing rarely, you decrease your related demand-reputation less than if you request frequently. (And if your Requests feed into your Offers, your reputation will balance out.)

Currents and other Measures built from it are implemented by: judgement of Offers/Requests according to kind (etc.), and somewhere to store and accumulate. That is, they are functions on the (ever-changing) network to yield data of Measures of it, over time. (Currents and other Measures are a bit like PageRank.)

Supplement

Certain measures might be certified and mandated globally. E.g. some things Requested (or Offered) are considered more necessities than others – so everyone is more ensured of supply.

Matching

The main algorithmic structure is Matching. It does the economic allocation as a form of search, using Offers, Requests, Goods, and most particularly Currents/Measures (which underlie the main indexes).

The primary ingredients, and drivers, of the search are Offers and Requests, since joining each to the other is the ultimate aim; and they work as an extended kind of search-term.

The nature of Offers and Requests means queries are more general and complex. Because they can have various time properties, they can also be ongoing announcements/notices or standing queries. And because they are mutually both question and answer to each other, they can form interactive responses and counter-queries.

Currents/Measures can provide a range of knowledge to the search, and the foundation of Matching is to build that into its indexing (and pre-calculation). But allocation/connection of Requests to Offers can, and probably should, also be done by two other means: human judgement/choice, and randomness. The job of Matching's usability structure is to help that.

The main engineering challenge is making this very large and very distributed. It does seem possible, but only on the edge of possibility to do it well.

Supplement

Perhaps parts of the matching algorithm handling Currents/Measures must be cryptographically secured/signed: to ensure there is only one kind of measure (related to ensuring a normal money supply is limited). Unless there is a way to automatically converge: the measurement calculation is distributed, and averaged somehow . . .

Comment

Analysis

There are four parts: three kinds of data and one kind of algorithm:

  • Signals – (requests, offers) events referring to goods;
  • Goods – identifiers of things, activities, people;
  • Measures – measures of the network over time;
  • Matching – of requests and offers, by search, using currents/measures.

The system can be understood first as discretising the two basic concerns – supply and demand – in the three dimensions of the data:

  • discretising the occurrence of supply and demand – Signals,
  • discretising the kinds of supply and demand – Goods,
  • discretising the state of supply and demand – Currents/Measures.

And, secondly, the operation, the algorithm, of the system (hence economy) is to link supply and demand together in different ways as circumstances change, using certain information about the network up to now.

How does the established money/market system fit with that perspective? The current economic system can be seen as:

  • discretising occurrence by property transfer rules and implicitly in persons,
  • discretising kinds with informal knowledge, not ‘machine-readably’ mostly,
  • discretising state by money, the most digital aspect.

And the operation of linking supply and demand is also done informally mostly, and so more information-poorly.

Notable features

There is no money, no loans, no repayment, and no symmetrical/reciprocal exchange generally. Economic interaction is expressed as it really is: asymmetrically. If you want something you just Request the thing and maybe get it (or something like it). Similarly with Offers: you give and maybe it is taken.

It could be seen as a software-oriented formalisation and expansion of Graeber's idea of everyday communism: it encodes and implements “From each according to their ability, to each according to their need” – which is perhaps the most general expression of the economic problem and solution.

No money, no-one gets rich:
People get what they need/want to do useful things – richness is economic waste.
No debt, no repayment:
Loans disappear: replaceable by Requests – repayment, in sending resources back again to where they were plentiful, is / would be dysfunctional allocation.
No symmetrical/reciprocal/exchange:
Reciprocal exchange does not make sense economically (or morally).
No pervasive externalities:
Using more information allows seamless internalisation of externalities: there is no ‘external’ really: whatever should be considered in allocating can be, up to tech limits.
Still decentralised:
At least largely so, and where it makes sense to be.
Still uses property:
But perhaps enables more flexibilities of.

Most other thinking about economic systems is about money, and seems never quite easy to understand, it seems perpetually somewhat obscure and uncertain. Because money itself is confusing and obscuring: what does it do? does it not ‘measure’ and help ‘exchange’ of ‘value’? what is ‘value’? The whole approach leads to the wrong questions – it becomes a Wittgensteinian fly-bottle.

But Offers and Requests are simple: they are about what is wanted and what is available. There is nothing mysterious. Anyone can immediately understand, and see that is what an economic system is essentially about.

By focusing on the real essentials and being built around using more information than the current money/market system this architecture should have the potential to address the economic problem more generally and precisely, while still being practicable for modern technology.

Motivation and morality

Will this system sufficiently motivate people to produce? This is a likely question. The current market system obviously substantially has and sets a demanding comparison. But answering leads to questions of morality and what the aim here is anyway.

The current market system is claimed to drive progress especially much. To do so it must be that people work more than they otherwise would according to their deliberate wishes and to cover their basic needs. And if this effect is attributable to the market system (rather than deliberate wish), it must be concluded that it forces people to work more.

That seems immediately morally questionable (from a JS Mill view). Even though it is cooperatively good – it, by our collective action, produces what we do all want – working extra hard is something people have not really genuinely agreed to.

The proper task of an economic system (in the strict informational/computational sense used by this article) is not to integrate particular biases or intents of what might be wanted or not. Rather it is to be abstract and to allow any wants to be expressed and handled. The system should ideally be only the intermediary: it facilitates any connection of desires and availability without prejudice. The presented architecture aims to do that.

(But anyway the question is really one of effectiveness, and in the end the answer must be empirical: build it and see.)

Metadata

(TXON)

DC:`
   title:`Software Architecture For A New Economic System`
   creator:`Harrison Ainsworth`

   date:`2013-02-03`

   description:`A rough, high-level software description for a general economic system: an informational structure/means for organising cooperation. (Or an 'engineering fiction'.)`
   subject:`economics, information, computation, software, engineering-fiction`

   language:`en-GB`
   type:`article`
   relation:`http://www.hxa.name/`
   identifier:`http://www.hxa.name/articles/content/economic-system-software-architecture_hxa7241_2013.html`
   rights:`Creative Commons BY-SA 3.0 License`
`