This is part 2 of my Robodex series, where I explain how I was finally able to solve my Second Brain frustrations.
Part 1 - How I finally solved my Second Brain frustrations

The fundamental constraint of any current AI assistant is that it holds no memory between sessions. Open a new conversation and the agent starts from zero: no recall of the notes it filed last week, no knowledge of the folder structure it has worked with for six months, no awareness of the mistake it made three sessions ago. The only thing that carries information forward is what you wrote down. CLAUDE.md is what I wrote down.

It is a markdown file at the vault root, currently running to about 1,500 words. The agent reads it at the start of every session. Think of it as an onboarding document for a worker who resets completely each Monday morning: the vault structure, the routing rules, the filename conventions, what operations require confirmation, what never to attempt. Write it poorly and the agent improvises. Write it precisely and the agent is predictable. The difference between those two outcomes, across six months of daily use, is substantial.

Structure is the key

The vault structure block at the top of the file looks like this:

The inline comments are not decorative. An agent told “05 - Inbox is for rough notes” will make different decisions than one told “staging area; the daily task categorizes, enriches, crosslinks, and moves them to their final vault location.” The second version is a job description. It tells the agent not just what the folder is, but what process it belongs to and what should happen to everything that lands in it. That specificity is the difference between an agent that files correctly and one that improvises.

The most load-bearing section of the file is the layer-routing decision table. Every note the agent processes has to be placed somewhere in the vault’s eight layers, and the rules that govern that placement are exactly the kind of decision that collapses into inconsistency when expressed in prose. A table with explicit decision rules has proven more reliable than any amount of paragraph-form guidance:

Six rows. The agent has never misrouted something this table covers.

Continuous Improvement

CLAUDE.md started at about 200 words. It grew to its current length through a process that is less a design exercise than a feedback loop: every time the agent does something wrong, I write a rule. A verbal correction in conversation is forgotten by the next session; a rule in the file persists. Mistakes compound into precision.

The incident-specific frontmatter section is a useful illustration. The vault tracks confirmed cyber incidents, and early notes had inconsistent geography fields: “Netherlands” in one, “The Netherlands” in another, “NL” in a third. The fix was two rows of enumerated values:

geography: NL | EU | Global
sector: [Government, Finance, Healthcare, Telecom, Energy, Retail, Manufacturing, Technology, Education, Aviation, Defence, Sports, AI]

Exact values that are clearly listed. The agent picks from the list. The result was that inconsistency across 100-odd incident notes was completely gone.

Tag formatting had the same problem, Obsidian doesn’t support multi-word tags with spaces, and the agent kept producing supply chain instead of supply-chain. One sentence in the file fixed it permanently: “Tags must be a single word or hyphenated.” The rule has been followed in every session since.

The clearest example of what CLAUDE.md is actually for involves the Personal folder.

The vault includes a section for personal notes: invoices, holiday planning, recipes, an overview of the LEGO I own. Early on the agent occasionally crosslinked cyber research notes to personal content when a keyword matched tangentially. A NIS2 enforcement note would acquire a crosslink to a grocery receipt because both mentioned “the Netherlands.” I added a routing boundary to the file: Personal/ is a separate subtree; crosslinks do not cross the boundary between it and the cyber content.

Every mistake the agent makes is now a candidate for a new rule. The manual compounds over time, and the agent working with the vault today is better-instructed than the one from six months ago, not because the model changed but because the instructions and rules got more precise.

Limitations

The file has limits worth naming. The agent occasionally ignores a rule, and the pattern is consistent: it happens most often when a rule is written in prose rather than as a table or an enumerated list. The response is always the same, which is to tighten the rule. I’ve never had to correct the same mistake three times. The second correction always involves converting prose to a table or replacing vague guidance with explicit values.

There is also a category CLAUDE.md can’t cover: genuinely novel situations the file never anticipated. When those arise, the agent improvises. Sometimes the improvisation is fine. Occasionally it produces a mess. For file operations, which are the irreversible category, I added hard limits: never delete files, confirm before anything goes to the removal queue. Content decisions have latitude, but file operations have hard limits.

Growing one mistake at a time

Any AI you work with repeatedly needs a written operating manual, and every mistake it makes should become a rule in it. This applies past knowledge management to coding agents, drafting agents, support agents: any AI doing the same type of work more than a few times will drift without a contract.

