Each block will have:
- A name
- An ID
- A value that determines whether the block has an inherent initial base score or its initial base score is determined by the definition of the system in which the block is contained
- A score (the source of which is determined by the above)
- A set of inputs
- A (ranked) list of outputs
- A name
- A fuel type
- An external and/or internal type value
- A modifying factor
- An amount (or capacity or bandwidth)
- A queue
- An accept/refuse insufficient fuel switch
- A wait/discard fuel switch
Each block simply pools all the fuel it receives from its inputs on each cycle, and then sends fuel out, starting at the top of its output list*. Within the block, fuel types are ignored, but the types of inputs and outputs a block can contain can be determined by its owning system's definition. For example, a body system could disallow any connection to or from a "heart" block which is not of "blood" type fuel.
The goal should be that the total input and output amounts are equal (or in favor of the input), which would mean that the block is at equilibrium. The reason for this is because the overall health of the system the blocks belong to is determined by some function (determined by the system's definition) of all the scores of all the blocks after their outputs have been sent out--midpoint of the fuel cycle. The lower a block's score, the lower the overall health of the system. If the overall health of the system reaches a critical level (determined by its definition), the system is broken or unusable until it is fixed or whatever.
Now, just because a block is at equilibrium does not mean that the entire system is at equilibrium. Care must be taken to ensure that the system is configured in such a way that no block's score quickly reaches zero. This could result in a cascade failure of blocks and thus, the system.
*Update: This is the reverse of what I intend to actually happen (which is: ouput first, then input).