--- title: "De actuele toestand en het register: twee geheugens van een bedrijfsbesturingssysteem" url: "https://hurukan.com/nl/blog/de-actuele-toestand-en-het-register-twee-geheugens" description: "Een bedrijfsbesturingssysteem heeft twee geheugens nodig: de actuele toestand die modules veranderen, en het register van elk voorstel en besluit." --- # De actuele toestand en het register: twee geheugens van een bedrijfsbesturingssysteem 21 oktober 2026·5 min leestijd·Redactie Een rustige archiefruimte van opzij: een archivaris aan een statafel met één tablet dat een abstract blauw-grijs grootboek toont, achter hem lange rijen identieke grijze opbergdozen onder een dunne blauwe ledlijn, ochtendlicht door een hoog raam Een kredietbeheerder opent de goedkeuringsinbox. Een agent heeft voorgesteld een geblokkeerde order vrij te geven: de klant heeft vanochtend twee achterstallige facturen betaald, het openstaande saldo valt nu binnen de limiet, het voorstel verwijst naar beide betalingen. Ze keurt goed. Drie maanden later betwist de klant een toeslag, en de auditor stelt een eenvoudige vraag: wat wist het systeem om 9.14 uur die dag, en wie heeft besloten? De modules kunnen de eerste helft alleen beantwoorden als er sindsdien niets is overschreven. De betalingstabel toont het saldo van vandaag, niet dat van die ochtend. De order toont zijn huidige status, niet die de agent zag. Het voorstel zelf is uit de inbox verdwenen omdat ernaar is gehandeld. Een systeem waarin agents voorstellen en mensen goedkeuren produceert besluiten in een tempo waarin “we reconstrueren het wel” geen antwoord meer is. Het heeft een tweede geheugen nodig. ## Waarom de opslag van de modules niet het enige geheugen kan zijn De opslag onder de modules is voor één ding gebouwd: de actuele toestand van het bedrijf veilig veranderen. Eén order, één vergrendeling, één transactie, indexen afgestemd op het snel vinden van één rij. Dat is precies wat ze moet zijn, en niets hier stelt voor haar te vervangen. Superintelligentie stelt dezelfde data andere vragen, en elk daarvan belast die opslag. **Lezen op schaal.** Een voorstel over één klant leest duizenden rijen uit orders, facturen, betalingen en klachten. Een model dat het leveringsrisico van het hele orderboek scoort, leest er miljoenen. Leesbewerkingen van die omvang concurreren met de transacties die de opslag moet beschermen. **Geschiedenis.** De opslag bevat wat nu waar is. De meeste vragen aan een agent gaan over verandering: wat de limiet was toen de order werd geaccepteerd, hoe lang deze leverancier al uitloopt, of de marge van deze klant drie kwartalen op rij is gedaald. Een opslag die overschrijft, kan die niet beantwoorden; een geheugen dat versies bewaart wel. **Het hele bedrijf tegelijk.** De order staat in verkoop, de klacht in klantenservice, de pallet in voorraad, de stilstand in bedrijfsvoering. In één besturingssysteem delen ze een datamodel, en dat is het punt van het systeem. Ze hebben daarmee nog geen handige plek om alles tegelijk te lezen zonder de tabellen te raken waarin de modules schrijven. **Wat de agent zag.** Een voorstel is alleen verdedigbaar als de data waaruit het is gemaakt later precies zo kan worden getoond als ze was. Dat vraagt een momentopname, geen actuele waarde. Het antwoord van Hurukan zijn twee geheugens onder één ontologie: de **actuele toestand**, die de modules seconde na seconde veranderen, en het **register**, een onveranderlijke, geversioneerde geschiedenis van elke gebeurtenis, elk voorstel en elk besluit. De [laag Data](https://hurukan.com/nl/system/data) die beide draagt is in aanbouw; wat volgt is hoe ze wordt ontworpen. ## Waar het register van is gemaakt Het register is geen product. Het zijn drie beslissingen, elk één keer genomen. **Bestandsformaten zijn de bakstenen.** Elke gebeurtenis en elke momentopname van een tabel wordt weggeschreven in bestanden in een open formaat. Rijen die tussen modules en connectoren reizen gaan als [Apache Avro](https://avro.apache.org/docs/1.12.0/specification/), waar het schema met de data meereist en compatibiliteit tussen schrijver en lezer een formele regel is. Data die stilligt en per kolom wordt gelezen gaat als [Apache Parquet](https://parquet.apache.org/docs/file-format/), waar een vraag over twee kolommen in miljoenen rijen twee kolommen raakt. Welk formaat welke taak dient is het onderwerp van [Parquet en Avro: de gebeurtenis tussen modules en het register dat superintelligentie leest](https://hurukan.com/nl/blog/parquet-en-avro-de-gebeurtenis-en-het-register). **Een tabelformaat is het bouwplan.** Bestanden alleen zijn een hoop. Een tabelformaat — Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon — bewaart de metadata die zegt welke bestanden op een bepaald moment een tabel vormen, wat haar schema is en hoe ze is veranderd. Omdat de bestanden zelf nooit worden bewerkt, blijft elke versie van de tabel leesbaar: daar komt tijdreizen (time travel) vandaan, en daarmee het antwoord op “wat zag de agent om 9.14 uur”. De keuze ertussen is een keuze over het auditspoor, en die wordt gemaakt in [Het auditspoor is een tabel: Delta Lake, Iceberg of Hudi](https://hurukan.com/nl/blog/het-auditspoor-is-een-tabel). **Een catalogus zegt waar de waarheid is.** Iets moet de verwijzing naar de huidige versie van elke tabel bewaren en bepalen wie haar mag lezen. Die catalogus, niet de bestanden, is waar soevereiniteit wordt gewonnen of verloren. Ze draait op infrastructuur die het bedrijf kiest, en de [laag beveiliging en soevereiniteit](https://hurukan.com/nl/system/beveiliging-en-soevereiniteit) behandelt haar als deel van het eigen bezit van het bedrijf. ## Hoe een gebeurtenis reist Een module verandert de actuele toestand: een betaling wordt geboekt. Dezelfde verandering wordt gepubliceerd als gebeurtenis onder een contract — een benoemd schema met een versie. Een pijplijn zet de gebeurtenis in het register als nieuw bestand onder de metadata van de tabel, binnen de vertraging waar de business om heeft gevraagd. Een nachtelijke verwerking is genoeg voor een margerapport. Minuten zijn nodig voor een kredietbesluit. Seconden zijn nodig voor een werkrij op de werkvloer, en seconden kosten meer dan minuten, en daarom is het niveau een beslissing en geen standaardinstelling. Het register wordt in één richting geschreven. Agents en superintelligentie lezen het, samen met de [ontologie](https://hurukan.com/nl/system/ontologie) die hun vertelt wat een “geblokkeerde order” of een “uitlopende leverancier” betekent. Ze schrijven er niet rechtstreeks in. De uitvoer van een agent is een voorstel dat in de goedkeuringsinbox belandt; een mens keurt goed; de module verandert de actuele toestand; de verandering wordt als gebeurtenis gepubliceerd; de gebeurtenis komt in het register. Het besluitenlog is zelf een tabel in het register, met het voorstel, zijn bronnen, de goedkeurder en het tijdstip. ## Wat de agent zag, en wie besloot Die lus maakt de vraag van de auditor beantwoordbaar. Het register om 9.14 uur is een versie van de tabellen, geen reconstructie. Het voorstel is een rij met de identificatoren van de rijen die het las. De goedkeuring is een rij met de naam van een mens. Niets in de keten hangt af van iemands geheugen. Dezelfde eigenschap dient de mensen die het systeem bouwen. Als een nieuwe versie van een agent wordt geëvalueerd, kan een dag aan gebeurtenissen uit het register tegen haar worden afgespeeld en kunnen haar voorstellen worden vergeleken met wat mensen werkelijk hebben goedgekeurd. Het register is de evaluatieset. ## Agents bouwen de laag Data, onder goedkeuring Hurukan wordt gebouwd en uitgebreid door agents, en de laag Data is geen uitzondering. Een agent schrijft de pijplijn die een nieuw gebeurtenistype aanlevert. Een agent stelt de schemawijziging voor wanneer een module een veld erbij krijgt, en de compatibiliteitscontrole tegen het schemaregister loopt voordat iemand het voorstel leest. Een agent plant het compacteren van kleine bestanden en het verlopen van oude momentopnamen. Elk daarvan is een voorstel met een diff en een testresultaat, en een mens keurt het goed. De goedkeuring wordt vastgelegd als elke andere. Wat bij mensen blijft is wat niet ongedaan kan worden gemaakt of niet kan worden afgeleid: het contract tussen modules, de bewaartermijn van de geschiedenis en het wissen van de gegevens van een persoon, de keuze van formaat en catalogus, en elke protocolupgrade van een tabel die een oudere lezer zou buitensluiten. ## Het register dat u meeneemt Elk deel van het register staat in een formaat dat andere engines lezen. Als het bedrijf vertrekt, vertrekt het met zijn geschiedenis: de bestanden, de tabelmetadata en de catalogus, op zijn eigen infrastructuur. Waar het bedrijf al tools heeft die één formaat lezen — een Microsoft-omgeving, een dochter op Snowflake — kunnen dezelfde bestanden in dat formaat worden ontsloten zonder kopie, wat het onderwerp is van [Eén register, leesbaar voor de tools die u al hebt](https://hurukan.com/nl/blog/een-register-leesbaar-voor-uw-tools). En waar domeinagents de actuele toestand nodig hebben in plaats van de geschiedenis — de werkrij, de voorraad, de goedkeuringsinbox — houdt een tabelformaat dat voor stromen is gebouwd die toestand leesbaar zonder de opslag van de modules te blijven bevragen, en dat is [de zaak voor Paimon](https://hurukan.com/nl/blog/de-toestand-die-agents-lezen-paimon). ## Een test die u vandaag kunt doen Neem één besluit dat uw bedrijf vorig kwartaal nam op basis van een rapport: een kredietlimiet, een nabestelling, een prijs. Probeer de data te reproduceren precies zoals ze was op de dag van het besluit, en de naam van de persoon die het nam. Tel de uren. Dat getal is de prijs van één geheugen, en daarvoor is het register er. - register - lakehouse - audit - tabelformaten - soevereiniteit ## Lees verder - [Een identiteit voor mensen en agents: wie wat mag doen](https://hurukan.com/nl/blog/een-identiteit-voor-mensen-en-agents) - [Een agent die naar het ERP schrijft: lezen versus schrijven](https://hurukan.com/nl/blog/een-agent-die-naar-het-erp-schrijft)