The key take away is:

This series explains how I used Claude Cowork combined with Obsidian to solve my second brain frustrations. For years I’ve been looking for a way to clear my mind quickly, with minimal maintenance and the tools to get information quickly. And what’s great about this solution, is that it’s basically independent of the tool or model you use. Because everything is stored as markdown files, it’s portable and transferable, which is especially handy if a government decides to block access to specific models or tools.

One thing to note, is that there are many tutorials out there about this exactly this topic, each with their own methods, solutions and quirks. I read more then 10 to figure out mine approach, so this is my contribution to the tutorial landscape, in the hope it will help someone else, just like all those others helped me.

Every personal knowledge system dies the same death. The capture rate drops, the filing backlog accumulates, the search becomes unreliable, and one day you realise you haven’t opened the application in six weeks. The graveyard is a universal experience among anyone who has tried to build one, which is why you can tell the vintage of a knowledge worker by the tools they no longer use. First I tried Evernote, but the UI/UX wasn’t for me. After that, OneNote was the tool of choice, since it integrated with my M365 tools, but it being a Microsoft product meant it caused more irritation then joy. Notion seemed gold at first, allowing me to build complex notes with databases and other cool stuff, but it gave way to the same accumulation of debt the moment the initial enthusiasm ran out. Even an earlier attempt at exactly this Obsidian setup collapsed under its own weight around month 4, when the structure I’d designed began to require more maintenance than the notes themselves.

The cause of death in every case was identical: the work of maintaining a knowledge system is human work, and I reliably stopped doing it. Again, and again.

Monday morning, 08:20. An agent is processing my inbox while I bring my kids to school. It’s reading the rough notes I dropped into a staging folder over the past week: a saved URL about Dutch NIS2 enforcement, a news article about Digital Autonomy, a cool infographic about AI governance, a nice recipe I want to make, 3 lines I typed into my phone at 11pm before going to sleep. By the time I sit down, those notes are categorised, tagged, crosslinked, and filed in the correct location. The inbox is empty. I did nothing to make that happen.

That is the answer to the maintenance problem.

The requirements

So after realising all my previous attempts failed at maintenance, I set out a few non-negotiable requirements:

I don’t want to manually

• enter notes

• reference and cross-link notes

• summarize notes

• order and structure notes

Also the notes had to be easy transferable, I didn’t want to get stuck to a specific tool.

Because these were exactly the things that caused frustration as the database grew. Luckily, this was right around the time that AI and LLMs were getting more mature and Claude CoWork came along.

The architecture

The architecture that makes this possible fits in a paragraph, and the central decision in it is worth understanding precisely.

Obsidian stores everything as plain markdown files in a local iCloud folder. No proprietary format, no database, no sync API, no cloud dependency. The files are just files: readable by any text editor and writable by any AI. Claude Cowork is the worker: a desktop agent I direct in natural language, with no integration layer between it and the files it reads and writes. A single markdown file at the vault root, called claude.md, is the operating manual: routing rules, naming conventions, frontmatter requirements, what never to overwrite, what to always verify against the live vault before acting.

Plain markdown is the right choice because it removes the translation layer that makes AI assistance fragile. When I paste a file, note or URL and say “save this,” the agent fetches the page, writes a structured note with a summary and crosslinks to related content already in the vault, files it in the correct folder per the routing rules, and confirms the filename. The file I open afterward is one I could have written myself in 15 minutes. I didn’t have to. And critically, it is exactly the same file format I would have produced: not a database record, not a synced object, not something that requires the app to render. Just a markdown file in a folder, already where it belongs.

The folder structure that determines where things belong:

00 - Sources/       single-origin material — raw notes, clippings, first summaries
05 - Inbox/         staging area — rough notes drop here, agent routes daily
10 - Reference/     stable material — frameworks, regulations, glossaries
20 - Templates/     reusable playbooks and work products
30 - Projects/      project concepts in development
50 - Analysis/      synthesised insights from multiple sources
80 - Presentations/ presentations given or in preparation
90 - Published/     content that has left the vault

A note enters at 05 - Inbox or 00 - Sources. From there it can develop into a synthesis in 50 - Analysis, through a draft, eventually into 90 - Published. The agent knows these routing rules because I wrote them down in CLAUDE.md, and it has followed them consistently since the first session.

A day in the vault looks like this.

