Recipes

[bhaugen]

Recipes could be a big sub-project for ValueFlows.

Here are a couple of discussions with potential collaborators about them.

• In scuttlebutt.
• In GOSH (Gathering for Open Science Hardware) Forum.

GOSH has standardized on DocuBricks and are discussing in this document.

I'm looking into DocuBricks and will start to ask them some questions, which I will report back here.

My questions have to do with the broad range of use cases that I think we need to support in VF, and whether DocuBricks can do that. Those include making open source hardware, which DocuBricks seems to focus on, as well as growing and processing food, and also more general workflows. Regardless, I think we at least want to be able to translate VF Recipes to and from DocuBricks.

In general, this topic is about documenting "how we do something that we do repeatedly", so we don't need to reinvent it all every time. Recipes are also used for planning.

After a long discussion in Sensorica, we ended up calling those Recipes, and I still like that word. That wiki page also explains a little bit about how those kinds of documentation have evolved in the history of manufacturing systems. Workflow systems have had their own parallel evolution, of which I am less familiar, but I think they have evolved similarly into loosely coupled networks.

I have two questions here and now:

• who wants to collaborate on this topic?
• and should it have its own repo in the valueflows github org?

[bhaugen]

This is what I've found about the DocuBricks vocabulary so far:
http://www.docubricks.com/software.jsp

[elf-pavlik]

Thanks @bhaugen I'll try to check all the links you have shared here

and should it have its own repo in the valueflows github org?

👎 It looks like over time we ended up using just this repo for everything and while we were trying to use multiple repos I had impression that it caused caused more extra effort.

[bhaugen]

@elf-pavlik thank for responding. Are you doing anything with recipes in Vientos or elsewhere? I know you are as interested in food as we are....;-)

I'm getting some feedback from DocuBricks, which I will report back here when it becomes something...

[fosterlynn]

👎 It looks like over time we ended up using just this repo for everything and while we were trying to use multiple repos I had impression that it caused caused more extra effort.

I agree, no more repos unless they are implementations, not vocabulary.

[bhaugen]

You're so strict.

But, ok with me...

[bhaugen]

Nanomonkey applies for grant to implement recipes and resource management in scuttlebutt

He says,

It's very much aligned with ValueFlows, in fact I believe it's a component that they have not yet implemented.

One of the things I love about SSB is that @dominictarr got some money from Dfinity and instead of spending it himself, is splitting it up into a series of grants for other people to improve SSB. Nanomonkey is applying for one of those grants.

[bhaugen]

More about recipes and related topics in this article about steps to creatxing successful open hardware

[bhaugen]

I'm taking a category theory class based on the book seven sketches in compositionality .

Chapter 2 is about recipes. And includes a simple and elegant way to graphically represent recipes that is totally compatible with VF.

To simplify even farther, just remove the labels on the connecting lines. This does not include all the lines, but you should be able to get the idea.

[elf-pavlik]

This looks like 5 processes with inputs and outputs. Would you see in VF intermediate resources like (egg yold and egg white) created just to connect them as output of one of those processes and input of the other one? In many cases both would start with quantity 0 and after process end up with quantity 0 and never get incremented again.

[bhaugen]

@elf-pavlik

Would you see in VF intermediate resources like (egg yold and egg white) created just to connect them as output of one of those processes and input of the other one? In many cases both would start with quantity 0 and after process end up with quantity 0 and never get incremented again.

At this stage of learning category theory, I would do that. Likewise I have seen bakeries who keep separated egg components on hand in big containers for multiple uses, so it's not much of a stretch.

The attraction for me (and why I would follow strictly at first) is to learn their rules of composition: what can connect to what, how. How you can nest one network within another and then connect that nested network to yet another. And compute mathematically over the resulting compositions.

However, I am just getting started. When I started with REA, for example, I was a lot less likely to compromise with the rules than Bill McCarthy was...

[elf-pavlik]

I have seen bakeries who keep separated egg components on hand in big containers for multiple uses, so it's not much of a stretch.

