Action Chains

As described, Weals represent processes that coordinate actions of groups.  The action cycle will start with some initiating action, for example the declaration of an intention or making a promise or request.  These initiatives can be negotiated and agreed to and then carried out, or not, and get a final disposition according to outcomes (completed, cancelled, completed with reservations, etc.).  Further, these chains may be part of larger chains or have sub-chains constituting a dependency hierarchy of related weals.

 

We want to be able to code the state transitions as XPFL patterns, XPFL+example+Action_Chains, and by having the Wagn Weals modules use these patterns to decide when actions are allowed and present the appropriate options to each user, wagneers can now become action flow engineers as well by evolving the XPFL cardsets available for the community.

 

Action Language

Years ago, I (Gerry)used a program called The Coordinator, which was basically email, but with a twist.  A sequence of emails related to the same coordinated action would be actions that are tracked state changes from a request or offer through the completion of a promised action.

 

Here are some of the language actions extracted from the link above:

 

 

Request Action, Decline Promise 

Offer Action, Declare complete 

Cancel, Ask for progress report 

Report completion, Revoke promise

 

Using this software and learning from the designer, Fernando Flores, I understood the power in understanding language a s a technology for coordinating actions as well as the personal power in handling our commitments.  Even when we don't have a piece of software telling us, we know to be clear in making or declining promises and canceling or revoking them as well.

 

You can look at language actions through these categories:

 

Interrogation -- ask a question expecting a response

   Stream actions in this class don't affect the state of any objects, just compute a result to view or reference.
Assertion -- assert a fact with reference to evidence

   Stream actions in this class assert correspondence between logical forms on the statement and facts in the system or world.  Can be true or false.
Assessment -- summarize qualities based on systemic knowledge

   This is probably where the trust map most comes in.  Good assessments are grounded in both facts and observations evaluated by someone with skills and experience in the field of judgement.
Declaration -- a statement constituting an action with authority

   Stream actions in this class create all of the primary data objects of the system.  Declarations are meaningful to the extent that they are authoritative.  In the sense that a judge has the authority to make declarations in court, or more simply in our personal authority to declare our intentions. 

 

Creating New Action Chains

 

My purpose of introducing the above is not to propose any particular ontology for the action languages we are in the process of designing, but to draw attention to this way of thinking about language as a technology of action.  I see this as also key to what we are doing at FlowSpace.  Where I do want to start getting specific is in around the ontology of connecting projects "intentionally", that is in action networks.

 

 

More background: See also.

 

 

 

 


I really like the idea of building an instance of something like The Coordinator on the Metacurrency platform.

 

It can be much more powerful than email (for moving intentions forward). It is easy to define the set of breaths/statements/speech-acts available. I think it would be a powerful example of a simple yet powerful Metacurrency application.

  --Arthur Brock.....Sun Mar 14 04:03:36 +0100 2010

 

Notes and examples towards a language for declaring action chain patters so that actions can be authenticated and validated when they are posted to a weal card.

 

Arrows (->) indicate the next state of the weal

Action: new: Create an -> intention weal

   new :generative : Create a new intention with the ":generative" property which means that the intention is recreated for each request or offer as needed.  This way the same intention can be the parent of many weal cycles.

  destroy <weal> (only possible if it has no links) -> null

 

Actions for Weal Type: Intention:

  is_aligned: Declare as co-holder of this intention

  is_interested:  Declare that another intention or weal supports this intension, that it is wealth for us in the context of this intension.

  is_offered:  Declare value offered, requests that you are open to

  make_request: Enter negotiation -> <interested weal (self)> requests <contract> from <offered weal>

  make_proposal: Enter negotiation: -> <offering weal (self)> proposes <contract> to <interested weal>

  satisfied: Declare the intention -> completed

  cancel: Reverses a declaration of alignment

 

# self is the counter-party of the offer, the from side who has offered something that is requested now.

Actions for Weal Type: Request:

  promise <contractor> agrees to <contract> (Contract includes interested weal and details, must be able to contract to the terms, have capacity to perform and be authorized as <contractor> (user or circle)

  counter-offer (counter request with offer at different terms)

 

# self is the counter-party to the request.  Counter-offer and counter request will ping pong between

Actions for Weal Type: Offer:

  accept <contract> -> promise

  counter-request: (counter an offer with a request at different terms)

 

Actions for Weal Type: Promise:

  satisfied: Declare that <contract> terms are met, the weal action is complete -> satisfied

  modify_promise <new contract>: enter negotiation for new terms (change delivery date, costs, etc.)

  cancel: Declare that the promise will not be completed.  -> default

 

Actions for Weal Type: Satisfied/Default:

  acknowledge <value>: Declares the wealth created or destroyed -> complete

  nack: <why> Negative acknowledgement, declares non-acceptance of the completion declaration (satisfied vs. default) back to -> promise


I think the main differences from current FP work is they way intentions are handled. Eric says they already have the idea of :generative for intentions to stay around, so that isn't a real difference.

 

The way the idea of interested and offers that can link intentions into chains and as decompositions of smaller tasks and goals within overarching global intentions help by many.

 

The request/offer and promised actions following is from my experience with the Coordinator and I am confident in this design because of that experience. I don't think it is that different than FP weal transitions, but there are some details to work out.

  --Gerry.....Thu Oct 22 19:49:21 +0200 2009