I paste a PDF (or URL, random note, graphic, etc.) into Cowork and say “save this.” The agent saves a clipping with a short summary and crosslinks to anything related already in the vault; the whole operation takes about 15 seconds.

Rough notes from a meeting go to 05 - Inbox, where the daily task in the morning picks them up, determines what they are, enriches them, and routes them to their final location without further input from me. Day 28 of each month, a monthly summary generates automatically: everything saved that month, key themes, what changed in the vault’s composition. Day 1 of the next month, a batch of content ideas drawn from that summary. Sunday mornings, topic reference cards get reviewed and updated against any new content added during the week.

The vault currently has 547 notes, and each one is more useful than the last because every new note has more to connect to. The crosslinking compounds as the vault grows.

Every previous second brain I built was most useful in its first few weeks, before the debt accumulated. This one improves with age, because the maintenance that would have killed the others is now fully automated.

The principle embedded in this architecture transfers past personal knowledge management to any workflow where you want an AI to do ongoing work.

• Separate storage from labour.

• Pick a storage format an agent can read and write directly.

• Plain files beat apps and APIs: the agent is replaceable; the files aren’t.

• If a better model comes along next year, or if Cowork is superseded by something else, I point the new agent at the same folder and hand over the CLAUDE.md.

• The vault transfers intact. No migration, no re-filing, no lost crosslinks.

• The storage doesn’t depend on the worker, which means the investment in the storage compounds independent of any decision I later make about tooling.

The agent is rented labour, the files are mine. (yes, this is an AI generated oneliner.. )

Subscribe for free to get notified on each of the following posts!

The output

Basis: team results over the past 8 years (2018–2026: World Cups, continental tournaments, qualifying), adjusted from a ranking/odds baseline. Times in CEST (NL); the date shown is the NL calendar date. Predictions generated 11 June 2026, before any match was played.

Title Favorites: Spain is the consensus favorite at +450, with France just behind at +450 to +500, followed by England (+700), Brazil (+800), and Portugal and Argentina (around +900).

The topscorers will be, ordered by most likely:

• Kylian Mbappé

• Harry Kane

• Erling Haaland

• Mikel Oyarzabal

• Lionel Messi

• Christiano Ronaldo

It ended with an interesting note though:

“Even the most likely single result hits roughly 40-60% of the time; expect a meaningful share of these to be wrong.”

It is an uncertainty problem.

The body of work that names this problem most precisely is not in any cyber framework. It is Nassim Nicholas Taleb’s two books The Black Swan (2007) and Antifragile (2012). Stripped of the philosophy (which is not why most of us would read them), Taleb provides a small set of named principles that diagnose, with uncomfortable accuracy, what is wrong with mainstream cyber risk thinking. He also points to concrete fixes.

Five theorems: what each one means, why it matters in cybersecurity, and what changes in a programme that takes it seriously. No casino math. No epistemology detours. Just the operationally useful parts.

AI disclosure This post was written with substantial AI assistance. The author directed the work and wrote parts of it; AI drafted or expanded others, using claude-sonnet-4-6.

Theorem 1. Mediocristan and Extremistan: know which world you’re in

Taleb’s first move is to split the statistical world into two regimes.

In Mediocristan, outcomes are bounded. Human height, blood pressure, daily call volumes, machine error rates. The distribution is a bell curve. The mean is meaningful. One more observation barely shifts the average. The biggest outlier you will ever see is two or three times the typical case, not a thousand times.

In Extremistan, outcomes are unbounded. Wealth, book sales, pandemic mortality, and — critically for us — cyber loss. The distribution is a power law. A single observation can exceed the sum of everything that came before. The mean is uninformative. The tail is the entire story.

Cyber lives in Extremistan, for three structural reasons. Hyperconnectivity removes the independence that bell-curve math assumes: one Log4j, one SolarWinds, one CrowdStrike update, one shared Cloudflare configuration correlates failures across thousands of unrelated organisations. The tails fatten because the underlying graph is not the one drawn on the risk register. Attackers are adaptive, so the next event is not drawn from the same distribution as the last; novel attack categories (prompt injection, agentic supply-chain compromise, AI-generated zero-days) keep appearing with no historical analogue. And the loss distribution itself is power-law: the Verizon DBIR, IBM’s Cost of a Data Breach study, and the Advisen loss database all show the same shape, a long body of routine incidents and a fat tail that contains most of the damage.

