Zonder wiskundig bewijs blijft software onvermijdelijk legacy

Hans. Konstapel Leiden, 28-09-2025. All Rights Reserved.

Introductie

Volgens Wiebe Edsger Dijkstra (1930-2002) behoort de informatica tot de wiskunde en niet tot de bedrijfskunde.

Dat betekent dat de waarheid van de software formeel moet worden bewezen.

Op zoek naar een toepassing van de wiskunde in de software-engineering? Druk hier.

60 jaar Software Engineering

Wicked Systems

Veel mensen verdienen hun brood net met het corrigeren van wat niet werkt, waardoor iets anders weer niet werkt.

Ga direct naar de aanpak van Dijkstra, druk hier.

Onbewijsbare Ongrijpbare Complexiteit

Dit is een vervolg op Over de Legacy van de Legacy Software.

Het kan lang duren voordat je beseft dat niet iedereen hetzelfde denkt als jij of zo anders dat ze je nooit zullen begrijpen.

Dokumentaire over Edsger Dijkstra:

“Programmeren is de kunst van het organiseren van complexiteit, het beheersen van veelheid en het zo effectief mogelijk vermijden van chaos”

“Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence“

Inmiddels is het bewijzen in de wiskunde geautomatiseerd, dus we kunnen aan de slag, want de basisfuncties in de bedrijfskundige wiskunde zijn bekend.

1. Legacy?

is een onoplosbaar probleem, omdat hele nieuwe software eer heel snel oud is, omdat de context steeds verandert behalve als je de context begrijpt, die er van boven (m.b.v. abstractie)af simpel uit ziet.

Legacy-software is een term die slaat op hele oude vaak slecht gedocumenteerde software die nog steeds in gebruik is.

Ze kan niet worden aangepast, niet worden vervangen en dus niet worden verwijderd.

De “echte” oorzaak van legacy is slechte softwarekwaliteit en de onnadenkende aanschaf van pakketten of open source bibliotheken die nooit goed zijn getest.

Hierdoor wordt van alles aan elkaar geplakt via bruggetjes API genoemd.

2 De Huidige situatie : Volgens Pragmatic Coders

Ongeveer 70% van de software bij Fortune 500 bedrijven is meer dan twee decennia oud 2025 Legacy Code Stats, en de gecumuleerde technische schuld in de VS bereikte $1,52 biljoen in 2022 2025 Legacy Code Stats.

Technische schuld (of technical debt) is een concept uit softwareontwikkeling dat verwijst naar de gevolgen van keuzes die je maakt om snel een oplossing te implementeren, maar die op de lange termijn extra werk en kosten veroorzaken.

Voorbeelden:

• Snelle, slordige code schrijven om een deadline te halen.
• Oplossingen die niet goed gestructureerd zijn en moeilijk uitbreidbaar.
• Verouderde afhankelijkheden of frameworks gebruiken zonder upgradepad.

Sectoren zwaar getroffen:

Banking: 70% van banken wereldwijd gebruikt nog steeds legacy systemen, en 95% van alle ATM-transacties worden verwerkt via COBOL-gebaseerde systemen 2025 Legacy Code Stats

Zorgverlening: Meer dan 60% van Amerikaanse ziekenhuizen draait kritieke applicaties op verouderde software 2025 Legacy Code Stats

Overheid: Slechts tien kritieke federale legacy systemen kosten $337 miljoen per jaar om te onderhouden 2025 Legacy Code Stats

Grootste uitdagingen:

3. Inzicht en Overzicht

Niemand weet hoe het totaal er van binnen uit ziet.

Talent tekort: 60% van organisaties die COBOL gebruiken meldt dat het vinden van bekwame ontwikkelaars hun grootste uitdaging is 2025 Legacy Code Stats

Beveiligingsrisico’s: Datalekken in de zorgverlening kosten gemiddeld $9,77 miljoen 2025 Legacy Code Stats

Budgetdruk: Legacy onderhoud kan tot 80% van IT-budgetten opslokken

4. Inpakken en Wegwezen

In het algemeen lost men dit probleem op met behulp van een wrapper (een verpakking) waardoor de oude software volledig onzichtbaar wordt maar wel zijn functie uitoefend.

Dit soort onderdelen zijn ideaal voor hackers die er tijdbommen in kunnen verbergen die ze op afstand kunnen activeren.

