English version: scroll down

Complexe systemen falen altijd. Het is geen pessimistische uitspraak maar een natuurwet. Reliability Engineering is geboren in de luchtvaart, defensie en ruimtevaart. Niet uit academische nieuwsgierigheid, maar uit noodzaak. Wanneer mensenlevens afhankelijk zijn van elektronica, software en hydraulica, wordt optimisme gevaarlijk. Complexe systemen falen altijd; de enige vraag is wanneer – en vooral – of je het ziet aankomen.

In de luchtvaart werd redundantie doctrine. In fly-by-wire systemen — digitale besturing in plaats van mechanische kabels — worden signalen meervoudig uitgevoerd. Sensoren worden driedubbel uitgevoerd. Computers controleren elkaar continu. Als één kanaal afwijkend gedrag vertoont, wordt het uitgeschakeld. Niet na een crash. Tijdens de vlucht. Een modern verkeersvliegtuig is geen machine die “werkt”. Het is een machine die zichzelf permanent controleert. Testen is daar geen fase. Het is een continue toestand.

De digitale wereld dacht dat ze anders was

In cyberspace zijn we minder streng geweest. We hebben infrastructuren gebouwd op snelheid, schaal en efficiëntie. Cloudplatforms groeiden sneller dan governance kon bijbenen. Software werd continu uitgerold, maar zelden continu getest op systeemniveau. Logging werd een bijzaak — terwijl het in feite de black box van onze digitale wereld had moeten zijn. We hebben uptime verward met betrouwbaarheid.

En ondertussen zijn we een digitale oorlog ingerold zonder een eigen digitale oorlogsindustrie te bezitten. Kritieke infrastructuur draait op buitenlandse hyperscalers. Hardwareproductie is uitbesteed. Kernsoftware is afhankelijk van mondiale ketens. Digitale soevereiniteit blijkt een kwetsbare constructie. Betrouwbaarheid is daarmee geen technische optimalisatie meer. Het is een geopolitieke voorwaarde.

Testen als permanente parallelle realiteit

Echte reliability betekent dat je systeem nooit “af” is. Het bevindt zich permanent in een parallelle testfase. Dat idee is in de ICT-wereld teruggekeerd onder nieuwe namen: observability, continuous monitoring, chaos engineering. Maar de principes zijn oud. In aerospace en defensie weet men al decennia dat logging essentieel is. De flight data recorder — de black box — registreert niet alleen wat misgaat, maar ook wat goed gaat. Juist om afwijkingen vroegtijdig te detecteren en te weten dat iets niet (meer) klopt.

Wanneer logging intelligent wordt — wanneer AI patronen herkent die voor mensen onzichtbaar blijven — ontstaat iets fundamenteel nieuws: ‘continuous testing’ op systeemniveau. Niet alleen controleren of een functie werkt. Maar controleren of het systeem zich nog gedraagt zoals ontworpen. Inclusief de fouten. De kern van procesgerichte kwaliteitsborging. Meten van non-kwaliteit. Immers als kwaliteit de norm en dus vanzelfsprekend is, kun je alleen nog maar de afwijkingen, de fouten, de non-kwaliteit meten. 

Dat laatste is cruciaal. Een goed ontworpen systeem bevat expliciet gedefinieerde foutcondities. Als een gebruiker iets verkeerds doet, moet een voorspelbare fout optreden. Als die fout níet optreedt, is dat een alarmsignaal. Want dan wijkt het systeem af van zijn ontwerp. AI maakt het mogelijk om dit continu te toetsen. Parallel. Op schaal. Zonder dat het primaire proces wordt stilgelegd. Je systeem draait dan feitelijk in twee werkelijkheden tegelijk: de operationele realiteit en de verificatierealiteit.

Gecontroleerd falen als strategie

Chaos engineering klinkt modern, maar het principe is oud. In defensiesystemen worden red teams ingezet om kwetsbaarheden bloot te leggen. In ruimtevaartprogramma’s worden subsystemen getest tot ze breken — op de grond, niet in de lucht. Gecontroleerd falen is geen zwaktebod. Het is een vorm van strategisch realisme.

Het sluit naadloos aan bij het idee van antifragiliteit waar ik eerder over schreef: systemen die sterker worden door blootstelling aan stress. Maar antifragiliteit zonder reliability is roekeloosheid. Eerst moet het systeem zijn faalgrenzen kennen. Pas daarna kan het gecontroleerd worden belast. Dat betekent: verstoren om te leren. Simuleren om te begrijpen. Testen om soeverein te blijven.

Systems engineering als weerbaarheidsstrategie

Reliability Engineering is een discipline binnen systems engineering. Het kijkt niet naar losse componenten, maar naar interacties, afhankelijkheden en keteneffecten. In onze digitale infrastructuur zijn single points of failure eerder regel dan uitzondering. Centrale identity-providers. Monoculturen in software. Globale updates die wereldwijd identieke kwetsbaarheden introduceren.

In aerospace is dat ondenkbaar. Daar is elk potentieel enkelvoudig falen een ontwerpfout. Wanneer we digitale soevereiniteit serieus nemen, moeten we reliability positioneren als kerncompetentie. Niet als compliance-checklist. Niet als IT-bijlage. Maar als strategisch ontwerpprincipe. 

