This is a demo of an application very much in progress for the Carbon Farm Network in the New York Hudson Valley. The CFN is a group of independent designers who want to source fibers from farms that are implementing carbon beneficial practices on their lands. They are organized as a purchasing cooperative, which coordinates their supply chain network together, to produce yarns for their individual final products. The larger network also includes farmers, fiber scourers, spinners, knitters, and shippers.

This demo shows what has been accomplished with the funding raised so far.

In terms of technology, this is being implemented using Holochain, which is a serverless open source peer-to-peer app framework. It also uses an existing software layer called hREA, for holochain-resources-events-agents, which implements the Valueflows standard vocabulary and model for economic networks working towards a more fair and sustainable future. All of that is very generic, so this application is designed specifically for the Carbon Farm Network, while keeping in mind usability by other networks that follow roughly the same supply chain coordination process.

First we'll briefly show how the app can be set up and configured for the specific network. As we said, the app is intended to be highly configurable for different kinds of supply chain networks, including different kinds of textiles, but also any supply chain network that has fairly standard process flow.

First, a set of resource specifications is set up. (show list plus click into one) Those include all material items and services that are part of the supply chain. Here you see… The network would also set up units of measure from a standard list, but that's not done yet.

If a network wanted, this could also include types of work, equipment, or so-called externalities.

Here they have set up all the agents (which can be people or organizations) involved in the network. (show list plus click into one) They could also include ecological agents such as rivers or forests, if they wanted to track impact on the ecosystem. Here again, the network can define their own roles for agents.

Here you see process specifications. These will be used in recipes, and on the planning page. Recipes will define the standard steps used in the supply chain, along with inputs and outputs at each stage of production. That portion of the app isn't complete yet, so we are using dummy data tailored for the Carbon Farm Network right now. When complete, each network will be able to define their own processes and supply chain recipes.

Also we can create what we call "facets" for agents and for resource specifications, for later use filtering and searching. Here's the one we set up for the demo. (show)

So that's the setup. There will also be other miscellaneous configuration, such as location and scope of the map, icons used, network logo, etc. Basically when this is complete, it will be entirely configurable for different networks. All of this will be done basically once per network, with tweaking as the network itself changes.

OK, let's get on with the real network coordination, starting with planning. The Carbon Farm Network plans and operates for a whole season at once. The software will support having multiple separate plans, as needed.

First, all the suppliers inform the network what they can offer for the season. This is entered by the network administrators now, or could be eventually by the suppliers themselves. Here are the offers that have been entered. (show list, plus click into one).

Also, the designers have entered their requests for yarn for their specific products for the season. (show list plus click into one).

So now we have a starting version of possible inputs and outputs for the whole season, and are ready to start planning.

Before looking at the planning process, here's a look at the map of the network. All the organizations involved are on the map. (bring up one) For any organization, you can see their information and current offers. There is also search capability, right now by name, but eventually by any useful attribute, like color or fiber type or carbon beneficial certification.

OK, now it is the beginning of the season and we are ready to start a new plan. The plan page brings up the offers and requests we are working with. First we want to create a first draft plan based on the recipes for this network. To do that, we can start with an assumption that all requests will be satisfied. (click on the button). You can see that first a column is created for what requests the network plans to satisfy. And a plan has been created from the recipes, to feed satisfying the requests, which are commitments, one step farther than the requests. (scroll around) The columns are process specifications, and the order is based on the recipes found when the plan is created. The white shapes are commitments, which are planned economic events, inputs and outputs of the processes, which are not represented specifically on the user interface, but are separated in the column.

The quantities are created using a demand driven algorithm, starting with the requests to satisfy, and working backwards, using formulas embedded in the recipes. For each input for a stage, it looks for outputs from another recipe that could feed into that input, based on the resource specification.

For example, here is the spinning stage of the plan. It includes a process for each type of yarn being created, with its inputs and outputs. Each process is created using a recipe. The recipe calls for half brown alpaca and half white sheep wool inputs, and the spinning process creates brown yarn, losing about 10 percent of the weight in the process. The output will satisfy the total requests for that yarn. A service output is also created.

The algorithm works its way backwards in this manner until it can't find any more recipes. So you can see that it shows everything that is needed to satisfy this season's requests, back to the farms.

Recipes are primarily for a production plan for the supply chain, but they can also include exchange recipes when an input or service will be exchanged for another resource, in this case money, although it could be anything. In this plan, those exchanges show up as cost. And here is a total cost, which will determine the total cost to the designers, and so becomes an important part of the plan to juggle.

Before the initial plan is saved, you can play with the satisfy requests column, and it will recalculate backwards. Say I want to add some yarn for making samples, I can do that here. (do it) Also, I can add, change or delete any request.

Looking at the beginning, you can see that the offers don't exactly match the demand. If there is not enough, the network can look for another source, for example. This is the only alert we have programmed thus far, but there will be others that will be helpful, as the plan and the season progresses.

Another feature we want to add is capability to also do some supply-driven calculations, column by column going forward, starting with the offers. For example, they might want to pick up all the fiber they can get, and store some in inventory for next season, at any stage.

Once the basic plan is in place, it is saved. (do it)

After it is saved the first time, it will not do any automatic demand-driven recalculation, and is opened up for adding, changing, deleting any of the individual inputs or outputs. (do an add and change on first column)

We expect to learn a lot more, as the CFN starts to use it this season.

One small start to the next round of work is the ability to record actual economic events that fulfill the commitments on the plan. (show one) Also you can mark the commitment complete, or leave it incomplete for further events. (show) Note that the actual quantities replace the planned quantities. Through the color coding, the network can follow the progress through the season, and be alerted to problems.

Also this is where the planned re-calculations from the left will be handy. For example, after a stage of the supply chain is done, you could re-schedule forward from what actually happened, and see an updated picture of how the rest of the season could play out, and take any steps needed to change the trajectory.

We think this page will be used to coordinate the supply chain through the season. There will be other features needed for non-production work.

This includes adding interfaces to view the recorded events; record events that occur outside the production processes, like payments, fees, donations. These will constitute a complete record of the accounting, so there should be a standard set of accounting reports that will use all the recorded events.

Another feature will be inventory management, a byproduct of recording economic events. Existing inventory from the previous season could show up as part of the planning page.

There is also a long list of smaller improvements needed, and we'll discover more through usage.

(summary… ? we're currently fundraising for the remaining work?)