5. Voorbeeld Fusie ABN AMRO

De fusie van ABN en AMRO in 1991 bracht het bedrijf op de rand van de afgrond, omdat er politieke keuzes werden gemaakt voor de slechtste softwareonderdelen van beide bedrijven.te kiezen namelijk de software van binnenland AMRO en buitenland ABN.

6.Slim Vertalen

Software wordt door een parser vertaald naar machinecode.

Meta-Parser

De huidige oplossing om Legacy weer als nieuw te maken, is om ergens tussen die twee een nieuwe meta-parser te zetten die je weer kunt programmeren.

Het probleem is dat talen in de loop der tijd veranderen (dialecten) en programmeurs nieuwe slimmigheid introduceren, waardoor de vertaling de totale kwaliteit niet verbetert, maar verandert, waardoor nieuwe software weer legacy wordt en oude software legacy blijft.

Het probleem is daarmee onoplosbaar behalve als men besluit om alles opnieuw te maken en dan wel op de goede manier die later discutabel blijkt te zijn.

Zo is het zeker dat AI, zonder het te weten, foutjes (hallucinaties) introduceert.

In het volgende hoofdstuk gaan we doen wat Dijkstra eigenlijk wilde.

Deel 2: de Dijkstra Aanpak

deel 2.1: First Time Right:

Het ontwikkelproces is geen keten van idee→realisatie, maar een landschap van heel veel cycli waarin processen elkaar corrigeren, verbeteren of tegenwerken.

het Platform IO

was bedoeld om de engineering te verbeteren. Daartoe werden proces- en gegevensmodellen gemaakt, die voor ieder project opnieuw moesten worden gemaakt.

Opvallend was dat men geen enkel contact had met de dienstensector, bijvoorbeeld banken, waar hetzelfde gebeurde.

Zo is er altijd wel weer een eiland te vinden, zoals een grote klant die totaal een andere weg kiest of een topmanager die een oud contact meeneemt dat het in zijn context goed deed, maar dat succes niet kan kopiëren.

Mensen willen hun eigen problemen oplossen en hun oplossing is de beste totdat een nieuwe generatie weer opnieuw begint en het wiel weer net iets anders uitvindt.

Standaarden

zoals PIM zijn aan interpretatie onderhevig, net als een AI die ook steeds gokt dat het klopt en soms zijn gok slim verbergt, wat voor problemen later zorgt.

Het Kernprobleem

Standaardisatie lijkt een opgelost probleem: we hebben ETIM voor productclassificatie, CB-NL voor semantische begrippen, en talloze internationale normen. Toch worstelen ingenieurs dagelijks met hetzelfde fundamentele probleem: verschillende partijen delen hetzelfde systeem op incompatibele manieren op, waardoor integratie mislukt en tijd wordt verspild.

Een afsluiter heet bij de ene leverancier “kogelafsluiter”, bij de andere “ball valve”. Beide hebben “RVS” respectievelijk “stainless steel” als materiaal. Zijn ze hetzelfde? Huidige standaarden vertrouwen op menselijke interpretatie om dit te bepalen – een proces dat foutgevoelig, tijdrovend en niet-schaalbaar is.

De Wiskundige Aard van het Probleem

Dit is geen communicatieprobleem, maar een wiskundig probleem. Verschillende decompositiesystemen creëren verschillende hiërarchieën voor hetzelfde object, zonder formele methode om equivalentie te bewijzen. HVAC-systemen kunnen functioneel (verwarming, koeling), fysiek (leidingen, kleppen), of operationeel (onderhoudseenheden) worden ingedeeld – allemaal geldig, maar onderling niet formeel gerelateerd.

Standaarden proberen dit op te lossen door conventies af te spreken, maar conventies blijven interpretatief. Ze elimineren ambiguïteit niet; ze verplaatsen die naar het implementatieniveau.

Homotopy Type Theory als Oplossing

Homotopy Type Theory (HoTT) biedt een wiskundig rigoureuze benadering. In HoTT wordt elk object gedefinieerd als een type met expliciete eigenschappen en relaties. Cruciaal is dat HoTT formeel kan bewijzen wanneer twee verschillende representaties van hetzelfde object equivalent zijn.

