Most inference involves reasoning about eternal truths or relationships that are outside of time.   The assertion that "all men are moral" rests on knowledge about human lives stretching back several hundred generations.  Although it is taken to be eternally true, it is logically impossible to prove it beyond doubt at any given instant of time.  

However, unlike logical rules, workflow are stubbornly rooted in the flow of time and must obey the logic of time.

Models of temporal 'objects' employ two fundamental constructs, points of time and spans of time.  A point of time has a definite date/time 'location' in history, such as June 5th 2007 9:22:52 AM .  A time span is a measure of 'distance' in time.  It is not fixed to single point in time - a span of 3 days measures time, but has no 'location' in time.

From the two fundamental constructs of points and span, we can build composites types - intervals of time and durations.  A interval has a definite start and an end point in time.  A duration has a start time and a span, such as June 5th 2007 9:22:52 AM and the following 3 days.  There may also be variations such as a rule stating that someone must buy a certain product between two dates and apply before another date to qualify for a rebate.  Three points of time are required to construct the temporal object associated wit the rebate rule.

As stated above, reasoning about time involves temporary truths about activities or events happening in some sort of orderly sequence.  Most temporal reasoning moves either of two directions,

1 -  Forward in time from a set of actual or proposed causes to their logically necessary effects or,

2 -  Backward in time from intended or observed effects to their necessary causes.

Scheduling or planning problems tend to move backward in time from an intended objective, such shipping a product on a certain date, to the series of steps necessary to achieve the objective.  Often, there are logical constraints or business requirements placed upon the series of steps, such as one step  must happen before or after some other, or must not start or end before a certain duration of time, or that two events must happen at the same time in order to satisfy a requirement, etc.

The logical expression of these temporal relationships can be quite complex.  The table below shows the thirteen types of constraints on relationships between activities or events described in James Allen's 'temporal algebra'.

Each of these thirteen constraints can has descriptive ( describing what is ), prescriptive ( state what must be must ) and proscriptive ( what must not be ) variations as well, so the complexity of the logical expressions can grow rapidly a dozen or so activities or events.  

There also is a higher level of complexity resulting from logical inferences to be made about relationships between multiple events.  As a trivial example, if A precedes B and B precedes C, then A must precede C.  As a more complex example, if A contains B and B meets C, then C must start during A.  If for some reason, there is additional constraint that C must end before A is finished, there is a potential conflict between the constraints.  Effectively A contains C as well as B - there is a hidden constraint lurking under the surface.          

Simplifying complex models of temporal constraints may be challenge.  Even with the power and flexibility of everyday language, it sometimes difficult to describe in detail an exact sequence of events.  It may help to employ something like a canned set of temporal design patterns for typical uses.  

The most feature is pre-conditions and post-conditions which allow an inference engine to control of the execution of the process .  The workflow itself is a black box.  It could be a workflow language interpreter or compiled computer code, they would look the same to the outside world.   

Note that the status of other processes can be tested, both as entry conditions and as exit conditions, allowing the rule engine to implement some level of control over conditions determining when a process runs, for example, when one process must end successfully  before another can begin or to cause an error if an independent process did not complete successfully.  This allows a level of useful control over the execution of process without the burden of a full-blown workflow controller.    

The complex topic of executing workflow models will be covered in greater depth in the section for Rule Engines.