Outline of my model of information dynamics.

The description is vague for two reasons -- it is very general, and I have not elaborated it in my own mind.

The heart of the model is a 3 dimensional discreet space, or 3 D matrix if you like.

The X axis divisions are allocated to processors. A given processor may be a person or a computer, or groups of these depending on the scale. At one scale I am a processor, at others a branch, division, company or country is a processor.

The Y axis divisions are allocated to the things being cognitively processed by the processors. Call them items or issues depending on your taste for abstraction. When reading this page you might call it an item, but if you think about it later it is more like an intangible issue. Scaling also applies, so an issue might be early reduction credit under the Kyoto protocol, climate change per se, or geophysics.

The Z axis divisions are steps in the processing of issues. Not time, but steps -- this is crucial because while you cannot go back in time you can and often do go back in progress. Consider all the "re-" words in English -- redraw, repeat, resend, rework, etc. In the model this retracing of steps creates looping of work flow and greatly increases the complexity of the dynamics, along the lines of real life. Planning would be easy if every step were forward.

So each cell in the space represents the potential for a given processor processing a given item at a given stage of development.

A given state of the system, at a time, in its simplest configuration will be defined by the ensemble of two sub states. In the queue sub state some cells contain items that have been delivered to a processor in a given stage of development, but the processor is not processing them. (Stuff in your pile.) In the processing sub state some cells contain items in a given state of development that are actually being processed. (The allocation of attention of the processors at the time.)

The dynamics devolve as follows. A processor selects an item available to it, processes it, changing its stage of development or not, then stops, sending it to another processor or not. In the general case, any processor can send any item to any stage of development as a result of its processing, and to any other processor. In actual organizations many of these options are constrained, but that is what makes this a powerful model of organizations. Constraints change the dynamics.

Thus we see that in general there is a family of flows of items or issues among processors and stages, and likewise a family of flows of the attention of processors, topologically orthogonal to the former. Under certain common circumstances looping is characteristic in these flows.

Chaos management is about modeling and dealing with these flows. Once you assimilate this model you might want to read the nontechnical essay again.

For many purposes, though possibly not for testing for chaos, the model can be reduced to the X and Y dimensions -- items (or issues) and processors. In this form it is probably isomorphic to a standard queuing model, such as an i-think model. Also note that for both my examples -- building permits and Naval research -- data collection and visualization only require these two dimensions.

In its simplest definition, looping merely means that an item visits a processor more than once. However, my concept is that the return visit is "unexpected" and this modal concept may be hard to capture mathematically. However, I note that typical work flow analysis lays out steps in their logical sequence as though nothing ever goes wrong. Indeed, they often have "review" steps but seldom consider the implications for complex looping. The organizations I study are those where looping is the rule -- issue driven organizations. There are many and they are increasingly common.

So maybe the way to model is to first define a "supposed to be" work flow, then add unplanned looping to stress the system. The physicists at the Naval Research Lab started with a single worker processor and a reviewer processor in sequence. We had not found chaos by the time they quit in fear. But as I point out, while finding deterministic chaos would be profoundly important, the model is a powerful management tool in any case.

By the way, probably the most profound alternative in the work flow procedures that define an organization are whether there is replication of items or not. Seattle building permit application packages could not be duplicated so only one processor at a given time could have any given package. The Admiral's questions, on the other hand, were massively replicated. Things like copiers and email broadcast lists can lead to rapid exponential growth in instances of an item in the organization. This may be a separate stress from looping.

Note too that cognitive production organizations, unlike factories, are organized around knowledge, or information, specialties. So as an issue unfolds it will be directed to the appropriate offices. In my ecology analogy I say that issues seek the information they need to resolve themselves. This too makes issue driven work flow unpredictable. It also means that the logical structure of issues is what drives the form of the dynamics -- what I call the patterns of the issue storms. In fact my research began in 1973 (October 14, to be precise) when I discovered the fundamental form of all issues -- the issue tree. I only found my first loop in 1978, and thought it a rare thing. Seattle building permits was an accidental discovery in 1982 or so. Now I know that looping is a major feature of our way of life.