Copyright © 2026 VNG Realisatie. Dit werk is gelicenseerd onder een Creative Commons Naamsvermelding 4.0 Internationaal-licentie (CC BY 4.0).

Samenvatting

Overheidsregisters zijn pas betrouwbaar als ze de werkelijkheid kunnen volgen. Die werkelijkheid is complex, want de situaties van burgers en bedrijven zijn zo gevarieerd als ze zijn. Een betrouwbaar register volgt die complexiteit, zo eenvoudig als het kan: zo simpel als de complexe wereld toestaat.

Registers zijn nog vooral techniek

Veel registers zijn ontstaan in een tijd van mechanisatie en automatisering. Daarom zijn ze nog vaak technisch ingericht, als een database met gegevens. Maar een register is veel meer dan dat. Het legt de besluiten vast die de overheid neemt als ze de wet uitvoert.

Zo is het echter vandaag de dag niet. De gegevens in de systemen weerspiegelen enigszins de eindstanden van die besluiten en sluiten vaak niet aan bij de werkelijke gebeurtenissen van burgers en bedrijven. Dan gaat het mis zodra een situatie afwijkt van wat het systeem verwacht. Een fout is lastig te herstellen. En achteraf kan de overheid niet goed uitleggen waarop een besluit gebaseerd was. Met het verbinden van systemen groeit dit probleem exponentieel.

Gemeenten merken dat elke dag. De VNG schreef in 2019:

“De basisregistraties zijn opgebouwd als aparte silo’s en functioneren nog altijd grotendeels als zodanig. Er is dus geen sprake van een stelsel, maar een stel basisregistraties. Het gebrek aan samenhang belemmert gemeenten in het uitvoeren van hun taken en daar hebben inwoners en ondernemers last van.”

– VNG, position paper Het stelsel van basisregistraties door de ogen van gemeenten (2019)

Wat maakt een register betrouwbaar?

Betrouwbaar betekent in deze handreiking niet dat de gegevens altijd kloppen. De handreiking gaat er juist van uit dat overheidsinformatie soms onjuist is. Een register is betrouwbaar als het dat eerlijk laat zien, kan verantwoorden en kan herstellen.

Een betrouwbaar register legt niet alleen vast wat de overheid weet, maar ook waarop dat rust, wie ervoor instaat en hoe zeker het is. Het laat fouten herstellen zonder dat de geschiedenis verdwijnt. Dat rust op drie pijlers.

1. Verantwoordbaar: elk gegeven is herleidbaar. Gegevens zijn de gevolgen van de taken die de wet aan de overheid geeft. Bij elke vastlegging legt het register de herkomst vast: de bron, de wet of regel die het handelen toestaat, wie verantwoordelijk is en hoe het is gedaan. Ook als alles geautomatiseerd is, staat er altijd een mens voor in. Het register houdt meerdere tijdlijnen bij. Het laat zien wat in werkelijkheid gold en het laat zien wat het register op welk moment voor waar hield. Zo kan ook een organisatie die de gegevens gebruikt achteraf aantonen op welk gegeven ze handelde.

2. Herstelbaar: niets verdwijnt stilletjes. Een besluit rust op een context: de gegevens die er op dat moment zijn. Die context is niet altijd volledig, juist of accuraat. Het register verwerkt daarom correcties, ook als die uit systemen eerder in de keten komen. Wat eenmaal is vastgelegd, verandert niet meer. Een correctie is een nieuwe vastlegging die je kunt herleiden. De oorspronkelijke vastlegging blijft bestaan. Moet iets volgens de wet vernietigd worden? Dan blijft er een merkteken achter. Je ziet dat er iets was, zonder de inhoud te zien. Zo kan het register altijd vertellen wat het eerder heeft verstrekt en hoe het nu is.

3. Eerlijk over zekerheid: over het gegeven én over de verstrekking. Een betrouwbaar register is op twee manieren duidelijk over wat zeker is:

• Hoe zeker is het gegeven? Twijfelt een afnemer aan een gegeven? Dan meldt die dat terug. Het register legt dat vast als betwijfeling. Het blijft het gegeven leveren, maar met een aanduiding van hoe zeker het is. Zo weten alle afnemers van de twijfel terwijl het onderzoek nog loopt. De twijfel reist mee en de fout gaat niet ongemerkt verder door de keten.
• Wat is er geleverd? Het register weet precies wat het heeft geleverd. Elke verstrekking krijgt een eigen referentie. Met die referentie kan het register een eerdere verstrekking altijd precies zo opnieuw leveren. Het kan ook aantonen dat die verstrekking is gedaan. Zo staat vast op welke gegevens een besluit rustte, ook als die gegevens later zijn gecorrigeerd.

Van techniek naar betekenis

Een betrouwbaar register vraagt om een verschuiving: van technische infrastructuur naar functionele analyse en ontwerp. Begin je met een nieuw register? Richt het dan meteen betrouwbaar in. Veel vaker bestaan er al systemen en kun je niet zomaar opnieuw beginnen. Ook dan kun je de overstap maken.

Betekenis kun je achteraf niet toevoegen als die nooit is vastgelegd. Daarom begint de overstap aan de voorkant van het register, waar wijzigingen binnenkomen. Nu is dat vaak een technische interface die alleen gegevens aanmaakt, wijzigt of verwijdert (een ‘CRUD API’). Dat moet anders: niet ‘wijzig adres’, maar ‘registreer verhuizing’. De interface gaat functionele commando’s ontvangen en daaruit gevolgen vastleggen. Van daaruit groeit het register stap voor stap naar meer betekenis.

Wat de handreiking oplevert

De handreiking maakt betrouwbaarheid concreet. Ze geeft een gedeelde taal, duidelijke grenzen, bewijs dat het werkt en steun bij het verbeteren van bestaande systemen.

• Een gedeelde taal. De handreiking beschrijft de begrippen en hoe de onderdelen samenhangen. Twee begrippen staan centraal. Het gevolgenjournaal legt alle gevolgen van de taakuitvoering vast. Een projectie toont die gevolgen vanuit één perspectief.
• Duidelijke grenzen. Een register werkt binnen één afgebakend domein, een ‘bounded context’. Gegevens van buiten neemt het over via expliciete vertaalregels. Zo blijft zichtbaar wat er bij die overgang verloren gaat. Andersom kijken afnemers vanuit hun eigen domein naar dezelfde gevolgen. Er zijn dus altijd meerdere perspectieven. Een register ondersteunt daarom meerdere projecties, elk toegesneden op de informatiebehoefte van afnemers. Juist als systemen met elkaar verbonden worden, houdt dit de keten beheersbaar.
• Demonstraties in werkende code. De voorbeelden zijn scenario’s uit een echte applicatie. Ze gebruiken de BRP en de WOZ als casus. Ze laten zien dat correctie, terugmelding, betwijfeling en onttrekking ook in complexe gevallen werken. Het is dus niet alleen theorie. De voorbeelden laten ook zien hoe je het bouwt. Daarmee zijn ze een bron van inspiratie, voor een nieuw register én voor het verbeteren van een bestaand systeem.
• Steun bij het verbeteren van bestaande systemen. Veel mensen zien een register als ‘de database’. De instapverhalen helpen hen vanuit hun eigen achtergrond de handreiking in te stappen. De handreiking vraagt niet om opnieuw te beginnen. Samen met de voorbeelden biedt ze inspiratie en bouwstenen om een bestaand systeem stap voor stap te verbeteren.

Elke verandering aan een systeem is een kans om zo’n stap te zetten. Zo wordt een bestaand register steeds betrouwbaarder.

Vertrekpunt

Voordat we beschrijven hoe een betrouwbaar register werkt, leggen we vast waar het vandaan komt: welk probleem het oplost, wat we onder een register verstaan en in welke overheid het moet functioneren. Dit vertrekpunt levert de begrippen en uitgangspunten waarop het conceptueel registermodel voortbouwt.

In het kort

De overheid grijpt vergaand in het leven van burgers en bedrijven in, en door automatisering op steeds grotere schaal. Zolang alles volgens plan verloopt – de happy flow – gaat dat goed. Maar wat moet worden aangevochten, onderzocht of gecorrigeerd – de crappy flow – verspreidt zich veel moeizamer door de keten dan de fout zelf. Omdat overheidsinformatie nooit volledig foutloos zal zijn, vraagt dat om epistemische nederigheid: erkennen dat onze kennis beperkt en mogelijk onjuist is, en registers zo inrichten dat je kunt nagaan waar informatie vandaan komt, hoe zeker die is en hoe die door de tijd is veranderd.

In deze handreiking is een register applicatiefunctionaliteit voor het betrouwbaar vastleggen en verstrekken van de resultaten van overheidshandelen binnen een afgebakend domein. De handreiking richt zich op de semantische laag en de applicatielaag, en doet geen uitspraken over wetgeving, organisatie of specifieke producten.

Die afbakening is nodig, omdat de overheid geen homogeen geheel is. Ze valt uiteen in domeinen en, preciezer, in bounded contexten: afgebakende taakgebieden met een eigen, ondubbelzinnige taal en een eigen model. Binnen zo’n context leidt een signaal tot een taak, en de taak tot een gevolg: een duurzaam betekenisvol resultaat van overheidshandelen. Over dat gevolg worden anderen geïnformeerd met verstrekkingen, die elders weer een signaal kunnen zijn. Waar een verstrekking de grens tussen twee contexten oversteekt, ontstaat een contextovergang, en moet taal van de ene context worden vertaald naar die van de andere.

Bestaande registers zijn op dit samenspel slecht toegerust. Ze brengen bijhouding en verstrekking samen in één model, bedienen alle afnemers met dezelfde gegevensset, leggen de context van een wijziging onvolledig vast, houden historie beperkt bij en ondersteunen betwisten en corrigeren nauwelijks. Daartegenover stelt de handreiking een aantal uitgangspunten: gegevens betrekken bij de bron, onderscheid maken tussen proces en resultaat, tussen gevolg (betekenis) en verstrekking (representatie), en tussen bijhouding en verstrekking.

Hoofdstukken

• Aanleiding en doel – waarom registers niet alleen de happy flow, maar ook de crappy flow van fouten en herstel moeten ondersteunen, vanuit epistemische nederigheid.
• Wat is een register? – wat we onder een register verstaan, en op welke architectuurlagen de handreiking zich richt.
• De overheid verkaveld – hoe de overheid uiteenvalt in domeinen en bounded contexten, en wat er gebeurt bij een contextovergang.
• Uitvoeringscontext van registers – hoe overheidshandelen via signaal en taak tot gevolgen leidt, en hoe verstrekkingen over die gevolgen elders tot nieuw handelen leiden.
• De ‘datalaag’ van de overheid – waar bestaande registers tekortschieten, en welke uitgangspunten de handreiking daartegenover stelt.

Van vertrekpunt naar model

Wat in het vertrekpunt als behoefte of uitgangspunt naar voren komt, krijgt in de rest van de handreiking een concrete plek:

Aanleiding en doel

Waar ontbreekt het (nu) aan?

De overheid heeft de bevoegdheid om vergaand in de situatie van burgers en bedrijven in te grijpen. Door automatisering van het inwinnen en verwerken van gegevens kon dit ingrijpen een steeds grootschaliger karakter krijgen. Onze vermogens om overheidshandelen te begrijpen, controleren en daarbij eventueel gemaakte fouten te herstellen hielden met de mogelijkheden van digitalisering echter geen gelijke tred.

Waar het misging werden daardoor niet alleen meer burgers en bedrijven getroffen. Doordat gegevens geautomatiseerd door ketens stroomden, konden op basis daarvan meerdere organisaties handelen. Fouten hadden daardoor voor betrokkenen ook verstrekkender gevolgen.

Deze handreiking beschrijft hoe we overheidsinformatie in registers zodanig kunnen vastleggen en beschikbaar stellen dat we de betekenis en waarde daarvan beter kunnen beoordelen, fouten zoveel mogelijk kunnen voorkomen en die - als dat niet lukt - in ieder geval kunnen herstellen.

De happy en de crappy flow

Zolang burgers en bedrijven dingen willen die wij vooraf hadden bedacht, tijdig de juiste informatie aanleveren, en ‘onze’ overheidsgegevens kloppen - voorwaarden waaraan in de meeste gevallen wordt voldaan - verlopen processen snel en met minimale menselijke tussenkomst.

Maar wat gebeurt er als zo’n burger of bedrijf wordt geconfronteerd met een situatie die niet past binnen de grenzen van de happy flow? Bijvoorbeeld naar aanleiding van een minder vaak voorkomend verzoek of betrokkenheid bij een proces met onvoorspelbaar verloop. Nog lastiger wordt het als iets moet worden aangevochten, onderzocht of gecorrigeerd. Deze handelingen zijn onderdeel van de crappy flow: een werkstroom die vrijwel altijd handwerk vereist, en soms überhaupt niet wordt afgehandeld.

Dit betekent dat resultaten die ontstaan uit happy flows zich gemakkelijk en grotendeels geautomatiseerd door het overheidsapparaat kunnen verspreiden, terwijl uit crappy flows voortkomende twijfelindicaties en correctiehandelingen - als ze al verwerkt worden - nauwelijks de grens oversteken naar vanuit gegevensgebruikperspectief stroomafwaarts liggende domeinen, waardoor in die domeinen op basis van verkeerde gegevens onjuiste gevolgen geproduceerd kunnen worden.

Parabel: Infrastructuur van Digitalië

De eilanden van het atollenrijk Digitalië zijn met indrukwekkende hogesnelheidsinfrastructuur verbonden. Maar die is alleen toegankelijk voor een selecte meerderheid van contente conformisten.

Pogingen om op deze infrastructuur ook een minderheid van abusievelijke anarchisten toe te laten zijn allemaal mislukt. Want deze groep zonder vaste bestemming negeerde zorgvuldig vastgestelde gewichts- en hoogtebeperkingen, bewoog zich tegen rijrichtingen in en vroeg om afritten op onmogelijke plaatsen.

Terwijl hoog boven de golven contente conformisten voortrazen, zijn abusievelijke anarchisten in hun kleine scheepjes nog altijd overgeleverd aan de stormen van de Analoge zee. “Natuurlijk is dat onrechtvaardig”, bevestigt een beleidsmaker. “Maar er is gewoon geen businesscase.”

Epistemische nederigheid

Het bovenstaande maakt duidelijk dat overheidsinformatie niet altijd klopt. En dit soort onjuistheden zullen altijd overblijven, hoeveel crappy flows we ook in happy flows weten om te zetten. Deze constatering vraagt om epistemische nederigheid: het erkennen dat onze kennis beperkt, voorlopig en mogelijk onjuist is.

Maar naar dit principe handelen is moeilijk als het gereedschap om de waarde van informatie te kunnen beoordelen ontbreekt. Binnen de overheid kunnen we zo’n inschatting op dit moment vaak alleen voor het ‘eigen’ domein maken. Dit betekent dat we niet kunnen achterhalen wie een keten van overheidshandelen in beweging heeft gezet, en wanneer en met welke reden dat is gebeurd. En dat we geen compleet beeld hebben van hoe lang óns handelen verderop in de keten nog doorwerkt.

Om dit op te lossen hebben we meer en beter inzicht in de context van onze informatie nodig. Deze behoefte kunnen we samenvatten in een aantal aspecten:

• Bron: welke input vormde de basis voor ons handelen?
• Legitimering: welke wet of regel legitimeerde ons handelen en het gevolg dat door dat handelen werd geproduceerd?
• Verantwoordelijke: wie was verantwoordelijk voor ons handelen?
• Werkwijze: welke (geautomatiseerde) handelingen hebben we uitgevoerd om een gevolg te produceren?
• Zekerheid: in hoeverre, en op grond waarvan kunnen we uitgaan van de (on)juistheid van een gegeven?
• Historie: hoe zag de situatie er in het verleden uit en welke veranderingen hebben door de tijd heen plaatsgevonden?
• Betekenis: wat betekent deze informatie?

Wat is een register?

Betekenis van het begrip ‘register’

Het woord ‘register’ heeft in verschillende contexten uiteenlopende betekenissen. Een organist zal daarbij denken aan een serie orgelpijpen met dezelfde klankkleur, een auteur ziet een lijst met trefwoorden voor zich, terwijl een werkplekbeheerder zich de editor voorstelt waarmee instellingen van Windowssystemen kunnen worden aangepast.

Associaties van geïnteresseerden in deze handreiking zullen waarschijnlijk dichter bij elkaar liggen. Maar ook als we de betekenisruimte inperken door te stellen dat een register iets te maken moet hebben met het verwerken van informatie binnen de overheid, blijven nog uiteenlopende zienswijzen over. Bijvoorbeeld:

• holistisch: een volledig stelsel gericht op het bijhouden en leveren van bepaalde gegevens, bestaande uit wet- en regelgeving, betrokken organisaties en hun onderlinge afspraken, systemen voor opslag en distributie van gegevens en de technische infrastructuur die hiervoor nodig is;
• universeel: een digitaal of fysiek bijgehouden verzameling geordende informatie;
• afnamegericht: een plaats waar bepaalde gegevens onder bepaalde voorwaarden verkregen kunnen worden, of
• technisch: een database.

Om verwarring te voorkomen, is het belangrijk het begrip register in de context van ‘Uit betrouwbare bron’ betekenis te geven. Wij definiëren een register als volgt:

“Applicatiefunctionaliteit voor het betrouwbaar vastleggen en verstrekken van de resultaten van overheidshandelen binnen een afgebakend domein.”

Register of registratie?

Binnen de overheid gebruiken we voor aanduiding van een georganiseerde gegevensverzameling zowel het begrip register (Kentekenregister, Register van overheidsorganisaties, BIG-register, UBO-register) als registratie (met name in de context van basisregistraties).

Er zijn twee redenen om binnen ‘Uit betrouwbare bron’ het begrip register te gebruiken. Enerzijds sluit dat het beste aan bij de betekenis in ‘gewoon’ taalgebruik. Een register is volgens het Van Dale-woordenboek een “inschrijvingsboek, naamlijst; goed geordende inhoudsopgave: bevolkingsregister, namenregister”, terwijl registratie wordt gedefinieerd als “inschrijving in een register: de registratie van een koopakte.”

Daarnaast willen we de indruk vermijden dat ‘Uit betrouwbare bron’ gaat over basisregistraties. Hoewel het project niet tot doel heeft een in productieomstandigheden werkend register op te leveren, verwachten we dat in deze handreiking beschreven bevindingen in eerste instantie waardevol zullen zijn binnen domeinen waarbinnen op basis van gedeelde kennis intensief wordt samengewerkt, maar (nog) geen basisregistratie bestaat.

Perspectieven op het register

Een definitie alleen is niet genoeg om duidelijk te maken waarover ‘Uit betrouwbare bron’ gaat. Ook een register kan je immers vanuit verschillende perspectieven benaderen. Om duidelijk te maken welke daarvan wij innemen, beschrijven we de scope van het project aan de hand van twee elkaar aanvullende architectuurmodellen:

1. De European Interoperability Reference Architecture (EIRA)
2. Het Common Ground-vijflagenmodel

Architectuurlagen en scope UBB

Betere ondersteuning van de crappy flow en het faciliteren van epistemische nederigheid vereist verandering in alle EIRA-lagen: juridisch, organisatorisch en technisch. Deze handreiking richt zich echter primair op de semantische en applicatielaag (het gebied binnen de paarse gestreepte lijn in bovenstaande figuur).

Binnen de applicatielaag kunnen we dankzij het Common Ground-model preciezer zijn over onze scope: we beperken ons tot de lagen ‘databronnen’, ‘diensten’ en, vanwege de relatie tussen bijhoudingsdiensten en processen die deze gebruiken, ook een deel van ‘procesinrichting’ (gele gestreepte lijn in bovenstaande figuur). Dit betekent dat we bijvoorbeeld aanbevelingen doen voor:

• welke concepten belangrijk zijn om de werking van het register te begrijpen, welke betekenis we daaraan geven en hoe de samenhang daartussen eruitziet;
• uit welke conceptuele ‘bouwblokken’ het register bestaat en welke rol die spelen;
• welke generieke (dus onafhankelijk van welke gegevens een register omvat toepasbare) functionaliteit het register moet leveren, en
• hoe deze functionaliteit met behulp van API’s toegankelijk te maken.

Hoewel we andere lagen niet helemaal kunnen en willen negeren - verderop bespreken we bijvoorbeeld de begrenzing van het register in relatie tot de (organisatorische) domeinen die het ondersteunt - betekent deze scopeafbakening dat we in deze handreiking geen aanbevelingen doen over bijvoorbeeld:

• interpretatie of herziening van wet- en regelgeving;
• verdeling van verantwoordelijkheden over organisaties (wel/niet gescheiden organisaties voor bijhouding en verstrekking, bijhouding en verstrekking wel/niet organisatorisch federatief of juist centraal);
• gebruik van specifieke technische producten (hoewel die bij onze beproevingen wel een belangrijke rol spelen);
• bij concrete implementatie in één technisch product clusteren van applicatiecomponenten (bijvoorbeeld vanwege efficiëntie- of performanceredenen), en
• het ontwerpen van interfaces om registergegevens aan gebruikers te presenteren.

De overheid verkaveld

Registers staan niet op zichzelf, maar ondersteunen de overheid bij het invullen van haar administratieve behoeften. Die overheid vormt geen homogeen, eenduidig handelend geheel, maar is een pluriform en complex systeem.

Om de verhouding tussen register en overheid te kunnen duiden, moeten we dat systeem - liefst op basis van objectieve criteria - kunnen verkavelen naar logisch samenhangende delen, zonder daarbij al te veel door bestaande indelingen geleid of gehinderd te worden.

