@mike623317 : Every maintenance interval, we record the historical stats of the budget. These can be accessed as objects 2.13.x.
The reserve is the sum of the three "from" fields, from_initial_reserve, from_accumulated_fees, from_unused_witness_budget. It represents the overall inflation cap, i.e., the total number of the additional core asset (i.e., BTS) that will ever be able to come into existence.
The total_budget is the amount of core asset that can be allocated to workers or witness pay. Depending on what the committee and voters do, up to total_budget can be spent; exceeding the total_budget would require a hardfork.
The total_budget is calculated as a tiny fraction of the reserve, specifically, 17 / 2**32 times the number of seconds in a maintenance interval, rounded up. This number was chosen to initially give about the same rate of creating BTS as 101 delegates all with 100% pay in BTS 0.x.
witness_budget is how much is reserved for witness pay. This is the time to next maintenance interval times witness pay.
worker_budget is how much is available for workers to be paid. Witnesses have higher priority than workers.
leftover_worker_funds is how much is available for workers to be paid.
supply_delta is how much the supply changed due to fees and budget logic operation during this maintenance interval. It does not include activities like manual reserve/burn of assets, or the operation of reserve/burn workers.
Right now there is one reserve worker, 1.14.0. Like "normal" workers, the reserve worker is voted to receive BTS with the worker system; unlike "normal" workers, the chain itself forces a reserve worker to immediately return all of its funds to the reserve. So the supply delta in budget_record_object misleadingly indicates the network is massively unprofitable, since it does not account for the fact that most of the BTS go to reserve400k and are
burned returned to the reserve. This needs to be fixed, and tracking of e.g. how much a worker has received needs to be implemented.