What Makes an Intelligence Product?
When I built Varjolaivasto.fi (a shadow fleet radar for the Baltic Sea) 2 months ago, I called it a demo built on open data, not an intelligence product. It combines public AIS position signals broadcast by ships with sanctions data and shows sanctioned tankers moving through the Baltic, often uncomfortably close to European critical infrastructure.
Even when I said it was demo, multiple people asked me whether I had shown it to any of the Finnish authorities, like Finnish Border Guard, Finnish Defence Forces or our intelligence agency. And if I had, what did they think of it?
My answer wasn't very satisfying. It was a demo born in 6 hours of work. I hadn't built it with any users or authorities in mind except for myself, and I really had no insider knowledge to fall back on. I haven't worked in intelligence, and I haven't designed or built intelligence products before. I've done and written a lot of research and analysis and used them to build plenty of products and services, including tools for people working in mission and safety-critical environments, but this is a totally different field.
Those questions still got me interested in the subject. What would make Varjolaivasto an intelligence product? How could AI integrate to an intelligence product?
In this note I'll go through some of the stuff I found interesting during this learning journey and introduce a prototype of what Varjolaivasto as an intelligence product could look like.
Reading the public rulebook
Intelligence is an awkward subject to research from the outside. A lot of the interesting details are, quite reasonably, not public. Different countries and organizations also do things differently and public doctrine (as at least UK calls it) can tell me something that is totally different from the reality of the day-to-day work.
Still, I was pleased to learn that there is much more public material than I expected. I ended up reading or scrolling through the Finnish Military Intelligence Review 2025, US directives on analytic standards (ICD 203), sourcing (ICD 206) and product utility (ICD 208), the newer standard on citing public and commercial information, open-source intelligence (OSINT) and AI-assisted services (ICS 206-01), and the UK's joint intelligence doctrine and wonderfully plain-language guide to uncertainty.
The US and UK standards are not Finnish product requirements, and I'm definitely not claiming they reveal how Finnish intelligence organizations work. I used them as public clues and design material since I couldn't find similar documents from Finnish authorities.
I wanted to focus on analytic products. So not just reporting where a vessel is, but helping someone judge what it might be doing. That's kinda where the harder rules begin in these documents.
The first interesting piece of knowledge was that the term "product" means totally different thing to me and the intelligence community. An intelligence product is basically the output (report, assessment, publication etc.) of intelligence work and not a digital product or system like it would be in my vocabulary. Another useful clue was that the format doesn't define the product. ICD 206 explicitly includes assessments, studies, databases, graphics and interactive publications in its definition of a "disseminated analytic product". But it also says they are created by an intelligence-community analytic component. So, the analytic component could potentially be part of a digital support system that outputs intelligence products.
The way I understand this is that, in the case of Varjolaivasto, a map-based UI is not disqualified just because it isn't a PDF. Open information isn't disqualified either. Under the US standard, publicly or commercially available information becomes OSINT (Open-Source Intelligence) when it addresses a specific intelligence priority, requirement or gap.
Under this definition, I also interpret that open data can become intelligence. It just doesn't become intelligence by putting it on a dark map and making it look terribly official.
Start with the requirements, not a dataset
Varjolaivasto started with data I could easily get. An analytic product normally starts somewhere else. There's probably a customer or a user somewhere with requirements, priorities, information gaps or customer needs.
This distinction appears everywhere in the documents. ICD 208 (Maximizing the Utility of Analytic Products) starts with knowing the customer. What they need, when they need it, what they are allowed to receive, and how the product will reach them. The UK doctrine starts the intelligence cycle with direction and requirements, then moves through collection and processing to dissemination. As a designer, I can't but love the customer- and user-centricity. Intelligence Agencies have understood the most simple thing many organizations are still struggling with. A perfect answer to a wrong question is, in most cases, useless.
To put this into context, "Show sanctioned vessels in the Baltic" is a nice feature (and one that I wanted an answer to), but "Which vessel should we investigate next, and why?" is much closer to a real customer or user requirement. The second question tells you something about priority, time, uncertainty and what the user might want to do next.
Without an intended audience, a real information need and a use it should support, you may have a useful map or an impressive data visualization. But you're still missing the thing that gives the product its purpose.
Good design has always started with understanding the customer, the user and their needs. Intelligence doctrine just makes the cost of getting it wrong considerably more obvious.
Show what you saw and what you think
Varjolaivasto mostly shows observations: this vessel broadcast this identity from this position, it appears on a sanctions list, it's near critical infrastructure.
ICS 206-01 makes a useful distinction here. A standalone OSINT product can mainly just provide observations and informational content. An actual analytic intelligence product has to go further than showing facts. It also has to make it painfully clear where purely an observation ends and a judgment based on analysis begins.
ICD 203 requires analysts to:
- separate information, assumptions and judgments
- assess source quality
- consider alternatives and
- make the main message obvious
They way I understand this, in digital product terms, is that "AIS went silent for six hours" and "the vessel was probably trying to hide a ship-to-ship (STS) transfer" cannot be the same object in the UI. One is an observation. The other is an interpretation that needs evidence, assumptions, explanations and alternative explanations attached to it.
An interface could assess that a STS transfer is taking place, but there are also alternative explanations, like maybe the transponder failed, maybe the coverage was poor, maybe the vessel was hiding something entirely different. A product should not bury those possibilities just because the most dramatic explanation makes a better red alert.
Uncertainty needs more than one number
Most dashboards and alerts love a single score. Give something a risk score of 87, color it red and sort it to the top. Job well done.
Usually that score actually quietly mixes several different questions/factors. How likely is the explanation? How good is the source material? How accurate was the measurement? How much of the picture are we missing?
The US and UK material separates at least two of these:
- Probability describes how likely a judgment is to be true.
- Analytical confidence describes how sound and stable the foundation under that judgment is.
Something can be highly likely but still low-confidence if it is based on incomplete information. Something else can be a genuine fifty-fifty judgment supported by excellent information.
The UK framework evaluates confidence through the information base, analytical rigor, and the complexity and volatility of the subject. The UK's joint doctrine also treats the reliability of a source and the credibility of the particular information it provided as separate things.
Instead of collapsing everything into a score of 87, the product should show the judgment, the probability, the confidence, and what new information would/could change it.
So what I gather from all this is that uncertainty isn't just a disclaimer you hide at the bottom (like most AI products), but an integral part of the product.
A source link is not provenance
The sourcing documents go much further than adding a little "source: AIS" label.
ICD 206 requires sourcing that lets appropriately authorized readers locate sources and assess their quality and scope. It also strongly encourages summaries of the source base's strengths and weaknesses. A source reference could include its age, completeness, possible bias, technical limitations, access, validation and even the possibility of deception.
That matters with sensors, like what Varjolaivasto is using. A radar detection has resolution and geolocation uncertainty. AIS can be switched off or spoofed. A passive-radio detection may corroborate activity nearby, but often with coarser location data. "Three sources" tells you little unless you know what each can and cannot support.
Since I was also interested in how AI agents could be integrated to an intelligence product, ICS 206-01 had one interesting detail regarding it. It treats AI-assisted analysis as a sourcing problem. When AI contributes judgments, recommendations, inferences or predictions to a covered product, it has to be cited. The standard calls for relevant details such as the system or model, version, settings, performance and training-data information, prompt or parameters, and date of use. Generative AI can (and will) return a different answer to the same prompt, so reproducibility doesn't happen by magic or often at all. This kind of citation bureaucracy has pretty big effect on how AI actually can be integrated to the analysis.
Useful beats impressive
Even excellent analysis is useless if it arrives too late, goes to the wrong person or cannot be shared in the form they need.
The UK doctrine defines dissemination as getting intelligence to the people who need it, at the right time and in an appropriate form. It also includes feedback and dialogue between decision makers, users, analysts and collectors. ICD 208 adds discoverability and access. It also says alternate or sanitized versions must keep their facts, judgments, confidence and probability language consistent.
All this makes building an intelligence product quite complex, as it of course should be.
Building Aurora
Before I actually did any research on the subject, I already had started to imagine what would be an intelligence version of Varjolaivasto. The first version I built was exactly the non-standard thing I've just argued against. It was a console with risk scores and plausible-looking reasons. It didn't really show how and why it has come to its conclusions.
After the first version I started reading about the subject to learn more and decided to make my learnings and findings concrete by building a hypothetical next version of Varjolaivasto, called Aurora. Aurora is a maritime-intelligence prototype using entirely simulated vessel, sensor and assessment data. The UI is pretty messy since I just started cramming things in after I learned more and changed my opinions, but it should give some idea of the things I've written about.
You can check out Aurora at https://luntta.fi/aurora.
Aurora imagines analysts using synthetic aperture radar, or SAR, to look for vessels that have stopped transmitting AIS. Unlike optical imagery, SAR can work at night and through cloud. The prototype combines simulated SAR, AIS and passive-radio detections to help triage contacts and see what changed between passes.
I built the assessment layer around the standards and doctrines I had found. Observations are kept separate from judgments. Likelihood and confidence are separate. Each assessment includes source labels and grades, measurement uncertainty, a leading hypothesis and benign alternatives with evidence for and against them. It also adds a synthetic change note tied to an earlier pass.
I took the same approach with the AI agent built into the system (Ask Aurora). Its answers show the contacts they reference and the sensor types attached to their assessments. The scripted path derives confidence from those assessments, and the agent has explicit caveat and abstention states. Each query also logs some basic provenance: a configured engine and model identifier, cited contacts and a compact scene digest. It isn't a persistent or reproducible audit trail yet.
At least now it shows how and why.
What it still isn't
Aurora is still a prototype. Every vessel, track, sensor return and assessment in it is simulated. The confidence model is a heuristic, the hypotheses are deterministic, and nobody should mistake its calibrated-sounding language for a calibrated operational system.
It's also missing the most important thing: a real customer with a real requirement and a real use for the answer.
There is plenty more missing: full lineage to raw inputs, versioned assessments, real audit and handling controls, identity resolution, and a collection loop. Then there is security, accreditation, training and governance.
In other words, its missing most of the difficult institutional stuff that a nice front-end prototype lets me conveniently ignore. :)
So, unfortunately, reading a pile of public documents and building a deeper prototype has not turned me into an intelligence professional just yet. Aurora borrows from public analytic tradecraft. It is not a validated or operational system, and I'm not claiming compliance with standards written for organizations I have never worked with or in.
I also still can't tell you what the Finnish Border Guard, Defence Forces or Security and Intelligence Service would think of it. Researching public documents is not the same as involving the people who do the work. I did this to learn a bit more, not to build a commercial product.
But I do have a better answer to the question that started this rabbit hole.
An analytic intelligence product isn't a tactical-looking interface, a secret dataset or a confident score. It is tied to real requirements, priorities or needs, and to an intended use. It separates observation from judgment, shows uncertainty and sources, arrives in time to matter, and improves through feedback.
At least that's what I've learned so far.
If you work with intelligence products, I'd love to hear what I've misunderstood, oversimplified or missed.