Ons streven is dat ieder van die delen groot genoeg is om zelfstandig bestaansrecht te hebben, maar klein genoeg om een ondubbelzinnig begrip van concepten, regels en processen te kunnen waarborgen.

Domein

Vaak wordt het woord domein gebruikt om binnen het totaal aan taken en verantwoordelijkheden van de overheid een specifiek, samenhangend werkgebied aan te wijzen. Maar anders dan in de wiskunde kent het begrip domein in organisatorische context geen objectieve afbakeningscriteria. Dit blijkt bijvoorbeeld uit de definitie die Eric Evans hanteert in de context van Domain-driven design. Evans beschouwt een domein als “een sfeer van kennis, invloed of activiteit”. Hoewel deze definitie een zekere mate van interne samenhang veronderstelt, sluit die niet uit dat binnen één domein:

• dezelfde concepten verschillend geïnterpreteerd worden,
• regels en gedrag niet consistent zijn, en
• bedrijfsprocessen niet op elkaar zijn afgestemd.

Een domein voldoet dus weliswaar aan de eis van zelfstandig bestaansrecht, maar is niet restrictief genoeg om ondubbelzinnig begrip van wat daarbinnen gebeurt te waarborgen.

Bounded context

Binnen een domein kunnen meerdere subdomeinen of taakgebieden bestaan. Daarbij horen verantwoordelijkheden, die zijn toegekend aan specifieke teams, afdelingen of bedrijfseenheden. Zij worden ondersteund door eigen semantiek, processen en regels. Deze zaken kunnen worden beschreven in een model: een systeem van abstracties dat beschrijft hoe men vanuit een taakgebied naar de wereld kijkt en reageert op veranderingen in de buitenwereld. Zo’n model is beschreven in gemeenschappelijke taal die binnen het hele taakgebied begrepen wordt.

Model en taal beschrijven dus een voor betrokkenen herkenbare ‘blauwdruk’ van het taakgebied, die (onder andere) de basis kan vormen voor het ontwerp van een register. Een in gemeenschappelijke taal ondubbelzinnig en samenhangend gemodelleerd taakgebied noemen we een bounded context.

Het belang van het erkennen van bounded contexten wordt door Eric Evans in ‘the Blue Book’ over Domain driven design als volgt beschreven:

“A bounded context delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other contexts. Within that context, work to keep the model logically unified, but do not worry about applicability outside those bounds. In other contexts, other models apply, with differences in terminology, in concepts and rules, and in dialects of the ubiquitous language [red. gemeenschappelijke taal]. By drawing an explicit boundary, you can keep the model pure, and therefore potent, where it is applicable. At the same time, you avoid confusion when shifting your attention to other contexts. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly.”

Uit dit citaat blijkt dat de ambiguïteiten die we op domeinniveau nog konden tegenkomen binnen een bounded context (idealiter) verdwijnen. Hier geldt (zoveel mogelijk) dat:

• dezelfde concepten eenduidig geïnterpreteerd worden (op basis van gemeenschappelijke taal),
• regels en gedrag consistent zijn, en
• bedrijfsprocessen op elkaar aansluiten.

Contextovergangen

Bounded contexten bestaan zelden in volledige isolatie. Veel vaker zijn ze in ketens of netwerken verbonden met andere bounded contexten. Dit betekent dat een gevolg dat werd geproduceerd in de ene context, in een volgende context wordt beschouwd als aanleiding of trigger voor het produceren van een nieuw gevolg. Bij het oversteken van de grens tussen de twee bounded contexten ontstaat een contextovergang. Hierbij moeten taal en model van de ene context omgezet worden naar taal en model van de andere.

Verstrekkingen kennen daarom geen ‘vaste’ bounded context. Deze kunnen zijn opgesteld in de taal van de context die het gevolg produceerde waarover een verstrekking gaat. In andere gevallen kan een verstrekking echter expliciet bedoeld zijn om een specifieke (afnemende) bounded context te informeren. Op verzoek van deze contexten kunnen vanuit de producerende context daarom verstrekkingen worden geproduceerd die dichter tegen de context van de ‘afnemende bounded context’ aanliggen.

Afhankelijk van de situatie zal een producent van gevolgen ervoor kiezen om beide te doen: naast één of meerdere verstrekkingen die taal en model van de ‘eigen’ context volgen, worden dan óók verstrekkingen gemaakt die aansluiten bij de conventies van bounded contexten van afnemers.

Taak en gevolg hebben wel een vaste bounded context en conformeren zich altijd aan de taal en het model van de bounded context waarbinnen ze worden uitgevoerd c.q. geproduceerd.

Voor meer informatie zie de Verdieping: Bounded Context Bridge en voorbeeld belang overgegaan naar aanleiding van eigendomsoverdracht.

Uitvoeringscontext van registers

Binnen iedere bounded context wordt gewerkt. Een deel van dat werk slaat neer in onze registers. Om te begrijpen welk deel, moeten we het karakter van dit werk op abstract niveau begrijpen. In dit hoofdstuk beschrijven we daarom een conceptualisering van de overheid als uitvoerder van taken die horen bij publieke dienstverlening. Die vertrekt bij de overheid als producent van gevolgen en afnemer van verstrekkingen.

De overheid als producent van gevolgen

Het begrip gevolg wordt op Wikipedia beschreven als “een gebeurtenis of omstandigheid die optreedt als resultaat van een of meer oorzaken en bijdragende factoren en omstandigheden”. Binnen de context van deze handreiking hanteren we een wat preciezere betekenis, namelijk het gevolg als “duurzaam betekenisvol resultaat van overheidshandelen”.

Om bovenstaande definitie te begrijpen, is het behulpzaam het handelen van de overheid nader te bekijken. Dat handelen begint bij een taak of bevoegdheid, die ontstaat vanwege attributie (‘toewijzen’) door de wetgever. Artikel 5.8 van de Omgevingswet attribueert bijvoorbeeld aan het college van burgemeester en wethouders de bevoegdheid te beslissen of een omgevingsvergunning al dan niet wordt verleend.

Een bevoegdheid houdt (mits aan een aantal basisvoorwaarden voldaan is) een plicht tot handelen in; het college kan er dus niet zelfstandig voor kiezen de ene aanvraag wel, en de andere niet in behandeling te nemen. Dit betekent dat een aanvraag altijd leidt tot één of meer handelingen, die weer één of meer resultaten opleveren. In het geval van de omgevingsvergunning is aan te denken aan handelingen als:

• beoordelen op indieningsvereisten (juistheid en compleetheid)
• inwinnen advies bij ketenpartner
• besluiten over verlenen vergunning

Daarbij horen resultaten als:

• aanvraag is in behandeling genomen
• advies ingewonnen
• vergunning verleend (of niet verleend)

Niet al deze resultaten zijn echter een gevolg. We hebben immers gesteld dat daarvoor een duurzaam betekenisvol karakter nodig is. Het is niet eenvoudig deze karakteristiek in algemeenheid waterdicht te definiëren. Informeel kunnen we stellen dat het resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt als gevolg gezien moet worden. Vaak (maar niet per definitie) is zo’n gevolg gelijk aan het rechtsgevolg dat naar aanleiding van overheidshandelen ontstaat.

In het geval van de omgevingsvergunningaanvraag beschouwen we op basis hiervan het verlenen (of juist het niet verlenen) van de gevraagde omgevingsvergunning als gevolg. Specifieke voorwaarden waaronder de vergunning is verleend, zoals een maximaal bouwvolume of vereiste goothoogte, kunnen van zo’n gevolg onderdeel zijn.

Hoewel het voor de hand ligt een gevolg te beschouwen als verandering in de bounded context waarbinnen gehandeld wordt, maakt het bovenstaande duidelijk dat hiervan niet altijd sprake hoeft te zijn. Het niet-verlenen van de omgevingsvergunning betekent vanwege het gesloten karakter van het omgevingsrecht dat iets wat vóór de aanvraag niet mocht, nu nog steeds niet mag. Hier is dus sprake van een (beargumenteerde) bevestiging van de bestaande situatie, en niet van een verandering. Zo’n verandering zien we wel als de vergunning wordt verleend, waarna iets wat eerst niet mocht, (nu) wel mag.

Productie van een gevolg

Voor een vollediger begrip van hoe een gevolg ontstaat, moeten we het bijbehorende productieproces in meer detail bekijken. Binnen dat proces kunnen we drie belangrijke concepten onderscheiden. Hierbij geldt dat ieder volgend concept afhankelijk is van het voorgaande:

1. Signaal: een indicatie dat er ergens - in de buitenwereld, een andere of de eigen overheidsorganisatie - iets is gebeurd wat aandacht verdient.
2. Taak: de handelingen die naar aanleiding van een signaal moeten worden uitgevoerd.
3. Gevolg: een duurzaam betekenisvol resultaat van overheidshandelen.

De overheid als afnemer van verstrekkingen

Hierboven benoemden we het signaal als aanleiding voor de productie van één of meerdere gevolgen. Maar we beschreven niet waar zo’n signaal vandaan komt. Omdat binnen de overheid vaak in ketens of netwerken wordt gewerkt, is de bron van zo’n signaal heel vaak óók de overheid. Meer precies een andere bounded context die een gevolg heeft geproduceerd en keten- of netwerkpartners daarover informeert.

Dit betekent dat de productie van een gevolg in heel veel gevallen niet het eindstation van overheidshandelen is. Vrijwel altijd willen we daarover ook anderen informeren - bijvoorbeeld de burger die een omgevingsvergunning heeft aangevraagd uit het voorbeeld hierboven, maar ook bedrijven, partnerorganisaties of collega-overheden. Deze doelgroepen hebben uiteenlopende informatiebehoeften en verwerken informatie op verschillende manieren.

Diversiteit in behoeften en verwerkingsvoorkeuren betekent dat een informering meer omvat dan alleen de betekenis die een gevolg beschrijft. Die betekenis wordt in een bepaalde vorm overgebracht - denk aan een per mail verzonden besluit in pdf-formaat, het resultaat van een specifieke query of een voor geautomatiseerde verwerking geschikte notificatie. Dit betekent dat we te maken hebben met een representatie van een gevolg.

Bij die representaties horen verschillende verstrekkingspatronen. Sommige verstrekkingen vinden plaats op verzoek, bijvoorbeeld na aanroep van een bevragingen-interface (API). Andere verstrekkingen worden juist proactief aangeboden, zoals een systeemnotificatie die naar aanleiding van registratie van een nieuw gevolg automatisch wordt verzonden.

Dat we met het doel anderen daarover te informeren op basis van een gevolg verschillende representaties creëren, rechtvaardigt het toevoegen van een vierde begrip aan de drie concepten die we hierboven opsomden:

4. Verstrekking: een voor afname bedoelde doel(groep)specifieke communicatie-uiting over een gevolg.

Met de toevoeging van verstrekking (hieronder geïllustreerd als levering) is onze conceptualisatie van overheidshandelen bij publieke dienstverlening in de uitvoering compleet. Hieronder is dit proces volledig geïllustreerd.

Succesvol verstrekken

Dat overheden elkaars verstrekkingen gebruiken als grondstof voor het produceren van nieuwe - eigen - gevolgen klinkt vanzelfsprekend, maar brengt voor zo’n verstrekking wel eisen met zich mee.

Een afnemer van verstrekkingen heeft bijvoorbeeld duidelijkheid nodig over de bedoeling en betekenis van zo’n verstrekking, zodat bepaald kan worden of de eigen taken of bevoegdheden het nodig maken naar aanleiding daarvan te handelen. Dit betekent dat bij verstrekkingen verschillende aspecten van interpreteerbaarheid een rol kunnen spelen: wat is de boodschap, op welk moment heeft die betekenis, voor wie is die bedoeld, en in welke omstandigheden is die toepasbaar? Dit noemen we de context van de verstrekking.

Producenten van verstrekkingen kunnen interpretatieverwarring over verstrekkingen deels voorkomen door die te laten aansluiten bij taal en model van afnemende bounded contexten waarbinnen gegevens ontvangen en verwerkt gaan worden.

Onderdeel van deze contextinformatie is ook twijfel over de juistheid van, of andere kwaliteitsvoorbehouden bij de inhoud van de verstrekking. Zulke twijfels kunnen zijn ontstaan na constatering van (vermoedelijke) fouten door een verstrekkingsafnemer. Die moet dergelijke fouten dan wel kunnen melden, wat vraagt om betwistbare verstrekkingen - of met andere woorden: verstrekkingen waarop teruggemeld kan worden, waarop onderzoek, en indien nodig, correcties kunnen volgen.

Verstrekkingen moeten daarnaast een onveranderlijk karakter hebben. Het vandaag opvragen van geleverde gegevens moet ook morgen of over een aantal jaar - zolang tenminste dezelfde vraag gesteld wordt - hetzelfde resultaat opleveren. Dit noemen we de herhaalbare vraag.

Toegangsbeperkingen zijn een laatste punt van aandacht. Bijvoorbeeld vanwege het waarborgen van de privacy van betrokkenen mogen sommige afnemers misschien niet kennisnemen van een volledig gevolg - zoals een adoptie - terwijl onderdelen daarvan - zoals een verandering van ouderschap - voor hen wel relevant zijn.

Bespiegeling over de modellering van gevolgen

Bovenstaande roept vragen op over wat nu precies de omvang en granulariteit van gevolgen bepaalt. Hierboven noemden we als uitgangspunt het (handelings)resultaat dat in meest directe zin de aanleiding voor of vraag om het overheidshandelen beantwoordt. Dit impliceert dat alléén vanuit het proces dat ze produceert wordt bepaald wat als gevolg wordt beschouwd. Als vervolgens echter blijkt dat afnemers in heel veel gevallen slechts recht hebben een deel van een gevolg in te zien - zoals in het adoptievoorbeeld - is de vraag gerechtvaardigd of voor dat gevolg niet een te grote omvang is gekozen.

De ‘datalaag’ van de overheid

Nu we een beeld hebben van hoe publieke dienstverlening binnen de overheid werkt en beschikken over een bijbehorend begrippenkader, kunnen we overstappen naar het onderwerp van deze handreiking: registers. We beginnen die gezamenlijk te beschouwen, als ‘datalaag van de overheid’.

Tekortkomingen van bestaande registers

Bestaande overheidsregisters zijn op basis van ondertussen vaak decennia-oude techniek en inzichten primair ontworpen om administratieve processen efficiënter te maken. Deze inzichten en techniek zijn verrassend veerkrachtig en toekomstbestendig gebleken. Maar dit vereiste ook dat bijvoorbeeld bijhouding en verstrekking in één model werden samengebracht.

Dit compromis blijkt terugblikkend ongemakkelijk. Registers bevatten daardoor presentaties die niet helemaal voldoen aan de behoeften van afnemers, maar tegelijkertijd vanuit bijhoudingsperspectief ook niet de essentie - ofwel de gevolgen - representeren.

Veel registers bedienen alle afnemers op basis van één generieke gegevensset. Omdat in dat geval geen onderscheid wordt gemaakt naar taken en bevoegdheden, krijgen sommige afnemers meer informatie dan nodig - en soms zelfs toegestaan - is, terwijl anderen juist gegevens missen.

In veel registers wordt bovendien contextinformatie niet (volledig) vastgelegd. Informatie over de aanleiding van een wijziging, de juridische grondslag of de handelingen die tot het resultaat hebben geleid ontbreekt of is onvolledig. Voor een afnemer is daardoor niet altijd duidelijk wat een gegeven precies betekent, voor welke situatie het geldt en hoe het moet worden geïnterpreteerd.

Historie wordt vaak slechts beperkt bijgehouden. Soms is alleen de actuele toestand beschikbaar, in andere gevallen is die beperkt tot eendimensionale wijzigingshistorie. En als wel volledige historie in twee dimensies wordt bijgehouden, maakt het toestaan van wijzigingen in de registratietijdlijn (bijvoorbeeld als gevolg van rechterlijke uitspraken) het stellen van een gegarandeerd herhaalbare vraag onmogelijk.

Ook het betwisten en corrigeren van gegevens is vaak onvolledig ondersteund. Wanneer een afnemer een mogelijke fout constateert, bestaat er meestal geen gestandaardiseerde manier om die constatering zichtbaar te maken voor andere afnemers. Terugmeldprocessen bestaan meestal wel op organisatieniveau, maar de koppeling tussen deze processen en de registers die betwiste gegevens leveren is niet altijd goed ingericht.

Een combinatie van bovenstaande zorgt ervoor dat het vaak niet mogelijk is mutaties met terugwerkende kracht uit te voeren. Dit betekent dat fouten niet kunnen worden hersteld als daarvoor niet-actuele informatie gecorrigeerd moet worden. Daardoor worden betrokkenen blijvend geconfronteerd met de gevolgen van onjuiste gegevens.

Deze beperkingen waren lang onvermijdelijk en werden, afgezet tegen geboekte efficiëntiewinst, als acceptabel beschouwd. Maar nu overheidsorganisaties de ambitie hebben (zie hieronder) veel vaker elkaars gegevens te gebruiken als grondstof voor nieuwe besluiten en gevolgen, en dat bovendien bij de bron te doen, wordt het belangrijk dat verstrekkingen ook context, betwistbaarheid, reproduceerbaarheid en passende toegang ondersteunen.

Overheidsbrede ontwikkelingen

De Architectuur Digitale Overheid 2030 onderkent de belangrijke rol van data bij (proactieve) beleidsontwikkeling en dienstverlening van de overheid. Om wildgroei en kwaliteitsverlies te voorkomen, willen we die data liever vanuit een aangewezen bron hergebruiken dan (steeds) opnieuw inwinnen.

Bovenstaande lukt alleen als partijen in de FDS-rol van data-aanbieder hun data zodanig kunnen vastleggen en beschikbaar stellen dat die een bruikbare basis vormt voor FDS-datadiensten.

Als het gaat om vernieuwing van het fundament van de overheidsinformatievoorziening wordt ook verder in de toekomst gekeken. De geautomatiseerd uitvoerbare regels van Regelrecht zouden veel gegevensopslag overbodig kunnen maken. En Chronolexografie is een manier om heel gestructureerd rechtstoestanden - oftewel “hetgeen juridisch gezien het geval is (geweest)” - vast te leggen en te reproduceren.

Helpende uitgangspunten

De hierboven beschreven aandachtspunten en ontwikkelingen beschrijven een deel van de context waarbinnen deze handreiking tot stand kwam. Onderstaande uitgangspunten helpen te begrijpen hoe we ons tot die context verhouden en wat deze handreiking wel en niet beoogt.

Gegevens betrekken ‘bij de bron’

We kopiëren te veel gegevens zonder mechanismen om kwaliteit en actualiteit van die kopieën te waarborgen. Deze handreiking is erop gericht de noodzaak voor het maken van gegevenskopieën bij het uitvoeren van publieke dienstverleningsprocessen waar dat haalbaar is weg te nemen.

Onderscheid maken tussen proces en resultaat

We erkennen een verschil tussen formeel beschreven of informeel uitgevoerde processen en daaruit voortkomende resultaten. Een proces vertelt hoe de overheid handelt. Als resultaat daarvan ontstaat iets met betekenis of waarde. Deze handreiking gaat niet over procesautomatisering, maar beschrijft op welke manier we de resultaten daarvan zo goed mogelijk kunnen vastleggen en beschikbaar stellen.

Onderscheid maken tussen gevolg (betekenis) en verstrekking (representatie)

Als het gaat om bovengenoemde resultaten, erkennen we het verschil tussen betekenis van een resultaat - dat we gevolg noemen, en communicatie daarover, waarvoor een representatie (verstrekking) nodig is. Het verenigen van deze concepten in één artefact - bijvoorbeeld een akte - werkt het ontstaan van ‘vormfouten’ (bijvoorbeeld het onjuist overnemen van een juiste conclusie in een besluit of databasetabel) in de hand.

Hoewel sprake is van een afhankelijkheidsrelatie - de verstrekking is (via een projectie) afgeleid van het gevolg - zijn ze vanuit verantwoordingsperspectief van even groot belang. Het gevolg geldt als ‘kern’ van wat bedoeld werd, en de verstrekking is hetgeen op basis waarvan anderen (mogelijk) hebben gehandeld.

Bij deze conceptualisatie past de metafoor van de januskop of het hoofd met twee gezichten. Janus deelt één brein - dus een gedeelde, onderling verbonden hoeveelheid kennis, met daarop twee perspectieven, ingegeven door twee paar zintuigen. Het ene paar blikt terug op een proces dat een bepaald resultaat - of gevolg - opleverde, terwijl het andere paar vooruit kijkt, richting door verstrekkingen van die gevolgen in gang gezette vervolghandelingen.

Janus(kop)

Afbeeldingscredit Igor Gordeev

In de beeldhouwkunst en schilderkunst is een januskop een hoofd met zowel aan de voorzijde als aan de achterzijde een gezicht. Het is genoemd naar de Romeinse god Janus, die in een van zijn verschijningsvormen twee gezichten had.

Janus was een Romeinse god die heerste over alle begin en overgang. Vóór hij door Jupiter tot god met twee gezichten gemaakt werd, heerste hij volgens legende als koning over Latium. Daar werd hij beschouwd als stichter van het maatschappelijke leven en van de maatschappij, die de mensen verloste uit hun barbaarse toestand en tot een ordelijk leven bracht.

Onderscheid maken tussen bijhouding en verstrekking

Gelijktijdig erkennen van het verschil tussen, en gelijkwaardig belang van gevolg en verstrekking, vraagt in registerarchitectuur om onderscheid tussen bijhouding en verstrekking. Dit maakt het mogelijk om op de specifieke informatiebehoefte van bepaalde afnemers toegesneden projecties te leveren.