Taleb’s original illustration is deliberately extreme. Take a room of one thousand people and ask what happens to the average height if you add the world’s tallest person — it barely moves. Take the same room and ask what happens to the average net worth if you add the wealthiest person on the planet — it shifts by orders of magnitude. Height lives in Mediocristan; wealth in Extremistan. The structural reason: height is determined by many independent genetic factors, each contributing a small bounded amount, and the distribution is genuinely bell-shaped. Wealth is determined by network effects and compounding returns, which are neither independent nor bounded. The mathematics of one world cannot be imported into the other.

The academic literature has arrived at the same point by a different route. In a 2026 paper in Technology and Regulation, Bibi van den Berg draws on Frank Knight’s 1921 typology to separate what she calls ‘statistical uncertainties’ (where historical data can generate useful probability estimates, however imperfect) from ‘Knightian uncertainties’ (where the distribution is nonexistent and measurement is impossible in principle, not just in practice). Her terminology differs; the diagnosis is the same. Cyber losses at the catastrophic end, state-sponsored attack campaigns, and systemic infrastructure failures are Knightian. Treating them as if they are statistical is not a conservative approximation. It is a category error.

What changes if you accept this. Stop reporting expected annualised loss to the board as if it summarised anything. Report tail scenarios separately, with their structural assumptions visible. Treat any forecast presented as a single number with a confidence interval as a model statement, not a reality statement. The big incidents are not bolts from the blue — they are the shape of the distribution. A security programme that doesn’t recognise this is preparing for a world it doesn’t live in.

Theorem 2. The Ludic Fallacy: your quantification model is not the world

Taleb borrows the Latin ludus (game) to name the mistake of confusing the well-defined uncertainty of a game with the wild uncertainty of reality. In a casino, the rules are fixed, the distribution is known, no one changes the deck, and the math works perfectly. The world is not a casino.

This is the single sharpest critique of mainstream cyber risk quantification. FAIR-style Monte Carlo, annualised loss expectancy, and most board-facing risk dashboards are casino math. They take historical loss data, fit a distribution, simulate ten thousand draws, and produce a confidence interval. Inside the model, the answer is precise. Outside the model — in reality — three of the model’s assumptions are routinely violated. The rules change (new attack techniques, new regulations, new dependencies). The distribution is non-stationary (yesterday’s frequencies don’t predict tomorrow’s). An adversary actively works to find what the model didn’t anticipate.

The output is useful inside its assumptions. The problem is what happens next. The precision of the number flatters the precision of the underlying knowledge. A 90% confidence interval is a statement about the model. When the model is gamelike and reality is not, the interval understates the tail by an order of magnitude or more. The catastrophic scenario — the one the organisation actually cannot survive — is hidden inside a thin probability the model has no real basis to estimate.

Taleb illustrates the fallacy with a deliberately mundane counter-example. A casino, he points out, is not actually the risky environment for the casino itself. The house’s edge is precise; the mathematics is well understood; the distribution of outcomes is known in advance. The casino is Mediocristan by design — and the casino operators had risk-managed the tables exhaustively. The losses that actually threatened the business came from entirely outside the model. A tiger mauled the headline performer on stage, shutting down the show. An employee failed to file regulatory paperwork, triggering a legal crisis. A disgruntled patron attempted to blow up the building. Not one of these appeared on the risk register. The moral is precise: the model protects you from the risks you modelled, and leaves you exposed to everything it did not anticipate. In cybersecurity, the analogue is everywhere — the risk register addresses last year’s incident categories with admirable thoroughness, and leaves the next novel attack class entirely unaddressed.

Martijn Dekker’s UvA inaugural lecture adds a practitioner dimension: cybersecurity claims are unfalsifiable. You cannot prove you are secure. You can only observe that you have not yet been breached. The quantification we produce sits on a foundation that, strictly speaking, cannot be verified.

What changes if you accept this. Use quantification, but communicate its limits honestly. The phrase that should appear next to every Monte Carlo output is: this is a model estimate under stated assumptions; the tail scenarios are outside the model’s reliability. Force the conversation about which scenarios live in the tail, and treat them with scenario planning rather than probability multiplication. The point is to stop letting the math do work the data cannot support.

Theorem 3. Silent Evidence: what you don’t see is the point