Net zoals HoTTSQL kan bewijzen dat verschillende SQL-queries hetzelfde resultaat geven, kan HoTT bewijzen dat een “kogelafsluiter RVS DN50” en een “ball valve stainless steel DN50” wiskundig equivalent zijn – ongeacht naamgeving of leverancier.

De Praktische Implementatie

HoTT vereist dat alle eigenschappen, synoniemen en relaties expliciet en formeel gedefinieerd worden:

Objecten als types: Elke afsluiter wordt een type met velden voor diameter, materiaal, drukklasse.

Synoniemen formaliseren: “Kogelafsluiter” ≡ “Ball Valve” wordt expliciet gedefinieerd, niet geïnterpreteerd.

Equivalentie bewijzen: Het systeem kan automatisch verifiëren dat ProductA ≡ ProductB.

Voordelen ten opzichte van Conventionele Standaarden

Waar conventionele standaarden flexibiliteit toestaan die tot ambiguïteit leidt, elimineert HoTT interpretatie volledig. Dit lost drie kernproblemen op:

Automatische verificatie: Geen menselijke expertise meer nodig om equivalentie te bepalen

Schaalbare integratie: Nieuwe componenten kunnen automatisch worden gematcht tegen bestaande systemen

Formele zekerheid: Equivalentie wordt bewezen, niet aangenomen

Een Nieuw Paradigma voor het Bankwezen: De Synthese van Gedragswetenschap en Formele Wiskunde via Homotopietypetheorie

Introductie: Voorbij de Grenzen van Huidige Financiële Technologie

De financiële sector bevindt zich op een technologisch kruispunt. De huidige systemen, vaak een complex conglomeraat van decennia-oude legacy-code en moderne, maar gefragmenteerde, microservices, vertonen fundamentele zwaktes. Ze zijn inherent broos, moeilijk te auditen en worstelen om de toenemende complexiteit van zowel regelgeving als irrationeel menselijk gedrag adequaat te modelleren. De traditionele aanpak—het achteraf testen van systemen op fouten en het empirisch modelleren van risico’s—is als het repareren van een schip terwijl het al op open zee vaart. Dit essay introduceert een radicaal ander paradigma, gebaseerd op het werk van J. Konstapel, dat een fundamentele verschuiving voorstelt: van een systeem dat getest wordt op correctheid, naar een systeem dat wiskundig bewezen correct is door zijn eigen constructie.

Door de synergie van Knowledge-Based Behavioral Systems Engineering (KBSE) en de abstracte wiskunde van Homotopietypetheorie (HoTT), wordt een blauwdruk geschetst voor een bancair systeem dat niet alleen operationeel robuust en schaalbaar is, maar ook een diepgaand, formeel begrip heeft van de regels, doelen en menselijke gedragingen die het bestuurt. Dit is geen incrementele verbetering; het is een conceptuele revolutie die de potentie heeft om de fundamenten van financiële technologie te herdefiniëren.

---

De Conceptuele Fundamenten: Gedrag en Bewijs als Pijlers

De voorgestelde architectuur rust op twee intellectuele pijlers die samen een raamwerk vormen dat zowel expressief als rigoureus is.

1. Knowledge-Based Behavioral Systems Engineering (KBSE): Het Systeem dat ‘Begrijpt’ KBSE is een methodologie die verder gaat dan traditionele softwareontwikkeling. In plaats van een systeem te bouwen dat enkel processen automatiseert, streeft KBSE naar het creëren van een systeem dat kennis representeert en daarop redeneert. Dit omvat:

• Expliciete Kennis: Gecodificeerde regels zoals de Basel III-normen, anti-witwaswetgeving (AML) of interne compliance-protocollen.
• Gedragsmatige Kennis: Formele modellen van de cognitieve biases (zoals de confirmation bias van een belegger), marktsentiment en de psychologische drijfveren achter financiële beslissingen.

Een dergelijk systeem kan proactief adviseren, risico’s identificeren die voortkomen uit irrationeel gedrag en compliance garanderen, niet omdat het een checklist afwerkt, maar omdat de regels een integraal onderdeel zijn van zijn operationele logica.

2. Homotopietypetheorie (HoTT): De Wiskundige Grondslag voor Absolute Zekerheid HoTT is een relatief nieuw en zeer abstract veld binnen de wiskunde dat logica, verzamelingenleer en ruimtelijke topologie verenigt. Voor het doel van dit essay kan HoTT het best worden begrepen als het genetisch materiaal (DNA) van het banksysteem. Waar traditionele programmeertalen een beschrijving van een systeem geven (die fouten kan bevatten), is een systeem in HoTT een wiskundig object waarvan de eigenschappen en de correctheid inherent zijn aan zijn definitie.