De wens onnodige kopieën te vermijden vraagt erom deze perspectieven op één onderliggende werkelijkheid beide als bron met zelfstandig bestaansrecht te beschouwen. De betrouwbaarheidsaspecten van een register zijn dan ook voor beide perspectieven relevant. De begrippen gevolgenjournaal en projecties gebruiken we om de gegevensverzamelingen die bij de perspectieven horen te onderscheiden.

Registermodel

In het kort

De hoofdlijn van het model is te lezen van links naar rechts. Een uit een externe bevinding vertaald of rechtstreeks aangeboden commando komt de bounded context van het register binnen. De functie Optekenen produceert op basis van het commando één of meerdere gevolgen, opgebouwd uit gevolgdelen, met herkomst en tijd, en voegt die toe aan het gevolgenjournaal. De functie Projecteren leidt uit dat journaal projecties af, elk met een eigen bereik en vorm. Deze projecties zijn de bron voor verstrekkingen aan afnemers, met referenties die verificatie en herlevering mogelijk maken. Wie vermoedt dat een geleverd projectie-element onjuist is, kan een terugmelding indienen. En als beweringen niet langer beschikbaar mogen zijn, worden ze Blijvend ontoegankelijk gemaakt.

Opbouw van het model

Het model bestaat uit onderdelen die elk een samenhangend deel van de functionaliteit van een register beschrijven. Elk onderdeel heeft een eigen hoofdstuk:

• Bounded contextmodel – wat het register kan opnemen, in welke taal, en hoe dat doorwerkt in wat het levert.
• Commando’s – hoe wat van buiten binnenkomt wordt omgezet in een commando in de taal van het register.
• Gevolgen – hoe het register op basis van commando’s gevolgen optekent in het gevolgenjournaal, en hoe het corrigeert, twijfelt en onttrekt.
• Projecties – hoe uit het gevolgenjournaal projecties worden afgeleid die aansluiten bij de informatiebehoefte van afnemers.
• Verstrekken – hoe het register projectie-elementen verstrekt, en die verstrekkingen later kan herleveren en attesteren.
• Betwisten – hoe afnemers kunnen terugmelden dat een geleverd projectie-element vermoedelijk onjuist is.
• Vernietigen – hoe het register beweringen blijvend ontoegankelijk maakt.

Daarnaast bevat het model een aantal begrippen die alle onderdelen ondersteunen: de bewering en wat daarbij hoort. Die beschrijven we hieronder.

Bewering als bouwsteen

Een register bevat beweringen. Zo’n bewering is een eenheid van gegevens die op basis van herkomst en tijd als geheel wordt beschouwd en waarvan de juistheid als geheel staat of valt. Een bewering valt dus niet uiteen in delen waarvan de juistheid afzonderlijk zou kunnen worden beoordeeld. Wat samen wordt vastgelegd, wordt samen betwist en samen onttrokken.

Een gegeven is het kleinste betekenisdragende onderdeel van een bewering. Losse gegevens komen in het register niet voor; een gegeven bestaat alleen binnen een bewering en ontleent daaraan zijn herkomst en zijn plaats in de tijd.

Het register kent twee soorten beweringen: gevolgen, die het register als primair feit optekent, en projectie-elementen, die daarvan zijn afgeleid.

Entiteit

Het register beschrijft dingen: personen, gebouwen, huwelijken, voertuigen. In het model heten die entiteit. Het register houdt die entiteiten zelf niet bij – in plaats daarvan omvat het beweringen over entiteiten. Omdat de entiteit in de bounded context die het register ondersteunt een centrale rol speelt, maar in het register niet bestaat, wordt die in het model als bedrijfsobject gerepresenteerd.

Om beweringen over een entiteit met elkaar te verbinden, is identiteit nodig. Die verleent het register met een identiteitsverlenend gevolgdeel (zie Identiteit). Welke soorten entiteiten er zijn en hoe ze worden geïdentificeerd, legt het entiteittype vast.

Herkomst en tijd

Elke bewering kent herkomst en tijd. Dat geldt voor gevolgen en voor projectie-elementen.

Herkomst is de verantwoording van de totstandkoming van een bewering: welke bron eraan ten grondslag ligt, wie als verantwoordelijke voor de productie instaat, welke legitimering is toegepast en welke werkwijze is gevolgd. Waar de bron in een document is vastgelegd, verwijst het model daarnaar.

Tijd plaatst een bewering in de tijd en valt uiteen in twee soorten. De domeintijd is het punt of de periode die onlosmakelijk hoort bij wat een bewering beschrijft. De systeemtijd is het punt dat het register bij het vastleggen toevoegt. Aan de domeintijdkant kunnen meerdere tijdsdimensies bestaan; er is één systeemtijddimensie. Omdat gevolgen en projectie-elementen elk een eigen systeemtijd hebben, komt die dimensie op twee plekken terug: aan de journaalkant als gevolgtijdstip en aan de projectiekant als projectietijdstip. Beide liggen op dezelfde as.

Betrouwbaarheidsaspecten

Herkomst en tijd zijn eigenschappen van elke afzonderlijke bewering, maar hun waarde blijkt pas als je ze door het hele register volgt: van externe bevinding via gevolg en projectie-element tot verstrekking, en van daar naar het volgende register in de keten. Hetzelfde geldt voor de zekerheid waarmee het register een bewering onderschrijft en voor de betekenis die het eraan geeft. Deze vier betrouwbaarheidsaspecten staan dwars op de onderdelen van het model en hebben elk een eigen hoofdstuk:

• Herkomst – de herkomstkenmerken en de herkomstketen, van gevolg naar voortgaand gevolg en van verstrekking terug naar bron.
• Tijd – domeintijd en systeemtijd, en hoe tijdstippen van gevolg naar projectie-element en verstrekking doorwerken.
• Zekerheid – hoe twijfel het register binnenkomt, zich verspreidt en bij afnemers zichtbaar wordt.
• Betekenis – hoe betekenis wordt vastgelegd en behouden op elke plek waar een bewering van vorm verandert.

Bounded contextmodel

Een register beweert binnen een afgebakend domein, in een gemeenschappelijke taal, over een beperkt aantal soorten dingen. Dat geheel heet het bounded contextmodel: het model van wat het register opneemt en hoe dat doorwerkt in wat het levert. Wat een bounded context is en waarom die afbakening ertoe doet, staat in De overheid verkaveld.

Het bounded contextmodel beschrijft geen dingen in het domein, maar wat het register daarover kan zeggen. Het bevat dus zelf geen beweringen. De andere onderdelen van het register gebruiken het als specificatie: commando’s zijn gesteld in de taal ervan, gevolgen en projectie-elementen zijn beweringen van een soort die het definieert, en de specificaties voor vastleggen en projecteren werken de regels ervan uit.

Beweringssoort en gegevenssoort

De beweringssoort geeft aan welke soorten beweringen het register kan produceren en welke gegevenssoort daarbinnen kan voorkomen. Elke bewering is van één beweringssoort en elk gegeven binnen een bewering is van een gegevenssoort. De waardelijst begrenst het waardenbereik van een gegevenssoort.

Omdat een bewering als geheel staat of valt, is de keuze welke gegevenssoorten samen één beweringssoort vormen geen neutrale modelleerkeuze. Wat samen in één beweringssoort zit, wordt samen vastgelegd, samen betwist en samen onttrokken. Een beweringssoort die te veel samenneemt, dwingt het register later een hele bewering te betwijfelen of te onttrekken terwijl maar één gegeven onjuist is. Een beweringssoort die te weinig samenneemt, maakt beweringen die los van elkaar niet te begrijpen zijn.

Bij de beweringssoort hoort ook betekenis: uitleg van wat een beweringssoort inhoudt, bedoeld om beweringen van die soort te kunnen duiden. Hoe betekenis door het register heen doorwerkt, staat in het hoofdstuk Betekenis.

Entiteittype

Het entiteittype geeft aan over welke soorten dingen het register kan beweren en welke gegevenssoort een ding van dat type identificeert. Entiteittypen kunnen onderling relaties hebben, zoals een persoon die een adres bewoont of een WOZ-object waarbij een persoon belanghebbende is.

Het bounded contextmodel legt ook vast welke beweringssoorten iets veranderen aan entiteiten van een bepaald type. Daarmee is per entiteittype bekend welke soorten beweringen erover kunnen bestaan. Dat is de basis waarop een projectie later alle beweringen over één entiteit in een reeks samenbrengt.

Inwerkingsregel

De inwerkingsregel verbindt beweringssoort en entiteittype. Hij beschrijft of een bewering een entiteit doet ontstaan dan wel het bestaan daarvan veronderstelt, en hoe zo’n bewering doorwerkt in wat over die entiteit beweerd wordt. Een inschrijving doet een persoon ontstaan; een verhuizing veronderstelt een persoon die al bestaat.

De inwerkingsregel is een conceptuele regel. Twee specificaties werken hem uit, elk voor één kant van het register:

• De vormingsspecificatie doet dat voor wat wordt vastgelegd: welke gevolgen op basis van een commando worden geproduceerd en uit welke gevolgdelen die bestaan. Of een commando het bestaan van een entiteit veronderstelt, wordt getoetst tegen de opnametoestand.
• De projectiespecificatie doet dat voor hoe het vastgelegde in projecties doorwerkt: of een gevolg een reeks opent en welk projectie-element het oplevert.

Doordat beide specificaties dezelfde inwerkingsregel uitwerken, blijven vastleggen en projecteren met elkaar in lijn, ook al zijn het gescheiden processen met een eigen werkwijze.

Samenhang met de andere onderdelen

Voorbeelden en verdieping

De casussen beschrijven elk hun eigen bounded context: zie de bounded context van de casus WOZ en die van de casus BRP. Een generieke technische vertaling van deze begrippen staat in de verdieping generiek technisch domeinmodel.

Open vraag: verandering van het bounded contextmodel zelf

Ook een bounded contextmodel verandert: beweringssoorten worden toegevoegd, gegevenssoorten krijgen een andere waardelijst, inwerkingsregels worden aangescherpt. Via de werkwijze is vast te leggen in welke versie van een specificatie een bewering tot stand kwam. Hoe het register omgaat met beweringen die onder een eerdere versie van het bounded contextmodel zijn vastgelegd, is nog niet uitgewerkt.

Commando’s

Registers werken zelden in isolatie. Ze ontvangen informatie van andere registers, van andere overheidsorganisaties en van burgers, en die informatie gebruikt de begrippen van een andere context. Bijhouding vindt plaats in de taal van de eigen bounded context, en overname vraagt dus om vertaling. Dit onderdeel van het register beschrijft hoe wat van buiten komt, wordt omgezet in een commando in de eigen taal.

Externe bevinding

Wat van buiten binnenkomt, is een externe bevinding: een uitspraak die buiten de bounded context van het register is ontstaan. Denk aan een notariële akte, een geboorteakte, een notificatie van een ander register of de uitkomst van een onderzoek naar een terugmelding.

Vaak is een externe bevinding de verstrekking van een ander register. Wat in de ene bounded context een gevolg was, komt in de volgende binnen als bevinding die aanleiding kan geven tot een eigen gevolg. Zo ontstaan de ketens van gevolgen die De overheid verkaveld beschrijft. De externe bevinding is ook de grond waarop het gevolg dat eruit voortkomt rust: zij is de bron in de herkomst van dat gevolg.

Vertaalregel en Overzetten

Een vertaalregel beschrijft hoe een externe bevinding met behoud van betekenis wordt omgezet naar een contexteigen commando. De functie die de omzetting uitvoert, heet Overzetten.

De vertaalregel maakt ook duidelijk wat achterblijft. Een geboorteakte bevat een tijdstip van geboorte; een register dat alleen geboortedata kent, neemt dat tijdstip niet over. Wat de eigen context niet kent, gaat bij de overgang verloren, en de vertaalregel legt vast wat dat is.

Niet elk commando komt via een vertaalregel binnen. Is een bevinding al in de taal van de eigen bounded context gesteld, bijvoorbeeld omdat een medewerker van de bronhouder haar zelf heeft vastgesteld, dan kan het commando rechtstreeks worden aangeboden.

Expliciteren van contextovergangen

De vertaalregel draagt de capability Expliciteren van contextovergangen: het vermogen inzichtelijk te maken hoe bevindingen van buiten de registercontext daarbinnen bruikbaar worden gemaakt. Wie wil weten waarom een gegeven in het register afwijkt van wat in een bronbericht stond, vindt het antwoord in de vertaalregel.

Dat de overgang expliciet is, maakt ook de betekenis van wat het register vastlegt navolgbaar. De vertaalregel is de plek waar een begrip uit de ene context wordt gekoppeld aan een begrip uit de andere.

Commando

Een commando is een in de gemeenschappelijke taal van de bounded context gestelde opdracht aan het register om een gevolg op te tekenen. Het commando is een opdracht, nog geen gevolg. Of er een gevolg ontstaat, bepaalt de functie Optekenen, die het commando toetst aan de opnametoestand. Een commando over een persoon die volgens het register niet bestaat, of een akte die al eerder is verwerkt, leidt niet tot een gevolg.

Het commando is daarmee de grens tussen buiten en binnen. Alles vóór het commando is gesteld in de taal van een andere context; alles erna in de taal van het register.

Voorbeelden en verdieping

De verdieping Bounded Context Bridge werkt het vertalen tussen contexten technisch uit. De casus WOZ bevat voorbeelden van overgangen vanuit de BRK, zoals belang overgegaan naar aanleiding van eigendomsoverdracht, en vanuit de BAG, zoals gebouw geregistreerd.

Gevolgen

Gevolg

Een gevolg is een bewering waarmee een daartoe bevoegde actor performatief handelt, die binnen een bepaalde context een basis vormt voor vervolghandelingen en waarop betrokkenen die actor kunnen aanspreken. Het gevolg beschrijft altijd iets dat zich heeft voltrokken.

Performatief betekent dat de uitspraak iets tot stand brengt. Dat de gemeente vastlegt dat iemand op een adres woont, maakt dat hij daar voor de overheid woont, met de rechten en verplichtingen die daaraan verbonden zijn. Een gevolg hoeft daarvoor geen bijzondere grammaticale vorm te hebben. “Persoon p1 is verhuisd naar adres a1” is een mededelende zin en toch performatief, omdat het optekenen ervan door de bevoegde actor het institutionele feit vestigt. Bepalend zijn de bevoegdheid en de context.

Een gevolg is een primair feit, dat niet opnieuw uit zijn invoer af te leiden is. Wie hetzelfde commando opnieuw zou aanbieden, handelt opnieuw performatief en krijgt dus een nieuw gevolg.

Gevolgen leggen zonder oordeel vast wat er is waargenomen of besloten. Ze drukken daarmee de intentie van een observatie of besluit uit – niet het effect ervan op de toestand van het register. Gevolgen zijn temporeel atomair: ze gebeuren op één moment en hebben dus geen duur. Een gevolg wordt daarom altijd uitgedrukt als occurrent. Geboortes, verhuizingen of huwelijken markeren geen toestand, maar beschrijven de verandering die van de ene toestand leidt naar de volgende. Gevolgen zijn daarmee een voorbeeld van wat transitional modeling of overgangsmodellering wordt genoemd.

Voor de oorsprong van het begrip in de uitvoering van overheidstaken, zie Uitvoeringscontext van registers. Voor een modelleringsgerichte uitwerking, zie de verdieping modellering van gevolgen en projecties.

Gevolgenjournaal

Gevolgen worden vastgelegd in het gevolgenjournaal: een onveranderlijke en geordende vastlegging van alle gevolgen die binnen een bepaalde context zijn geproduceerd, in de volgorde waarin die gevolgen ontstonden. De naam is ontleend aan het scheepsjournaal, waarin nauwkeurige waarnemers volledig, chronologisch, zonder weglating én zonder oordeel noteren wat is waargenomen.

Het gevolgenjournaal richt zich uitsluitend op het nauwkeurig vastleggen van wat er is gebeurd: observaties, besluiten en registraties. Afnemers en hun informatiebehoeften spelen daarin geen rol. Het principe is: negeer de afnemer. Dit uitgangspunt geldt zo sterk mogelijk, maar de gevolgen vormen wel de grondstof waarmee de informatiebehoefte van afnemers – voor zover realistisch en redelijk – moet worden ingevuld. Die informatiebehoefte vullen projecties in.

Het gevolgenjournaal is append-only: gevolgen worden alleen toegevoegd, nooit overschreven of verwijderd. In een betrouwbaar register verwijderen we geen gegevens die we mogelijk ooit hebben verstrekt. Fysiek verwijderen levert op conceptueel niveau geschiedvervalsing op en breekt op functioneel niveau de garantie op de herhaalbare vraag. Herstel, twijfel en onttrekking verlopen daarom altijd via nieuwe gevolgen. Alleen vernietigen maakt een bewering blijvend ontoegankelijk, en ook dan blijft zichtbaar dat er iets was.

Hoe een gevolg tot stand komt

De functie Optekenen produceert gevolgdelen en gevolgen daaruit, en voegt die gevolgen toe aan het gevolgenjournaal. Optekenen leest daarvoor drie dingen: het commando, de vormingsspecificatie die beschrijft welke gevolgen op basis van het commando moeten worden geproduceerd en uit welke gevolgdelen die worden opgebouwd, en de opnametoestand. De vormingsspecificatie werkt de inwerkingsregel uit het bounded contextmodel uit.

De opnametoestand is een uit het gevolgenjournaal afgeleide toestand waartegen wordt vastgesteld of een commando tot gevolgen kan leiden, en waaruit voor de inhoud van die gevolgen gegevens worden overgenomen. De opnametoestand vervult dus twee functies: toetsing, bijvoorbeeld op de vraag of de persoon over wie het commando gaat bestaat en of de akte niet al eerder is verwerkt, en levering van gegevens. Wanneer een persoon ingeschreven wordt in het bevolkingsregister, komen de persoonsgegevens uit de opnametoestand en niet uit het commando (zie het voorbeeld inschrijving op geboortedatum). De functie Opnametoestand samenstellen stelt de opnametoestand samen uit het gevolgenjournaal.

Gevolgdelen

Een gevolg wordt opgebouwd uit gevolgdelen. Een gevolgdeel is een bouwsteen die wordt gebruikt binnen het productieproces van gevolgen en daarbuiten niet bestaat. Gevolgdelen verlaten dit onderdeel van het register niet en zijn na productie niet zelfstandig aanwijsbaar; wat in het journaal staat en waarnaar later kan worden verwezen, is het gevolg. Het model kent drie soorten, elk met een eigen functie.

Een identiteitsverlenend gevolgdeel verleent een entiteit binnen het register identiteit en maakt die daarmee aanwijsbaar. De bijbehorende functie is Identiteit verlenen. Zie Identiteit hieronder.

Een primair gevolgdeel gaat over een entiteit en brengt verandering in wat volgens het register in het domein geldt. De bijbehorende functie is Opstellen.

Een beweringsgericht gevolgdeel gaat over een bewering. Het verandert niets aan wat het register over het domein zegt, maar aan de houding die het register inneemt tegenover een eerder vastgelegde bewering. Er zijn drie soorten: een betwijfeling trekt de juistheid van een bewering in twijfel, een betwijfelingsopheffing neemt die twijfel weer weg, en een onttrekking trekt de onderschrijving van een bewering in. De bijbehorende functies zijn Betwijfelen, Betwijfeling opheffen en Onttrekken.

Identiteit

Het register houdt entiteiten niet zelf bij, maar beweringen over entiteiten (zie Entiteit). Om beweringen over een entiteit met elkaar te verbinden, is identiteit nodig. Het register geeft, als onderdeel van een identiteitsverlenend gevolgdeel, een identificerend gegeven uit waarmee beweringen die één entiteit beschrijven aan die entiteit kunnen worden gerelateerd. Wat het register over een entiteit beschikbaar heeft, is het geheel van beweringen die naar dezelfde identiteit verwijzen. Welke gegevenssoort een entiteit identificeert, legt het entiteittype vast.

Identiteit verlenen is een eigen gevolgdeel en geen bijzaak van een inschrijving, omdat identiteit ook los daarvan kan worden verleend. De verdieping gevolg-archetypen werkt de verschillende manieren uit waarop gevolgen entiteiten laten ontstaan, veranderen en beëindigen.

Herkenbaar bijhouden

Optekenen draagt de capability Herkenbaar bijhouden: het vermogen het register bij te houden met administratief herkenbare handelingen, in de vorm van gevolgen die aansluiten bij wat er in het domein gebeurt. Een gevolg “geboorte persoon p1 geregistreerd” is herkenbaar voor wie in het domein werkt; een gevolg “rij 4711 bijgewerkt” is dat niet.

Herkenbaar bijhouden is geen kwestie van naamgeving alleen. Het vraagt dat elk gevolg in het journaal een relatie heeft met een besluit of ander betekenisvol gebeuren uit het domein, en dat de omvang van een gevolg wordt bepaald door wat in het domein als één handeling geldt. De ontwerpafwegingen hieronder werken dat uit.

Feitelijk of administratief formuleren

Gevolgen kunnen we op twee manieren formuleren:

1. Feitelijk, beschouwd vanuit de werkelijkheid waarop het handelen betrekking heeft, ongeacht de wijze waarop het administratief is verwerkt of vastgelegd. Bijvoorbeeld "persoon p1 geboren".
2. Administratief, beschouwd vanuit de administratieve context waarbinnen het handelen heeft plaatsgevonden: de registratie, vastlegging of formalisering van een feitelijk gevolg binnen een specifiek overheidsproces. Bijvoorbeeld "geboorte persoon p1 geregistreerd".