The cemetery of failed initiatives doesn’t get to argue its case. The breaches that didn’t happen don’t credit the controls that prevented them. The attackers who tried and failed silently don’t show up in any metric. The lessons-learned literature is written by the survivors of past breaches, not by the organisations that quietly went under. The data you have is shaped by what survived, not by what is.

This is one of Taleb’s most useful tools because it shows up everywhere in cybersecurity, and it is almost never named.

Taleb’s named illustration is the turkey. The bird is fed every day, without fail, for a thousand days. With each passing day its confidence in the reliability of human kindness grows — supported by more data, more consistent observations, a more stable statistical picture. On day one thousand, its confidence is at its historical maximum. On day one thousand and one, it is slaughtered. The turkey’s error was not a failure of observation. Its observations were perfectly accurate. The error was structural: it used the past to predict a future governed by an entirely different logic, one whose defining event could only appear once, and whose appearance would make all prior data irrelevant.

For cybersecurity, the parallel is exact. An organisation that has not been breached in five years has more data confirming its controls than one that has been operating for eighteen months. That data feels like evidence. It is, in fact, a growing accumulation of turkey observations. The threat landscape shifts, attacker capabilities expand, novel techniques develop, new exposures are introduced through acquisitions and integrations — and none of this shows up in the absence-of-breach metric. Day one thousand arrives as a surprise. It always does. The danger is not ignorance; it is confidence built on a sample that cannot, by its nature, contain the information that matters most.

Three examples of how this plays out in practice. First, the justification for almost every legacy control: “we haven’t had an incident, so it must be working.” That is observational evidence, not causal evidence. The absence of a breach could be explained by the control, by attacker disinterest, by luck, by a different control nobody is tracking, or by an incident that simply hasn’t been detected yet. Second, the entire incident response literature is shaped by organisations that survived to write it up. The ones that didn’t — the ones where the breach was the end of the organisation — don’t contribute lessons. Third, the unfalsifiability problem mentioned above is silent evidence in action: an absence of detected breaches is being treated as evidence of effective control, when the more honest reading is “we don’t know.”

Taleb’s sharpest historical example is ancient medicine. Treatments survived because patients survived — but patients also died from those same treatments, and the deaths were attributed to the disease rather than the cure. The entire body of medical knowledge was shaped by what practitioners chose to record, and they chose to record the cases that confirmed their methods. The discipline looked reliable; it was selection-distorted. The same structure applies to almost any knowledge domain built on practitioner experience rather than controlled experiment.

Cybersecurity is practitioner-experience-dominated and experiment-poor. The controls credited with prevention almost never have a counterfactual — no one runs the same organisation without the control for three years and compares the incident rate. What this means in practice: the confidence the controls-based programme implies is wider than any dashboard currently shows. Silent evidence does not narrow the error bar. It hides it.

What changes if you accept this. Be deeply suspicious of any control whose justification rests on “we haven’t had an incident.” That sentence should trigger a follow-up, not an approval. Build the discipline of reverse audits: not “what are we missing?” but “which of our controls have we actually verified, and which are we prepared to remove?” Force the dashboard to distinguish between observational and causal evidence — the honest version reads, we believe these controls reduce risk, the evidence is observational, and we have not run the counterfactual. It is intellectual honesty about a field that quietly runs on assumed effectiveness.

Theorem 4. The Antifragility Tetrad: most programmes aim at the wrong rung

Taleb’s central contribution in his second book is the term antifragile: a system that gains from disorder, structurally distinct from robust (which holds) and resilient (which recovers). The distinction sounds like a slogan until you understand the biological mechanism Taleb draws on: hormesis. It is a well-documented phenomenon in physiology where small doses of a stressor (a toxin, a physical load, a pathogen) make an organism more capable of handling larger doses later. This is not metaphor. It is a structural property of living systems that has no equivalent in engineered ones. A bridge does not get stronger from near-misses; a muscle does. The practical consequence: antifragility requires exposure to stress as a design input, not an accident to be avoided.

Taleb maps this onto three symbols. The Sword of Damocles hangs above its owner: fragile, poised at the edge of catastrophic failure, calm conditions its only friend. The Phoenix rises from its own ashes: resilient, returning to the prior state after each destruction. The Hydra grows two heads for every one cut off: antifragile, structurally stronger with each stress applied. Most CISO programmes are Damocles with Phoenix aspirations. The Hydra is rarely articulated as a design target, because it requires a fundamentally different relationship with failure: not suppressing it, not recovering from it, but treating it as the raw material of improvement. He lays out four states, and the tetrad is one of the most useful diagnostic tools in cybersecurity that almost no one uses.

