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
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
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
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.