Inconsistencies in Intelligence Collection

Matt Welch | 28 June 2016

Amid the rising talk of “intelligence” within the security industry, the concept of intelligence collection has gained traction. However, I’ve noticed a fair bit of confusion with some of these terms; between intelligence, evidence, data and information.

In its traditional government applications, intelligence has generally been confused with evidence. This is exacerbated by subjective interpretations of the concept across different industries, sectors, states and applications. This becomes even further complicated when terms like evidence or intelligence are defined by law. From a legal standpoint, while both evidence and intelligence are methods of collecting data, they serve two separate purposes. Evidence establishes the veracity of a past, or current instance, through the application of objective, deductive, empirical observation. The truth of a conclusion based on evidence is a logical consequence of the factual premise. In plain English, evidence verifies whether something has or has not occurred.

On the other hand, intelligence does something slightly different. Intelligence estimates the probability of a current or future event, through the application of subjective, inductive, theoretical hypothesis. The accuracy of the premise is what makes the veracity of the conclusion probable. In effect, intelligence is an informed estimate based on incomplete data. In plain English, intelligence estimates whether something has probably, or probably not, occurred.

This is usually where someone says “Great, so intelligence is guessing. What value does that have?” Intelligence is a function of assurance; it informs decision-making. Irrespective of the sector, decision-makers everywhere have to regularly deal with high-risk choices. Whether the stakes are people, employees, funding, equipment, time, or effort, making an informed decision is significantly preferable to a blind decision. In cases where information about the subject isn’t complete, intelligence is the tool of choice.

So how do we go about actually getting this intelligence? This might seem a bit pedantic, but the statement “Intelligence Collection” does not refer to the collection of intelligence itself, but the function of collection using the intelligence method. In other words, it is information collected by the intelligence method.

Why does this matter? At the most basic level, there is data. Data can take on numerous forms and shapes, but it is roughly defined as portions of information that have no attributed context. If I write a string of numbers and provide no context, this is raw data. For example:

675982845 8 675864172 8 675345894 4 675546543 4

It could be a telephone number; it could be lottery numbers. If we are able to define the string as a telephone number, we’ve applied metadata, or data attributes. If we have a series of telephone numbers, we have information. If the information exists in a sequence, we have an information record. If we take information from a number of different sources, observe a possible relationship between that information, and postulate a conclusion, we have an intelligence assessment. In our example, the information record of phone numbers could be cross-referenced with the call record on my mobile. It could be observed that all of my previous phone calls have occurred between 8am and 7pm UTC +10. This in turn could be cross-referenced with other information such as my LinkedIn profile, which might list my place of work as being located in Port Moresby. If the question were posed “in which time zone does the author live?”, it would be reasonable to assess that my residence is in Papua New Guinea. In this case, the conclusion is an intelligence assessment.

The process is structured, responsible, reasonable, but it doesn’t guarantee anything. This is why terms like possible, plausible, probable – the Language of Uncertainty – are used to describe the likelihood of the assessment being true. In complex and obscure cases, you might need specialized support, and in future posts I’ll discuss the merits of developing a codified collection plan.