1. Fragile — breaks under stress. The system gets worse, sometimes catastrophically. Monolithic legacy estates with single points of failure. Most organisations are here, regardless of what their risk register says.

2. Robust — survives stress unchanged. Hardened, redundant, predictable. The goal of most “hardening” programmes.

3. Resilient — survives stress and returns to the prior state. The current industry aspiration. NIST CSF 2.0, DORA, NIS2 — all built around it.

4. Antifragile — gains from stress. After the event, the system is structurally better than before, not merely repaired.

Almost every CISO programme aims, implicitly, at robust or resilient. Antifragile is rarely articulated as a goal, let alone designed for. And yet it is the only state that actually keeps solving the problem over time. Robust systems eventually meet a stress big enough to break them. Resilient systems eventually meet a stress that permanently changes the environment, and “the prior state” no longer exists to return to. Antifragile systems use the stress as input: each incident leaves the organisation faster, more decentralised, more legible to itself than before.

What does antifragile look like concretely in cybersecurity?

Chaos engineering. Netflix’s Chaos Monkey approach applied to production security infrastructure — deliberately killing systems to force the organisation (and the people) to handle failure as a routine condition, not an exception.

Blameless post-incident learning. Punitive cultures suppress the error signals antifragile systems feed on. If people cannot speak freely about what went wrong, the organisation cannot learn from it.

Attack surface rotation. Ephemeral containers, short-lived credentials, rotating certificates. Any foothold an attacker gains becomes temporary by design. The system benefits from its own churn.

Decentralised decision authority during incidents. Fragile organisations escalate everything to a central command during crises. Antifragile ones push authority to the edge, where responders can act on local information without waiting for approval. This is also the practical answer to Dekker’s decision latency problem: the time between an alert and a meaningful response decision. As latency increases, solution space shrinks and damage compounds. Decentralisation directly attacks the problem.

Assume-breach architecture. Zero trust is not just a network design; it is an antifragile posture that improves with each detected anomaly rather than collapsing when a perimeter is crossed.

What changes if you accept this. Run the tetrad over your stack. For every major control and process, ask: under stress, does this break, hold, recover, or improve? The honest answer for most of the stack is “we hope it holds.” That gap — between hoping it holds and designing it to improve — is the antifragility opportunity. It is also the highest-leverage investment most security programmes are not making.

Theorem 5. The Barbell and Via Negativa: where to put the money

Taleb’s strategic recommendation under deep uncertainty is the barbell: combine extreme caution on the downside with deliberate, aggressive exposure to controlled stress on the upside. Avoid the moderate middle, where risks are poorly understood and improvements never materialise. Pair this with via negativa: the principle that improvement often comes from subtraction, not addition. Removing fragility tends to be more powerful, and more durable, than adding strength.

The barbell originated in Taleb’s thinking about portfolio construction. The conventional wisdom (diversify across a range of moderate-risk assets) concentrates exposure in precisely the zone where model uncertainty is highest. You believe you understand the risk distribution; you don’t; the distribution is fat-tailed; the middle blows up. His alternative: hold nothing in the middle. Push to the extremes. A large allocation in assets where the downside is hard-capped — government bonds in the original formulation — paired with a small allocation in instruments with genuine asymmetric upside: deep out-of-the-money options that lose their premium in most scenarios but pay many multiples in the rare scenario that needs them. The defining property of this structure is bounded downside and uncapped upside. The expected value is lower than a moderate-risk portfolio in normal conditions; the survival probability under tail events is dramatically higher. In the Extremistan world he is describing, survival probability matters more than expected value.

Via negativa has older roots. Taleb draws on both Stoic philosophy and apophatic theology, where God is understood through negation, defined by what is absent, because negative knowledge is more stable than positive knowledge. He secularises the principle into a general epistemological claim: subtractive knowledge is more durable than additive knowledge, because it does not expire. Positive knowledge (knowing what works) has a shelf life that tracks the rate of change in the domain. Negative knowledge (knowing what demonstrably does not work) accumulates and stays valid. The formula for effective security changes every two years as threat actors adapt and technology shifts. The list of what has consistently failed (single-vendor critical dependencies, unrotated long-lived credentials, unverified backups, perimeter-only defences) compounds and holds. Pruning is an epistemological exercise.

