Tracked process governance

This issue extends #140

In our cost tracking, we currently catalog labor, labor_hours, and resources. However, in the context of ecology which is core to the project, cataloging the processes that transform or transport resources is essential. Either we should add another section for processes or somehow lump it in with resources.

The tricky thing here is that although resources can be tracked in numeric units (10g iron, 5L oil, etc), finding standard units for processes might not make sense.

ValueFlows handles this by crawling back the tree, but in the case of global production networks, traversing this immense network every time we wish to derive the information for price calculation would be infeasible. This is why we bundle ongoing costs in a feed-forward, semi-aggregate manner. It allows us to carry the pertinant information forward as it flows through the system. We need some way of doing this with resource/process pairs.

So, like #17, we will want to catalog various processes that can transform resources and allow some amount of assignment of cost to thos processes in whatever quantities they are engaged in. Because we may be tracking resource origins (ie, lumber from X forest in Oregon, or iron from Y mine in northern MN), it might make sense to also attach process information here as well, and price resource-process pairs by the units the resource uses. Thus, some resources might have a flat price attached to them, like lumber. However, if we burn the lumber to create a fire that is used in the creation of another resource (far fetched, but just an example), then the 10kg lumber becomes 10kg burned lumber, which could have both the cost of the lumber + the cost of burning 10kg lumber.

The same mechanisms as resource tracking would have to occur here: the bloc burning the lumber assigned the cost of the burned lumber to whatever resource is output from that process. When another company orders that resource, the burning bloc gets a refund for the cost of the burn (almost as if they had mined a resource). This promotes tracking the burn process accurately.

Thought vomit time (this helps me work through ideas)...

There are two main lines to my thinking:

Processes transform resources

Resource -> Process -> NEW RESOURCE. In this case, we would track both the resource and the new resource. If the process is worth tracking, then so is the resulting resource.

Pro - Determining the final BoM is fairly simple because it's all tracked
Pro - Somewhat low cognitive overhead of tracking (does this matter, if costs can be reduced to a price?)
Con - Requires tracking resources beyond raw materials...balloons the number of resources needing to be kept up to date
Con - Storage model is somewhat convoluted
- If you know resource A became resource B, you don't know what process it too to become B so that has to b stored

Processes apply on top of resources

Resource -> Process -> Process -> ... In this case, we track a raw material, then the processes that apply to it.

Pro - Only requires tracking raw materials
Con - What about processes where A becomes B AND C? If crude oil gts refined then how do I know if this product has asphalt in it or jet fuel?
- Need a way to label outputs of processes (ie, first method)

Ok so it seems the first method is required in some manner, but also some of the second method. What does the data model for this look like?

Lt's tak a look at our simple dumb oil example:

oil + methane + propane -> refine -> gasoline + jet fuel + asphalt

two inputs, one process, three outputs. The inputs have distinct units, as do the outputs. The interesting thing with tracking processes is that the volume or magnitude of the process itself might be determined entirely by the inputs, meaning determining a unit for the process itself might be unneccesary. This is probably obvious, but just thinking out loud.

The final cost should include the current resource but also the processes applied to it. Ok, and here's where process units/magnitudes might be useful to determine. Even with our contrived example above, we combine oil + propane: the propane usually comes from the refining processes, meaning we have a temporal loop. If we were to track every process as a function of a resource, over time we'd have oil + (refine (refine (refine (refine propane)))).

We need to find a way to reduce the process itself to a numeric unit so it can be aggregated, just like labor and resources. Maybe that's it: maybe we just track the inputs:

Cost of lumber:

{
  labor: { lumberjack: 3hr },
  resources: { wood: 5kg, gasssoline: 4L },
  processes: { refine: { oil: 8L, methane: 1L } },
}

Makes 5 chairs:

{
  labor: { chairman: 4hr, lumberjack: 3/5hr },
  resources: { wood: 1kg, gasssoline: 4/5L },
  processes: { refine: { oil: 8/5L, methane: 1/5L } },
}

Now they can be added together/divided/etc. When costing the refining process, we could even decide to just track the oil input and cost that specifically, or run it through some kind of simple algorithm: C = 9/5 oil + methane. Obivously introducing even rudimentary math makes democratizing costs insanely complicated.

I think the solve here is to define the units of the inputs for a process up-front and determine the ratio of cost for them such that there is no equation, just 0.9 * oil + 0.1 * methane.

Interestingly, given #138 we don't even need to determine costs of processes, we just need to track them.

basisproject / tracker

Tracked process governance #137

Processes transform resources

Processes apply on top of resources