Conundrum methodology · 2 min read · Updated September 2026
An intelligence collection plan is the document that pairs every priority intelligence requirement with the collection asset best suited to answering it. It is where requirements stop being a wish list and become an operation, and where the gaps between what you want to know and what you can actually find out become visible.
Read first: Priority Intelligence Requirements (PIRs) (you need requirements before a plan)
A set of requirements describes what an organisation wants to know. A collection plan describes how it intends to find out. The second is where most of the value is realised, because a requirement nobody has assigned an asset to is an aspiration.
Building the plan starts by populating it with the requirements judged critical, and then matching each one to the asset best suited to answer it, whether that is a technical tool, a human source, an open-source method or a relationship with a peer. That pairing is the plan's core function.
Doing it properly demands an honest understanding of what each asset can and cannot do. Assets are not interchangeable: a network monitoring tool may be excellent at identifying malware communication patterns and no use at all for establishing why an actor is doing what they are doing. A plan that matches on convenience rather than capability will look complete and produce nothing.
The most useful thing a collection plan produces is not the pairings. It is the requirements with nothing next to them.
When an asset repeatedly fails to answer the requirement it was assigned, that is information about the asset, and it should prompt a reassessment of whether the tool is right for that task and whether the money is well spent. When no asset exists at all for a requirement the organisation considers critical, that is a capability gap, and it belongs in front of whoever makes investment decisions rather than quietly dropped.
Both of these are only visible because the plan exists. Without it, an unanswerable requirement simply goes unanswered and nobody can say why.
A collection plan written once and filed is a description of a moment. Requirements shift as the business and the threat landscape change, assets are bought and retired, and sources degrade. The plan has to be revisited on the same rhythm as the requirements it serves, or it will quietly stop describing reality.
Conundrum treats the collection plan as a live object rather than a document. Requirements, the sources collecting against them and what those sources have actually produced are held together and visible, per vector, so the pairing can be inspected at any time rather than reconstructed annually.
Source health is part of the same view, which addresses the failure mode above directly: an asset that has stopped producing is flagged rather than quietly continuing to appear in a plan as though it were working.