The barbell, translated into a security programme, has three parts.

Left side: hard caps on catastrophic loss. Identify the loss scenarios the organisation cannot survive: data-destructive ransomware, regulatory tail event, foundational supplier collapse, complete loss of customer data confidentiality. Then engineer hard caps against each. Immutable backups. Network segmentation that means a single foothold doesn’t reach everything. Contractual liability transfer where possible. Cyber insurance with realistic sub-limits, read carefully. Pre-negotiated forensics and legal retainers, because no one negotiates a contract well during a crisis. These investments are not optimised for the mean. They are optimised for the tail.

Right side: deliberate, frequent stress. Chaos engineering. Production-realistic red teams operating with minimal constraints, not scope-documented penetration tests that confirm what you already suspect. Tabletop exercises that rehearse decisions rather than technical recovery — Dekker’s decision latency is where Extremistan meets the org chart, and most tabletops still test the wrong layer. Attack surface rotation as continuous practice rather than annual exercise. Inverse stress testing: instead of asking “can we recover from scenario X?”, ask “what would need to go wrong simultaneously to cause total failure?” Then deliberately probe those combinations. This is Taleb’s barbell in practice: protect the catastrophic downside by actively hunting for it.

Middle: via negativa. Prune. Most security stacks are carrying compliance theatre, dashboards no one reads, escalation ladders that add latency without adding value, and controls whose only justification is silent evidence (Theorem 3). The discipline of pruning (what Dekker calls the response to cyber senescence, the aging and degradation of security ecosystems through accumulation of uncertain controls) is structurally absent from almost every framework. NIST CSF doesn’t have a “Prune” category. ISO 27001 doesn’t ask you to remove controls. The result is the slow accumulation of fragility, dressed as defence-in-depth.

What changes if you accept this. Build pruning into the operating cadence at the same rhythm as adding controls. Move budget from the middle toward both ends of the barbell. And remember Taleb’s clearest line on the right side: optionality is cheap until you need it, when it becomes priceless.

Putting it together: five operating principles

If the five theorems are the diagnostic, the five operating principles below are what changes in the programme:

1. Two parallel risk views, never one. A mean-loss view for budgeting decisions. A tail-loss view for survival decisions. Never collapse them into a single chart. The board needs to see both, with the assumptions of each visible.

2. A pruning discipline. Treat control removal as a discipline of the same rank as control addition. Schedule reverse audits. Make pruning targets measurable.

3. Decision rehearsals over technical recovery exercises. Most tabletops test scripts. The more important question is whether leaders can make the right calls, in the right order, fast enough. Rehearse the choices, not just the recovery.

4. Convex over concave tooling. Prefer tools with capped downside and significant upside — modularity, ephemeral infrastructure, segmentation. Avoid tools with capped upside and significant downside — long-lived shared dependencies, monolithic suites, single-vendor stacks. The CrowdStrike and Cloudflare incidents are textbook concave-payoff failures: a moderate steady benefit on the upside, a catastrophic tail on the downside.

5. Five strategies, not one. Bibi van den Berg’s work at Leiden University makes the same argument from a different direction. In a 2026 paper in Technology and Regulation, she argues that cyber risk management is only legitimately applicable to the ‘statistical’ end of the uncertainty spectrum — threats frequent enough and similar enough to generate reliable probability estimates. Knightian uncertainty (novel attack classes, state-sponsored campaigns, systemic infrastructure failures) demands supplementary approaches: preparedness — building general absorptive capacity regardless of which specific threat materialises — and Security by Design — embedding security as a structural property rather than a risk-adjusted add-on. Her earlier work catalogues five strategies for handling cyber uncertainty: risk management, resilience, regulation, trust, and considered acceptance. Most programmes are massively overweight on the first. A portfolio approach to uncertainty handles the full spectrum better than treating risk management as the whole field.

Using the theorems: questions worth asking

One or two diagnostic questions per theorem, designed to surface the assumptions most programmes leave unexamined. None require a consultant. They require a CISO willing to ask them, and a board willing to hear the answers.

