Feature: Swap up view in the graph to show who holds custody of the resources

[adaburrows]

We can add a switch somewhere to allow making the view more agent centric. When the switch is flipped the graph should show the agents in the nodes instead of in the edges.

Note, this will require looking up the agent data from the edges. Looking up the data from the edge allows us to construct who will have the resource once events are logged.

The true custodial view will only be possible once we have the full accounting and can show the EconomicResources and not the ResourceSpecification placeholder.

This of course highlights how there are really different views based on the stage of execution. Each layer of Recipe, Intent/Commitment, Event each has slightly different data available. So we should try to be more aware of that context for UX.

[adaburrows]

Issue

I've been thinking about this in terms of the morphisms (maps) available to the data we have in the planning stage without simulating what would happen based on the plan. Since all we're dealing with is ResourceSpecifications in this view, it is impossible to know which person has the specific resource we need until we have actual EconomicResources. This comes from the fact that all ResourceSpecifications in one plan graph are technically indistinguishable from each other and all connections to repeated ResourceSpecifications are essentially made to the same ResourceSpecification. The ability to use more than one of the same ResourceSpecification is mostly a matter of convenience for the UX. So this is impossible in this context.

Multiple Contexts

I'm actually settling down into thinking there are more explicit layers in Valueflows than the ones in the documentation:

• Knowledge
• Intent
• Recipe
• Commitment
• Event/Observation

These actually fit into the steps of coordination taken to produce something:

• Knowing who, what, and which processes are going to be a part of the overall scheme of action.
• Intending to make something with research scenarios to intents and a proposal (and probably some actual events for prototyping and the research process).
• Finalizing what it is that's going to be done into a "recipe".
• Gathering commitments (let's say getting to at least a certain level of funding, or a certain number of orders, or knowing that you are going to make something specific for someone in exchange for a certain monetary amount).
• Actually recording the events for the production run or business execution and shipping according to what occurs, and not necessarily what was planned.
• Seeing what the current state of inventory is both in planning and production.

Some stages might be skipped entirely, some stages will be revisited. The UX should not be the data structures. Accounting, BOMs (bill of materials), and the various stages should each have special UX based on context.

Possibility

This kind of UX is possible if we simulate the observation layer and use that to create the UI or it's possible in the Observation level.

The other possibility adding in other data structures that mirror the EconomicResource that are used in planning. So we could have a PlannedEconomic resource that would outline the expectations of what would happen during production/execution.

[adaburrows]

Oh, and I'll point out the reason why there isn't a PlannedEconomicResource, is because most of the information needed to create those are encoded in the commitments, but it might still be a useful object in the UI code.

[fosterlynn]

🤔

In the meantime, see https://lab.allmende.io/valueflows/valueflows/-/issues/663 for previous thoughts for a different need, but same problem, when we were working on this earlier.