Complexiteit vraagt volwassenheid

Complexe systemen falen altijd. Maar volwassen systemen falen gecontroleerd. Ze loggen. Ze testen. Ze simuleren hun eigen ondergang — om die te voorkomen. Misschien is dat de echte les uit de ruimtevaart en de luchtvaart. Niet dat techniek onfeilbaar kan worden. Maar dat betrouwbaarheid voortkomt uit georganiseerd wantrouwen. Vindt de minimale non-kwaliteit die ergens altijd nog aanwezig zal zijn. 

In een wereld waarin digitale infrastructuur een slagveld is geworden, kunnen we ons geen naïviteit meer permitteren. Zelfs de kleinste systeemfout zal gevonden worden, dus moeten we hem zelf vinden. Betrouwbaarheid is geen luxe. Het is geen optimalisatie. Het is de voorwaarde voor autonomie. En misschien zelfs voor vrijheid. 

—————————-  Translated by ChatGPT  ————————

Reliability Is Designed Distrust

Complex systems always fail. That is not a pessimistic statement but a law of nature. Reliability Engineering was born in aviation, defense, and spaceflight — not out of academic curiosity, but out of necessity. When human lives depend on electronics, software, and hydraulics, optimism becomes dangerous. Complex systems always fail; the only question is when — and above all — whether you see it coming.

In aviation, redundancy became doctrine. In fly-by-wire systems — digital control instead of mechanical cables — signals are executed multiple times. Sensors are triplicated. Computers continuously cross-check one another. If one channel exhibits anomalous behavior, it is shut down. Not after a crash. During flight. A modern commercial aircraft is not a machine that simply “works.” It is a machine that permanently audits itself. Testing is not a phase. It is a continuous state.

The Digital World Thought It Was Different

In cyberspace, we have been less rigorous. We built infrastructures on speed, scale, and efficiency. Cloud platforms expanded faster than governance could keep up. Software was continuously deployed, but rarely continuously tested at system level. Logging became an afterthought — while in reality it should have been the black box of our digital world. We confused uptime with reliability.

Meanwhile, we have drifted into a digital war without possessing our own digital war industry. Critical infrastructure runs on foreign hyperscalers. Hardware production has been outsourced. Core software depends on global supply chains. Digital sovereignty turns out to be a fragile construct. Reliability is no longer a technical optimization. It is a geopolitical precondition.

Testing as a Permanent Parallel Reality

True reliability means your system is never “finished.” It permanently exists in a parallel testing phase. In the ICT world, this idea has re-emerged under new labels: observability, continuous monitoring, chaos engineering. But the principles are old. In aerospace and defense, logging has been essential for decades. The flight data recorder — the black box — records not only what goes wrong, but also what goes right. Precisely to detect deviations early and to know when something no longer behaves as intended.

When logging becomes intelligent — when AI recognizes patterns invisible to humans — something fundamentally new emerges: continuous testing at system level. Not merely verifying whether a function works, but verifying whether the system still behaves as designed. Including its failures. That is the essence of process-oriented quality assurance: measuring non-quality. If quality is the norm, then only deviations, errors, and non-quality can be measured.

This last point is crucial. A well-designed system explicitly defines its failure conditions. If a user does something incorrect, a predictable error must occur. If that error does not occur, it is an alarm signal — because the system is deviating from its design. AI makes it possible to verify this continuously. In parallel. At scale. Without shutting down the primary process. Your system effectively operates in two realities at once: the operational reality and the verification reality.

Controlled Failure as Strategy

Chaos engineering may sound modern, but the principle is old. In defense systems, red teams are deployed to expose vulnerabilities. In space programs, subsystems are tested until they break — on the ground, not in the air. Controlled failure is not a sign of weakness. It is a form of strategic realism.

It aligns seamlessly with the concept of antifragility I have written about before: systems that grow stronger through exposure to stress. But antifragility without reliability is recklessness. First, the system must know its failure boundaries. Only then can it be deliberately stressed. That means: disrupt to learn. Simulate to understand. Test to remain sovereign.

Systems Engineering as a Resilience Strategy

Reliability Engineering is a discipline within systems engineering. It does not look at isolated components, but at interactions, dependencies, and cascading effects. In our digital infrastructure, single points of failure are more the rule than the exception. Central identity providers. Software monocultures. Global updates introducing identical vulnerabilities worldwide.

In aerospace, that would be unthinkable. There, any potential single failure is a design flaw. If we take digital sovereignty seriously, we must position reliability as a core competence. Not as a compliance checklist. Not as an IT appendix. But as a strategic design principle.

Complexity Demands Maturity

Complex systems always fail. But mature systems fail in a controlled manner. They log. They test. They simulate their own demise — in order to prevent it. Perhaps that is the real lesson from spaceflight and aviation. Not that technology can become infallible. But that reliability emerges from organized distrust. From identifying the minimal non-quality that will always exist somewhere.

In a world where digital infrastructure has become a battlefield, we can no longer afford naivety. Even the smallest system flaw will be found — so we must find it ourselves. Reliability is not a luxury. It is not an optimization. It is the precondition for autonomy. And perhaps even for freedom.