Economic Networks

Part 1 introduced the New York Textile Lab (NYTL) and how they might use Valueflows to help coordinate their economic network, which produces clothing from (mostly) woolen fibers. This part will get a lot deeper into how the coordination might work.

Software for economic coordination

A year and a half ago, NYTL selected Holochain as their partner for developing network coordination software.

That software is getting closer but not quite ready for their use. I hope this series of blog posts helps all the participants to identify some of the functions the software will need to handle.

This post started to describe some of the required features. The next post will get into even more detail on the configuration of the software..

The annual cycle

The NYTL uses natural fibers which are grown by animals (mostly sheep and alpacas) to keep them warm in the winter. So they like to get their wool trimmed in the spring before they get too hot. So the farmers, who want the wool for making warm clothing for humans, shear the animals every spring. That starts the yearly cycle for the NYTL.

The first stage of the annual cycle will be a lot more conversational and free-form, everybody talking to everybody else, more like a social network than the later stages with structured messages in structured interactions.

Network map

One of the main features of the software should be a map of the network, showing all of the members, and selections of what is happening in different locations.

The map shown below is an early prototype. Would be good for some of the network members to suggest what what kinds of information they'd like to see on the map, or in popups on map locations.

Network resource flows

Those will happen, and can be depicted, on several levels:
* resource flows that have happened (the past)
* resource flows that are happening now (the present)
* resource flows that are planned (the near future)
* resource flows designs that could be planned (what we call “recipes”).

Here's a repeat from Part 1 showing two different resource flows planned by one designer: to create two products, a hat and a blanket

Recipes and planning

Recipes in this case are not for cooking, they are for planning resource flows to create textile products. The resource flows will need to be planned over and over again, for each textile order, and creating the plans by hand will be tedious work. So let's automate them!

A Recipe starts with
* an end product (for example, a hat),
* and then adds the process to create the hat,
* and then the inputs to that process,
* and the processes to create those inputs,
* and their inputs, etc.

The inputs might include
* textile materials,
* work of various kinds,
* equipment of various kinds,
* and whatever other resources might be needed at each process in the recipe flow.

Planning from recipes

The designers will generally do the planning. When a design gets an order for some products, like 100 hats, they will kick off the recipe software that woll create the plan for producing those 10 hats, including all of the material inputs, the equipment, and the work that needs to be scheduled.

If the required materials can be found in network inventory, they will be allocated to fulfill this order. Likewise if the scope of the plan is internal to one node in the network (as contrasted with planning the whole network at the same time). the people to do the work may be known, and they can be scheduled to perform the processes and given work orders. Required equipment and process locations will be scheduled, with orders to their custodians. Anything that can not be found will go on a todo list for the designer to find and add to the plan.

Planning logic

The planning logic is the same as MRP which is explained in this pattern called Dependent Demand and has been implemented lots of different software.

This diagram from that pattern paper shows the principle behind the pattern:

The order for 100 hats is the independent demand. All other requirements flow from the 100 hats, to fulfill the order.

Sensorica's NRP software. developed by http://mikorizal.org/ , has working code to plan from recipes.

Preview of Part 3:

We'll explain a couple of the configuration features of the upcoming software:
* Type objects, and
* Facets.
We want these features because, while we love the Textile Networks, we also have many other kinds of networks waiting in the wings and we want the software to also work for them (for example, fablabs which will use Valueflows to fabricate and assemble hardware). Plus, the textile networks may evolve and need the same configuration features.