Om de intentie zo scherp mogelijk uit te drukken, stellen we de volgende richting voor:

1. Administratief voor fysieke waarnemingen. Gevolgen van fysieke waarnemingen of fysieke gebeurtenissen worden vanuit een register als administratieve gevolgen verwoord. Een gevolg "geboorte persoon p1 geregistreerd" verdient de voorkeur boven "persoon p1 geboren". De persoon is namelijk ook geboren als dat niet in de registratie als gevolg is vastgelegd.
2. Feitelijk voor registratieve beslissingen. Gevolgen die inherent, vaak juridische, consequenties hebben doordát ze zijn vastgelegd, kunnen feitelijk worden uitgedrukt. Met het gevolg "parkeervergunning pg1 vastgesteld" ís de parkeervergunning vastgesteld. Uiteraard kan een "bewijs voor parkeervergunning uitgegeven" volgen als een fysiek bewijs is uitgegeven.

De keuze werkt door in twee betrouwbaarheidsaspecten: in de tijd die een gevolg draagt en in de vraag of aan een gevolg te twijfelen valt.

Correcties

Correctie is geen apart mechanisme in dit model. Een correctie ontstaat doordat de bestaande functies binnen één optekening worden aangeroepen in de samenhang die het geval vraagt, bijvoorbeeld een onttrekking van de onjuiste bewering en een primair gevolgdeel met de juiste inhoud, samen in één gevolg. Optekenen draagt daarmee de capability Corrigeren: het vermogen onjuist geachte beweringen te herstellen.

Omdat het journaal append-only is, betekent correctie altijd het toevoegen van een nieuw gevolg dat één of meerdere eerdere gevolgen ongedaan maakt of herziet. Bij of na correctie zijn twee fundamentele vragen aan de orde:

1. Hoe had het gevolgenjournaal eruit moeten zien?
2. Wat is er precies gecorrigeerd, en waarom?

Om beide vragen te kunnen beantwoorden, bevat een correctiegevolg idealiter drie dingen:

1. welke gevolgen worden gecorrigeerd;
2. hoe de gevolgentijdlijn er voor de betreffende periode had moeten uitzien;
3. de exacte hersteloperatie en de context daarvan.

Bij voorkeur gebeurt dat in de taal van de bounded context; een gevolg als "emigratie p1 herroepen" maakt de bedoeling direct duidelijk. Deze aanpak heeft een praktische beperking: het is niet goed mogelijk om vooraf alle situaties te voorzien waarin correctie nodig kan zijn. Bovendien vereist ieder domeinspecifiek correctiegevolg dat de bijbehorende bedrijfsregels worden bepaald en geconfigureerd, wat bij een laag correctievolume onevenredig veel ontwerplast met zich meebrengt.

Daarom kan het soms nodig zijn generieke correctiegevolgen te introduceren die domeingevolgen ‘passeren’ en direct inwerken op de begrippen uit projecties, zoals "verblijfsadres p1 gecorrigeerd". Belangrijk is dat zulke correcties altijd in het gevolgenjournaal worden opgenomen en transactioneel worden afgehandeld, zodat het journaal consistent blijft.

In het uitzonderlijke geval dat niet meer te reconstrueren is hoe een bepaalde toestand is ontstaan, maar wel bekend is hoe die eruit zou moeten zien, kan het nodig zijn op basis daarvan een nieuwe historie op te bouwen. Dit soort ingrijpende correcties moet zoveel mogelijk vermeden worden, omdat (al dan niet geautomatiseerde) integriteitscontrole hierbij nauwelijks mogelijk is en betekenisvol verstrekken daarna lastig is.

Niet elke fout zit in een gevolg. Blijkt na onderzoek dat de gevolgen juist waren en zat de fout in het projecteren, dan volstaat herstel aan de projectiekant (zie Correctie en onttrekking in projecties).

Voor een implementatiegerichte beschrijving van correcties, zie de verdieping correctie van gevolgen in detail. De correctie van een verhuizing is een eerste voorbeeld.

Onttrekking

Een onttrekking trekt de onderschrijving van een bewering in. Het register zegt daarmee dat het een eerder vastgelegde bewering niet langer voor juist houdt, zonder dat de bewering zelf verdwijnt. De onttrokken bewering blijft bestaan en blijft vindbaar voor wie wil weten wat het register ooit onderschreef; in het normale verkeer doet zij niet meer mee.

Aanleidingen voor onttrekking

Om de aanleiding voor een onttrekking goed te begrijpen, is het nodig twee vormen van juistheid te onderscheiden:

1. Feitelijke juistheid verwijst naar de mate waarin geregistreerde gegevens een accurate weergave vormen van de fysieke, juridische of administratieve werkelijkheid die ze representeren.
2. Systeemjuistheid verwijst naar de mate waarin het register gegevens verwerkt op de manier die is bedoeld door wie die verwerking heeft gespecificeerd, ongeacht of die gegevens zelf feitelijk juist waren.

Vervolgens kunnen we ten minste de volgende aanleidingen onderscheiden:

• Feitelijk onjuiste gegevens aangeboden. Door verkeerde informatie, een vergissing of een technisch mankement zijn gegevens aan het register aangeboden die feitelijk onjuist zijn, op basis waarvan feitelijk onjuiste gevolgen en mogelijk feitelijk onjuiste projecties zijn geproduceerd.
• Onjuiste verwerking geconstateerd. Door een gebrek aan systeemjuistheid zijn feitelijk juiste gegevens niet op de bedoelde manier verwerkt, waardoor feitelijk onjuiste gevolgen en/of projecties zijn geproduceerd.
• Nieuw begrip van feitelijke juistheid. Naar aanleiding van juridische of beleidsmatige heroverweging kunnen gegevens die eerder als feitelijk juist werden beschouwd niet langer als zodanig worden aangemerkt.

Een verzoek om vergeten of een verstreken bewaartermijn is geen aanleiding voor onttrekking. Daar gaat het niet om juistheid, maar om de vraag of een bewering nog mag bestaan. Dat is vernietigen.

Onttrekking in het journaal

Iedere onttrekking van een gevolg begint in een nieuw gevolg, dat een onttrekking als gevolgdeel bevat. Alleen als de fout uitsluitend zat in de wijze waarop projecties uit het gevolgenjournaal werden afgeleid, is er geen gevolg nodig.

In de administratieve praktijk verschijnt een onttrekking zelden kaal. Ze is onderdeel van een herkenbaar gevolg zoals een correctie, een herroeping of een nietigverklaring. Zo’n gevolg beschrijft altijd de context van de onttrekking, die achteraf reconstrueerbaar maakt waarom en wanneer een gevolg niet langer wordt onderschreven, en omvat ten minste:

• een verwijzing naar het onjuiste, te onttrekken gevolg;
• het tijdstip waarop tot onttrekking is besloten (‘gebeurd op’);
• de reden voor de onttrekking;
• een verwijzing naar het onderzoeksdossier waarin meer informatie over de aanleiding te vinden is (zie Herkomst).

Een onttrekking geldt altijd voor een bewering als geheel, omdat de juistheid van een bewering als geheel staat of valt. Moeten delen afzonderlijk onttrokken kunnen worden, dan horen die in een eigen beweringssoort.

Hoe een onttrekking in projecties doorwerkt, staat bij Projecties. Voorbeelden staan in de casus WOZ, zoals het onttrekken van een WOZ-object.

Twijfelen

Betwijfelen en Betwijfeling opheffen dragen samen de capability Twijfelen: het vermogen aan de juistheid van een bewering te twijfelen of dat juist niet langer te doen. Een betwijfeling verandert niets aan wat het register over het domein zegt en trekt ook de onderschrijving niet in. Ze maakt bekend dat het register de juistheid van een bewering niet langer zeker acht.

Waar twijfel vandaan komt, hoe die zich door het register verspreidt en wat afnemers ermee kunnen, staat in het hoofdstuk Zekerheid.

Ontwerpafwegingen voor gevolgen

Bij het ontwerpen van gevolgen zijn een aantal afwegingen van belang. Welke het zwaarst wegen, verschilt per domein. De onderstaande afwegingen bieden houvast bij het maken van weloverwogen keuzes.

• Intentie. Gevolgen drukken de intentie van de observatie, het besluit of de vastlegging uit.
• Negeer de afnemer als het gaat om vorm en omvang. Het domein bepaalt onafhankelijk van afnemerbehoeften de vorm en omvang van gevolgen die binnen de bounded context worden geproduceerd.
• Respecteer de afnemer als het gaat om inhoud. Alle gevolgen die een bounded context produceert, moeten samen voldoende informatie vastleggen om (redelijke en realistische) informatiebehoeften van afnemers in te kunnen vullen.
• Herkenbaar voor de business. Gevolgen worden gedefinieerd op basis van functionele behoefte. Ieder gevolg in het gevolgenjournaal heeft een relatie met een besluit of ander betekenisvol gebeuren uit de business.
• Hergebruik. Gevolgen kunnen als bouwsteen worden hergebruikt binnen omvangrijkere gevolgen, zonder dat ze daarmee hun zelfstandig bestaansrecht verliezen.

Gevolgen van dezelfde soort delen een gevolgtype, zoals GeboorteGeregistreerd of VerhuizingGeregistreerd. Gevolgtypen zijn een verfijning van de beweringssoort; ze zijn te gedetailleerd om in het conceptueel model op te nemen, maar bepalen in de praktijk hoe herkenbaar het journaal is.

Bij het modelleren van gevolgtypen kunnen onder andere de volgende constructen worden ingezet:

• Naamgeving van gevolgtypen drukt zoveel mogelijk de intentie en context uit, bijvoorbeeld in GeboorteGeregistreerd, NaamGewijzigdNaarAanleidingVanAdoptie of WozObjectOntstaatNaarAanleidingVanPerceelsplitsing.

• Typering als gegeven van een gevolg kan aanvullend worden gebruikt naast de naam van het gevolgtype, bijvoorbeeld door een waardelijst in het veld typeGevolg op te nemen.

• Hergebruik, decompositie en interfacing. Een gevolg kan kenbaar maken dat het een bepaald type wijziging omvat, zodat afnemers daarop kunnen aansluiten zonder de specifieke aanleiding te hoeven kennen. Een verhuizing en een adoptie leiden allebei tot een adreswijziging. Door beide gevolgen een gemeenschappelijk “adreswijziging”-contract te laten vervullen, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren.

  In objectgeoriënteerde talen wordt dit gerealiseerd via interface of abstract class (inheritance en composition); in functionele talen via een trait. Het concept is ook herkenbaar in UML.

Voorbeeld – adoptie in de BRP

Een adoptie brengt doorgaans drie wijzigingen tegelijk met zich mee: een naamswijziging, een adreswijziging en een wijziging van gezag. Elk van die drie kan echter ook zelfstandig voorkomen – door een eigen naamskeuze, een verhuizing, of een rechterlijke uitspraak die niets met adoptie te maken heeft.

Door gevolgen als AdoptieGeregistreerdNaRechterlijkeBeschikking en VerhuizingGeregistreerd allebei de interface AdresGewijzigd te laten implementeren, kunnen afnemers die alleen de adreswijziging nodig hebben op beide reageren – zonder de onderliggende aanleiding te hoeven kennen. In het BRP-stelsel speelt ook een autorisatiereden mee: afnemers zonder adoptie-autorisatie mogen PersoonGeadopteerd niet ontvangen, maar wel AdresGewijzigd.

interface NaamGewijzigd {
    val nieuweGeslachtsnaam: String
}

interface AdresGewijzigd {
    val nieuwAdres: Adres
}

interface GezagGewijzigd {
    val nieuweOuders: List<Persoon>
}

data class AdoptieGeregistreerdNaRechterlijkeBeschikking(
    override val nieuweGeslachtsnaam: String,
    override val nieuwAdres: Adres,
    override val nieuweOuders: List<Persoon>,
    // ...
) : NaamGewijzigd, AdresGewijzigd, GezagGewijzigd

data class VerhuizingGeregistreerd(
    override val nieuwAdres: Adres,
    // ...
) : AdresGewijzigd

Projecties

Het gevolgenjournaal legt nauwkeurig vast wat er is gebeurd, maar is in veel gevallen geen praktische bron voor bevragingen. Wie wil weten waar iemand nu woont, wil voor een antwoord niet alle adreswijzigingen sinds 1994 moeten afspelen. Voor het beantwoorden van zulke vragen maken we projecties.

Rol van projecties

Een projectie is een uit het gevolgenjournaal afgeleide, op de informatiebehoefte van afnemers toegesneden verzameling van projectie-elementen. Een projectie-element is een individuele bewering binnen een projectie. Waar het gevolgenjournaal documenteert wat er is gebeurd, beantwoorden projecties vragen als “leeft persoon p1 nog?”, “wat is zijn burgerlijke staat?” en “heeft hij gezag over p3?”. Zulke vragen veronderstellen een toestand: een beeld van de wereld dat gedurende een bepaalde periode geldig is.

Niet alle projecties beschrijven een toestand. Een notificatiebericht informeert een afnemer over een verandering die door registratie van een gevolg is veroorzaakt. Net als het onderliggende gevolg is zo’n bericht temporeel atomair: het beschrijft wat er is gebeurd, niet welke toestand na dat gebeuren geldig werd.

Gevolgen en projectie-elementen zijn dus allebei beweringen. Toch hebben ze binnen het register niet dezelfde status. Het gevolg is een ‘primair feit’, ontstaan als uitkomst van performatief handelen en waarop een bevoegde actor kan worden aangesproken. Een projectie-element is daarvan slechts een afgeleide. Dit betekent dat projectie-elementen, anders dan gevolgen, wél opnieuw van hun invoer (gevolgen) af te leiden zijn. Door gevolgen opnieuw te verwerken (replay) kunnen projecties dus meer dan eens worden opgebouwd.

Afstemming van projecties op de informatiebehoefte van afnemers vereist dat één journaal meerdere projecties kan voeden, elk met een eigen bereik en een eigen vorm. De bijbehorende capability is Onderhouden van projecties op maat: het vermogen meerdere projecties te onderhouden die aansluiten bij de informatiebehoefte van specifieke doelgroepen.

Hoe projecties technisch worden bijgehouden, is een implementatiekeuze: ze kunnen vooraf worden berekend en opgeslagen, of op het moment van bevraging op basis van de opgegeven parameters worden gegenereerd. Het tweede deel van dit hoofdstuk, vanaf de ontwerpafwegingen, gaat over die keuze.

Projectieperspectief: continuant of occurrent?

Als we willen begrijpen hoe projecties eruit zien, helpt het te begrijpen hoe we data willen representeren en wat de consequenties daarvan zijn. Dat doen we door om te beginnen een onderscheid aan te brengen tussen projecties die gaan over continuants (ook wel endurants of in het Nederlands voortdurenden) en projecties van occurrents (ook wel perdurants of in het Nederlands voorkomenden).

Een toestandsprojectie projecteert een entiteit - de continuant - die in de tijd beschouwd kan worden. Zo’n projectie levert voor ieder moment van het bestaan (of de geldigheid) van de continuant een complete en betekenisvolle toestand op.

Niet alle continuants zijn gelijk. Sommige daarvan kunnen onder één identiteit maximaal één geldigheidscyclus doormaken (denk aan een mens). Hun bestaansperiode is continu. Daarnaast komen continuants (zoals een huwelijk) voor die meerdere, discontinue (of onderbroken) geldigheidsperiodes kunnen kennen. Het ontstaan van een tweede (of derde, vierde enzovoort) geldigheidsperiode bij zo’n entiteit noemen we vaak herleven.

Een gebeurenprojectie projecteert een entiteit - de occurrent - die zich in de tijd voltrekt. Zo’n projectie kan alleen compleet en betekenisvol zijn als we alle momenten die de voltrekking van de occurrent duurde samen beschouwen.

Occurrents kunnen we onderverdelen naar de tijd die voltrekking duurde. Punctuele occurrents zijn instantaan (of temporeel atomair) en voltrekken zich op één moment. Duratieve occurrents voltrekken zich gedurende een periode, die in veel gevallen kan worden opgedeeld in fases (of stages).

Wetenschappelijke achtergrond en debat

In deze handreiking noemen we continuant en occurrent omdat ze helpen geprojecteerde gegevens te begrijpen. Achter deze begrippen gaan een lange wetenschappelijke geschiedenis en veel debat schuil.

De woorden continuant en occurrent werden voor het eerst beschreven in het driedelige ‘Logic’ (1921–1924) van de Britse logicus W.E. Johnson. Via debatten over persistentie en formele ontologie, waaronder Barry Smiths Basic Formal Ontology, vonden ze vervolgens hun weg naar de informatica.

Over deze begrippen bestaat binnen de wetenschap veel discussie. Zo stelde James F. Allen in ‘Maintaining Knowledge about Temporal Intervals’ dat occurrents weliswaar instantaan kunnen lijken, maar dat voltrekking bij nadere beschouwing (“turning up the magnification”) toch altijd een periode met tijdsduur vraagt.

In reactie daarop (‘A critical examination of Allen’s theory of action and time’) betoogde Antony Galton dat het problematisch is om alle occurrents als interval te behandelen en dat we daarnaast ook instants moeten kunnen herkennen. Een middenpositie wordt ingenomen door Bittner et al., die in ‘Endurants and Perdurants in Directly Depicting Ontologies’ de periode waarbinnen een occurrent zich voltrekt verdelen in al dan niet instantane stages (fases).

Ook het zelfstandig bestaansrecht van continuants staat ter discussie. Zo betogen perdurantisten dat alle objecten in vier dimensies bestaan. Wat we hierboven een continuant noemden, is vanuit dit perspectief geen zelfstandige entiteit, maar slechts een instantane doorsnede van zo’n vierdimensionale occurrent.

Projectiedoel bepaalt perspectief

Of een entiteit geprojecteerd wordt als continuant of als occurrent staat los van de manier waarop we gegevens in het gevolgenjournaal of andere bron voor onze projectie hebben vastgelegd. Het projectieperspectief wordt dus niet bepaald door het vastleggingsperspectief van het bronmateriaal, maar door de manier waarop we naar dat bronmateriaal willen kijken - en in het verlengde daarvan van door de informatiebehoefte die we met een projectie willen invullen.

Dit betekent dat op basis van één set gevolgen voor de ene doelgroep toestandsprojecties kunnen worden geproduceerd, terwijl voor andere afnemers projecties vanuit occurrentperspectief worden gemaakt.

Onderstaand voorbeeld illustreert hoe op basis van één set gevolgen die rondom een vergunning zijn bijgehouden, projecties in continuant- én occurrentvorm kunnen worden geproduceerd. De toestandsprojectie beschouwt de vergunning als entiteit waarvoor een toestand kan worden getoond. Projecteren we de vergunning als occurrent, dan krijgen we een aan de hand van ‘milestones’ geïllustreerde levenscyclus te zien.

// In het gevolgenjournaal bekende gevolgen die de levenscyclus van de vergunning hebben beïnvloed

[
  {
    "gevolgId": "ev-001",
    "gevolgType": "vergunningsaanvraag ontvangen",
    "betreft": { "type": "aanvraag", "id": "av-2004-1459" },
    "gebeurdOp": "2004-03-12"
  },
  {
    "gevolgId": "ev-002",
    "gevolgType": "vergunning verleend",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "beïnvloedt": { "type": "aanvraag", "id": "av-2004-1459" },
    "gebeurdOp": "2004-06-18"
  },
  {
    "gevolgId": "ev-003",
    "gevolgType": "vergunning ter inzage gelegd",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-06-21"
  },
  {
    "gevolgId": "ev-004",
    "gevolgType": "bezwaar ontvangen",
    "betreft": { "type": "bezwaar", "id": "bz-2004-0213" },
    "beïnvloedt": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-06-23"
  },
  {
    "gevolgId": "ev-005",
    "gevolgType": "bezwaar afgewezen",
    "betreft": { "type": "bezwaar", "id": "bz-2004-0213" },
    "beïnvloedt": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-07-17"
  },
  {
    "gevolgId": "ev-006",
    "gevolgType": "vergunning onherroepelijk geworden",
    "betreft": { "type": "vergunning", "id": "vg-2004-0815" },
    "gebeurdOp": "2004-08-02"
  }
]

// Vergunningaanvraag als continuant: het object met actuele toestand

// Request
{
  "resource": "vergunningen",
  "id": "vg-2004-0815",
  "presentatieperspectief": "continuant",
  "geldigOp": "2004-07-24"
}

// Response
{
  "id": "vg-2004-0815",
  "status": "verleend",
  "isOnherroepelijk": "false"
}

// Vergunningaanvraag als occurrent: gefaseerde levenscyclus

// Request
{
  "resource": "vergunningen",
  "id": "vg-2004-0815",
  "presentatieperspectief": "occurrent",
  "gebeurdVanaf": "1970-01-01",
  "gebeurdTot": "2004-07-25"
}

// Response
{
  "id": "vg-2004-0815",
  "fases": [
    { "type": "vergunning verleend", "gebeurdOp": "2004-06-18" },
    { "type": "vergunning ter inzage gelegd", "gebeurdOp": "2004-06-21" },
    { "type": "vergunning door bezwaar betwist", "gebeurdOp": "2004-06-23" },
    { "type": "betwisting vergunning door bezwaar beëindigd", "gebeurdOp": "2004-07-17" }
  ]
}

Intermezzo: van gevolg naar projectie

Een projectie is geen directe weergave van de gevolgen in het journaal – er zit altijd bewerking tussen. Bij de toestandsprojectie hierboven is dat bijvoorbeeld zichtbaar in de boolean isOnherroepelijk. Die is op false gezet omdat er op het gevraagde moment nog geen gevolg “vergunning onherroepelijk geworden” was geregistreerd. Om tot een te projecteren toestand te komen, worden hier dus gevolgen geïnterpreteerd.