Yeah, at the bakery I worked in NYC, they used to order egg yolks in tetra packs and use them to make such pies. I guess general (shared) recipes would need to have variants for how things get composed, one would include separating yolks from whites process and other one would sort of 'delegate' such process and rely on having those two already separated.

Bakery later would have at least 3 options

1. get eggs and separate them
2. get whites and yolks already separated
3. get eggs and 'outsource' separating them, so just get that service

I think option 3) doesn't come as obvious and very likely not very practical when it comes to eggs. It might make more sense when pressing apple juice. The juice pressing provider would never own or sell (exchange) apples or juice itself, only provide pressing service.

How you can nest one network within another and then connect that nested network to yet another. And compute mathematically over the resulting compositions.

Sounds good! Also mentioned above option 3) gives IMO interesting example that composition can involve processes managed by different agents and we can't assume that they get composed only 'within boundaries' of one agent.

[bhaugen]

I designed outsourced manufacturing process at that ERP system I used to work for. Wonder if I can remember anything about it. Basically it's both a set of physical movements and a set of exchanges.

But I wouldn't mess with it until somebody needed it. It was a little messy in practice...

[fosterlynn]

Yeah, at the bakery I worked in NYC

Ah, that might explain why your English is so good, down to all the slang! 😄

interesting example that composition can involve processes managed by different agents and we can't assume that they get composed only 'within boundaries' of one agent.

👍

[bhaugen]

Followup to the pie recipe above:

So the whole recipe above is collapsed into one box, with all the lines coming in representing resources that do not exist in the recipe, but need to come in from outside. And then the unbaked pie and the oven can get together in the "bake pie" process, where the outputs are the baked pie and the oven, because the oven was not consumed in the process.

If you put a schedule following this combined recipe on a timeline, the oven would be occupied during the timespan of the "bake pie" process, and then would be free again for the next oven-using process.

[bhaugen]

@elf-pavlik @fosterlynn another angle on this observation:

interesting example that composition can involve processes managed by different agents and we can't assume that they get composed only 'within boundaries' of one agent.

Here's a much earlier (from 2012, early days of working with Sensorica) set of notes on what are the organizational-governance implications of recipes crossing agent boundaries.

When we discuss recipes in the category class, I hope to be able to get more insight on this set of issues from this other source.

[elf-pavlik]

But if each exchange between value network processes requires explicit agreement between the agents responsible for each process, those explicit agreements will introduce friction and transaction costs into the network.

I think Recipes aim at lowering friction related to planning processes. #266 (Agreement Recipes) can help in similar way with lowering friction related to agreements related to those planned processes.

In Value_network_recipe_design_principles, this was described as an alternation of processes and exchanges:
process1->exchange->process2->exchange->process3->etc.
In more detail, the value network goes:
process1->output value1->exchange->input value1->process2->etc,
where each process can have more than one output and input, forming a network.

I think we managed so far pretty well to keep processes and agreements orthogonal. In current VF events, commitments and intents can relate to processes via inputOf and outputOf. At the same time the same events and commitments which have such relation with processes, can relate to agreements via under. This creates pretty much many-to-many between processes and agreements (so also exchange agreements). Processes and agreements (again including exchange agreements) don't happen as series but in a way we have agreements overlaying the chain of processes, which in my opinion gives much more flexibility and better handling of work and use where we don't have resources (i guess output values in that value network snippet) incremented and/or decremented.

[bhaugen]

@elf-pavlik

Processes and agreements (again including exchange agreements) don't happen as series

The series described in that old Sensorica-oriented document were over-simplified to get an idea across. In real life, they happen as directed graphs, and do not alternate so strictly.

Not sure what you mean by

agreements overlaying the chain of processes

In an economic network, on the observation layer, processes and exchanges can alternate, but usually in directed graphs rather than a series or chain, and the nodes can be all process or all exchanges or some of each.

Same could be true of agreements. A recipe can be a kind of agreement, for that matter: this is how we will do x, y, and z. The Dhen network was pretty much like that.

[elf-pavlik]

In an economic network, on the observation layer, processes and exchanges can alternate, but usually in directed graphs rather than a series or chain, and the nodes can be all process or all exchanges or some of each.

