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.

Intentions

This is how we will distinguish the things we are committed to. This can be as small as going to the store, or as big as saving the world. We articulate and tag our intentions so that we may find alignment, allies and supporters. We also articulate our highest aims to inspire ourselves and others. In the crafting of global shared intentions we are also connecting ourselves in specific, local networks of engagement. If we are later able to view both completed actions and the ongoing networks of engagement, that is more source material for further connection.

Any data representation of interests needs to handle the multi-scale, network connencted nature of interests. People will use different language and attach themselves to different aspects of an issue, and our systems need to find a way to connect any semantically connected intentions.

Interests

Interests have the same scaled, networked nature as intentions, but instead of being our commitments they are where we declare how the intentions of others affect us. Our interest may be simply to be informed of their progress, or we may want to oppose an intentions that is harmful to us. Active interest might involve paying an Open Source developer to provide some specific enhancements or just to speed up their schedule on work wanted by both parties.

Resources

Intention: Confluence model of collaboration -- Espians

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