## 3 The Universe Does Not Run on Workflow  
Enterprises today are run largely by sets of static processes, which we will loosely call static \"workflows\", although this term may have a more narrow definition in some contexts. The essential point is that these are pre-defined procedures authored by a (workflow) programmer who has had to identify company policies (such as managers need to authorize requests over a certain amount) and who has had to foresee all contingencies that should be handled in the future.  
In contrast to this, events happen in the world because objects obey the laws of physics rather than programming. The ballistic arc of a thrown ball is not prescribed by a written procedure, but rather is a result of the laws of gravity and momentum. Even a guided missile takes into account these laws and makes physical adjustments to arrive on target. These laws can be made explicit and computations can take them into account. Were the universe run like enterprises, these laws would be be implicit in code and a path computed for each ball to be thrown in anticipated directions.  
Running an enterprise by such static procedures has the effects that managers never know whether their corporate policies have been correctly represented and workflow users are frequently trapped inside an overly-complex process given what they want to accomplish and their current context. Such static workflows also cannot easily respond to changes in policies and to contingencies.  
There are supply chain problems, resulting from a needed change in suppliers, that could not be handled by today's workflows, such as the example below, explicated in [19].  
* CENTRA is a car company that needs a CD player connected to a CD dispenser connected to a power supply.
* The technology used is a special power/control connection that can only be disconnected by the company who made the connection.
* Any company that makes a connection offers a disconnection service.
* Each component has 2 ports for connections.
* UNIBUS offers a service for connecting CD components.
* CENTRA has a service that can connect any CD component to the car chassis via a free port.
* A shipping service can move components (connected components are also components) from company to company.
* CARCDs offers a CD Dispenser (advertised in a service).
* CDsR'Us offers a CD Player and a power supply (advertised in a service).  
The workflow, a sequence of service calls, for handling this standard supply chain is obvious. The components are shipped to Unibus that makes the connections according to instructions from Centra, and then ships the finished macro-component to Centra, which connects it to the chassis.  
But now there is a contingency: CDsR'Us cannot deliver the power supply in time. A search of services, based upon their semantic descriptions, shows that another company, WeCDs, offers a CD player connected to a power supply, which can be delivered in the needed quantities on-time. Let us ignore for now the management of change and focus on the question of how the workflow should be changed to take advantage of this solution to the contingency.  
A naive approach to workflow modification would be to simply substitute WeCDs for CDsR'US as a provider of the CD player and power supply components. Figure 1 illustrates the subtle flaw in this approach. The \"planning\" arrow refers to the construction of the workflow.  
A naive substitution of CD suppliers results in CENTRA not being able to connect the final product to the car chassis because all of the connectors are already used. Standard workflow techniques will not detect this problem until the workflow is executed. The expensive fix to this requires shipping the whole system back to WeCD's with a request to disconnect the CD player and power supply, and then shipping back the result.  
Recognizing that the world is committed to workflow technology, we now outline one way that semantics would be used for a dynamic workflow system that could overcome the problems of static workflow systems.