Are you suggesting I am not a ‘normal person’? 
But seriously, the video I shared was a summary of how I thought something could be set up in Fibery (in this case inventory management) and it’s true that there was probably a lot of trial and error that had gone before, in order to reach this point.
For example, I have previously set up systems for bill of materials, for manufacturing process tracking, for product architectural breakdown, etc. and it’s hard to pinpoint what I learned along the way that allowed me to reach the point where I could define 4 simple databases to implement a nice inventory management system.
To be fair, the example shown does have some inbuilt assumptions, which are not made explicit.
The template assumes that the items (cheese, bread, etc.) are fungible. That is to say, if you buy three packs of cheese and make a load of sandwiches from them, it is not possible to be able to distinguish which pack the cheese in any given sandwich has come from. In the real world (especially for perishable goods, but also for serialised items) this is not appropriate, and the design of the databases would probably be completely different, in order to support traceability.
Similarly, there will be times when product specifications evolve over time. What if you decide that a sandwich actually needs 30g of cheese and not 20g. You can’t just change the definition of a sandwich, since all sandwiches made up until that point have used 20g so any calculation of stock that assumes that 30g is required will give an incorrect result. So the databases would need to support version control.
Anyway, I am sort of making the point that the tool and the implementation is only as good as the level of depth of thinking that goes into the reality that you want the tool to describe.
So to a certain degree, my thought process in relation to setting up the Fibery workspace is secondary to the thoughts that go into deeply understanding the process/activity/data that I hope to document/manage in Fibery.
In a sense, I think this is what you are stating when you say this:
Indeed, this is/was a crucial observation, but I don’t know how I can explain how I got to it, other than working backwards:
What do you want to know? Stock levels
What do you mean by stock level? Well, it’s what you have bought/made minus what you have sold/used
How does something get made? Some things get taken from stock and put together to make something else
Are these events (where something gets made) repeatable and do they follow the same rules each time? Yes, and yes
… and so on
until eventually you conclude that these ‘events’ are in fact just multiple ‘occurrences’ of a particular predefined ‘step’, i.e. we need to record the date of an occurrence where an occurrence will always represent a particular manufacturing/purchasing/sales ‘step’.
And each ‘occurrence’ uses up some amount of some items, and will generate some amount of other items. Let’s call these consumption/production values the ‘effects’ of any given ‘step’. Which means that when a step occurs, we know what effect this will have on the stock level of a given item.
I don’t know if any of this is helping, but it’s so far the best explanation of what my thought process was…