The way we currently have it in VF, I wouldn't say they 'alternate'. You can have one process with events and commitments referencing it using inputOf and outputOf, and the same events and commitments can reference various agreements using under. In the same way events and commitments referencing particular agreement using under can reference various processes using inputOf and outputOf. Since we can have certain set of events and commitments which reference both processes (via inputOf & outputOf) and agreements (via under), we could say that processes and agreements group those events and commitments in particular subsets. I don't really see it as 'alternating' since any event and commitment can reference both - a process and an agreement, so in a way same event or commitment can appear in both subsets, one grouped by process and one by agreement.

[elf-pavlik]

@bhaugen I just dug out this version of a diagram which IMO nicely shows that processes and agreements (including exchanges) happen at the same time and some events and commitments reference both (this diagram still needs arrows between flows (I | C | E) and agreements, just like it has arrows between them and processes.

EDIT: I think the Flow Recipe would not reference both Process Recipe and Agreement Recipe but only one. So only any Flow[Intent | Commitment | Event] can reference both Process and Agreement.

[bhaugen]

@elf-pavlik got a concrete example of what you mean?

I might be missing something. I have seen processes happen without prior agreements, but not very often, and never if there's a prior plan. I have seen agreements happen during planning, but it's a slow way to do it if it happens a lot. In that case, I've mostly seen contract-like agreements, for example, if you request X, and I have any, I'll give you some.

[elf-pavlik]

I have seen agreements happen during planning, but it's a slow way to do it if it happens a lot.

I think you refer again to friction. In a similar way to how process recipe supposed to lower a friction related to preparing a plan, agreement recipe supposed to lower a friction related to preparing agreement.

Let's stay with a use case where Bob and Alice press apple cider.

1. Alice stays in control of the press
2. Alice has skills to operate the press
3. Bob has skills to operate the press

---

Process pseudo recipe (pressing apple cider)

inputs (flow recipes)

• use of the press
• work of a person to operate the press
• consume apples

outputs (flow recipes)

• produce apple cider

---

Using that one can prepare plans to press apple cider. Let's consider two cases, both of them will use the press controlled by Alice. I will use providedBy and receivedBy and later make version for #276

---

Agreement pseudo recipe 1 (usage of the press)

commitments (flow recipes)

• use the press for 1 day, providedBy ?A, receivedBy ?B
• produce apple juice 10 liters, providedBy ?B, receivedBy ?A

---

Now Alice in her system link that agreement recipe from the apple press resource, and substitute / bind variable ?A with her agent identity. When Bob just wants to use that press in the process he runs, when creating process from recipe and assigning Alice's press as input he would also have to add an agreement using that agreement recipe. In practice app Bob uses could right after selecting number of days he wants to use the press in the process, prompt him to agree to agreement where he would commit to produce for Alice days * 10 liters of apple juice.

In second variant we could consider that Alice besides making the press available will also do the work. For that we need:

---

Agreement pseudo recipe 1 (work to operate the press)

commitments (flow recipes)

• work operating the press for 1 hour, providedBy ?A, receivedBy ?B
• produce apple juice 5 liters, providedBy ?B, receivedBy ?A

---

Once again, from press resource Alice can advertise that agreement recipe as well, probably she could also advertise a process recipe which appeared on top - Process pseudo recipe (pressing apple cider)

Now when Bob wants to press apple cider, in the app he uses to plan the process and agreements from recipes, in addition to making agreement from first recipe (for using the press), he will make agreement from the second agreement recipe (work to operate the press). In a same way once he selects number of hours for work input, and invite Alice to assign herself to that work, app will prompt him to create proposal where he will commit to produce hours * 5 liters juice for Alice. In the end (once alice accepts the proposal) they could have two agreements - one for using the press and one for doing the work, or even commitments from both could get merged into single agreement - possibly little to no difference for Alice and Bob.

Now the use, work commitments in the plan will reference both, the process and the agreement(s). Once observed, the events can also reference both, the process and the agreement(s).

The produce event where Bob produces juice for Alice would probably need some 'transfer' like functionality discussed in #275 Possibly Bob in process would produce all the juice in one resource (with specific LOT) and later transfer control over certain quantity of that resource to Alice to fulfil relevant commitment in a contract.

We could also add here consume on apples and more variants between Alice and Bob, where each of them can provide apples, or even add 3rd party (let's say Clair) who can provide apples, sometimes to the work and receive share of apple juice.

[bhaugen]

@elf-pavlik thank you for the very nice and detailed example.

Still looks like the agreements precede the processes. No? Otherwise can they start juicing the apples before they have agreed on anything?

[elf-pavlik]

In the simpler example which only requires agreement to use, Bob gets prompted to accept that condition - days of usage * 10 liters of cider, which Alice put on usage of that press. Since Alice puts that condition, she could configure her system to auto-accept proposals based on it (just as e-commerce shop would do for their carts and checkout process eg. current Open Food Network making orders online functionality), for Bob it would just require one-click - "yes I agree to the specific condition put by Alice."
Above doesn't sound like that much of an extra friction, and Alice might not want Bob to just 'start juicing his apples' if he doesn't agree for the condition she puts on using her press.

I assume here that they both use VF based software to manage their planned processes and agreements. If they just do it in informal pen and paper way, we don't need to consider them as VF based software audience.

[bhaugen]

for Bob it would just require one-click - "yes I agree to the specific condition put by Alice."

That's not much friction, but is an easy way to modify an agreement. But both the previous agreement and the new condition and the click happen before Bob starts using the cider press, no? Might be only one click before. but that's a technicality. The point being that if Alice and Bob do not agree before Bob starts to use Alice's cider press, I think they have violated one of @gcassel 's principles of agreement-based relationships. (And also the P2P Foundation's ideas of mutual coordination economics.)

So I am guessing you meant that the click precedes the apple-pressing...

[elf-pavlik]

So I am guessing you meant that the click precedes the apple-pressing...

Yes, just as placing order online happens in Open Food Network before you can eat or even pick up that food. Or when you rent a car you may go need to formalize that rental, possibly even make payment first or at least provide your credit card details before you can drive it.

So far in VF we use Agreement (which includes exchange agreement), as a way to group commitments and events together, they reference the Agreement using vf:under. Similar to how a Process groups commitments and events together using vf:inputOf and vf:outputOf.
Besides that in our examples agreements didn't have any additional information, and just gave a scope/context to set of commitments and events. This may differ from what we commonly call an agreement which can go beyond grouping commitments and events together.

for Bob it would just require one-click - "yes I agree to the specific condition put by Alice."

That's not much friction, but is an easy way to modify an agreement. But both the previous agreement and the new condition and the click happen before Bob starts using the cider press, no?

I don't understand what do you mean by 'modifying an agreement'. The agreement with commitments:

• use the press for 3 days, providedBy Alice, receivedBy Bob
• produce apple juice 30 liters, providedBy Bob, receivedBy Alice

would get created based on agreement recipe

• use the press for 1 day, providedBy ?A, receivedBy ?B
• produce apple juice 10 liters, providedBy ?A, receivedBy ?B

where Alice already bound her agent identity to ?A variable, and Bob binds his agent identity to ?B variable in recipe and scales quantities according - just like one scales quantities when creating flow intents from flow recipes when starting to plan process from a process recipe.

Similar agreement recipe could get used in Open Food Network, when Bob would like to sell the juice for mutual credit tokens. He could take recipe

• issue apple juice 1 liters, providedBy ?B, receivedBy ?X
• recive 12 tokens, providedBy ?X, receivedBy ?B

and bind Bob's agent identity to ?B variable. While making an order, someone let's say George would bind one's own agent identity to ?X and scale quantities according to how many litters he wants. This would result in proposal which Bob's OFN system could auto-accept which would result in Agreement (exchange) between George and Bob with 2 commitments:

• issue apple juice 4 liters, providedBy Bob, receivedBy George
• receive 48 tokens, providedBy George, receivedBy Bob

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/valueflows/-/issues/260.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.