Ook bij een gebeurenprojectie is bewerking nodig, maar die is subtieler. Omdat het gevolgenjournaal zelf al bestaat uit occurrents, zou je kunnen denken dat die in een projectie één op één overgenomen worden. De projectie in het voorbeeld hierboven wijkt niettemin subtiel af van de gevolgen waarop die gebaseerd is. Dat komt door een afwijkend perspectief. Het journaal beschrijft vanuit bijhoudingsperspectief zo nauwkeurig mogelijk wat er binnen een bounded context gebeurt. Vanuit projectieperspectief is het gewenst het gebeurde opnieuw te ordenen rond bepaalde kernconcepten.

In het voorbeeld zie je dit op twee manieren terug. Het gevolg “bezwaar ontvangen” is opgesteld rond het vanuit bijhoudingsperspectief meest relevante concept - het bezwaar zelf. In de vergunningprojectie moet dit gevolg ‘hertaald’ worden zodat het leest als een fase in de levenscyclus van de vergunning, ergo “vergunning door bezwaar betwist”. Het gevolg “vergunningsaanvraag ontvangen” verschijnt in de projectie helemaal niet omdat de vergunning op dat moment nog niet bestond en de levenscyclus daarvan dus nog niet was begonnen.

Toestandsprojecties en gebeurenprojecties

Het conceptuele registermodel vertaalt het onderscheid tussen continuant en occurrent naar twee hoofdvormen van projecties. In een toestandsprojectie beschrijven de projectie-elementen toestanden; de inhoud is uitgedrukt als continuant. In een gebeurenprojectie beschrijven de projectie-elementen gebeurens; de inhoud is uitgedrukt als occurrent. Dit onderscheid bepaalt welke vragen een afnemer aan een projectie kan stellen. Op basis van een toestand kan worden gevraagd wat er op enig moment gold; van een gebeuren kan worden gevraagd wanneer het plaatsvond en wat eraan voorafging.

Wat een projectie verder bevat, legt de projectiespecificatie vast als het bereik van die projectie. Daarin zitten onder meer twee temporele keuzes: welke domeintijd wordt meegenomen (alleen wat actueel geldt, of ook wat ooit gold) en welke onderschrijving (alleen wat het register nu onderschrijft, of ook wat het ooit onderschreef). Uit combinaties van die keuzes ontstaan vijf veelvoorkomende patronen, de projectie-archetypen.

Archetypen van toestandsprojecties

Archetypen van gebeurenprojecties

Hoe deze archetypen te implementeren zijn, staat verderop bij de implementeringsvormen per projectie-archetype.

Tijd in projecties

Bij toestandsprojecties en gebeurenprojecties horen verschillende vormen van domeintijd: geldigheidstijd voor toestanden en voltrekkingstijd voor gebeurens. Een toestandsprojectie bevraag je met parameters als geldigOp, geldigVanaf of geldigTot; een gebeurenprojectie met een voltrekkingsperiode, zoals gebeurdVanaf en gebeurdTot. Daarnaast draagt elk projectie-element een eigen systeemtijd, het projectietijdstip. Het hoofdstuk Tijd werkt dit uit, inclusief de oorsprong van het begrip geldigheidstijd en het onderscheid met voltrekkingstijd.

Projecties opbouwen

De functie Projecteren werkt een gevolg door in een projectie. Projecteren leest daarvoor drie dingen: het gevolg, de projectiespecificatie die per projectie beschrijft hoe gevolgen daarin doorwerken, en de projectie zelf, omdat het bepalen van de verandering die een gevolg binnen een toestandsprojectie teweegbrengt veelal kennis van de bestaande of ‘huidige’ stand vereist. De projectiespecificatie werkt de inwerkingsregel uit het bounded contextmodel uit.

De opbouw van projecties loopt daarmee parallel aan die van het gevolgenjournaal:

Projecteren bestaat uit twee deelfuncties. Openen opent een reeks voor een entiteit die nog niet in de projectie voorkwam. Bijwerken produceert een projectie-element. Door het bijwerken van projecties altijd via deze twee standaardoperaties te laten verlopen, ongeacht het soort gevolg dat wordt verwerkt, verkleint het register de kans op verwerkingsfouten. Elke verwerking volgt hetzelfde patroon; alleen de projectiespecificatie bepaalt hoe een concreet gevolg doorwerkt. Deze standaardisatie is een aanbevolen ontwerppatroon voor robuuste projectieopbouw.

Een reeks is het geheel van projectie-elementen binnen één projectie die samen een entiteit beschrijven. De reeks groepeert wat over dezelfde entiteit is vastgelegd en is daarmee de plek waar de identiteit uit het gevolgenjournaal doorwerkt. Ook elementen die over een bewering gaan, horen bij de reeks. “Bewering b1 over de bewoning van adres a1 door persoon p1 is onttrokken” beschrijft p1 niet, maar zonder dat element klopt de bewoningsgeschiedenis van p1 niet.

Een projectie-element draagt alleen de tijd van zijn eigen productie en wat zijn grond over de domeintijd zegt. Wanneer een toestand ophoudt, blijkt uit een volgend element in de reeks. Het einde in domeintijd volgt uit de volgende toestand van de entiteit, het einde van de onderschrijving uit een element dat de onttrekking weergeeft. Een tabel met kolommen voor begin en einde registratie is een manier van opslaan die meerdere elementen uit één reeks samenbrengt.

Een gevolg legt één besluit of gebeuren vast. Dat besluit kan bestaan uit deelbesluiten, maar het blijft één besluit, dat (voor zover relevant voor de projectie) in zijn geheel wel of niet in een projectie wordt verwerkt. Zie transactionaliteit bij de ontwerpafwegingen.

Voor meer details, zie de verdiepingen temporaliteit in projecties en bijwerken van projecties.

Correctie en onttrekking in projecties

In de meeste gevallen is een verstrekt projectie-element onjuist omdat één of meerdere gevolgen waarop het steunt onjuist waren. Herstel begint dan in het gevolgenjournaal, met een correctiegevolg. Projecteren werkt dat gevolg door zoals elk ander gevolg: het voegt projectie-elementen toe. Een element dat de onttrekking weergeeft, beëindigt de onderschrijving van het onjuiste element; nieuwe elementen beschrijven met terugwerkende kracht hoe het had moeten zijn.

Bestaande projectie-elementen blijven daarbij behouden; de nieuwe elementen worden ernaast geplaatst, met een later systeemtijdstip. Het register overschrijft nooit, als temporele consequentie van het append-only-patroon.

Ook kan uit onderzoek blijken dat de gevolgen juist waren en de fout zat in het projecteren. Dan wordt de projectiespecificatie of de software die haar uitvoert hersteld, waarna de gevolgen volledig of selectief opnieuw worden verwerkt (replay). Ook in dit scenario wordt bepaald vanaf welk moment een bestaande foutieve toestand niet langer wordt onderschreven; de foutieve projectie-elementen worden opnieuw opgebouwd, en de nieuwe elementen komen naast de oude te staan. Een nieuw gevolg is hiervoor niet nodig. Dat de nieuwe elementen met een herstelde werkwijze zijn afgeleid, blijkt uit hun herkomst. Zie het voorbeeld projectiefout hersteld via replay.

Of een afnemer de onttrekking ziet, hangt af van het archetype van de projectie. Projecties die alleen bevatten wat het register nu onderschrijft – de actueel geldige toestand, de in domein geldige historische toestanden en het onderschreven verloop – laten het onttrokken element weg. Voor wie zo’n projectie bevraagt, is het resultaat voor onttrokken gegevens hetzelfde als voor gegevens die nooit hebben bestaan. Projecties die ook bevatten wat het register ooit onderschreef – alle historische toestanden en het volledig verloop – behouden het onttrokken element, naast het element dat de onttrekking weergeeft. Daarmee blijft de herhaalbare vraag beantwoordbaar en kan een afnemer aantonen dat het register een gegeven ooit juist achtte. Toegang tot die projecties kan worden beperkt, bijvoorbeeld tot juridisch of historisch onderzoek.

Projectiesoorten

Met het onderscheid tussen continuant en occurrent en de bijbehorende temporele dimensies hebben we de bouwstenen om projecties scherper te kunnen typeren. Voor welke ‘soort’ projectie is welke domeintijd relevant? Geldigheidstijd, voltrekkingstijd, of geen van beide? En binnen die dimensie: zijn meerdere geldigheidsperiodes mogelijk of niet, duurt voltrekking tijd, of gebeurt dat in één moment?

Onderstaande tabel plaatst deze categorieën op een domeintijdas. Op de andere as kunnen we dan de tijdsdimensie plaatsen die wel door het register wordt bepaald: de systeemtijd. De tabel die hierdoor ontstaat kunnen we vullen met acht projectiesoorten. Voor ieder daarvan volgt hieronder een korte typering en één of meer voorbeelden.

Nota bene: tabel en projectiesoorten gaan over projecties die in het normale verkeer aan afnemers worden getoond. Betrouwbaar beheer en navolgbaar foutherstel maken het in vrijwel alle gevallen gewenst systeemtijd bij te houden - dus ook voor specificatiegegevens, automatische observaties en vaste waarden.

Herlevend ding

Een toestandsprojectie van een entiteit die meerdere, al dan niet aansluitende geldigheidsperiodes onder dezelfde identiteit kan kennen. Tussen periodes kan de geldigheid onderbroken zijn en later weer worden hervat. Voorbeeld: een huwelijk dat na ontbinding opnieuw wordt voltrokken tussen dezelfde personen.

Niet-herlevend ding

Een toestandsprojectie van een entiteit die onder één identiteit één aaneengesloten geldigheidsperiode kent. Eindigt de geldigheid, dan eindigt de entiteit definitief – een tweede geldigheidsperiode onder dezelfde identiteit is niet mogelijk. Voorbeelden: een mens, een dienstverband, een vergunning.

Traject

Een gebeurenprojectie van een entiteit die zich gefaseerd over een aaneengesloten periode voltrekt. Het traject heeft een aanvang, een einde en interne fases die samen de voltrekking vormen. Voorbeelden: een vergunningprocedure, een behandeltraject, een bezwaarprocedure.

Gebeurtenis

Een gebeurenprojectie van een entiteit die zich op één moment in de tijd voltrekt. De gebeurtenis kent geen interne fases en is temporeel atomair. Voorbeelden: een melding, een meting, een klantcontact.

Systeemevent

Een gebeurenprojectie van een gebeurtenis die uitsluitend binnen het systeem plaatsvindt en geen tegenhanger heeft in de werkelijkheid daarbuiten. Domeintijd ontbreekt; alleen systeemtijd is relevant. Voorbeelden: een logregel, een audit trail entry, een systeemmelding.

Specificatiegegeven

Een toestandsprojectie van een entiteit met beperkte veranderlijkheid die de kaders beschrijft waarbinnen andere, meer volatiele gegevens zich bewegen. Daarom hoeft hierover bijgehouden registratiehistorie in projecties doorgaans niet te worden getoond. Voorbeelden: een zaaktype, een producten- en dienstencatalogus, een classificatie.

Automatische observatie

Een gebeurenprojectie waarbij vastlegging zonder menselijke tussenkomst plaatsvindt op het moment van plaatsvinden, waardoor registratiemoment en voltrekkingsmoment per definitie samenvallen. Voorbeelden: een sensormeting, een GPS-track, een automatische transactie.

Vaste waarde

Een toestandsprojectie zonder tijdsdimensie. De waarde staat onveranderlijk vast en kent geen geldigheids- of registratiehistorie. Voorbeelden: een landcode, een geslachtsaanduiding, een natuurconstante.

Ontwerpafwegingen

Temporaliteit

Een belangrijke factor voor een projectie is de keuze voor wat betreft temporaliteit. Voor het kunnen beantwoorden van de herhaalbare vraag is bitemporaliteit een eis: als ingegrepen wordt op de tijdlijn, bijvoorbeeld als gevolg van een correctie, dient de projectie nog steeds de oorspronkelijke toestand te kunnen reproduceren.

Bitemporaliteit brengt op zichzelf echter complexiteit met zich mee die niet in alle gevallen nodig is. Wanneer het kunnen stellen van de herhaalbare vraag minder of niet van belang is, zou een specifieke temporele projectie op de geldigheidstijdlijn of alleen een actuele toestandsprojectie ook kunnen voldoen.

Een implementatiegerichte uitleg van verschillende vormen van temporaliteit in projecties is hier te vinden.

Eventual consistency als ontwerpoverweging

Tussen het vastleggen van een gevolg in het gevolgenjournaal en de zichtbaarheid van het resultaat in een projectie zit verwerkingstijd. Bij synchrone verwerking is die verwaarloosbaar; bij asynchrone of gedistribueerde architectuur kan het venster significant zijn. Gedurende dat venster kijkt een afnemer naar een projectie die het meest recente gevolg nog niet weerspiegelt.

Deze eventual consistency gaat uitsluitend over tijdigheid, niet over logische consistentie. Gevolgen zijn er juist op gericht om een eenduidige handeling als één samenhangend geheel vast te leggen, en ondersteunen daarmee de logische consistentie van het gevolgenjournaal. Een projectie die het meest recente gevolg nog niet weerspiegelt, is dus niet tegenstrijdig met wat al is vastgelegd – de informatie is alleen nog niet doorgekomen.

Dit is geen fout maar een eigenschap van de architectuur: gevolg en projectie leven in gescheiden stores, elk met een eigen systeemtijdstip. De inherente beperkingen aan de herhaalbare vraag benoemen dit als grens van herhaalbaarheid; hier benoemen we het als ontwerpkeuze. Bij het ontwerp van een projectie moet worden afgewogen hoeveel verwerkingstijd acceptabel is en welke consequenties dat heeft voor de garanties die aan afnemers worden geboden.

Query-complexiteit versus query-flexibiliteit

De keuze van gegevensrepresentatie van een projectie en de gewenste informatie die een afnemer wenst, bepalen de complexiteit van de (database)query die gedaan moet worden om in een informatiebehoefte te voorzien. In het voorgestelde patroon, waarin we commando’s, gevolgen en projecties van elkaar scheiden, hebben we niet meer de ‘ballast’ van de commandokant, en kunnen we onze projecties specifieker optimaliseren voor de afnemer(s).

Hier zijn echter nog steeds afwegingen in te maken. Een projectie kan gebouwd worden op een manier dat de payload response van een query as is (in bijvoorbeeld een json- of xml-structuur) opgeslagen wordt in de database. We noemen dit de bitemporele opslag van snapshots, kortweg snapshotting. Elke snapshot combineert daarin de payload met metadata over herkomst en tijd. Deze wijze van persisteren heeft een aantal voordelen:

1. Dit is de best mogelijke manier om de herhaalbare vraag te kunnen beantwoorden: de payload wordt as-is opgeslagen, en (later) veranderende code beïnvloedt deze payload niet.
2. Omdat de structuur van het bericht vastligt, ook nadat er codewijzigingen gedaan worden, kan er in terugmeldingen en onderzoeken via bijvoorbeeld xpath of jsonpath hard verwezen worden naar entiteiten of velden waarover getwijfeld wordt.
3. De (database) opvraging is eenvoudig: op basis van tijdstippen en een index dient een payload opgezocht te worden. Dit voorkomt grotendeels het verstrekken van foutieve informatie als gevolg van foutief geïmplementeerde queries.

Zeker in combinatie met bitemporaliteit zien wij snapshotting als een goede keuze voor wat betreft informatieverstrekking. Bitemporaliteit kan, in combinatie met bijvoorbeeld ingewikkelde correcties, zeer ingewikkelde situaties opleveren die zelfs voor experts moeilijk te doorgronden zijn. Het feit dat de query eenvoudig is en de payload statisch is bij snapshotting, maakt dat deze projectievorm uitermate robuust is voor het beantwoorden van de herhaalbare vraag.

Snapshotting heeft echter ook nadelen: omdat de datastructuur zo rigide vastligt kun je moeilijker, of niet, meerdere soorten vragen beantwoorden met dezelfde projectie. Ook leent deze vorm van opslag zich minder voor joins (het combineren van verschillende payloads/entiteiten). Dit alles maakt deze structuur minder flexibel, en dit dwingt je tot het maken van veel zeer afnemerspecifieke projecties.

Het bitemporele tabelmodel kan naargelang behoefte dan een goede keuze zijn. Een relationeel model, en zeker een bitemporeel relationeel model, is veel flexibeler in het kunnen beantwoorden van allerhande soorten vragen. De aard van de datarepresentatie maakt echter wel de queries en de mapping naar de doelstructuur van de payload complexer, wat het garanderen van herhaalbaarheid van vragen doet afnemen.

Betrouwbare modellen versus onbetrouwbare realiteit

Een goed datamodel beschrijft structuren, entiteiten en properties van een domein. Een huisnummer is een getal, terwijl een adres een straatnaam bevat als string met een maximaal aantal karakters. Deze eigenschappen worden idealiter goed gevalideerd aan de commandokant, en door dat te doen kun je duidelijke contracten afspreken met je afnemers over wat voor data je verstrekt en in welke vorm. Dergelijke modellen bepalen databasestructuren en beperkingen voor wat betreft gegevensopslag.

De realiteit is echter vaak weerbarstig: ooit verkeerd geïmplementeerde validaties, oude data uit migraties of veranderingen in het datamodel naar verloop van tijd kunnen er in veel gevallen voor zorgen dat de data die je hebt niet altijd voldoet aan het voorgeschreven gegevensmodel. Huisnummers met letters, te lange straatnamen… Als je gebonden bent aan het principe van het kunnen beantwoorden van de herhaalbare vraag zal deze data altijd foutief blijven.

Een relationeel model biedt duidelijkheid over het datamodel, maar is minder flexibel als het gaat om data die niet aan dit model voldoet. Er moet altijd een keuze gemaakt worden: voor zeldzame uitzonderingen dient het model aangepast te worden, of deze uitzonderingen kunnen niet verwerkt worden. Hetzelfde probleem geldt vaak voor berichtvalidaties via bijvoorbeeld XSD’s.

Een verhuizing niet doorgeven omdat een straatnaam te lang is, vinden wij zeer onwenselijk. Afhankelijk van de datakwaliteit kan het dan een betere keuze zijn om data-opslag en berichtverkeer flexibeler te maken zodat afwijkingen van het datamodel wel opgeslagen en gecommuniceerd kunnen worden. Richting een afnemer kan het dan wenselijk zijn deze communicatie te doen met een extra melding: “in dit bericht voldoen we niet aan het datamodel”.

Generieke versus specifieke implementatie

Varianten

Hieronder volgt een niet-uitputtende lijst van varianten van projecties die gebruikt kunnen worden. Elke projectievariant heeft voor- en nadelen die, afhankelijk van de use case, sterker of minder sterk gelden. Het is niet ons doel om te stellen welk van deze varianten de voorkeur geniet. Wel willen we voor- en nadelen van projectievarianten benoemen.

Transactionaliteit

Een gevolg legt één besluit of gebeuren vast. Dit besluit kan bestaan uit deelbesluiten of anderszins opdeelbare elementen, maar uiteindelijk betreft het nog steeds één besluit, dat (voor zover relevant voor de projectie) in zijn geheel wel of niet verwerkt dient te worden in een projectie, wat in databasetermen betekent dat een gevolg altijd in precies één databasetransactie verwerkt dient te worden. Het verwerken van een door de business erkend gevolg in meerdere (database)transacties kan er namelijk toe leiden dat datacorruptie optreedt: als een gevolg in twee transacties verwerkt wordt, zou de tweede transactie mis kunnen gaan, waarbij een ongeldige situatie ontstaat.

De implementatie-uitdaging bij projecties

Om van gevolg te komen tot een opvraagbare projectie hebben we een aantal transities nodig, waarbij meestal een vorm van opslag een tussenvorm is tussen het gevolg en wat de afnemer uiteindelijk op zijn scherm ziet. Een simpele flow chart van dit proces ziet er als volgt uit:

Uitgaande van deze architectuur hebben we in feite twee implementatie-uitdagingen:

1. Hoe vertalen we de gevolgen naar een opgeslagen projectierepresentatie?
2. Hoe vertalen we de opgeslagen projectierepresentatie (herhaalbaar) naar een leverbaar artefact?

Bij beide uitdagingen hebben we een implementatievorm nodig die robuust te bouwen is zodat deze een lange periode, mogelijk tientallen jaren, betrouwbaar herhaalbare vragen kan beantwoorden. En in die periode hebben we te maken met software die continu blijft evolueren, waar regelmatig (wekelijks, of zelfs dagelijks) nieuwe features aan toegevoegd worden, en de technologie je om de zoveel jaar stuurt naar software- of datamigraties.

Zowel een gevolgenjournaal als een bitemporele store bewaart data (grotendeels) append-only: terwijl software veranderlijk is, blijft onze data behoorlijk statisch. We hebben dus vooral te maken met de veranderlijkheid van software. Hoe garandeer je dan de herhaalbare vraag? Bugs in deze software zijn ook onvermijdelijk. Hoe garandeer je hetzelfde (corrupte) antwoord na het oplossen van een bug? Zoals eerder benoemd kent herhaalbaarheid zijn grenzen, maar welke implementatiekeuzes passen het beste bij dit vraagstuk?

