# Inventory

Now that we have a process with an input and an output,
we can compute the *inventory* of how much one unit of the products of this process requires.
In this trivial example, the assessment engine should tell us that`my_first_process`

produces 1 kg of bread by
consuming 1 kg of flour.

Notice that a little green triangle has appeared in the gutter (the part with line numbers): ⏵.

Click it, and choose "Assess" (we will go into the other options later). A new window opens, with the result:

Item | Quantity | Unit | flour [kg] |
---|---|---|---|

bread from my_first_process{} | 1.0 | kg | 1.0 |

As expected, it tells us that we need 1 kg of flour to make 1 kg of bread using
`my_first_process`

.

Let us build a slightly more complicated system to illustrate how to connect two processes together. We state that 1 kg of flour requires to mill 2 kg of wheat:

```
process bake {
products {
1 kg bread
}
inputs {
1 kg flour
}
}
process mill {
products {
1 kg flour
}
inputs {
2 kg wheat
}
}
```

Assess the process `bake`

, and look at the line for bread. What happened ?

## Solution

Item | Quantity | Unit | wheat [kg] |
---|---|---|---|

bread from bake{} | 1.0 | kg | 2.0 |

This table states that, over all, 1 kg of bread requires 2 kg of wheat.

What happened? Behind the scene, the assessment engine notices that the process `bake`

requires 1 kg of flour, and that
there is exactly one process, `mill`

, that produces flour.
The engine inferred that the two processes must be connected, and executed the assessment accordingly.
You will notice that there are no processes that produce `wheat`

. The product `wheat`

is, what we call, a *terminal*
product. Informally, these terminal entities constitute the *boundary* of your model.

The new table gives you the inventory of `bread`

in terms of
`wheat`

and not `flour`

, since `flour`

is not a terminal product.