This is part 5 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

Part 2 - Growing my second brain one mistake at a time

Part 3 - Leveraging Skills: turning “do that thing again” into a trigger phrase

Part 4 - Scheduled tasks: my vault works the night shift

This chapter is some what of a weird duck in the bite, or as the British would say: an odd one out. But when your knowledge base is built around AI generated content, this is very important to implement.

About 6 months into using an AI to maintain my second brain, I sat down to read a note I’d saved about AI governance frameworks. But when I got three paragraphs in, I couldn’t tell whether I had actually formed the opinion it expressed or whether the model had summarised a source into something that read like my opinion. The note’s frontmatter said authored_by: ai-assisted. I had apparently reviewed and accepted it at the time, but I just couldn’t tell, anymore, whether what was mine and what wasn’t.

That is the provenance problem, and it gets structurally worse over time. The vault accumulates and gets bigger. Notes link to other notes. An analysis synthesising four sources draws on summaries, and the summaries were written by a model in sessions I don’t fully remember. By the time you’re writing a client briefing or a public article and citing the vault as source material, the epistemic status of what you’re citing is opaque — unless you labelled it at the moment of creation.

Every note in the Robodex carries three fields in its frontmatter, applied at the moment the note is written:

authored_by: ai-assisted
ai_model: claude-sonnet-4-6
ai_influence: ai-collab

authored_by records who created the content: human (written by me in my own words), ai-assisted (the model drafted or summarised, I reviewed it), or ai-generated (fully generated by the model without human editing, used for scheduled task outputs like monthly summaries). ai_model is the exact model string: claude-sonnet-4-6, claude-opus-4-8. ai_influence is the degree of involvement across five levels: ai-full (prompt in, content out, no human edit), ai-led (the model drafted the majority, I made minor edits), ai-collab (genuine joint authorship), ai-enhanced (I wrote the core, the model polished or restructured), ai-minimal (the model handled only a small mechanical task, like a reformatting pass).

The Claude.md file has clear guidance on which labels should be used:

The cost of applying these is a few seconds per note, but the actual value stays throughout the usage of the database.

The model string matters more than it initially seems, for a reason that becomes clearer as the AI landscape shifts.

A summary written in early 2026 by a specific model carries different reliability characteristics than one written by a different model in late 2026: different reasoning patterns and different failure modes in specific domains. If I’m reading a note in 2028 and deciding how much weight to give an inference it makes, knowing which model wrote it is useful context. The model string anchors the note to a moment in AI development. That anchor has value when the landscape shifts around it, as it reliably does.

The exact model string also does something subtler: it forces honesty about whether AI was involved at all. Vague labels like “AI-assisted” are easy to apply loosely, meaning “AI helped somehow,” which covers everything from “the model wrote the whole thing” to “I used autocomplete.” An exact model string requires actually recalling whether a model was used in that session, because there is no way to fake the version number without knowing which model was open at the time.

The distinction between ai-full notes and human notes changes how I use the vault as a thinking tool. An ai-full note is a lead: something the model generated from a prompt that I haven’t independently verified or thought through. It might be accurate and well-reasoned. I haven’t claimed it. A human note is a position I hold, something I wrote, something I can stand behind in a conversation or a document.

The vault currently has 32 notes marked ai-full:

Most are monthly summaries and scheduled task outputs: things the agent generates autonomously as part of its night-shift work. Of the 547 total notes, the majority carry some level of human involvement.

Organisations face the same problem at a scale where the consequences are larger. AI produces reports, analyses, briefings. The provenance disappears. Six months later, no one can reconstruct which decisions were made based on AI-generated summaries versus verified human analysis, or which model version was used in a period when that model later turned out to have systematic blind spots in a particular domain. The downstream consequences of this opacity are already visible in regulated industries where the provenance of advice and analysis is itself a compliance question.

I solved the problem for one person, in one vault, with three frontmatter fields applied at creation time. The implementation is not a blueprint for a corporate knowledge system. The principle is: label AI involvement at the moment of creation, with enough specificity that future readers can assess what they’re reading. Provenance cannot be reconstructed after the fact. The moment to label is when the note is written.

This is part 4 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

Part 2 - Growing my second brain one mistake at a time

Part 3 - Leveraging Skills: turning “do that thing again” into a trigger phrase

