Pass/Fail and States

[fosterlynn]

This is related to #603 but I think involves a different decision point. That one is about how to define measurement and test events themselves; this is to reconsider how to define the implications of measurements and tests in terms of economic events and economic resources.

Noting that we currently have pass and fail actions, which become the state of the resource referenced by the event. And noting that we have an active use case of a beef supply chain which includes longish transportation and various quality or validity tests, some of which go beyond pass or fail. For example, various tolerances of temperature readings may not "fail" the resource, but change the expiration date, which changes the price (and possibly the product, but that is part of this discussion, and we don't have full details on how they look at it).

So some questions:

• What actions do we want?
• Do we want states, and if so how and by whom are they defined?
• What are the increment/decrement processing rules for something that fails or tests not optimal in some way?
• What causes a new resource?
• What causes a new resource specification?

[fosterlynn]

Thinking out loud through some scenarios.

Production: I think this issue applies pretty much to "workflow" sequences of processes, where the same resource is input and output if all goes well. But am including produce for completeness. If something fails during production, it becomes split off into a separate resource with mostly a different resource specification. Like, you drop one of 30 pies, you output 29 pies, and 2 lbs of compost. So, you get "co-products" or "by-products".

Transportation: The beef use case fits in here. There are temperature readings taken throughout transportation in different parts of a container. All or part of a resource might be failed as unconsumable (if it is a frozen product that thaws); or might be down-graded but still tradeable (if it is a cooled product that become too warm, but within some tolerances). These are not separate quality testing processes, they are part of the transportation process, with pickup and dropoff actions. Or in ground transportation, for example, sometimes one package of many will disappear from the truck, so there is no dropoff or a dropoff with less quantity. We think that splitting off of failed or partially failed resources will usually happen on receipt, after the drop off (unloading). But either way, I think it basically gets split into separate resources that probably have different resource specifications.

Workflow processes: This includes taking a resource through more than one stage of development. It also includes doing an explicit quality testing (QT) process. And processes that repair or maintain a resource. In workflow processes, the resource reports the process specification of the last process it went through as the stage, to differentiate it from the same kind of resource at other stages. So you can tell if a translation was proofread, or a component was tested after production. The actions are accept and modify. And we have thought about pass and fail as additional possible output actions for QT processes, causing a change of state.

Some observations from those scenarios:

• "failing" can happen at any time, not just during a QT process
• there can be degrees of "failing"

Some tentative conclusions, for discussion, feedback welcome.

• I think we should get rid of the pass and fail actions. If we want to keep state as a property of a resource, it could be set using a different property, which probably should be user-defined.
• I think if "failing" or significant change in state of a resource results in a new resource specification, then that becomes a new resource or added to a different resource; a resource cannot change its specification except in case of data entry error.
• I'm not sure if we can get rid of state altogether, although it would certainly simplify processing. I think in most cases, a new resource specification will handle it, and be most appropriate. But I can think of possible exceptions, like if a piece of equipment is damaged so that it can't be used, the agent might still want to think of that as the same resource and same resource specification, especially if it can be repaired. Then state would be appropriate for the requirement. Possibly same for material items that fail QT but can be reworked. I think a different resource specification would work for these cases, but might not seem "correct" conceptually. Opinions?
• In case a resource gets split into different resources based on a test or loss or other unexpected happening, then there needs to be an extra piece of processing to decrement what came into the process by way of accept, pickup, etc. Maybe a lower event can handle that cleanly and explicitly? Not sure this works well in all cases. [edit] Maybe a move event would be better, since it does both a decrement and an increment already, and can move to a new resource. Wouldn't need a process. Need to try some different use cases.

[pospi]

Don't know that I have anything clear for all this just yet, but the basic contention that handling state assignment with resources also means splitting them up into separate resources certainly rings true.

So, as you say we need this extra bit of processing at the output of the Process. Agree that move makes sense after reading "change location and/or identity", but I would prefer there to be some semantic data in that event to indicate that the inventory was split in response to a state change. (Somewhat related- I was thinking of referencing the data used in such state change assessments via the SSO side of the grammar, which isn't exactly "which state we are changing to" but does cover "why the state change is happening".)

What you're describing above also made me consider the idea of using ResourceSpecifications to represent the states of other ResourceSpecifications. Not sure if that's necessarily a good idea, but perhaps such information could be used to answer the missing questions like "This tool is broken. Are there any working ones in my inventory?"

[fosterlynn]

(Somewhat related- I was thinking of referencing the data used in such state change assessments via the SSO side of the grammar, which isn't exactly "which state we are changing to" but does cover "why the state change is happening".)

Sounds good, will be interesting to see how that hangs together - I think it will.

[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/610.

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