Door bij het opslaan van de transformatie van de gevolgen in de projectiestore te streven naar standaardisatie kunnen we fouten voorkomen: een bitemporele store kunnen bijwerken met standaardoperaties, onafhankelijk van het soort gevolg, en aan de andere kant willen we herhaalbare, simpele queries hebben zodat de kans op softwarefouten bij het beantwoorden van de herhaalbare vraag zo klein mogelijk is. De standaardoperaties voor het opbouwen van een projectie zijn hierboven besproken; ze zijn implementatietechnisch uitgewerkt in de verdieping van het bijwerken van projecties. Als elke projectie en elk gevolg afgehandeld wordt door een reeds eerder geïmplementeerde functie verkleint dat de kans op softwarefouten. Als we de transitie van gevolg naar projectie zoveel als mogelijk doen aan de ‘linkerkant’, kunnen we beter herhaalbaar leveren: ook de meeste softwarefouten ‘persisteren’.

Aan de rechterkant van onze store kunnen we streven naar ‘zo min mogelijk’ software voor de verstrekking van ons product. Als opvragingen uit onze store eenvoudig zijn, is de kans dat daar softwarefouten in zitten kleiner. Onze architectuur ziet er dan als volgt uit:

Het vereenvoudigen van de opvragingssoftware is niet zonder prijs. Er zal per projectie afgewogen moeten worden welke criteria het zwaarst wegen. De volgende paragraaf gaat daarover.

Implementeringsvormen per projectie-archetype

We onderscheidden hierboven vijf archetypische projecties: aan de toestandskant de actueel geldige toestand, in domein geldige historische toestanden en alle historische toestanden, aan de gebeurenkant het onderschreven verloop en het volledig verloop. Deze archetypen zeggen wat een projectie bevat; ze zeggen niet hoe je die bouwt. Per archetype zijn meerdere implementeringsvormen mogelijk, die langs twee assen variëren:

• Temporaliteit: alleen de actuele stand, domeintijd zonder systeemtijd, of domeintijd en systeemtijd samen (bitemporeel).
• Opslag- en leveringsvorm: rijen in relationele tabellen, payloads, een hybride vorm van cellen en payload, of een stream die het register zelf uitgeeft.

Dit noemen we in dit document overigens geen ‘soorten’; die term laten we voor de acht projectiesoorten hierboven, die gaan over het perspectief op de entiteit en niet over de bouwvorm van de projectie.

Deze paragraaf geeft een overzicht van de implementatievormen per archetype. De afwegingen tussen de vormen staan in de ontwerpafwegingen hierboven; de beslisboom hieronder leidt van de ontwerpvraag naar één van deze vormen.

Actueel geldige toestand

Voor de afnemer die alleen de stand van nu nodig heeft, komen twee vormen in aanmerking:

• Actuele tabellen: één toestand per entiteit die bij elke nieuwe toestand wordt overschreven. De eenvoudigste en snelste vorm; historie ontbreekt volledig. Deze vorm kan volledig relationeel gemaakt worden.
• Actuele payload: een payload per entiteit, eveneens herschreven bij elke nieuwe toestand.

Geen van deze vormen kan de herhaalbare vraag beantwoorden: een correctie in de domeintijd schrijft het verleden stilzwijgend over en het eerdere antwoord is weg.

In domein geldige historische toestanden

Wie enkel vragen over de domeinhistorie wil beantwoorden – “wat gold er op moment t?” – legt geldigheidsperiodes vast:

• Temporele tabellen: per rij een geldigVanaf- en geldigTot-waarde, met bij elke bijhouding een gesloten oud-periode en een nieuw-op-volg-periode. Vragen naar wat er toen gold zijn flexibel te beantwoorden; vragen naar wat het register toen onderschreef niet, want een correctie met terugwerkende kracht herschrijft de historie.
• Temporele payloads: payloads per geldigheidsperiode, in dezelfde hoedanigheid als hierboven, maar dan per geldigheidsmoment bewaard.

Deze vorm is passend zolang het antwoord op “wat gold er?” mag meebewegen met wat het register op dit moment voor juist houdt.

Alle historische toestanden

Dit archetype beantwoordt zowel “wat gold er?” als “wat onderschreef het register toen?”, en is per definitie bitemporeel. De keuze uit de beslisboom over opslagvorm komt hier op neer:

• Bitemporeel tabelmodel (zie bitemporele relationele databases): alle gegevens in cellen, geldigheid en registratie naast elkaar. Maximale query-flexibiliteit; herhaalbaarheid leunt dan voor een (groot) deel op query’s en code die over de jaren hetzelfde gedrag moeten blijven vertonen.
• Bitemporele opslag van snapshots (zie bitemporele opslag van snapshots): per toestandsprojectie-element wordt de payload zoals deze verstrekt kan worden, vastgelegd, per geldigheids- en systeemtijdstip. De query wordt eenvoudig en reduceert tot het opzoeken van één payload op basis van id en tijdstippen; de prijs is een eigen projectie per informatievraag.
• Hybride oplossing: opslag van payloads, maar dan met extra cellen om in queries te kunnen filteren en te aggregeren.

Volledig verloop

Het volledig verloop bevat ook de elementen die het register ooit onderschreef maar inmiddels niet meer. Dit verloop kan op twee verschillende manieren verstrekt worden:

• Als continue stroom van notificaties: elk gevolg (of een subset daarvan) leidt tot één of meerdere notificaties die direct aan afnemers geleverd worden.
• Als opvraagbare reeks per entiteit of entiteiten.

Omdat al het gebeuren gecommuniceerd wordt inclusief correcties, resulteert deze wijze van leveren in een bitemporeel beeld van het register.

Deze vorm lijkt het sterkst op het gevolgenjournaal zelf – en is het toch niet. Het journaal beschrijft vanuit bijhoudingsperspectief wat er binnen de bounded context gebeurde; een projectie vertaalt die naar een afgeleid gebeuren waar de afnemer naar kijkt, zoals het intermezzo ‘van gevolg naar projectie’ bij het projectieperspectief hierboven illustreert.

Onderschreven verloop

Het onderschreven verloop lijkt qua vorm sterk op het volledige verloop, en dus ook op het gevolgenjournaal, maar is dit niet. De vorm is hetzelfde, maar de inhoud niet. Niet langer onderschreven gevolgen worden gefilterd, correcties voegen nieuwe gebeurens toe. Het onderschreven verloop is dus expliciet een gebeuren-projectie.

Het verloop van gebeurenprojectie-elementen die het register nu onderschrijft kan je niet streaming leveren, enkel op verzoek (per entiteit of entiteiten). Indien er behoefte is aan herhaalbaarheid voor deze vraag dienen deze onderschreven gebeurenprojecties bitemporeel vastgelegd te worden bij elk gevolg dat met terugwerkende kracht werkt.

Beslisboom: perspectief, temporaliteit en opslagvorm

Nu we verschillende implementatievormen en hun kenmerken beschreven hebben is het zaak om te weten welke variant we onder welke omstandigheden zouden kiezen. Om hierbij te helpen hebben we een ‘beslisboom’ geformuleerd, die leidt tot een projectiekeuze.

Vanuit uit betrouwbare bron kunnen wij niet alle domeinspecifieke context meewegen. Beschouw deze boom daarom als een hulpmiddel om tot een keuze te komen en niet meer dan dat.

Beslisboom: welke projectievorm kies ik?

Boom 2: bitemporele toestandsprojectie

Boom 3: opvragen van gebeurenprojectie

Verstrekken

Projecties bestaan om te worden verstrekt. Een verstrekking is het moment waarop beweringen het register verlaten en anderen erop kunnen gaan handelen. Dit onderdeel beschrijft in welke vormen het register verstrekt, en hoe het later kan verantwoorden wat het heeft verstrekt.

In De ‘datalaag’ van de overheid staat waarom gevolg en verstrekking vanuit verantwoordingsperspectief even zwaar wegen: het gevolg als kern van wat bedoeld werd, de verstrekking als dat waarop anderen hebben gehandeld.

Verstrekking

Een verstrekking is een geheel van projectie-elementen dat het register in een bepaalde vorm uitgeeft. Het model onderscheidt twee soorten. Een notificatiebericht geeft het register op eigen initiatief uit, terwijl een antwoordbericht op aanvraag van een afnemer wordt geleverd. De bijbehorende functies zijn Melden en Bevraging beantwoorden.

Een verstrekking bevat altijd projectie-elementen, nooit gevolgen. Wat een afnemer ontvangt, is dus altijd afgeleid en op zijn informatiebehoefte toegesneden. Welke afnemer welke projectie-elementen voor welk doel mag ontvangen, vraagt om een grondslag voor de bevraging en de verstrekking die erop volgt; die kan bijvoorbeeld worden vastgelegd volgens de standaard Logboek Dataverwerkingen. Of daarnaast elk projectie-element een eigen legitimering heeft, is nog een open vraag.

Melden

Melden is verstrekken op initiatief van het register. Melden gebeurt altijd op basis van een gebeurenprojectie: een notificatie gaat over iets dat is gebeurd, en heeft daarvoor het gebeurtenisachtige karakter van een occurrent nodig.

De capability Betekenisvol notificeren houdt in dat het register notificaties kan leveren die informatie omvatten over de aanleiding voor en de betekenis van de beweringen waarover wordt genotificeerd. Een afnemer die een notificatie ontvangt, moet kunnen bepalen of zijn eigen taken het nodig maken daarop te handelen, zonder het register daarvoor opnieuw te hoeven bevragen. Hoe het register die betekenis meegeeft, staat in het hoofdstuk Betekenis.

Omdat een onttrekking in een gebeurenprojectie een eigen element is, kan het register een afnemer ook laten weten dat het een eerder geleverde bewering niet meer onderschrijft. Dat geldt ook voor twijfel: een betwijfeling is een gebeuren waarover kan worden genotificeerd. Zie voor een privacybeschermend voorbeeld de adoptiecasus in de BRP-voorbeelden.

Bevraging beantwoorden

Bevraging beantwoorden is verstrekken op aanvraag van een afnemer. Het antwoordbericht wordt samengesteld uit een projectie die past bij de vraag: een toestandsprojectie voor wie wil weten wat op enig moment gold, een gebeurenprojectie voor wie het verloop wil kennen.

Bevraging beantwoorden draagt de capability Historisch inzicht: het vermogen historische beweringen te leveren, zowel naar domeintijd als naar systeemtijd. Beide zijn nodig, de eerste om te leveren wat ooit gold, de tweede om te leveren wat het register ooit onderschreef. Zie de correcties voor BRP en WOZ, bijvoorbeeld het corrigeren van eigenaarschap in de WOZ, voor bitemporele bijhoudingen. De archetypen van projecties laten zien welke projectie welke historische vraag kan beantwoorden.

Verstrekkersreferentie

Elke verstrekking bevat een verstrekkersreferentie: een verwijzing naar die specifieke verstrekking, waarmee de inhoud daarvan kan worden geverifieerd of opnieuw kan worden ontvangen. Op de verstrekkersreferentie rusten twee capabilities.

Herleveren op aanvraag is het vermogen een eerder uitgegeven verstrekking met dezelfde inhoud in identieke vorm opnieuw te verstrekken. De bijbehorende functie is Historische verstrekking opnieuw verstrekken.

Attesteren is het vermogen een verklaring uit te geven die aantoont dat een verstrekking met een bepaalde inhoud door het register is gedaan. De functie Verifiëren controleert aan de hand van de verstrekkersreferentie of een bepaalde verstrekking door het register is gedaan, en produceert daarvan een leveringsattest.

De verstrekkersreferentie verbindt het register ook met wat er na de verstrekking gebeurt. Een afnemer die op basis van een verstrekking handelt, kan in de herkomst van zijn eigen gevolg naar die verstrekking verwijzen. Een afnemer die twijfelt aan een verstrekt projectie-element, kan in een terugmelding precies aanwijzen welk element hij bedoelt. Zo loopt de herkomstketen over de grens van het register heen.

De herhaalbare vraag

Een belangrijke eis aan een betrouwbaar register is dat het, zoveel als mogelijk, de herhaalbare vraag kan beantwoorden. Een afnemer moet, nadat hij op tijdstip T1 een gegeven heeft opgevraagd, op tijdstip T2 nog steeds de vraag kunnen stellen wat dit gegeven op tijdstip T1 was. Een betrouwbaar register kan dit ook nadat:

1. er nieuwe gevolgen zijn toegevoegd aan het gevolgenjournaal;
2. een gegeven is hersteld doordat het geldigheidstijdvak is veranderd vanwege een onjuist gevolg;
3. een softwarefout in de opvraging is hersteld waardoor de initiële opvraging fout was.

Criterium 1 en 2 introduceren bitemporaliteit in het register (zie Tijd). Criterium 3 vereist dat er mechanismen zijn die het mogelijk maken software aan te passen met behoud van de eerdere gegevensrepresentatie.

De herhaalbare vraag is wat Herleveren op aanvraag en Historisch inzicht mogelijk maakt. Hoe zwaar ze weegt, bepaalt in grote mate de keuze voor de opslag- en leveringsvorm van een projectie; zie de ontwerpafwegingen en de beslisboom bij Projecties.

Inherente beperkingen aan de herhaalbare vraag

Elk register loopt tegen inherente beperkingen aan. Zowel geldigheids- als gevolgtijdstippen hebben te maken met eventual consistency: er zit altijd tijd tussen het begin van een registratie en het einde daarvan, en er zit altijd tijd tussen een opvraging en de zichtbaarheid van deze gegevens voor de afnemer. Dit betekent dat een afnemer altijd in potentie naar verouderde informatie kijkt. Zie ook eventual consistency als ontwerpoverweging.

Daarnaast heeft een register meestal niet de volledige controle over de verstrekking van informatie. Beweringen verlaten op een bepaald moment het register om elders te worden gepresenteerd – in een browser, een API-response, of een ander systeem dat het register niet kent.

Herhaalbaarheid van opvraging is dus hoogstens te behalen tot op het niveau van de gegevensrepresentatie net voordat deze het systeem verlaat. En ook die grens vervalt waar het register een bewering moet vernietigen: wat blijvend ontoegankelijk is gemaakt, kan niet opnieuw worden verstrekt.

Betwisten

Een register dat zijn verstrekkingen niet laat betwisten, kan fouten alleen zelf ontdekken. Dit onderdeel beschrijft hoe afnemers en andere betrokkenen het register kunnen laten weten dat een geleverd projectie-element vermoedelijk onjuist is, en hoe die terugmelding via onderzoek buiten het register tot een nieuw gevolg kan leiden.

Terugmelden

Terugmelden is het proces waarbij een afnemer van gegevens aan de bronhouder meldt dat hij twijfelt aan de juistheid van verstrekte gegevens. De term is afkomstig uit het stelsel van basisregistraties. Binnen dat stelsel zijn overheidsorganisaties verplicht twijfel over de juistheid van gegevens aan de bronhouder te melden. Functioneel is het principe breder toepasbaar: overal waar gegevens worden gedeeld tussen een beheerder en afnemers, kan terugmelden als mechanisme dienen om de kwaliteit van die gegevens gezamenlijk te bewaken.

Een terugmelding is een melding waarmee de juistheid van een geleverd projectie-element wordt betwist. Het register biedt een voorziening waarmee een melder een projectie-element kan aanwijzen en kan beschrijven wat er niet klopt. Het resulterende bericht is de terugmelding. De functie Terugmelding ontvangen leest de terugmelding en het projectie-element waar die over gaat. Zij draagt de capability Terugmelden: het vermogen meldingen te ontvangen dat een geleverd projectie-element vermoedelijk onjuist is.

Terugmelden gebeurt altijd op een projectie-element, en dus niet rechtstreeks op een gevolg in het gevolgenjournaal. De melder kent alleen wat hem is verstrekt. Of de fout in een gevolg zit of in het projecteren, blijkt pas uit onderzoek.

Inhoud van een terugmelding

Omdat projecties over uiteenlopende samenstellingen van gegevens kunnen gaan en de aard van geconstateerde onjuistheden sterk kan verschillen, kan een terugmelding vele vormen aannemen. Daarbij past geen beperkend ‘terugmeldformulier’, maar vormvrijheid en ruimte voor toelichting in vrije tekst. Als een bronhouder regelmatig terugmeldingen van dezelfde strekking ontvangt, kan hij overwegen daarvoor een specifieke, meer gestructureerde interface aan te bieden. Dit verlaagt de drempel voor de terugmelder en maakt de verwerking aan de kant van de bronhouder efficiënter.

Een terugmelding bevat in ieder geval:

• Een verwijzing naar het betwiste projectie-element. De terugmelder geeft aan op welk projectie-element of welk onderdeel daarvan de terugmelding betrekking heeft. Hoe die verwijzing eruitziet, hangt af van hoe projectie-elementen identificeerbaar zijn gemaakt. De verstrekkersreferentie maakt het mogelijk precies die verstrekking aan te wijzen waarop de melder zich baseert.
• Een toelichting. De terugmelder beschrijft in vrije tekst wat hij als onjuist beschouwt en waarom. Dit biedt de bronhouder de context die nodig is om het onderzoek gericht te kunnen starten.
• Contactgegevens van de terugmelder. Zo kan de bronhouder, als het onderzoek daarom vraagt, contact opnemen voor nadere toelichting of terugkoppeling.

Onderzoek buiten het register

Na een terugmelding moet de bronhouder beoordelen of de gemelde twijfel gegrond is. Daartoe onderzoekt hij of het betreffende projectie-element inderdaad onjuist is, en zo ja, of die onjuistheid te herleiden is naar één of meer onjuist vastgelegde gevolgen – en mogelijk andere daarvan afgeleide projecties.

Triage en onderzoek vinden buiten het register plaats, bijvoorbeeld in een zaaksysteem of ander procesondersteunend systeem, en worden daar ook verantwoord. Dat volgt uit het onderscheid tussen proces en resultaat: het register legt resultaten vast, geen processen. Het onderzoek zelf leidt dus niet tot nieuwe gevolgen of nieuwe projectie-elementen.

Van onderzoek terug naar het register

Wat het onderzoek oplevert, komt als externe bevinding het register weer binnen. Overzetten zet die om naar een commando en Optekenen produceert op basis daarvan nieuwe gevolgen. Daarvoor zijn twee momenten van belang.

Tijdens het onderzoek. Een terugmelding en de eerste beoordeling daarvan kunnen aanleiding zijn om aan de juistheid van één of meer beweringen te twijfelen. Met Betwijfelen maakt het register die twijfel bekend, zodat ook andere afnemers weten dat over de juistheid onzekerheid bestaat. De betwijfeling kan in eerste instantie gaan over het projectie-element waarop is teruggemeld, en later, wanneer het onderzoek de oorzaak aanwijst, over het gevolg waaruit het is afgeleid. Hoe twijfel zich daarna door het register verspreidt, staat in het hoofdstuk Zekerheid.

Na het onderzoek. Het eindresultaat leidt tot een gevolg, opgebouwd uit gevolgdelen die onjuist bevonden beweringen onttrekken, twijfel over bestaande beweringen opheffen en/of nieuwe primaire beweringen over een entiteit beschrijven. Dat is een correctie. Blijkt het gegeven juist, dan volstaat een betwijfelingsopheffing. Zat de fout uitsluitend in het projecteren, dan volgt herstel aan de projectiekant. Het onderzoeksdossier geldt voor het nieuwe gevolg als bron.

Zie de terugmeldingsvoorbeelden in de casus WOZ, en twijfel en herstel voor het volledige pad van terugmelding tot correctie.

Open vragen

• Terugmelden is binnen het stelsel van basisregistraties een voorwaarde voor afwijken van gegevens in de bron. Zouden terugmeldende afnemers dan voor eigen gebruik en hangende een onderzoek hun eigen, vermoedelijk juistere ‘alternatieve’ gegevens in het register moeten kunnen zetten?
• Hoe wijzen we gegevens waarover we terugmelden voor de bronhouder (historisch) onderscheidbaar aan?

Vernietigen

Een betrouwbaar register verwijdert in beginsel niets: het gevolgenjournaal en de projecties zijn append-only, en ook wat onjuist bleek, blijft als onttrokken bewering bewaard. Toch zijn er situaties waarin een bewering niet langer mag bestaan. Dit onderdeel beschrijft hoe het register daarmee omgaat zonder zijn verantwoordingsplicht op te geven.

Blijvend ontoegankelijk maken

De functie Blijvend ontoegankelijk maken maakt een bewering blijvend ontoegankelijk, zodat de inhoud niet gereconstrueerd kan worden. Dat geldt voor gevolgen en voor projectie-elementen. Wat overblijft, is een merkteken: een markering die getuigt van het bestaan van een bewering, zonder iets te vertellen over de inhoud daarvan.

Het merkteken houdt het register ook na vernietiging begrijpelijk. Een journaal waaruit stilzwijgend iets kan verdwijnen, is niet te verantwoorden. Door een markering achter te laten, blijft zichtbaar dat er iets was, zonder prijs te geven wat.

Omdat de inhoud niet gereconstrueerd mag kunnen worden, kan vernietiging niet beperkt blijven tot één bewering. Projectie-elementen zijn afgeleid van gevolgen en bevatten dus (een deel van) dezelfde inhoud. Wordt een gevolg blijvend ontoegankelijk gemaakt, dan geldt dat ook voor de projectie-elementen die eruit zijn afgeleid, en moet worden voorkomen dat die inhoud opnieuw ontstaat wanneer gevolgen later opnieuw worden verwerkt.

Vernietigen en onttrekken

Vernietigen en onttrekken lijken op elkaar, omdat in beide gevallen een bewering uit het normale verkeer verdwijnt. Ze verschillen in grond en gevolg:

Een bewering die het register heeft onttrokken, kan later alsnog worden vernietigd, bijvoorbeeld als de bewaartermijn verstrijkt.

Grondslagen voor vernietigen

