Intents vs Commitments
This is either a documentation or a model issue, which I want to have some discussion on, or at least think about out loud. I think it can be a documentation issue, but want to make sure.
- Operational production planning, with Commitments and Processes, was an early part of VF, and has been implemented a number of times. Commitments are part of REA.
- We added Intents (and Proposals) in response to the common use case of published offers/wants (mutual aid, marketplace, others). Intents are not part of REA.
- We make Intents a "flow", and synced it up with Commitments and EconomicEvents, so that it can be part of an operational plan, basically representing a Commitment which is firmly planned, but to which no (usually provider) agent has committed or been assigned yet.
- The Intents section of the model is very flexible, and supports various kinds of scenarios, as well as published offers/wants. One result is a lot of M:M relationships. Another result is that Intents run a big range of granularity and how close to being operational planning they are.
This has led to situations where we are technically using Intents for something that has been very concretely planned, usually by an organization, but not assigned yet. When assigned or committed to, there is excessive machinery involved to create a Commitment and hook it to the Intent. In other cases, Intents are very appropriate - when it is not sure it will happen; when more than one Agent will commit, etc.
Suggested way to think about those situations:
- There is a continuum of firmness, from idea to fulfillment. At some point, we can talk of Commitments. We have talked about Commitment being when both agents have committed. But...
- When making an operational plan, and there isn't really a question of some agent stepping up to commit or being assigned, then Commitments can be used, even though there may not be an agent committed yet. The criterion is firmness of plan, not commitments of agents.
- When drafting a plan, Plan can be used instead of Scenario, when there won't be several suggested plans to choose from, rather people will iterate the plan until it is finalized.
- If there will be several suggested plans, then use Scenario. It may be easier to generate a Plan from such a Scenario, once it is agreed upon, rather than using Satisfaction to hook them up. But either would work.