Het kernprincipe is “propositions as types” (stellingen als typen) en “proofs as programs” (bewijzen als programma’s). Dit betekent dat een stelling (bv. “elke transactie voldoet aan de AML-wetgeving”) wordt gerepresenteerd als een wiskundig ‘type’. Een bewijs dat deze stelling waar is, is een concreet object binnen dat type. Als een dergelijk object niet geconstrueerd kan worden, is de stelling onwaar. Een systeem gebouwd op HoTT is dus correct by construction: de architectuur zelf is het bewijs van zijn eigen integriteit. Fouten die in traditionele systemen pas tijdens het testen of, erger nog, in productie worden gevonden, zijn in een HoTT-framework wiskundig onmogelijk.

---

Architectonisch Ontwerp: De Atomen van een Bewijsbare Bank

Het abstracte fundament van HoTT wordt vertaald naar een concrete bancaire architectuur via specifiek gedefinieerde wiskundige structuren, of ‘typen’.

• Het Tetrahedron Type (T): De Operationele Kern Dit type modelleert de fundamentele bouwsteen van elke bancaire operatie. Het is een onlosmakelijk geheel van vier componenten:
  1. Financiële Doelstellingen: De strategische doelen (bv. winstgevendheid, marktaandeel).
  2. Transactionele Taken: De concrete operaties (bv. leningverstrekking, betalingsverwerking).
  3. Regulatoire Structuur: Het raamwerk van wet- en regelgeving.
  4. Risicocapaciteiten: De instrumenten en modellen voor risicobeheer. De wiskundige structuur garandeert dat geen enkele taak kan bestaan zonder een expliciete en bewezen relatie met de andere drie componenten. Een lening kan conceptueel niet worden gemodelleerd zonder een gekoppelde risicoanalyse en een validatie ten opzichte van de relevante regelgeving.
• Het Sefira Type (S): De Formalisering van Menselijk Gedrag Dit type modelleert de dynamische en vaak irrationele menselijke laag van de financiële wereld. Het vangt de feedbackloop tussen:
  1. Cognitie: De overtuigingen en biases van klanten en marktdeelnemers.
  2. Sentiment: De emotionele toestand van de markt.
  3. Actie: De daaruit voortvloeiende handels- of investeringsbeslissingen. Door deze elementen in een formele structuur te gieten, kan het systeem de dynamiek van bijvoorbeeld een speculatieve zeepbel of een paniekverkoop niet alleen observeren, maar ook wiskundig redeneren over de mogelijke evoluties ervan.

De algehele bank wordt gemodelleerd als een “Flower of Life”, een schaalbare structuur van met elkaar verbonden afdelingen (de “bloembladeren”) rond een centrale kern, wat zorgt voor een evenwichtige en modulaire groei. Veranderingen en de levenscyclus van producten worden gemodelleerd via “Path Spaces”, die garanderen dat elke evolutie in het systeem—van strategie tot implementatie—een volledig traceerbaar en geverifieerd pad volgt.

---

Strategische en Operationele Voordelen: De Business Case voor Wiskundige Zekerheid

De overstap naar een dergelijk raamwerk levert diepgaande strategische voordelen op:

• Radicale Risicoreductie: Operationeel risico verschuift van een probabilistische inschatting naar een deterministische zekerheid. Systeemfouten, inconsistente data en logische programmeerfouten worden in de ontwerpfase geëlimineerd.
• Gegarandeerde en Dynamische Compliance: Regelgeving is geen externe beperking meer, maar een integraal onderdeel van de systeemlogica. Bij een wetswijziging kan het systeem wiskundig aantonen welke onderdelen moeten worden aangepast, en de correctheid van de aanpassing kan formeel worden geverifieerd.
• Superieure Auditability: Elke transactie en beslissing genereert een wiskundig bewijsspoor. Audits worden een kwestie van het verifiëren van deze bewijzen, wat leidt tot een ongekend niveau van transparantie en vertrouwen voor toezichthouders.
• Een Nieuwe Generatie Financiële Producten: Door gedragsmodellen formeel te integreren, kan de bank hyper-gepersonaliseerde producten ontwikkelen die anticiperen op de behoeften en psychologische profielen van klanten, terwijl de risico’s volledig beheerst blijven.