Aan Blijvend ontoegankelijk maken zijn twee capabilities verbonden. Ze vereisen een vergelijkbare handeling, met verschillende grondslagen.

Vernietigen is het vermogen vernietigingshandelingen uit te voeren conform archiefwettelijke eisen. De archiefwettelijke bewaartermijn voor een bewering verstrijkt, en vernietiging volgt uit het register zelf.

Vergeten is het vermogen gegevens te wissen conform het recht op vergetelheid uit de Algemene Verordening Gegevensbescherming. Hier komt de aanleiding van buiten, van een betrokkene die verzoekt een feitelijk juiste bewering te laten verwijderen, en gaat er een afweging aan vooraf.

Open vraag: ethische of maatschappelijke overwegingen

Een eerdere versie van de handreiking noemde nog een derde aanleiding om een feitelijk juiste bewering niet langer te behouden: een ethische of maatschappelijke overweging. Het model kent daarvoor geen eigen capability. Of zo’n overweging onder Vernietigen of Vergeten valt, een eigen grondslag vraagt, of eerder een vorm van onttrekking is, is nog niet beslist.

Verantwoording van vernietiging

Ook vernietiging is een handeling waarover het register verantwoording aflegt. Het merkteken getuigt van het bestaan van de vernietigde bewering; wanneer, op welke grondslag en door wie de vernietiging is uitgevoerd, hoort bij de herkomst van die handeling. Hoe die verantwoording wordt vastgelegd zonder de vernietigde inhoud prijs te geven, is in de voorbeelden nog niet uitgewerkt.

Verstrekkingen die het register vóór de vernietiging heeft gedaan, vallen buiten zijn bereik: ze bevinden zich bij afnemers. Het register kan een eerdere verstrekking van een vernietigde bewering niet meer herleveren.

Begrippenoverzicht

Deze lijst volgt het conceptueel registermodel, per cluster van het model. Begrippen met een – als ArchiMate-type komen niet als element in het model voor, maar worden in de handreiking wel gebruikt.

Cluster beweringen – Assertions cluster

Cluster bounded contextmodel – Bounded context model cluster

Cluster commando’s – Command cluster

Cluster gevolgen – Effects cluster

Archetypen van gevolgen zijn uitgewerkt in de verdieping.

Cluster projecties – Projections cluster

Cluster verstrekken – Deliveries cluster

Cluster betwisten – Contestation cluster

Cluster vernietigen – Data destruction cluster

Betrouwbaarheidsaspecten

Het conceptueel registermodel beschrijft per onderdeel wat een register doet: commando’s ontvangen, gevolgen optekenen, projecties afleiden, verstrekken, betwisten en vernietigen. Of een register daarmee ook betrouwbaar is, blijkt pas als je een kwaliteit door al die onderdelen heen volgt. Dat doen de hoofdstukken in dit deel. Ze staan dwars op de onderdelen van het model en volgen elk één aspect van externe bevinding via gevolg en projectie-element tot verstrekking, en van daar naar het volgende register in de keten.

De vier aspecten sluiten aan bij de behoeften uit Aanleiding en doel: wie overheidsinformatie gebruikt, wil weten waar die vandaan komt, hoe die door de tijd is veranderd en hoe zeker die is. Daar voegen we betekenis aan toe: een gegeven is pas bruikbaar als duidelijk is wat ermee wordt beweerd.

In het kort

Herkomst is de verantwoording van de totstandkoming van een bewering: de bron waarop die rust, de verantwoordelijke die ervoor instaat, de legitimering en de werkwijze. Elke bewering legt één stap terug vast; achter elkaar gezet vormen die stappen een herkomstketen, van gevolg naar voortgaand gevolg in een volgende context.

Tijd valt uiteen in domeintijd, bepaald door wat een bewering beschrijft, en systeemtijd, bepaald door het register dat haar vastlegt. Domeintijd heeft voor toestanden de vorm van geldigheid en voor gebeurens de vorm van voltrekking. Wie beide samen bijhoudt, kan zowel vragen wat er gold als wat het register op een bepaald moment onderschreef.

Zekerheid is de mate waarin een bewering als feitelijk juist wordt beschouwd. Het register legt twijfel vast als handeling, met een betwijfeling of een betwijfelingsopheffing, zodat die twijfel zichtbaar wordt in projecties en bij afnemers, ook als het onderzoek nog loopt.

Betekenis is de uitleg van wat een beweringssoort inhoudt. Een bewering verandert onderweg een aantal keer van vorm: van externe bevinding naar commando, gevolg, projectie-element en verstrekking. Op elk van die overgangen moet de betekenis behouden blijven en navolgbaar zijn.

De aspecten door het register heen

Eén punt staat nog open: of een projectie-element een eigen legitimering heeft, of dat legitimering alleen bij gevolgen hoort. Zie de open vraag bij Herkomst.

Hoofdstukken

• Herkomst – de herkomstkenmerken en de herkomstketen, van gevolg naar voortgaand gevolg en van verstrekking terug naar bron.
• Tijd – domeintijd en systeemtijd, en hoe tijdstippen van gevolg naar projectie-element en verstrekking doorwerken.
• Zekerheid – hoe twijfel het register binnenkomt, zich verspreidt en bij afnemers zichtbaar wordt.
• Betekenis – hoe betekenis wordt vastgelegd en behouden op elke plek waar een bewering van vorm verandert.

Herkomst

Een betrouwbaar register legt niet alleen vast wat er is gebeurd, maar ook waarom en hoe dat is gebeurd. Op basis van het onderscheid tussen proces en resultaat trekken we het register niet de wereld van procesuitvoering in. Maar we willen afnemers wel in staat stellen verstrekte gegevens op onder andere betekenis, kwaliteit en juistheid te beoordelen, en het mogelijk maken fouten te herleiden en te herstellen. Daarvoor is herkomst nodig.

Herkomst is de verantwoording van de totstandkoming van een bewering. Elke bewering in het register heeft herkomst: elk gevolg en elk projectie-element. Dit hoofdstuk beschrijft eerst waaruit herkomst bestaat, en volgt haar daarna door het hele register en over de grenzen daarvan heen.

De herkomstkenmerken

Herkomst bestaat uit vier kenmerken: welke bron eraan ten grondslag ligt, wie voor de productie verantwoordelijk is, welke legitimering is toegepast en welke werkwijze is gevolgd.

Bron

De bron is de grond waarop de bewering rust: een eerdere bewering, een eigen waarneming of een getuigenis. Waar de bron in een document is vastgelegd, verwijst het model daarnaar.

Het model legt daarbij één stap terug vast en niet de hele keten. Wanneer een register een eigendomsovergang opneemt op grond van een notariële akte, is die akte de bron; de overeenkomst die aan de akte voorafging, hoort bij de herkomst van de akte. Wie de hele keten wil volgen, doet dat stap voor stap, omdat elke schakel een eigen herkomst heeft. Hoe die schakels op elkaar aansluiten, staat hieronder bij de herkomstketen.

Vragen bij het vastleggen van de bron

1. Wat slaan we op? Ten minste een verwijzing naar de voorliggende bewering of de externe bevinding, inclusief de partij die verantwoordelijk was voor de productie daarvan. Omdat hierbij grenzen tussen bounded contexten worden overgestoken, moeten contextoverstijgende afspraken worden gemaakt over vorm, inhoud en uitwisseling van deze verwijzing.
2. Wat doen we met bijlagen? Externe bevindingen kunnen gepaard gaan met ondersteunende documenten, zoals een aanvraagformulier of een bijgevoegd bewijs. Deze bijlagen zijn niet altijd op een volledig gevolg van toepassing. Een te complexe koppelstructuur tussen bijlagen en gegevens is moeilijk te begrijpen en te onderhouden. De vraag is of zulke complexiteit altijd noodzakelijk is, of dat een eenvoudiger benadering – aparte documentopslag waarnaar vanuit de bron kan worden verwezen – volstaat.

Verantwoordelijke

De verantwoordelijke identificeert wie voor de productie van een bewering instaat: een organisatie, een afdeling of een medewerker. Dat geldt ook wanneer de uitvoering geautomatiseerd is verlopen; automatisering verplaatst de verantwoordelijkheid niet naar het systeem.

De verantwoordelijke is uiteindelijk altijd een mens: degene die instaat voor het resultaat, wat dat resultaat ook is. Stuurt een medewerker het systeem direct aan – bij handmatige verwerking, of wanneer hij op basis van discretionaire bevoegdheid handelt – dan is ten minste die medewerker verantwoordelijk. Hoe de verantwoordelijke bij geautomatiseerde verwerking te herleiden is, staat bij van werkwijze naar verantwoordelijke.

Net als de systeemtijd is de verantwoordelijke extrinsiek: wie dezelfde gegevens in een ander register vastlegt, is daar zelf de verantwoordelijke.

Legitimering

De legitimering geeft het kader aan op grond waarvan is geproduceerd en hoe dat kader is toegepast, inclusief eventuele discretionaire afwijkingen. Voor ieder gevolg wordt een zo gedetailleerd mogelijke verwijzing vastgelegd naar het wettelijk of beleidskader dat diende als grondslag, en zo nodig de motivatie waarom op basis van discretionaire bevoegdheid van een norm is afgeweken.

Open vraag: legitimering bij projectie-elementen

Het conceptueel registermodel geeft elke bewering herkomst, en daarmee ook een legitimering. Een eerdere beslissing (vervolg op ADR 00020, 29 september 2026) stelt daartegenover dat legitimering alleen bij gevolgen hoort. Legitimering hoort bij wat een organisatie besluit, en besluiten liggen vast in gevolgen. Een projectie-element besluit niets: het werkt vastgelegde gevolgen door. Volgens die lijn heeft een projectie-element geen eigen legitimering. De legitimering van het onderliggende gevolg blijft via de bron bereikbaar. Het vaststellen van een projectiespecificatie kan wel als besluit worden gezien, maar dat betreft de inrichting van het register, niet de inhoud ervan.

In beide lijnen is een grondslag nodig voor elke bevraging van een projectie: welke afnemer mag welke gegevens, voor welk doel, inzien? Die grondslag hoort bij de bevraging en de verstrekking die erop volgt. Voor het vastleggen daarvan bestaat de standaard Logboek Dataverwerkingen. Welke lijn de handreiking volgt, moet nog worden besloten.

Werkwijze

De werkwijze legt vast volgens welke procedure of welk algoritme, en in welke versie, een bewering tot stand kwam. Zo is achteraf reconstrueerbaar op welke manier een bewering is geproduceerd, ook nadat de procedure of de software is veranderd. Software en versie horen hier, niet bij de verantwoordelijke: ze beschrijven hoe iets tot stand kwam, niet wie ervoor instaat.

Medewerkers en geautomatiseerde systemen volgen allebei vastgelegde werkwijzen. Voor een medewerker is dat een procedure of werkinstructie; voor een geautomatiseerd systeem de software, in een bepaalde versie.

Van werkwijze naar verantwoordelijke

De werkwijze is geen onderdeel van de verantwoordelijke, maar wel de weg ernaartoe. Er is een strikte relatie tussen beide: via de werkwijze moet de verantwoordelijke altijd te herleiden zijn tot een mens.

Bij een medewerker die het systeem direct aanstuurt, is die herleiding kort: de medewerker is ten minste zelf verantwoordelijk; de procedure die hij volgt, wijst naar wie die procedure heeft vastgesteld. Bij geautomatiseerde verwerking is de keten langer. Die loopt van de softwareversie naar de developers die de software bouwden, van hen naar de functioneel ontwerpers die de regels specificeerden, en van daaruit naar de hoofdverantwoordelijke binnen de organisatie voor de gehele procedure.

Dat stelt een eis aan de manier waarop de werkwijze wordt vastgelegd: een softwareversie moet eenduidig verwijzen naar de software die daadwerkelijk draaide. Een datum of een vrij gekozen versienummer volstaat daarvoor niet altijd; een verwijzing naar een revisie in het versiebeheer wel.

Softwarebeheer als werkwijze

Wanneer software de werkwijze is, wordt de manier waarop die software wordt beheerd onderdeel van de verantwoording. De herleiding van een bewering naar een mens is maar zo sterk als de schakels daartussen. Drie praktijken dragen daaraan bij:

• Versiebeheer. Elke wijziging in de software is vastgelegd als revisie, met wie de wijziging maakte, wanneer en waarom. Een softwareversie die naar zo’n revisie verwijst, maakt precies herleidbaar welke regels zijn toegepast.
• Voortbrenging. De weg van eis naar code is navolgbaar: welke functionele specificatie leidde tot welke wijziging, wie die wijziging beoordeelde en wie haar goedkeurde. Zo blijft zichtbaar hoe de verantwoordelijkheid van functioneel ontwerper en procedure-eigenaar in de software terechtkomt.
• Continuous delivery en DevOps. Een geautomatiseerde, herhaalbare route van revisie naar productie legt vast welke versie wanneer draaide. Daarmee is voor elk tijdstip te reconstrueren met welke software een bewering is geproduceerd – ook wanneer die bewering na herstel van een softwarefout opnieuw wordt afgeleid.

Een open vraag is hoe dit uitpakt voor aangekochte software. Een leverancier biedt doorgaans geen inzicht in zijn versiebeheer en voortbrenging, en de keten van softwareversie naar developers en ontwerpers loopt dan buiten de eigen organisatie. De verantwoordelijkheid voor het resultaat verschuift daarmee niet naar de leverancier. Hoe de herleiding in dat geval sluitend te maken is – bijvoorbeeld via contractuele afspraken, acceptatietests of eigen vastlegging van de toegepaste regels – werken we hier niet uit.

Eerdere indeling: verwerkingsverantwoording

Eerdere versies van de handreiking spraken van verwerkingsverantwoording, met de onderdelen aanleiding, legitimering en verklaring. Die indeling gaat op in de herkomstkenmerken: de aanleiding is de bron, de legitimering blijft de legitimering (inclusief hoe het kader is toegepast), en wat onder verklaring viel – toegepaste procedures, versies van algoritmes – is de werkwijze.

Herkomst van gevolgen en van projectie-elementen

De herkomstkenmerken gelden voor elke bewering, maar vullen zich verschillend in voor gevolgen en voor projectie-elementen.

Omdat projectie-elementen rechtstreeks uit gevolgen worden afgeleid, is hun herkomst beknopter dan die van gevolgen. De voornaamste verantwoording ligt al in de gevolgen waarop een projectie-element is gebaseerd, en via de bron blijft de herkomst van het gevolg bereikbaar. Toch is het afleiden een eigen productie, met eigen regels en eigen software: een fout in de projectiespecificatie is een andere fout dan een fout in het gevolg, met een andere verantwoordelijke en een ander herstel. Hoe de voorbeeldimplementatie de herkomst van projectie-elementen invult, staat in de verdieping over bitemporele opslag van snapshots.

De herkomstketen

Herkomst legt telkens één stap terug vast. Achter elkaar gezet, vormen die stappen een keten waarlangs elke verstrekte bewering te herleiden is naar haar oorsprong. Die keten is op twee niveaus te volgen.

Op hoofdlijnen: van gevolg naar gevolg

Overheden handelen in ketens. Een gevolg in de ene bounded context wordt verstrekt, en die verstrekking is in de volgende context aanleiding voor een nieuw gevolg (zie Uitvoeringscontext en Contextovergangen). Als zo’n voorliggend gevolg ontbreekt, ligt de aanleiding buiten de overheidscontext, bijvoorbeeld in een handeling of melding van een burger of bedrijf.

Op hoofdlijnen is de herkomstketen daarom een keten van gevolgen: elk gevolg verwijst via zijn bron naar wat eraan voorafging, en dat is vaak een verstrekking over een gevolg in een andere context.

In detail: door het register heen

Binnen één register bestaat elke stap in die keten uit meerdere schakels. Elke schakel heeft een eigen herkomst en verwijst één stap terug.

Van de oorsprong naar de afnemer gelezen:

1. Externe bevinding. Een uitspraak uit een andere context – vaak een verstrekking van een ander register – komt binnen. De vertaalregel maakt expliciet hoe die wordt omgezet naar een commando en wat daarbij achterblijft.
2. Gevolg. Optekenen produceert op basis van het commando een gevolg. De bron is de externe bevinding of het document waarin die is vastgelegd; de werkwijze omvat de vormingsspecificatie.
3. Projectie-element. Projecteren leidt uit het gevolg een projectie-element af. De bron is het gevolg; de werkwijze is de projectiespecificatie.
4. Verstrekking. Het register verstrekt projectie-elementen als notificatiebericht of antwoordbericht. De verstrekkersreferentie wijst precies die verstrekking aan.
5. Gevolg bij de afnemer. De afnemer handelt op basis van de verstrekking. Voor zijn eigen gevolg is die verstrekking de externe bevinding, en de verstrekkersreferentie de verwijzing in de bron. Daarmee begint de keten in de volgende context opnieuw.

Andersom gelezen is dit het pad dat een vraag over juistheid aflegt. Een terugmelding wijst een verstrekt projectie-element aan. Via de bron van dat element is het gevolg te vinden, via de bron van het gevolg de externe bevinding, en via die bevinding het voorliggende gevolg in een andere context. Op elke schakel geven verantwoordelijke, legitimering en werkwijze aan wie voor die stap instond en hoe die tot stand kwam. Zo kan onderzoek vaststellen of een fout in de bron, in het gevolg of in het projecteren zit.

Herkomst bij herstel

Ook herstel maakt deel uit van de keten. Een correctie of onttrekking na een terugmelding is een nieuw gevolg, met het onderzoeksdossier als bron (zie Betwisten). Een projectie-element dat na herstel van een projectiefout opnieuw is afgeleid, heeft hetzelfde gevolg als bron, maar een nieuwe versie van de projectiespecificatie als werkwijze. Zo blijft ook voor herstelde beweringen zichtbaar waarom ze er zijn.

Herkomst in opslag en verstrekking

In de bitemporele opslag van snapshots hoort de herkomst bij de metadata van een snapshot, naast de tijdstippen. Of en welke herkomstkenmerken een verstrekking meekrijgt, hangt af van de afnemer: een afnemer die zelf verantwoording moet afleggen, heeft meer nodig dan een afnemer die alleen de actuele stand wil weten. Via de verstrekkersreferentie blijft te achterhalen welke projectie-elementen zijn verstrekt, en daarmee ook wat hun herkomst is.

Tijd

Elke bewering in het register heeft een plaats in de tijd. Over tijd in relatie tot registers zijn boekenkasten vol geschreven, met eindeloos veel verschillende ‘tijdsoorten’ of ‘tijdsassen’. Deze handreiking maakt primair onderscheid op basis van wie of wat de waarde van een tijdstip of periode bepaalt. Dat levert twee soorten tijd op. Dit hoofdstuk beschrijft ze, en volgt ze daarna door het register: van gevolg via projectie-element naar verstrekking.

Domeintijd en systeemtijd

De domeintijd is het punt of de periode die onlosmakelijk hoort bij wat een bewering beschrijft en deze in de tijd van het domein plaatst. De waarde wordt bepaald door de werkelijkheid, de regelgeving of de bestuurlijke context waarbinnen een register werkt. Domeintijd is intrinsiek: onlosmakelijk onderdeel van het gebeuren of de toestand die een bewering beschrijft.

De systeemtijd is het punt dat het register bij het vastleggen aan een bewering toevoegt en deze op de tijdlijn van het systeem plaatst. De waarde wordt bepaald door het systeem dat gegevens verwerkt en opslaat. Dat kan een IT-systeem zijn, maar ook het sociotechnische systeem waarin mensen en IT-systemen samenwerken om taken uit te voeren. Systeemtijd is extrinsiek: het zegt iets over de verwerking van een bewering, maar niets inhoudelijks over wat de bewering beschrijft. Dezelfde gegevens hebben daarom in ieder register dat ze vastlegt een eigen systeemtijd.

De geboortedatum van een op 3 maart geboren kind is een moment in de domeintijd. Het moment (bijvoorbeeld 5 maart) waarop het inschrijvingsgevolg met die geboortedatum door het register wordt opgenomen, is een moment op de systeemtijdlijn.

Aan de domeintijdkant kunnen meerdere tijdsdimensies bestaan, bijvoorbeeld een geldigheidsperiode naast een moment van inwerkingtreding. Er is één systeemtijddimensie.

Domeintijd

Geldigheid

Geldigheid beschrijft wanneer iets ‘gold’ of beschouwd werd als ‘juist’ of ‘waar’. Geldigheidstijd is daarmee een vorm van domeintijd.

Geldigheid wordt bepaald door het administratieve domein dat gegevens registreert. Anders dan systeemtijd is geldigheid een onveranderlijk of ‘intrinsiek’ onderdeel van wat geregistreerde gegevens beschrijven. Gegevens die in meerdere registers zijn gedupliceerd, hebben daardoor in ieder van die registers dezelfde geldigheid.

Geldigheid als administratief construct

Hoewel het woord ‘intrinsiek’ anders kan doen lijken, is geldigheidstijd een administratief construct. Niemand zal kersverse ouders een kaartje sturen om hen te feliciteren met de nieuw verworven geldigheid van hun pasgeboren baby. In de ‘echte’ wereld, waar de dingen die we met behulp van gegevens beschrijven daadwerkelijk bestaan, komen we hooguit gebeurens tegen die aanleiding geven om gegevens in administratieve context als geldig te gaan beschouwen. In het geval van een persoon kan dat een geboorte zijn, maar bijvoorbeeld ook een immigratie als iemand pas op latere leeftijd in beeld komt van ‘onze’ administratieve werkelijkheid. Overlijden zou aan de andere kant een reden kunnen zijn om de geldigheid van een persoon te beëindigen.

