Network analysis: mapping the Netherlands' threat landscape
By Cascha van Wanrooij
Historically, the Netherlands became world-renowned for mastering water management after the 1953 floods. But today’s challenges are not only greater, but also more complex and intertwined: cyber attacks, ecological threats, and societal polarization. DenkWerk, a Dutch think tank, recently published "Resilience by Design” — a comprehensive analysis of emerging threats the Netherlands must prepare for.
DenkWerk’s approach involved building a network that visualizes how these threats interconnect and that identifies which ones can cause a ripple effect. The methodology shares some similarities with the World Economic Forum's annual risk report, but with three key differences. Firstly, it focuses specifically on the Netherlands. Secondly, it relies on existing data from ministries and research bureaus rather than expert surveys. And thirdly, it maps the directional relationships between threats.
Unlike traditional risk models which plot threats on two axes (impact and probability) to identify priorities, DenkWerk's directional analysis adds interconnectedness as a crucial third dimension. This way, it reveals how threats cascade through the system, illuminating upstream intervention points that the standard two-dimensional view misses.
The technical challenge
My contribution to DenkWerk's report was building this network. Specifically, I developed a node analysis tool that would help identify the central nodes ("knooppunten"): the threats that are likely to trigger other important threats. By identifying these central nodes, we could focus preventive efforts where they would have the greatest impact.
I split the project into three phases:
Programmatically scrape and download report PDFs from government and research bureau websites
Process content through LLMs to identify threats and their relationships
Construct the network and perform centrality analysis
Let's dig into phase two, where things got properly interesting.
Initial approach and cost constraints
After collecting approximately 100,000 PDFs, I immediately hit the universal project constraint: cost. My first instinct was frame-semantic parsing (here's an elegant Science Advances paper demonstrating this), which doesn't require massive decoder-only LLMs. But Dutch fine-tuned language models are scarce, so GPT-style models became the practical choice.
Starting with GPT-4o mini for cost efficiency, I designed a pipeline where the model processed document chunks to produce structured outputs: dictionaries containing cause-effect pairs with verbatim citations. N-gram matching verified citations against source text. Topic modeling then aggregated these relationships into broader threat categories, between which we can track relationships.
The statistical challenge of rare events
The pipeline functioned well for most cases, but revealed a fundamental issue: causal relationships between threats are rare in these documents. This scarcity creates a difficult statistical problem. Even with 99% precision/recall, processing thousands of chunks means accumulating substantial errors. With rare events, that 1% error rate becomes highly problematic. The model's mistakes weren't obvious hallucinations but subtle misinterpretations. One telling example: documents noted decreased CO2 emissions during COVID-19, particularly in aviation. The model cited this as evidence that pandemics worsen climate change, completely inverting the actual relationship.
Multiple mitigation strategies failed to resolve these issues:
Extensive prompt refinement
Alternative chunking strategies
Decomposing tasks into sequential LLM calls
Building comprehensive testing frameworks
Each fix introduced new problems. My prompts evolved into lengthy lists of prohibitions rather than clear instructions. The core issue remained: when searching for rare signals, even small error rates compound into significant noise.
The bigger model solution
Then Gemini 2.5 Flash (preview) arrived. At $15 cents per million tokens versus $10 cents for GPT-4o mini, it wasn't dramatically more expensive. But the performance difference was striking.
I scrapped my elaborate prompt engineering and started fresh with simple, clear instructions. It just worked. This is Rich Sutton's "bitter lesson" in action: clever engineering usually loses to approaches that better leverage computational resources. All my GPT-4o mini optimizations were essentially band-aids on a model that wasn't quite powerful enough for the task.
Lesson learned: start with the best model there is on a data subset. Establish what's possible, then optimize for cost if needed. Don't start cheap and try to engineer your way up, you'll waste time and sanity. Donald Knuth’s software engineering lessons can apply to machine learning as well.
What the network revealed
Among other things, the final analysis uncovered that cyber attacks, hybrid warfare, and societal polarization form a self-reinforcing triangle at the center of our threat landscape. This mirrors the recent Dutch security agency reports. It’s an unsurprising result given that these sorts of reports also belong in our corpus, but it is a nice, if somewhat unsettling, validation check.
Building the interactive visualization
The network data required an interface that would make exploration intuitive while maintaining transparency about sources. I used Claude Sonnet and Gemini 2.5 Pro to help quickly develop a static website with interactive graph visualization.
The primary visualization uses Reagraph, a WebGL-based graph library. While generally excellent, it had limitations in our case. For example, the clickable area for edges was too small. Nevertheless, modern LLMs proved very useful here, helping me quickly understand the library's architecture and create a forked version with improved interaction targets. This approach — using LLMs to navigate and modify unfamiliar codebases, significantly sped up development.
When SVG export functionality became a requirement, I took a pragmatic approach. Since Reagraph's WebGL foundation made direct SVG export challenging, I had the LLMs build a simple SVG-based graph renderer that matched our visual design. Once again, this shows the use of LLMs for these kinds of “standalone” projects.
Most importantly, every connection in the graph links back to its source. Click any threat relationship and you'll see the exact report and passage that identified it. Clicking any threat relationship reveals the original government report and specific citation. This design ensures the graph provides a transparent look into human-authored analysis rather than representing an opaque AI interpretation.
The complete dataset and interactive visualizations are available at: https://denkwerk-kickstartai.nl/knooppuntenanalyse/
Concluding thoughts
This project was genuinely fun to work on: a problem where AI served to connect human insights rather than generate synthetic ones. With LLMs handling the work of extraction and relationship mapping, allowing us to scale to thousands of documents.
The experience confirmed that core software engineering principles are just as relevant in ML work. Start with the best available tool, establish what's possible, then optimize.
Finally, building interactive websites with AI assistance has become really enjoyable. The usual cycle of coding, testing, and iterating speeds up when you can quickly navigate unfamiliar libraries and prototype ideas. Static sites with rich interactivity hit a sweet spot for LLM-assisted development. Instead of spending hours reading documentation, you can immediately test ideas and explore alternatives — removing the hurdles that typically slow down experimentation.
💡 Want to learn more about the KickstartAI community and our mission to accelerate AI adoption in the Netherlands? Check out our website, listen to our podcast, or follow us on LinkedIn! Want to connect with Cascha? Find him on LinkedIn!