Conclusie: De Volgende Grens van Financiële Engineering

Het raamwerk van Konstapel is meer dan een technologisch voorstel; het is een intellectuele uitdaging aan de financiële sector. Het dwingt ons om de aard van vertrouwen, risico en waarde opnieuw te overdenken. Door de precisie van formele wiskunde te combineren met de complexiteit van menselijk gedrag, biedt het een pad naar een financieel ecosysteem dat niet alleen efficiënter en winstgevender is, maar ook fundamenteel stabieler, eerlijker en veerkrachtiger. De implementatie vereist een aanzienlijke investering in nieuw talent en een andere manier van denken, maar de belofte is niets minder dan de creatie van een bank die wiskundig waterdicht is—een ware prestatie voor de 21e eeuw.

---

Uitgebreide en Toegelichte Referentielijst voor Verdere Studie

Hieronder volgt een lijst van academische en fundamentele werken die de concepten in dit essay verder uitdiepen. De referenties zijn thematisch geordend en voorzien van een korte toelichting.

1. Homotopietypetheorie en Formele Verificatie

• The Univalent Foundations Program, Homotopy Type Theory: Univalent Foundations of Mathematics (2013).
  • Toelichting: Dit is het canonieke, open-source boek over Homotopietypetheorie, vaak simpelweg “The HoTT Book” genoemd. Het is geschreven door een collectief van vooraanstaande onderzoekers en legt de volledige wiskundige en logische fundamenten van het veld uit. Voor een diepgaand technisch begrip van de principes die in het essay worden genoemd (typen, paden, equivalenties), is dit de primaire bron. Het is veeleisend, maar essentieel. Beschikbaar via homotopytypetheory.org.
• Voevodsky, V., “Univalent Foundations,” lezingenreeks en geschriften.
  • Toelichting: Vladimir Voevodsky was een Fields-medaillewinnaar en de visionaire grondlegger van de Univalent Foundations. Zijn lezingen en artikelen bieden een conceptueel inzicht in de motivatie achter het project: het creëren van een nieuwe, computer-verifieerbare basis voor de wiskunde die robuuster en coherenter is dan de traditionele verzamelingenleer.
• Pierce, B. C., Types and Programming Languages (2002).
  • Toelichting: Hoewel dit boek niet specifiek over HoTT gaat, biedt het een zeer toegankelijke en grondige introductie tot typetheorie, wat een absolute voorwaarde is om HoTT te kunnen begrijpen. Het legt de connectie tussen logische proposities en datatypen in programmeertalen uit, het centrale idee achter “propositions as types”.

2. Systems Engineering en Complexe Architecturen

• Blanchard, B. S., & Fabrycky, W. J., Systems Engineering and Analysis (5e editie, 2010).
  • Toelichting: Dit is een standaardwerk in het veld van Systems Engineering. Het biedt een alomvattend overzicht van de principes voor het ontwerpen, beheren en onderhouden van complexe systemen gedurende hun volledige levenscyclus. Het geeft de context voor de meer specifieke, tetrahedron-gebaseerde aanpak die in het brondocument wordt voorgesteld.
• Meadows, D. H., Thinking in Systems: A Primer (2008).
  • Toelichting: Een zeer invloedrijk en toegankelijk boek dat de lezer leert denken in termen van systemen, feedbacklussen en niet-lineaire dynamiek. Het is een uitstekende conceptuele voorbereiding om de interconnectiviteit van de componenten in het Tetrahedron- en Sefira-model te begrijpen.

3. Gedragseconomie en Financiële Psychologie

• Kahneman, D., Thinking, Fast and Slow (2011).
  • Toelichting: Het magnum opus van Nobelprijswinnaar Daniel Kahneman, waarin hij decennia van onderzoek naar cognitieve biases, heuristieken en de twee systemen van denken (intuïtief vs. deliberatief) samenvat. Dit werk levert de psychologische onderbouwing voor de noodzaak van een ‘behavioral’ component in elk serieus financieel model.