The first post of this series made a claim about why second brains die: the maintenance nobody asks for accumulates, and eventually the system costs more to keep up than it returns in usefulness. The demand-driven part of a vault is easy to automate — say “save this,” something gets saved. The harder problem is everything that needs to happen regardless of whether you thought to ask: the index rebuild, the crosslink audit, the scan of last week’s security news for things worth tracking. Nobody thinks to schedule those, so they don’t happen, and six months later the vault is stale.

The Robodex has 10 scheduled tasks. I set them up over the first few months of using the system. They now run autonomously.

My scheduled tasks

One runs daily. Four run weekly. Five run monthly.

The daily task is daily-inbox-process, at 02:00 every night. It processes whatever landed in 05 - Inbox the day before, routes each note to its final location, rebuilds the Pipeline index, and produces a brief activity summary. The inbox, which is a pile of unrouted notes when left to accumulate, is now a queue that drains itself.

The morning digest note from the daily inbox-process is waiting when I sit down at my desk:

The four weekly tasks:

• a glossary update that runs Sunday night and proposes new terms from recent vault content for me to review on monday morning;

• a QRC framework review at Sunday that patches topic reference cards in-place when new content warrants it;

• a clippings curation task on Friday that organises the Clippings folder into topic subfolders;

• The incident radar, which runs Thursday nights and is worth more than a line here, so more details can be found below.

The five monthly tasks:

• a vault summary on day 28 of each month covering everything saved that month;

• a content ideas batch on day 1 drawn from the prior month’s summary;

• a research synthesis on day 29 connecting related themes across sources; (wait, now I know why I missed February)

• a vault health check on day 2 that scans for structural drift and fixes it;

• a regulatory watch on day 3 covering NL and EU cybersecurity and AI regulation changes.

Ten tasks, none needing attention to run. The cumulative effect is a vault that maintains itself: its indexes rebuild, its filing stays current, its reference material stays crosslinked, and its structural health gets audited once a month.

Continuous Improvement

The current configuration is the result of at least one significant correction.

Originally there were two weekly tasks where one daily task now sits: weekly-inbox-process ran once a week, and weekly-vault-digest ran on a separate day. The problem was the batch size. By Friday’s run, the inbox had five days of accumulated notes, and the variety of content over that span was wide enough that the task would occasionally drift from the routing rules on unusual inputs. Small batches were fine. A week of varied content, including anything in an unfamiliar format or on a peripheral topic, produced judgement calls I wouldn’t have made. The solution was daily runs: smaller batches and tighter conformance to the routing logic. The two weekly tasks were retired and their functionality merged into a single daily task. I’ve let it create a seperate task registry note that still lists them, with the retirement date and the reason. That record exists so that future decisions don’t have to reconstruct reasoning that was obvious at the time but will be opaque twelve months later.

Diving into the details

Two tasks from the roster are worth examining in more depth, because they represent two different ways a scheduled task can be useful.

The vault health check runs on day 2 of each month. It scans files changed since the last run, checks frontmatter consistency, catches notes that ended up in the wrong layer, flags orphan files with no crosslinks. When it finds structural drift, it fixes it. When it encounters something ambiguous, it flags it for review rather than resolving it unilaterally. This is an agent auditing its own work, and correcting the drift that accumulates in any system where a human and an AI make filing decisions over an extended period. It is the closest the vault gets to running itself.

The incident radar is different in character. It runs Thursday nights and scans security news sources for notable incidents from the past week. It produces a shortlist of 5 to 8 incidents worth considering, with a brief rationale for each. Then it stops. It writes nothing to the vault. This is a deliberate design choice, and the reason for it is about where automated judgement is actually reliable.

The incident radar is good at finding things that look significant. It is not the right tool to decide whether a given incident is worth adding to a vault that will influence client briefings and public writing. That decision requires context the task doesn’t have: what clients I’m currently advising, what themes I’m tracking, what I already covered last month. The shortlist saves me the scanning work. The human decision saves me from a vault full of low-signal notes the agent thought were important.

It is logical to automate the maintenance, but it is important to keep the judgement for yourself. Maintenance tasks like filing, index rebuilding, folder organisation, crosslink auditing, etc. are predictable and tedious, and the right answer is determinate. Curation tasks, like deciding what’s worth tracking, what’s worth synthesising, what belongs in the vault at all, require assessment of significance. Keep those human. The split is about where human attention actually adds value. For a crosslink audit, it doesn’t. For a list of this week’s incidents worth tracking, it does.

