Types Of Uncertainty
In Wikis and Intelligence Analysis Wheaton suggests 4 stages for intelligence analysis:
- Modeling
- Collection
- Analysis
- Production
Work of all sorts is happening during each of these phases, but each phase is dominated by the concerns that label it. For example, in the modeling phase, most of the work is devoted to building a conceptual model to ground the rest of the research. Some data collection might occur, but the purpose of this collection will be to inform the model, rather than to draw conclusions.
With this in mind I've attempted to recast this view of intelligence analysis as a systematic process for collaborators to reduce uncertainty. Each of these phases would then emphasize reducing certain types of uncertainty, and progressing from one stage to another would be achieved when uncertainty had been reduced below a tolerable threshold. In the discussion we came up with this rough chart:
| Stage | Type Of Uncertainty | Questions |
|---|---|---|
| Modeling | Ontological | If one were to draw the problem on the white board, what would the features be? |
| Collection | Factual | What variables in the model can be measured? What are their values? What other information do we have? |
| Analysis | Logical | Are relationships in the conceptual model correct? |
| Production | Communicative | Can the insight provided by the analysis be clearly communicated? To who? |
These four types of uncertainty seem insufficient, however they seem like a decent starting point.
Perhaps it would be useful to map artifacts created by the intelligence analysis tasks to these stages of work and types of uncertainty. Our earlier discussion about concept maps and outlines really drove a lot of this thinking. A concept map seems like an obvious first choice for Ontological Uncertainty, while an outline seems excellent for managing Communicative Uncertainty.
Creating a correspondence between stages of intelligence analysis (as Wheaton describes them) and artifacts created by performing analysis tasks to seems like a good way to begin collecting requirements for building tools. Creating/Adopting a more subtle taxonomy of uncertainty might give us important metrics with which to evaluate existing tasks and tools.