• Thaler, R. H., Misbehaving: The Making of Behavioral Economics (2015).
  • Toelichting: Een toegankelijk en persoonlijk verslag van de ontwikkeling van de gedragseconomie door een van haar grondleggers. Thaler illustreert met talloze voorbeelden hoe menselijk gedrag systematisch afwijkt van de rationele modellen die traditioneel in de economie worden gebruikt. Dit rechtvaardigt de noodzaak van het ‘Sefira Type’ in de voorgestelde bankarchitectuur.

4. Categorientheorie en de Toepassing in Computing

• Spivak, D. I., Category Theory for the Sciences (2014).
  • Toelichting: Categorientheorie is de ‘wiskunde van de wiskunde’ en biedt een zeer abstracte taal om systemen en hun interacties te beschrijven. Het is een voorloper van HoTT. Dit boek van Spivak is uniek omdat het de abstracte concepten van categorientheorie direct toepast op problemen in de wetenschap en engineering, waardoor het een brug slaat tussen pure wiskunde en praktische systeemmodellering.
• Milewski, B., Category Theory for Programmers (2019).
  • Toelichting: Een zeer gewaardeerde bron die categorientheorie specifiek uitlegt voor softwareontwikkelaars. Het toont hoe concepten als functoren, monads en natural transformations concrete toepassingen hebben in het ontwerpen van robuuste en modulaire software. Dit geeft een praktisch perspectief op het type abstract denken dat vereist is voor het voorgestelde HoTT-framework.

Bijlage

Wiskunde, Homotopy en Kabbalah

Functional Programming

Samenvatting: Edsger Dijkstra’s Strijd tegen de Verflansing van de Informatica

Auteur: J. Konstapel
Datum: 28 september 2025

Kernstelling

Volgens Wiebe Edsger Dijkstra (1930-2002) behoort de informatica tot de wiskunde en niet tot de bedrijfskunde. Dat betekent dat jij de waarheid van de software moet bewijzen. Deze blogpost behandelt 60 jaar Software Engineering en presenteert een revolutionaire benadering gebaseerd op wiskundige bewijsvoering in plaats van testen.

Dijkstra’s Fundamentele Inzichten

• “Programmeren is de kunst van het organiseren van complexiteit, het beheersen van veelheid en het zo effectief mogelijk vermijden van chaos”
• “Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence”
• “Computing science is potentially fulfilling Leibniz’s Dream”

Hoofdstukindeling

Deel 1: Het Legacy Probleem – De Gevolgen van 60 Jaar Foutieve Benadering

1. Wat is Legacy?

Legacy-software is oude, slecht gedocumenteerde software die niet kan worden aangepast, vervangen of verwijderd. De echte oorzaak is slechte softwarekwaliteit door onnadenkende aanschaf van pakketten die nooit goed zijn getest, resulterend in systemen die via API-bruggetjes aan elkaar zijn geplakt.

2. De Huidige Situatie: Wicked Systems

Dramatische cijfers:

• 70% van Fortune 500 software is meer dan 20 jaar oud
• Technische schuld VS: $1,52 biljoen (2022)
• Banking: 95% ATM-transacties via COBOL-systemen
• Zorgverlening: 60%+ ziekenhuizen op verouderde software
• Overheid: 10 systemen kosten $337 miljoen/jaar onderhoud

Wicked Systems: Veel mensen verdienen hun brood met het corrigeren van wat niet werkt, waardoor iets anders weer niet werkt – een vicieuze cirkel van reparaties.

3. Inzicht en Overzicht – Niemand Weet Hoe het Eruit Ziet

• Talent tekort: 60% COBOL-organisaties vindt geen ontwikkelaars
• Beveiligingsrisico’s: Datalekken kosten gemiddeld $9,77 miljoen
• Budgetdruk: Legacy onderhoud eet 80% van IT-budgetten op

4. Inpakken en Wegwezen – Gevaarlijke Schijnoplossingen

Wrappers maken oude software onzichtbaar maar functioneel – ideaal voor hackers om tijdbommen te verbergen.

5. ABN AMRO Fusie – Politiek vs. Techniek

De fusie van 1991 bijna fataal door politieke keuzes voor de slechtste softwareonderdelen van beide banken.

6. Slim Vertalen – Het Meta-Parser Probleem

Pogingen om legacy te moderniseren via meta-parsers falen omdat:

• Talen veranderen (dialecten)
• Programmeurs introduceren nieuwe “slimmigheden”
• AI introduceert hallucinaties
• Fundamenteel onoplosbaar behalve door alles opnieuw te maken