On Mediocristan and Extremistan. Bring this into the next risk committee: If our three highest-severity scenarios materialised simultaneously at maximum impact, would the organisation survive? Then ask how that question is tracked separately from the mean-loss view on the current dashboard. If the answer is that it is not tracked separately, the board has one risk view where it needs two. The follow-up is sharper: Which of our tail scenarios have no historical analogue in our sector? Those are the ones the model is least equipped to price — and most likely to understate.

On the Ludic Fallacy. Ask the team that produces your risk quantification: What are the three assumptions this model makes that we have not empirically tested? Every Monte Carlo output has them. Naming them shifts the conversation from the precision of the number to the quality of the inputs — which is where the actual uncertainty lives. Then ask: Which attack categories that have materially affected peers in the last eighteen months are not represented in our risk register? The gap between those two lists is the space the model cannot see.

On Silent Evidence and the Turkey. Ask for a reverse audit: Which of our controls has an evidence base beyond the absence of incidents? For each control, has it ever been intentionally removed or bypassed to observe what happens without it? If the answer is no, effectiveness is assumed, not demonstrated. The harder question, rarely asked: If our environment were already compromised today and we simply hadn’t detected it yet, what would we expect to see — and are we actively looking for it? That reframes the absence of a breach as a hypothesis to test rather than a fact to report.

On the Antifragility Tetrad. Run the tetrad against your three most critical systems and your three most critical processes. For each, ask: Under significant stress, does this break, hold, recover, or improve? The honest answer for most of the stack is “we hope it holds.” Then ask: In the last five years, has any incident left us structurally better organised than before — and if so, was that by design or by accident? If the answer is accident, the organisation is learning by luck rather than architecture. Antifragility is the decision to make learning structural.

On the Barbell and Via Negativa. Two questions, both uncomfortable. First: What specifically are the scenarios that would end this organisation — not damage it, end it — and what hard structural caps exist to prevent each one? If the answer involves hoping controls hold rather than engineering the cap, the left side of the barbell is empty. Second: When did we last remove a control — not replace it, remove it — and what is the process for doing so? If there is no process, the programme is accumulating fragility with every framework update, every new compliance requirement, every tool added to an already-saturated stack. Via negativa demands an answer to that second question before the next addition is approved.

They are conversation instruments. The point is to find, in the gap between the question and the answer, exactly where the programme’s hidden assumptions live.

The board-level re-frame

The conventional board question is what does our quantified cyber risk look like this quarter? That question is built for Mediocristan. It is the wrong question in Extremistan.

Two better questions:

• Which scenarios would end this organisation, and what structural caps are in place to ensure they cannot?

• How much of our cyber spend is buying optionality versus chasing the mean?

If the answer to the second is “almost all of it goes to the mean” (more controls, more compliance, more dashboards), the organisation is optimising Mediocristan while living in Extremistan. The next Black Swan will find that gap. It always does.

Closing thought

None of this argues against frameworks, against quantification, or against the controls-based programmes most of us have spent careers building. The argument is narrower and more useful: those tools are necessary, they are partial, and they share a hidden assumption (thin-tailed, gamelike, predictable) that the world they describe does not satisfy. Taleb’s five theorems are the missing layer underneath. The part that says here is what your existing tools cannot see, and here is what to add so that the next event leaves the organisation stronger rather than smaller.

The shift from controls thinking to choices thinking, from Mediocristan to Extremistan, from resilience to antifragility is a different operating model for security under real uncertainty. The organisations that figure it out first are the ones that recognised, earlier than their peers, that uncertainty in cyberspace is a condition to be navigated. The navigation skill itself is the differentiator.

(not very light) further reading

• Nassim Nicholas Taleb, The Black Swan: The Impact of the Highly Improbable (Random House, 2007).

• Nassim Nicholas Taleb, Antifragile: Things That Gain from Disorder (Random House, 2012).

• Martijn Dekker, Uncertainty in Security: Managing Cyber Senescence (University of Amsterdam inaugural lecture, 2025).

• Martijn Dekker, “The Leadership of Cyber Resilience: From Controls to Choices,” Projective Group Institute Journal of Financial Services, Edition 2, March 2026.

• Bibi van den Berg, “Dealing with Uncertainty in Cyberspace” (Leiden University, Institute of Security and Global Affairs).

• Bibi van den Berg, “Risk and Uncertainty in the Digital Ecosystem,” Technology and Regulation, 2026, pp. 10–27. doi:10.71265/veh8cc91