Principle

Associate a costs to actions, thus giving the basis for an economical system, in order to provide the necessary support for incentive on usage and optimization from improvements. High leverage actions should naturally be preferred over low impact hight requirements actions. Also, the system would favor an increasingly precise estimation of costs (which is probably why this can not be delegated even to AWS#MechanicalTurk).

Solutions

Use include (limited by line numbers) to highlight the current main focus and the Site.AllRecentChanges page to show current activity (potentially related).

Demo

Goal

note that this demo has been largely superseeded by the (internally visible only) http://127.0.0.1/wiki/PBES/PotentialTasks

    1. cf PriorityByEconomicalSystem#closure
    1. PriorityByEconomicalSystem#FinancialPricingModels
    2. (:pagelist $:ActionCost*=- fmt=#simple:)
      1. PmWiki:PageTextVariables#pagelists

Last actions undertaken

Example

Ordered list of actions for strategy S (at t0) Ordered list of actions for strategy S (at t0+1)
starting point Action C realized
  1. x credits = action A (from project P)
  2. y credits = action B (from project P)
  3. z credits = action C (from project Q)
  4. a credits = estimated cost of action C (from project Q)
  5. b credits = estimated impact of action C (from project Q)

x>y>z>>a>b>0 proportional to the ROI of each action

  1. x' credits = action A (from project P)
  2. y' credits = action B (from project P)
  3. z credits = action C (from project Q)
  4. a' credits = estimated cost of action C (from project Q)
  5. b' credits = estimated impact of action C (from project Q)
Account=A Account=A+z

Dilbert comic strip for 04/18/2010

Structure

  • isolate an action A (atomic unit with clearly defined limits)
    • parent
      • default=root
    • expected impact of the realization
      • default=1/number of actions from the parent
      • impossibility to short-circuit the system and consider global impact
      • ultimately should be convertible to unit of energy
    • estimated cost
      • default=2300Kcal
        • shortcuts convertible to unit of energy
          • day of work for me
          • amount of money
          • amount of objects
          • combination of some shortcuts
          • ... (simple to add)
      • a ridiculously higher amount for the infrastructure
        • housing, administrative overhead, insurances, ...
    • return on investment (ROI)
      • expected impact of the realization/estimated cost
  • Hierarchy of actions
    • root=strategy S
      • default=homeostasis
    • actions

Remarks

  • there is no short-term incentive to price and since it is a complex thus costly function, the system is not being used
  • closure must be taken into account in order to
    • make projects "safe" from side-effects
    • lower the cognitive cost of comparing a long list of actions
      • overall costs is too complex to evaluate and update
      • consequently, consider the cost for each project
  • unit of energy in general as absolute value in one moment in time, as opposed to taking time into account, might be too simplified
    • as the price of a unit of energy is a function of time
    • especially important if strategy takes into account homeostatis for which
      • energy can be stored only to a limited extend
      • energy can not be consumed instantly
  • estimate waste by conversion
    • in both direction
      • in cost, waste of management
      • in estimated impact, energetic waste in order to get the final product
  • EROEI alone can provide a basis for optimization
    • use an estimated base EROEI and tend to perpetually improve it
  • Usability threshold
    • every process including chores would be there but even theoretically there is a usability threshold
    • small repetitive yet required tasks are probably under a threshold of resource required
      • managing them would require more energy than just doing it (cf EROEI) since they usually have low dependencies, it's not a complex network of effects and the consequence of doing or not doing them are highly predictable
    • example
      • "breathe in, breathe out" despite its fundamental importance as it is a default background task
      • yet how to breathe in and out in an optimal way sustaining the system could go in the dedicated Health page and hopefuly in Augmented Reality Heuristics System too

Credit earned by

  • realizing actions

Debit to spend on

To do

See also

Inspired by