Deel 2: De Dijkstra Aanpak – First Time Right

2.1 Het Landschap van Feedback-Loops

Het ontwikkelproces is geen lineaire keten maar een complex landschap van cycli waarin processen elkaar corrigeren, verbeteren of tegenwerken.

Platform IO Voorbeeld: Engineering verbetering mislukte door:

• Gebrek aan contact tussen sectoren (engineering vs. banking)
• Eilandvorming (grote klanten kiezen eigen wegen)
• Elke generatie heruitvindt het wiel

Het Kernprobleem van Standaardisatie

Ondanks standaarden zoals ETIM en CB-NL blijft het fundamentele probleem bestaan: verschillende partijen delen hetzelfde systeem op incompatibele manieren. Een “kogelafsluiter” vs. “ball valve” – zijn ze hetzelfde? Huidige standaarden vertrouwen op menselijke interpretatie: foutgevoelig, tijdrovend, niet-schaalbaar.

De Wiskundige Aard: Dit is geen communicatieprobleem maar een wiskundig probleem. Verschillende decompositiesystemen creëren verschillende hiërarchieën zonder formele methode om equivalentie te bewijzen.

Deel 3: Homotopy Type Theory (HoTT) als Oplossing

HoTT: Wiskundige Rigoureuze Benadering

HoTT kan formeel bewijzen wanneer twee verschillende representaties van hetzelfde object equivalent zijn. Net zoals HoTTSQL kan bewijzen dat verschillende SQL-queries hetzelfde resultaat geven.

Praktische Implementatie:

• Objecten als types: Elke afsluiter wordt een type met velden
• Synoniemen formaliseren: “Kogelafsluiter” ≡ “Ball Valve” expliciet gedefinieerd
• Equivalentie bewijzen: Automatische verificatie dat ProductA ≡ ProductB

Voordelen:

• Automatische verificatie (geen menselijke expertise)
• Schaalbare integratie
• Formele zekerheid (equivalentie wordt bewezen, niet aangenomen)

Deel 4: Een Nieuw Paradigma voor het Bankwezen

Knowledge-Based Behavioral Systems Engineering (KBSE)

Een systeem dat niet alleen processen automatiseert maar kennis representeert en daarop redeneert:

• Expliciete kennis: Basel III, AML-wetgeving
• Gedragsmatige kennis: Cognitieve biases, marktsentiment, psychologische drijfveren

HoTT als DNA van het Banksysteem

“Propositions as types” en “proofs as programs”:

• Een stelling = wiskundig type
• Een bewijs = concreet object binnen dat type
• Geen object mogelijk = stelling is onwaar
• Correct by construction: Het systeem IS het bewijs van zijn eigen integriteit

Architectonisch Ontwerp

Het Tetrahedron Type (T): Vier onlosmakelijke componenten:

1. Financiële doelstellingen
2. Transactionele taken
3. Regulatoire structuur
4. Risicocapaciteiten

Het Sefira Type (S): Formalisering van menselijk gedrag:

• Cognitie (overtuigingen, biases)
• Sentiment (emotionele marktoestand)
• Actie (handelsbeslissingen)

Flower of Life Structuur: Schaalbare, modulaire groei met centrale kern en verbonden afdelingen.

Strategische Voordelen

1. Radicale risicoreductie: Van probabilistisch naar deterministisch
2. Gegarandeerde compliance: Regelgeving integraal onderdeel van systeemlogica
3. Superieure auditability: Wiskundig bewijsspoor voor elke transactie
4. Nieuwe financiële producten: Hyper-gepersonaliseerd met beheerste risico’s

Conclusie: De Volgende Grens

Het raamwerk van Konstapel is meer dan technologisch voorstel – het is een intellectuele uitdaging aan de financiële sector. Door precisie van formele wiskunde te combineren met complexiteit van menselijk gedrag, biedt het een pad naar een financieel ecosysteem dat fundamenteel stabieler, eerlijker en veerkrachtiger is.

De Belofte: De creatie van een bank die wiskundig waterdicht is – een ware prestatie voor de 21e eeuw.

---

“Inmiddels is het bewijzen in de wiskunde geautomatiseerd, dus we kunnen aan de slag, want de basisfuncties in de bedrijfskundige wiskunde zijn bekend.” – J. Konstapel