The other pattern worth carrying: task rosters go stale. Schedules that made sense at launch don’t always make sense at month six. Review what you set up periodically. Retire what no longer fits the system you actually have, and record why you retired it for future reference.

This is part 3 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

Part 2 - Growing my second brain one mistake at a time

Ask an AI the same task ten times via ad hoc prompts and you get ten slightly different results. This is not a model bug, it is how large language models work. Every variation in how you phrase a request produces variation in what you get back, and those variations compound over time. A notes system’s value comes from structural consistency: notes that follow the same format, carry the same frontmatter fields, get filed in the same way. A vault full of notes with slightly different formats is a vault that is slowly losing coherence, and the cause is not the model but the interface: prompts that change every session.

Skills

In Claude Cowork, a skill is a markdown file with a description and a procedure. The description contains trigger phrases: the specific words that make the agent run the procedure automatically, without further instruction. The procedure is the procedure — every step, every check, every output format, every confirmation required.

The trigger phrases for obsidian-save, as stated in the skill file:

Say any of those and the skill runs. The same procedure, the same steps, the same output format, regardless of how I happened to phrase the request that day. The prompt drift problem disappears because there is no longer a prompt to drift.

Inside the procedure, the steps are specific to the point of being mechanical: check the content type, find the correct template for that type in 20 - Templates/Robodex/, write the note using that template with no deviations, route it to the correct folder per the layer-routing rules in CLAUDE.md, apply at least two tags, confirm the full filepath. Specific instructions, like exact folder paths, explicit frontmatter requirements, produce consistent output. Vague instructions produce vague output.

The image below shows a small snippet of the skill instructions

The core skills

obsidian-save is the workhorse. Everything I save goes through it: URLs, rough notes, incident reports, research clippings, conversation excerpts. It handles content-type routing (a cyber incident goes to a different folder than a recipe), selects the right frontmatter template for each type, and confirms the filed path. The skill has run hundreds of times, and the structural output is identical each time. That consistency is the point; it is also what makes 547 notes searchable and cross-linkable rather than just 547 files.

obsidian-publication-tracker handles the other end of the pipeline. When I publish something, like this Substack post, or a LinkedIn article, white paper, etc., I say “I published this.” The skill checks whether a matching draft already exists in the Pipeline folder, which it usually does. If found (the common path), it moves the file to 90 - Published/, updates the frontmatter in place with the publication date, platform, and source link, and adds a row to the running publication index. One phrase. One atomic operation. The index stays current without a manual update, and the draft-to-published transition is lossless.

The two skills also interact: obsidian-summarize (monthly summary generation) feeds obsidian-content-ideas (content idea generation). The first skill’s output becomes the second skill’s input. The scheduler triggers both automatically, but the chaining is a skill pattern worth naming: one procedure’s output as another’s input, each with its own trigger phrase and its own contract.

Continuous Improvement

Early on, obsidian-save had no template requirement. I’d written the procedure in prose but hadn’t specified which template to use for which content type, assuming the agent would infer the right choice from context. It would not. The notes it produced were structurally correct but with inconsistent frontmatter: sometimes including fields that belonged to a different content type, sometimes missing required ones. The fix was simple: a lookup table added to the skill file mapping content type to template filename. The agent reads the table before writing any note. The inconsistency stopped in the next session.

This is the same lesson as CLAUDE.md, applied to a different layer. Prose describes intent. Tables enforce it. The distinction holds at every level of the system.

The procedure you’d describe to a human assistant is 90% of a skill. Write: “When I say [trigger phrase], do [steps]. Produce [output]. Confirm [specific thing].” Add edge cases as you encounter them. The iteration is the same as CLAUDE.md: each failure becomes a new line in the procedure.

This approach applies beyond this use-case of knowledge management. A skill for drafting client emails. A skill for formatting incident briefings. If it is repeatable, it can be reproducible, and the cost of writing the procedure down once is paid back with the first session after you stop re-explaining it.

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

Any data store should start with structure, but because it’s hard to think about where it will grow, it’s important to start small. When I started, I only had 3 top folders: Notes, Templates & Analysis. Now it has grown to the structure explained in the previous post.

Remember that the basis is just markdown files in folders, so re-arranging the structure is as simple as writing a prompt.

The vault structure block at the top of the Claude.md file looks like this (it only shows the inbox & sources in this image):

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.

Growing one mistake at a time

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.

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.

Key Takeaway

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