Het begrip geldigheidstijd (of valid time) werd in 1986 gemunt door Richard Snodgrass en Ilsoo Ahn. In hun artikel ‘Temporal Databases’ illustreren de auteurs deze temporele dimensie aan de hand van een universiteitsmedewerker (‘Merrie’) die door de tijd verschillende functies heeft.

Informatie over de veranderende functie van Merrie vinden we door aan een projectie de vraag te stellen “wat was op moment tx de functie van Merrie?” Voor september 1973 zou het antwoord ‘instructor’ luiden, terwijl het voor december van dat jaar ‘assistant professor’ zou zijn. Hoewel het artikel dit niet expliciet maakt, veronderstelt dit voorbeeld een projectie over Merrie’s functies vanuit continuantperspectief: een toestandsprojectie.

Voltrekking

Een gebeurenprojectie kunnen we niet op dezelfde manier bevragen. Neem opnieuw de veranderende functie van Merrie, maar nu niet beschouwd vanuit een medewerker met verschillende rollen, maar als loopbaan: een gefaseerde voltrekking van opeenvolgende aanstellingen.

Stel dat je daarover vraagt: “hoe zag op moment tx Merrie’s loopbaan eruit?” Dan zou voor 1 oktober 1973 het antwoord als volgt kunnen luiden: “Merrie was als instructor aangetreden, de aanstelling als assistant professor was nog niet ingegaan.” Wat hier beschreven wordt, is geen toestand, maar een opsomming van op het bevragingsmoment gepasseerde en lopende fases.

De ‘geldigheid’ van een loopbaan op 1 oktober 1973 bestaat dus eenvoudigweg niet. Wat wel bestaat, is het feit dat een deel van de loopbaan achter de rug is – we noemen dit ‘voltrokken’ – en een ander deel nog moet komen. Gebeurens bevragen en projecteren we daarom niet op basis van geldigheidstijd, maar op basis van voltrekkingstijd (of occurrence time): het tijdstip of de periode waarin een gebeuren zich voltrekt.

Geldigheid + voltrekking = domeintijd

Toestanden en gebeurens kennen dus ieder hun eigen tijdsdimensie: geldigheidstijd voor de eerste, voltrekkingstijd voor de tweede. In de literatuur wordt de term geldigheidstijd echter vaak gebruikt als generieke aanduiding voor alles wat geen systeemtijd is. Dat is een historisch gegroeide onnauwkeurigheid: geldigheidstijd is passend voor toestanden, maar niet voor gebeurens.

Wat geldigheidstijd en voltrekkingstijd gemeen hebben, is dat ze beide iets uitdrukken over de (fysieke, juridische of administratieve) werkelijkheid die het register beschrijft, en niet over het register zelf. Deze categorie tijdsbegrippen duiden we aan met één begrip: domeintijd. Die omvat alle vormen van tijd die niet door het register zelf worden bepaald, maar door wat in het domein gebeurt of geldt – ook juridische inwerkingtredingsdata of beslistermijnen.

Bij toestandsprojecties hoort dus een vraag naar geldigheid (geldigOp, geldigVanaf, geldigTot), bij gebeurenprojecties een vraag naar voltrekking (gebeurdVanaf, gebeurdTot). De projectiesoorten zetten deze vormen van domeintijd af tegen systeemtijd.

Systeemtijd

Eén systeemtijddimensie, twee verschijningsvormen

Omdat gevolgen en projectie-elementen elk een eigen systeemtijd hebben, komt de systeemtijddimensie op twee plekken terug:

• aan de journaalkant als gevolgtijdstip: het moment waarop een gevolg in het gevolgenjournaal wordt vastgelegd;
• aan de projectiekant als projectietijdstip: het moment waarop een projectie-element wordt geproduceerd en beschikbaar komt voor afnemers. Bij notificaties heet dat moment ook wel het notificatietijdstip.

Tussen deze twee momenten zit verwerkingstijd. Beide liggen op dezelfde as; het projectietijdstip is geen derde temporele dimensie.

Tijd door het register heen

Gevolg: gebeurd op en gevolgtijdstip

Een gevolg is temporeel atomair: het vindt op één moment plaats en heeft geen (geldigheids)duur. In termen van temporele databases is het een event: een ogenblikkelijk feit.

Een gevolg draagt daarom twee tijdstippen:

• het gebeurd-op-tijdstip, in de domeintijd: het door het domein bepaalde moment waarop het gevolg in de echte wereld een verandering tot stand bracht;
• het gevolgtijdstip, in de systeemtijd: het moment waarop het gevolg in het gevolgenjournaal is vastgelegd.

Gebeurd op en geldigheid

In veel gevallen kan van het gebeurd-op-tijdstip van een gevolg een geldig-vanaf-moment in een toestandsprojectie worden afgeleid. Gaan we ervan uit dat het moment van geboorte het startpunt is voor een geldige inschrijving, dan kan van het gevolg persoon p1 geboren | gebeurd op 18-07-1985 de volgende projectie worden afgeleid:

Welk tijdstip als geldigheidstijdstip dient, is een keuze per projectie en ligt vast in de projectiespecificatie. Een gevolg kan meerdere domeintijdstippen bevatten, zoals een geboortedatum en een datum van inschrijving. Wie personen wil afbeelden vanaf de geboorte, kiest de geboortedatum; wie vooral in de administratie is geïnteresseerd, de inschrijvingsdatum. Bij een late geboorteaangifte maakt dat verschil uit. Het adoptievoorbeeld laat zien hoe verschillende projecties verschillende domeintijdstippen gebruiken.

De keuze tussen feitelijk en administratief formuleren werkt hierop door:

• Bij feitelijke formulering is het gebeurd-op-moment een logisch startpunt voor geldigheidsperiodes in projecties.
• Bij administratieve formulering blijft sprake van een domeindatum, maar neigt het gebeurd-op-moment meer naar het karakter van een ‘geregistreerd-op’-moment.

Projectie-element: geldigheid van de projectie en van de gegevens

Bij projecties die zijn opgebouwd uit meerdere gevolgen, is het belangrijk onderscheid te maken tussen de geldigheidsdatum van de projectie zelf en de domeindatums van de gegevens daarbinnen. De geldigheidsdatum van een projectie geeft aan vanaf welk moment deze projectie in deze vorm als ‘juist’ of ‘waar’ wordt beschouwd. Die datum zegt dus niets over de ouderdom van de entiteiten of andere gegevens die erin zijn opgenomen.

Neem als voorbeeld de volgende gevolgen:

• woz-object w1 ontstaan | gebeurd op 15-08-1994
• belanghebbende bij woz-object w1 is p1 | gebeurd op 23-08-1994
• belanghebbende bij woz-object w1 is p2 | gebeurd op 19-10-2009
• belanghebbende bij woz-object w1 is p3 | gebeurd op 07-03-2023

Het WOZ-object bestaat al sinds 15-08-1994, maar de projectie is voor het laatst bijgewerkt naar aanleiding van het gevolg van 07-03-2023. Die datum markeert dus niet het ontstaan van het object, maar het meest recente domeinmoment dat de huidige vorm van de projectie heeft bepaald.

Zonder toelichting riskeert een afnemer de datum verkeerd te interpreteren. Uit de projectie moet de betekenis daarom voldoende duidelijk blijken – bijvoorbeeld door de geldig vanaf-datum expliciet aan de projectie te koppelen, of door aan te geven dat die datum de laatste relevante wijziging in het domein betreft.

projectie l1
  geldig vanaf 07-03-2023
  woz-object w1
    eerste registratie 15-08-1994
    belanghebbenden
      p1
        start belang 23-08-1994
        einde belang 18-10-2009
      p2
        start belang 19-10-2009
        einde belang 06-03-2023
      p3
        start belang 07-03-2023

Een projectie-element draagt alleen de tijd van zijn eigen productie en wat zijn grond over de domeintijd zegt. Wanneer een toestand ophoudt, blijkt uit een volgend element in de reeks (zie Projecties opbouwen).

Verstrekking: het projectietijdstip meeleveren

Bij iedere concrete verstrekking kan het projectietijdstip worden meegeleverd. Of dat wenselijk is, hangt af van de situatie. Bij een vraag naar de actuele stand is dit tijdstip vaak niet relevant. In andere gevallen kan het meesturen ervan juist ongewenst zijn, omdat het informatie kan onthullen die niet met iedereen gedeeld mag worden, zoals het feit dat een correctie heeft plaatsgevonden.

Verwerkingstijd

Tussen het gevolgtijdstip en het projectietijdstip zit verwerkingstijd, en tussen het projectietijdstip en het moment waarop een afnemer de gegevens ziet nog meer. Een afnemer kijkt daardoor altijd in potentie naar informatie die net niet meer actueel is. Dat is geen fout, maar een eigenschap van de architectuur; zie eventual consistency als ontwerpoverweging en de inherente beperkingen aan de herhaalbare vraag.

Bitemporaliteit

Wie domeintijd en systeemtijd samen bijhoudt, werkt bitemporeel. Dat is nodig om twee vragen uit elkaar te houden: wat gold er volgens het register op een bepaald moment, en wat onderschreef het register op een bepaald moment? De capability Historisch inzicht vraagt beide. Ook de herhaalbare vraag is zonder bitemporaliteit niet te beantwoorden zodra correcties met terugwerkende kracht mogelijk zijn.

Bitemporaliteit brengt complexiteit met zich mee die niet in alle gevallen nodig is. Welke temporaliteit een projectie nodig heeft, is een ontwerpafweging.

Verdieping

• Tijdstippen en geldigheid werkt de tijdstippen van gevolgen en projecties uit.
• Temporaliteit in projecties gaat van actuele stand via unitemporaliteit naar bitemporaliteit.
• Bitemporele relationele databases beschrijft een tabelvorm voor bitemporele projecties.

Zekerheid

Met zekerheid bedoelen we de mate waarin een bewering als feitelijk juist wordt beschouwd. Zekerheid is om twee redenen geen eenvoudig begrip. Ten eerste is het gradueel: een bewering kan geverifieerd en onbetwist zijn, maar ook onbevestigd, in onderzoek of actief betwist. Ten tweede is zekerheid niet altijd gedeeld: verschillende partijen kunnen op hetzelfde moment een verschillend oordeel hebben over de juistheid van dezelfde bewering.

Dit hoofdstuk beschrijft hoe het register met zekerheid omgaat, en volgt twijfel door het register: van terugmelding via gevolg en projectie naar de afnemer.

Waarom zekerheid ertoe doet

Onzekerheid werkt diep door in ketens of netwerken. Als een bedrijfsregel bij het afleiden van een resultaat steunt op een gegeven waaraan getwijfeld wordt, is ook dat resultaat onzeker. Als datzelfde resultaat door andere partijen in de keten weer wordt gebruikt als basis voor eigen handelingen, kunnen weer nieuwe op onjuiste gronden gefundeerde resultaten ontstaan, enzovoorts.

Een register dat twijfel niet kenbaar maakt, laat afnemers op gegevens handelen alsof die zeker zijn. Een register dat twijfel wel kenbaar maakt, geeft afnemers de kans zelf te bepalen hoe ze daarmee omgaan, ook als het onderzoek nog loopt.

Twijfel in het register

Het register legt twijfel vast als handeling, niet als eigenschap die wordt overschreven. Een betwijfeling is een beweringsgericht gevolgdeel dat de juistheid van een bewering in twijfel trekt; een betwijfelingsopheffing neemt die twijfel weer weg. Beide maken deel uit van een gevolg en staan dus in het gevolgenjournaal, met herkomst en tijd. De functies Betwijfelen en Betwijfeling opheffen dragen samen de capability Twijfelen.

Daardoor is de zekerheid van een bewering op elk moment te reconstrueren: wie wil weten of het register op een bepaald moment aan een bewering twijfelde, kijkt welke betwijfelingen en opheffingen op dat moment waren vastgelegd.

Twijfel is geen onttrekking

Een betwijfeling en een onttrekking zijn allebei beweringsgerichte gevolgdelen, maar ze zeggen iets anders:

• Een betwijfeling zegt: het register onderschrijft deze bewering nog, maar acht haar juistheid niet zeker. Een betwijfeld gegeven wordt nog steeds geleverd, met een kenbare aanduiding van de twijfel.
• Een onttrekking zegt: het register onderschrijft deze bewering niet langer. In projecties die alleen bevatten wat het register nu onderschrijft, komt zij niet meer voor.

Twijfel is daarmee vaak een tussenstap. Een onderzoek begint met een betwijfeling en eindigt met een opheffing (de bewering bleek juist) of een correctie die de bewering onttrekt (de bewering bleek onjuist).

Twijfel door het register heen

1. Terugmelding. Twijfel komt het register meestal binnen via een terugmelding op een verstrekt projectie-element. De terugmelding zelf verandert de zekerheid nog niet; dat doet pas de beoordeling ervan.
2. Betwijfeling van een projectie-element. Een betwijfeling gaat over een bewering, en dat kan een projectie-element zijn. In eerste instantie kan de twijfel worden aangebracht op het projectie-element waarop is teruggemeld.
3. Betwijfeling van een gevolg. Lopende het onderzoek kan blijken dat de twijfel eigenlijk het gevolg betreft waaruit het element is afgeleid. Dan kan de betwijfeling naar het gevolg worden verplaatst: een opheffing voor het projectie-element en een betwijfeling van het gevolg.
4. Doorwerking in projecties. Een betwijfeling van een gevolg raakt alle projecties waarin dat gevolg doorwerkt. Projecteren maakt de twijfel daarin zichtbaar, als eigen projectie-element in de reeks van de betrokken entiteit.
5. Verstrekking. Afnemers zien de twijfel bij bevraging en kunnen er via een notificatie over worden geïnformeerd, ook als ze zelf niet hebben teruggemeld.

Een betwijfeling kan ook de basis vormen voor een correctie: wat het register eerst betwijfelde, kan na onderzoek worden onttrokken en vervangen.

Zekerheid voor afnemers

Zekerheidsaanduidingen zijn in de eerste plaats relevant voor afnemers. Zekerheid moet daarom zichtbaar zijn in projecties.

Omdat onzekerheid diep kan doorwerken in ketens, is het niet altijd voldoende alleen de zekerheid van een projectie als geheel aan te geven. Een daartoe geautoriseerde afnemer moet ook kunnen zien welk onderliggend gevolg de bron van twijfel is, zodat hij kan beoordelen in hoeverre zijn eigen verwerking daarop steunt en hoe hij daarmee wil omgaan. Hier raken zekerheid en herkomst elkaar: de herkomstketen wijst aan welke gevolgen en verstrekkingen op een betwijfelde bewering steunen.

Afhankelijk van de situatie kan een afnemer er bijvoorbeeld voor kiezen een bedrijfsregel situationeel buiten werking te stellen, onzekerheid door te geven aan zijn eigen afnemers, of processen die op de gegevens steunen expliciet te laten waarschuwen wanneer zij onzekere gegevens tegenkomen.

Twijfel aan gevolgen

Of twijfel over de feitelijke juistheid van een gevolg mogelijk of zinvol is, hangt af van de manier waarop het gevolg is geformuleerd:

• Bij feitelijke formulering beschrijft het gevolg iets wat buiten de context van het register is gebeurd. Dat gebeuren kan feitelijk waar, maar ook feitelijk onwaar blijken te zijn. Als we gevolgen feitelijk modelleren, is het dus nodig om aan de juistheid van een gevolg te kunnen twijfelen.
• Bij administratieve formulering gaat het gevolg over iets dat door het optekenen van het gevolg zelf waar wordt: de geboorteregistratie ontstaat door het optekenen van het bijbehorende gevolg. De feitelijke juistheid ontstaat hier door het optekenen zelf, en het lijkt niet zinvol om aan de juistheid van zo’n gevolg te twijfelen.

Voor zover twijfel mogelijk en zinvol is, maakt het register het mogelijk die in het gevolgenjournaal vast te leggen.

Voorbeelden

De casus WOZ werkt het volledige pad uit, van terugmelding via start betwijfelen tot betwijfelen afronden, en twijfel en herstel voor de combinatie met correctie.

Betekenis

Een gegeven zonder betekenis is een waarde zonder uitleg. Wie een verstrekking ontvangt, moet kunnen begrijpen wat ermee wordt beweerd: wat de boodschap is, op welk moment die betekenis heeft, voor wie die bedoeld is en in welke omstandigheden die toepasbaar is. In de uitvoeringscontext van registers noemen we dit de context van een verstrekking. Dit hoofdstuk beschrijft hoe het register betekenis vastlegt, en hoe betekenis wordt bewaard en overgedragen op elke plek waar een bewering van vorm verandert.

Betekenis in het bounded contextmodel

In het model is betekenis uitleg van wat een beweringssoort inhoudt, bedoeld om beweringen van die beweringssoort te kunnen duiden. Betekenis hoort bij de beweringssoort en niet bij de individuele bewering: alle beweringen van dezelfde soort delen dezelfde uitleg. Daarmee is betekenis onderdeel van het bounded contextmodel, opgesteld in de gemeenschappelijke taal van de bounded context.

Dat betekenis bij de soort hoort, maakt haar beheersbaar. Een afnemer hoeft niet bij elke bewering opnieuw uitleg te krijgen; hij kan de betekenis van een beweringssoort eenmaal leren kennen en die toepassen op alle beweringen van die soort.

Betekenis door het register heen

Een bewering verandert onderweg door het register een aantal keer van vorm. Op elk van die overgangen kan betekenis verloren gaan of verschuiven. Het register maakt die overgangen daarom expliciet.

Van externe bevinding naar commando

Een externe bevinding heeft betekenis in de context waarin ze is ontstaan. Een vertaalregel beschrijft hoe die bevinding met behoud van betekenis wordt omgezet naar een commando in de eigen taal, en maakt zichtbaar wat bij die omzetting achterblijft. Dat de bounded contexten eigen taal en eigen begrippen hebben, en dat dezelfde term in twee contexten iets anders kan betekenen, beschrijft De overheid verkaveld.

Van commando naar gevolg: intentie

Een gevolg drukt de intentie van een observatie, besluit of vastlegging uit, niet het effect ervan op de toestand van het register. Daardoor draagt het gevolg meer betekenis dan de wijziging die het teweegbrengt: “verhuizing geregistreerd” en “adoptie geregistreerd” kunnen allebei tot een nieuw adres leiden, maar betekenen iets anders. De ontwerpafwegingen voor gevolgen beschrijven hoe naamgeving, typering en interfacing die intentie vastleggen. Ook de keuze tussen feitelijk en administratief formuleren is een keuze over betekenis: zegt het gevolg dat iets is gebeurd, of dat het register iets heeft vastgelegd?

Van gevolg naar projectie-element: perspectief

Een projectie is geen directe weergave van de gevolgen in het journaal. Het journaal beschrijft vanuit bijhoudingsperspectief wat er binnen een bounded context gebeurt; een projectie ordent dat opnieuw rond de begrippen waarnaar een afnemer kijkt. Een gevolg “bezwaar ontvangen” verschijnt in een projectie over een vergunning als “vergunning door bezwaar betwist” (zie het intermezzo van gevolg naar projectie). De projectiespecificatie legt vast hoe die hertaling verloopt. Ook daar moet de betekenis behouden blijven: het projectie-element zegt hetzelfde als het gevolg, maar vanuit een ander perspectief.

Betekenis zit niet alleen in de inhoud, maar ook in de tijdstippen. Een geldig-vanaf-datum van een projectie kan iets anders betekenen dan een afnemer verwacht (zie Tijd). Uit de projectie moet duidelijk blijken wat zo’n datum aanduidt.

Van projectie-element naar afnemer

Een verstrekking is een representatie van wat een gevolg betekent (zie De ‘datalaag’ van de overheid). Verstrekkingen kunnen zijn gesteld in de taal van het register, maar ook in een taal die dichter aanligt tegen die van de afnemende context. Afhankelijk van de situatie doet een register beide.

Bij notificaties is betekenis het zwaarst. De capability Betekenisvol notificeren houdt in dat het register notificaties kan leveren die informatie omvatten over de aanleiding voor en de betekenis van de beweringen waarover wordt genotificeerd. Een afnemer die een notificatie ontvangt, moet daaruit kunnen opmaken of zijn eigen taken het nodig maken te handelen. Een notificatie die alleen meldt dat een adres is gewijzigd, laat de afnemer raden of het om een verhuizing, een adoptie of een correctie gaat.

Betekenis en toegang kunnen daarbij botsen. Een afnemer die niet geautoriseerd is om te weten dat een adoptie heeft plaatsgevonden, mag wel weten dat een adres is gewijzigd. Interfacing van gevolgen (zie het adoptievoorbeeld) maakt het mogelijk zo’n afnemer een betekenisvolle, maar beperktere notificatie te sturen.

Betekenis en afwijkingen van het model

Een betekenisvol gegeven past niet altijd in het model dat het moet dragen. Oude migratiedata, ooit verkeerd geïmplementeerde validaties of veranderingen in het datamodel kunnen ervoor zorgen dat gegevens niet voldoen aan het voorgeschreven model. Het is dan beter de afwijking te kunnen opslaan en verstrekken, met een expliciete aanduiding dat het bericht niet aan het model voldoet, dan het gegeven te weigeren. Zie betrouwbare modellen versus onbetrouwbare realiteit.

Open vragen

• Hoe wordt betekenis aan afnemers beschikbaar gesteld: als onderdeel van elke verstrekking, als aparte publicatie van het bounded contextmodel, of beide?
• Hoe wordt een verandering in de betekenis van een beweringssoort kenbaar gemaakt aan afnemers die eerder verstrekte beweringen van die soort hebben ontvangen?