Nearly every artifact, from web pages, documents, wikis, code, to non-software resources (houses in construction, purchase orders, etc.) goes through a lifecycle. In a few cases, the lifecycle of these artifacts is supported by a tool that allows their modeling, automation, monitoring, and management. This typically happens when the lifecycle is formalized and strictly followed. For example, the process of approving purchase orders and procuring the goods is, in some large companies, supported by a workflow management system. In these cases, a system can interpret a formal definition of the lifecycle and execute/enforce it.

In the majority of cases however, the lifecycle is informally defined, and is executed, monitored, and managed by hand, if at all. This is because generic process management tools are too complex and too rigid for this purpose, and are tightly coupled with the artifact they manage.

In Gelee we aim at providing an abstractions framework and a supporting environment that overcome these limitations and enable universal resource lifecycle management. We use the terms universal and resource as we want the system to manage whatever can be identified by an URI, regardless of its nature, managing application, owner, or location. We realize that such universality can often be at odds with ease of use, and indeed this is one of the challenges we face and address. The main characteristics of the proposed approach are the following:

• The system is targeted at advanced web users (e.g., users comfortable with writing on wikis), not only programmers. The lifecycle model is very simple, essentially based on state machines. There are no complex features such as path conditions, transactions or exceptions.
• There is no need for modeling the resource being managed and its properties. The resource can be a "black box" from the lifecycle perspective. This is key both to universality and to keep the model simple from the perspective of the lifecycle designer who does not need to worry about the specifics of each resource.
• We support automation of operations on the resources (e.g., changing access rights, submitting for reviews, etc.), achieved by actions that can be associated to phases (states) and executed upon entering a phase. Actions are where both the complexity and the resource type-specific behavior reside (e.g., sending a Google doc for review also requires setting access rights, and the way this is done is Google docs-specific). They are written by programmers, who populate a library of useful actions.
• The model is targeted at unstructured lifecycles, where there is a high potential variability and the need to place the human in the driver's seat. For example, the lifecycle owner can determine when the resource transitions to the next phase or which is the next phase among the possible ones.
• The lifecycle management tool is hosted and available as a service, together with the lifecycle design interface and the monitoring interface, i.e., the interface a project manager would use to visualize status and history of the resources under her responsibility.