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.

Inleiding

Voordat we beschrijven hoe een betrouwbaar register werkt, leggen we vast waarom we dit doen, hoe we naar registers kijken en waarover dit ontwerp iets zegt. Het conceptueel registerontwerp bouwt daarop voort.

We spreken bewust van register en niet van registratie. Dat sluit aan bij gewoon taalgebruik – volgens Van Dale is registratie de “inschrijving in een register” – en voorkomt de indruk dat het ontwerp (alleen) gericht is op basisregistraties.

Waarom dit ontwerp?

De overheid is bevoegd vergaand in te grijpen in de situatie van burgers en bedrijven. Door automatisering doet ze dat op steeds grotere schaal. Ons vermogen om overheidshandelen te begrijpen, te controleren en gemaakte fouten te herstellen zijn niet evenredig meegegroeid.

Als het misgaat, worden daardoor niet alleen meer burgers en bedrijven geraakt. Omdat gegevens geautomatiseerd door ketens stromen en meerdere organisaties erop handelen, hebben fouten ook verstrekkender gevolgen.

Dit model beschrijft hoe registers overheidsinformatie zo kunnen vastleggen en beschikbaar stellen dat we de waarde ervan beter kunnen beoordelen, fouten zoveel mogelijk voorkomen en ze – als dat niet lukt – in ieder geval kunnen herstellen.

De happy en de crappy flow

Zolang burgers en bedrijven vragen wat we vooraf hadden bedacht, tijdig de juiste informatie aanleveren en ‘onze’ gegevens kloppen, verlopen processen snel en met beperkte menselijke tussenkomst. Dat is de happy flow, die in de meeste gevallen gevolgd kan worden.

Past een situatie daar echter niet bij, of moet iets worden aangevochten, onderzocht of gecorrigeerd, dan belanden we in de crappy flow: een werkstroom die vrijwel altijd handwerk vraagt en soms helemaal niet wordt afgehandeld.

Resultaten uit de happy flow verspreiden zich daardoor gemakkelijk en geautomatiseerd door het overheidsapparaat. Uit de crappy flows voortkomende betwijfelingen en correcties bereiken ‘stroomafwaarts’ gelegen domeinen daarentegen moeizaam of helemaal niet.

Hoe komt de crappy flow in het ontwerp terug? Terugmelden, twijfelen en corrigeren ondersteunen aanvechten, onderzoeken en herstellen, betekenisvol notificeren helpt betwijfelingen en correcties stroomafwaarts te brengen.

Epistemische nederigheid

Betere ondersteuning van de crappy flow lost echter niet alles op. Hoeveel crappy flows we ook in happy flows veranderen: onjuistheden in overheidsinformatie blijven bestaan. Wie overheidsregisters toch als onfeilbaar behandelt, schept dus een tweede probleem: overmatig vertrouwen. Daartegenover stellen we _epistemische nederigheid: erkennen dat onze kennis beperkt, voorlopig en mogelijk onjuist is.

Epistemisch nederig handelen is onmogelijk zonder gereedschap om de waarde van informatie te beoordelen. We kunnen nu vaak niet achterhalen wie een keten van overheidshandelen in beweging heeft gezet, wanneer en waarom, en we zien niet hoe lang óns handelen verderop in de keten doorwerkt.

Daarvoor moeten we van informatie kunnen nagaan waar die vandaan komt (herkomst), hoe die door de tijd is veranderd (tijd), hoe zeker we zijn over de juistheid ervan (zekerheid) en wat we ermee bedoelen (betekenis).

Hoe komt epistemische nederigheid in het ontwerp terug? De vier betrouwbaarheidsaspecten – herkomst, tijd, zekerheid en betekenis ondersteunen epistemische nederigheid, net als de onze keuze voor wat het register bevat: beweringen, geen feiten.

Hoe we naar registers kijken

Performatieve handelingen en afgeleide representaties

Overheidsinformatie ontstaat uit handelen. Vaak is dat handelen performatief, wat betekent dat door dat handelen een nieuwe (administratieve) situatie ontstaat. Verklaart de ambtenaar van de burgerlijke stand twee mensen bijvoorbeeld in de echt verbonden, dan zijn zij vanaf dat moment getrouwd, met de rechten en plichten die daarbij horen.

Het is dus deze verklaring van de ambtenaar die de nieuwe situatie tot stand brengt. Daarom beschouwen we die als primair: de verklaring ontstaat niet door afleiding, maar puur door het handelen van een daartoe bevoegde ambtenaar, die daarop ook aanspreekbaar is. De verklaring vormt bovendien de basis voor alles wat daarna met het huwelijk gebeurt.

Die vervolghandelingen gebeuren echter vaak niet op basis van de verklaring zelf, maar op basis van daarvan afgeleide representatie. Het echtpaar krijgt een papieren huwelijksakte thuisgestuurd, de bevolkingsregistratie verwerkt een gewijzigde burgerlijke staat en de Belastingdienst wil weten wie iemands fiscale partner is. Welke representatie nodig is, hangt dus af van de afnemer en diens informatiebehoefte.

Hoe komen performatieve handelingen en afgeleide representaties in het ontwerp terug? Binnen het register wordt expliciet onderscheid gemaakt tussen primaire en afgeleide beweringen.

Januskop als metafoor

De primaire verklaring en de daarvan afgeleide representaties hebben dus een heel verschillend karakter, maar zijn vanuit verantwoordingsperspectief allebei belangrijk. Een register staat daarmee op een overgang: tussen het handelen dat iets tot stand bracht en het handelen dat daarop volgt. De Romeinen hadden een god voor overgangen: Janus, die vaak wordt afgebeeld als een hoofd met twee gezichten. Het ene kijkt terug, het andere vooruit.

Januskop (afbeelding: Igor Gordeev)

Ook een register moet twee richtingen op kunnen kijken. Wie wil weten wat er gebeurd is, kijkt terug naar de verklaring en het handelen waaruit die ontstond. Wie wil begrijpen waarom andere partijen het huwelijk handelden zoals ze deden, kijkt vooruit naar de representaties waarop zij zich baseerden.

Janus heeft twee gezichten, maar één hoofd. Net zo horen primaire en afgeleide beweringen horen bij elkaar, in één register, dat ook vastlegt hoe de een uit de ander is afgeleid. Wijkt de akte af van de verklaring, of de burgerlijke staat van de akte, dan is na te gaan waar het misging.

Hoe komt de januskop in het ontwerp terug? Het register omvat voor beide perspectieven een eigen cluster: primaire beweringen worden in een journaal herkenbaar bijgehouden, terwijl de vorm van afgeleide beweringen wordt bepaald door op maat van afnemers gesneden projecties.

Bounded context als begrenzend begrip

Betekenis is belangrijk, maar zelden vanzelfsprekend: hetzelfde woord kan in verschillende situaties iets anders betekenen. Binnen de context die een register bedient, willen we daarom geen conflicterende betekenissen. Een domein in de gewone zin – “een sfeer van kennis, invloed of activiteit” – is daarvoor te ruim: binnen één domein kunnen dezelfde begrippen verschillend worden uitgelegd en kunnen regels elkaar tegenspreken.

Daarom bakenen we het werkingsgebied van registers af met een begrip uit Domain-driven design: de bounded context. Dat is een taakgebied dat in een gemeenschappelijke taal ondubbelzinnig en samenhangend is gemodelleerd. Binnen zo’n context worden begrippen eenduidig uitgelegd en sluiten regels en processen op elkaar aan.

Bounded contexten zijn zelden volledig onafhankelijk van elkaar. Informatie die in de ene context als resultaat van handelen werd geproduceerd, kan in een volgende context nodig zijn om nieuwe handelingen te initiëren. Waar informatie de grens tussen twee contexten oversteekt, ontstaat een contextovergang.

Hoe komt de bounded context in het ontwerp terug? Het bounded contextmodel maakt expliciet wat het register binnen zijn context kan beweren, en de vertaalregel helpt contextovergangen te expliciteren.

Waarover gaat dit ontwerp (niet)?

Betere ondersteuning van de crappy flow en epistemische nederigheid bij het gebruik van overheidsinformatie vragen om verandering op allerlei fronten: juridisch, organisatorisch en technisch. Samen vormen die een grote oplossingsruimte, waarvan dit ontwerp bewust maar een deel verkent. Om dat deel af te bakenen, gebruiken we twee architectuurmodellen die elkaar aanvullen: de European Interoperability Reference Architecture (EIRA) en het Common Ground-vijflagenmodel.

Binnen EIRA richten we ons op de semantische laag en de applicatielaag (de paarse gestreepte lijn in de figuur). Binnen de applicatielaag beperken we ons tot de Common Ground-lagen ‘databronnen’ en ‘diensten’, en – omdat processen de bijhoudingsdiensten gebruiken – een deel van ‘procesinrichting’ (de gele gestreepte lijn). We beschrijven dus de concepten, bouwblokken en generieke functionaliteit van een register, en hoe die met API’s kan worden ontsloten.

Het ontwerp gaat niet over:

• de interpretatie of herziening van wet- en regelgeving;
• de verdeling van verantwoordelijkheden over organisaties, zoals gescheiden organisaties voor bijhouding en verstrekking, of een federatieve dan wel centrale inrichting;
• het gebruik van specifieke technische producten (al spelen die bij onze beproevingen wel een rol);
• het clusteren van applicatiecomponenten in één technisch product, en
• Interfaces die registergegevens aan gebruikers presenteren.

Wat betekent dit voor het registerbegrip?

Binnen de overheid lopen de opvattingen over wat een register is uiteen, van een volledig stelsel van wetgeving, organisaties en systemen tot een plek waar gegevens verkregen kunnen worden, tot simpelweg een database. Dit ontwerp beoogt niet deze interpretaties te verenigen of vervangen. Binnen dit ontwerp kiezen we echter wel één uitleg:

“Een register is applicatiefunctionaliteit die binnen een afgebakend domein primaire beweringen over overheidshandelen vastlegt en daarvan afgeleide beweringen verstrekt, zodanig dat hun herkomst, tijd, zekerheid en betekenis navolgbaar blijven en ze kunnen worden betwist en gecorrigeerd.”

Elk onderdeel van deze definitie verwijst naar iets wat hierboven aan de orde kwam:

• applicatiefunctionaliteit – we beperken ons tot de semantische laag en de applicatielaag (zie Waarover gaat dit ontwerp (niet)?);
• afgebakend domein – een bounded context;
• primaire en afgeleide beweringen – het onderscheid tussen performatieve handelingen en afgeleide representaties, en de twee gezichten van de januskop;
• herkomst, tijd, zekerheid en betekenis – de betrouwbaarheidsaspecten die epistemische nederigheid mogelijk maken;
• betwisten en corrigeren – ondersteuning van de crappy flow.

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 hoofdstuk Van bestaand naar betrouwbaar register gaat aan de onderdelen vooraf. Het beschrijft het handelingspatroon van inwinnen, verwerken, registreren en beschikbaar stellen, en laat per activiteit zien welke veranderingen een betrouwbaar register vraagt ten opzichte van een register zoals dat nu vaak is ingericht.

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 beschrijft het hoofdstuk Beweringen: wat een bewering is, waarover die gaat, hoe die in herkomst en tijd is geplaatst, en of die een toestand of een gebeuren beschrijft.

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 – systeemtijd, werkingstijd en domeintijd, 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.

Beweringen

Een register bevat beweringen, in twee lagen: primaire beweringen gevolgen en daarvan afgeleide beweringen projectie-elementen. Hoe elk van beide ontstaat, beschrijven de hoofdstukken Gevolgen en Projecties. Dit hoofdstuk beschrijft wat alle beweringen gemeen hebben. Het eerste deel laat zien waarom gegevens samen één bewering vormen; het tweede onderscheidt beweringen over toestanden van beweringen over gebeurens.

Wat beweringen bindt

Registerinhoud is opgebouwd uit gegevens. Dit zijn de kleinste betekenisdragende eenheden data die je binnen het register aantreft. We zijn gewend om over die gegevens te denken in relatie tot dingen: personen, gebouwen, huwelijken, voertuigen. In het registerontwerp heten die entiteiten. Het register houdt die entiteiten zelf echter niet bij – in plaats daarvan omvat het beweringen over entiteiten. Registergegevens zijn altijd onderdeel van zo’n bewering.

Een bewering is geen container waaraan achteraf wat contextuele data worden gehangen. Het is andersom: gegevens vormen samen een bewering juist doordat ze hun context delen, of meer precies: alle gegevens binnen een bewering delen hun herkomst en datering en kennen een juistheid die als geheel staat of valt.

Een gedeelde herkomst betekent één verantwoording: dezelfde bron, vastgelegd onder dezelfde verantwoordelijkheid, met dezelfde legitimering en volgens dezelfde werkwijze. Wat dit precies betekent, wordt bij het betrouwbaarheidsaspect Herkomst beschreven.

Een gedeelde datering betekent één werkingstijd in het domein en één systeemtijd op de tijdlijn van het systeem. Binnen het betrouwbaarheidsaspect Tijd worden de soorten tijd diepgaander uitgewerkt.

Een derde eis aan gegevens binnen één bewering is dat hun juistheid als geheel staat of valt. Het register werkt immers met beweringen als eenheid, niet met losse gegevens: het legt beweringen vast, leidt ze af en verstrekt ze, en het onderschrijft, betwijfelt of onttrekt ze. Een bewering omvat daarom wat als geheel juist of onjuist kan zijn: niet minder, want een huisnummer zonder straat valt niet op juistheid te beoordelen, en niet meer, want we willen voorkomen dat een correctie leidt tot het onnodig onttrekken van juiste gegevens. Waar in concrete gevallen precies de grens ligt, is een keuze die bij het ontwerp van de beweringssoort gemaakt moet worden, waarbij soms ook technische beperkingen een rol spelen.

Typen beweringen

Beweringen kunnen niet alleen in lagen worden geordend, maar ook typologisch, naar wat een bewering beschrijft. We onderscheiden twee typen, die domeinonafhankelijk zijn: iedere bounded context kent dezelfde.

Een toestandsbewering beschrijft een toestand: een “geheel van eigenschappen dat iets op een bepaald moment heeft”. Zo’n bewering is op ieder moment binnen de geldigheid compleet en betekenisvol.

Een gebeurenbewering beschrijft een gebeuren: “iets dat zich in de tijd voltrekt”. Zo’n bewering is alleen compleet en betekenisvol als alle momenten van de voltrekking samen worden beschouwd.

De toestanden en gebeurens die beweringen beschrijven, kunnen we zelf ook in typen uiteenrafelen.

Andere perspectieven op toestanden en gebeurens

Continuant en occurrent. De formele ontologie kent het onderscheid tussen toestand en gebeuren als continuant (ook endurant) tegenover occurrent (ook perdurant). Een continuant is op ieder moment van zijn bestaan geheel aanwezig; een occurrent ontvouwt zich in de tijd en is op een moment maar voor een deel aanwezig. De begrippen gaan terug op W.E. Johnson (1921-1924) en vonden via onder meer de Basic Formal Ontology hun weg naar de informatica. Of een occurrent ook op één moment kan plaatsvinden, is omstreden: Allen betoogt dat voltrekking bij nadere beschouwing altijd duur heeft, Galton dat ook momenten nodig zijn. Bij onze definitie van gebeurtenis (“gebeuren dat zich op één moment voltrekt”) volgen wij Galton.

Telisch en atelisch. De taalkunde (Vendler, 1957) en de temporele databaseliteratuur kijken naar wat er met een uitspraak gebeurt als je de periode waarover die gaat, opknipt of samenvoegt. Een atelische uitspraak blijft dan waar: wie in maart en april op adres A woonde, woonde er ook in april; en wie er in maart woonde en in april, woonde er in maart en april. Een telische uitspraak blijft niet waar: een woning die in maart en april is gebouwd, was eind maart nog niet (af)gebouwd, en wie in maart een woning bouwt en in april nog een, heeft niet in maart en april één woning gebouwd. Volgens Terenziani en Snodgrass (2004) interpreteren temporele databases elke periode impliciet atelisch, waardoor aansluitende trajecten samensmelten en lopende trajecten onterecht al voltooid lijken.

Zet je de twee begrippenparen tegen elkaar af, dan ontstaan vier kwadranten. Volgens registerontwerpterminologie passen in drie daarvan toestandsbeweringen, en een gebeurenbewering in één.

	Atelisch	Telisch
Continuant	‘P woont op adres A’. Register: toestand.	‘De woning wordt gebouwd’. Register: toestand (‘in aanbouw’); het doel, een afgebouwde woning, valt weg.
Occurrent	‘Er werd aan de woning gebouwd’. Register: toestand (‘was in aanbouw’).	‘De woning is gebouwd van 1 maart tot 15 november’. Register: gebeuren (traject).

In de tabel wordt geen gebeurtenis genoemd. Een gebeuren zonder duur, zoals ‘de woning is op 15 november opgeleverd’, is noch telisch noch atelisch: zonder periode zijn er geen deelperiodes of aansluitende periodes om iets over te zeggen. De literatuur noemt zo’n gebeuren punctueel. Een bewering daarover beschrijft in het register een gebeurtenis.

Omzetting. Veel dingen laten zich op meerdere manieren beschrijven. Dat betekent dat omzetting van de ene vorm naar de andere mogelijk is: van telisch naar atelisch, van atelisch naar telisch, of van een gebeurtenis naar de toestand die erop volgt. De taalkunde noemt al die omzettingen coercion (Moens en Steedman, 1988). Elke omzetting levert een andere uitspraak op, en in het register dus een andere bewering, waarbij soms informatie verloren gaat:

Omzetting	Voorbeeld	Resultaat
gebeuren naar toestand, in de lopende vorm	‘de aanvraag is behandeld van 1 maart tot 15 april’ wordt ‘de aanvraag was in behandeling’	Verlies: of de behandeling is voltooid of afgebroken, en hoeveel behandelingen het waren.
gebeuren naar toestand, als resultaat	‘verhuisd naar A op 1 mei’ wordt ‘woont op A vanaf 1 mei’	Verlies: het verloop van het gebeuren.
toestand naar gebeuren, door begrenzing	‘de aanvraag is in behandeling vanaf 1 maart’ en ‘op 15 april is een besluit genomen’ worden samen ‘de aanvraag is behandeld van 1 maart tot 15 april’	Uit twee beweringen ontstaat één rijkere bewering, die ook de begrenzing van de behandeling omvat: wanneer die begon en dat die werd voltooid.

De omzetting van gebeuren naar toestand is precies wat een toestandsprojectie doet. Het verlies daarbij is aanvaardbaar, omdat het gevolgenjournaal bewaart wat de omzetting weglaat.

Gebeurens: gebeurtenis en traject

Er zijn twee typen gebeuren, die verschillen in duur:

• Een gebeurtenis voltrekt zich op één moment en heeft geen duur.
• Een traject heeft wel duur: het voltrekt zich over een aaneengesloten periode en eindigt met een voltooiing. Een traject kan daardoor ook lopend zijn, en kan in veel gevallen worden opgedeeld in fases (of stages).

Hoe een gebeuren te bevragen is, beschrijft Voltrekking in het hoofdstuk Tijd.

Toestanden: eenmalig en herlevend

Er zijn twee typen toestand: de ene kan na een onderbreking niet onder dezelfde identiteit opnieuw gaan gelden, de andere wel.

• Een eenmalige toestand kan gedurende één aaneengesloten periode gelden. Een mens kent onder één identiteit één geldigheidsperiode.
• Een herlevende toestand kan onder dezelfde identiteit gedurende meerdere, door een onderbreking gescheiden periodes gelden. Het opnieuw gaan gelden heet ook wel herleven. Wie terugverhuist naar een eerder adres, laat dat adres niet herleven: de nieuwe bewoning is een nieuwe toestand, en geen voortzetting van de oude.

Hoe een toestand te bevragen is, wat herleven voor de geldigheid betekent, en hoe het met een andere modelleringskeuze te vermijden is, beschrijft Geldigheid in het hoofdstuk Tijd.

Overzichtstabel

Daarnaast heeft elke bewering een systeemtijd. Beweringen zonder werkingstijd, zoals systeemevents, vallen buiten deze typen.

Van bestaand naar betrouwbaar register: kern van de verandering

De dienstverlenings- en uitvoeringsprocessen van de overheid zijn heel divers. Maar wie door de oogharen kijkt naar processen die leiden tot het opnemen van gegevens in een register, ziet steeds dezelfde handelingspatroon terug: informatie wordt ingewonnen, verwerkt, geregistreerd, beschikbaar gesteld en eventueel opnieuw ingewonnen. Die structuur gebruiken we om te laten zien welke veranderingen een betrouwbaar register ten opzichte van de huidige situatie met zich meebrengt.

Een gemeenschappelijk handelingspatroon

Om deze veranderingen te kunnen duiden, moeten we eerst de binnen het handelingspatroon voorkomende activiteiten nader beschrijven.

Inwinnen is het gericht verzamelen van informatie. Inwinnen begint met een aanleiding van buiten of binnen de organisatie, zoals een aanvraag of een melding. Daarna wordt verzameld wat nodig is om die aanleiding te kunnen beoordelen.

Verwerken is het beoordelen van ingewonnen informatie en bepalen wat daaruit volgt. Daarbij wordt de ingewonnen informatie gewogen tegen wat al bekend is en tegen beleid, normen en wetten.

Registreren is het vastleggen van informatie die tijdens verwerking ontstaat, als basis voor vervolghandelingen. Dit is bijvoorbeeld een (representatie van) een recht, een besluit of een vastgestelde situatie.

Beschikbaar stellen is het toegankelijk maken van geregistreerde informatie voor anderen. Wie die anderen zijn en in welke vorm de informatie nodig is, verschilt: een besluit voor een aanvrager, een notificatie voor een ketenpartner, een antwoord op een bevraging.

Het handelingspatroon is een kringloop. Wat de ene organisatie beschikbaar stelt, is voor een andere organisatie aanleiding om in te winnen, of voor dezelfde organisatie bij een volgende taak. Zo ontstaan ketens van overheidshandelen.

Van bestaand naar betrouwbaar register

We starten bij een register zoals dat nu vaak is ingericht. Daarna laten we voor de activiteiten verwerken, registreren en beschikbaar stellen zien welke verandering een betrouwbaar register met zich meebrengt. Inwinnen ligt in alle gevallen buiten het register en wordt (hier) daarom niet besproken.

Hoe een bestaand register naar een betrouwbaar register kan groeien, beschrijven we in [nog op te nemen].

Elke figuur toont de vier activiteiten en de grens van het register. De figuren tonen qua elementen alleen de hoofdlijn: welke dataobjecten worden gecreëerd, gelezen en welke (applicatie)functies daarvoor verantwoordelijk zijn. Wat daaronder ligt beschrijven we verderop in detail in de hoofdstukken over registerontwerp.

Het bestaande register

Inwinnen en het behandelen van een externe bevinding, bijvoorbeeld de ontvangst van een verzoek en behandeling daarvan in een zaaksysteem, liggen buiten het register. Wat het register naar aanleiding van de zaakbehandeling wel bereikt zijn mutaties: opdrachten om vastleggingen toe te voegen, te wijzigen of te verwijderen, gesteld in termen van de opslagstructuur.

Die structuur is terug te zien in het CRUD-karakter van veel API’s, die het mogelijk maken create, read, update en delete-handelingen op tabelregels uit te voeren. Een mutatie met zo’n API beschrijft wel welke waarden veranderen, maar niet welke handeling binnen de bounded context daartoe aanleiding gaf. Die kennis zit in de systemen die het register aanroepen.

Een mutatie markeert de grens tussen verwerken buiten en binnen het register. De functie Muteren voert die opdracht uit, en het resultaat is een vastlegging: een door het register opgeslagen samenhangende verzameling waarden. Verstrekkingen komen rechtstreeks uit die vastleggingen. Het register omvat zo het registreren, en van het verwerken en het beschikbaar stellen het deel tussen de mutatie en de verstrekking. De verstrekking zelf verlaat het register.

Verwerken en registeren: een commando drukt een handeling uit

In een betrouwbaar register bereikt het resultaat van de verwerking het register als commando. Een commando drukt een handeling in het domein uit, zoals ‘registreer een geboorte’ of ‘corrigeer een adres’, in de gemeenschappelijke taal van de bounded context. Het commando draagt daarmee de bedoeling van wie het aanbiedt.

Die bedoeling blijft in het register behouden. De functie Optekenen toetst het commando en legt het resultaat vast als bewering. Waar een vastlegging alleen waarden bevat, heeft een bewering (tenminste) ook een herkomst en een datering. Daardoor is na te gaan wat er vóór registratie van een bewering in de bounded context gebeurde, en wanneer en waarom.

Registreren en beschikbaar stellen: primaire en afgeleide beweringen

Een commando maakt zichtbaar welke aanleiding er was om iets te doen, maar vertelt niet hoe het register die heeft verwerkt. Bij het optekenen wordt het commando getoetst aan informatie die het register al bevat en om te bepalen wat als resultaat daarvan binnen de bounded context moet veranderen. Om te begrijpen waarom informatie in het register staat, zijn aanleiding en de resultaat allebei nodig.

Een betrouwbaar register legt het resultaat van de verwerking daarom vast in zelfstandige primaire beweringen. Ook als die uitkomst weinig van het commando lijkt te verschillen, is de primaire bewering betekenisvol: die bewijst dat het commando is aanvaard, waardoor een administratieve situatie tot stand kwam, of veranderde. Primaire beweringen worden bijgeschreven in een journaal, waarin niets wordt gewijzigd.

Voor gebruik door afnemers zijn primaire beweringen minder geschikt. Zij zijn meestal niet geïnteresseerd in wat veranderde, maar hoe iets op een bepaald moment was - dus een toestand, opgebouwd uit een verzameling gegevens die bij hun eigen taken past. Daarom leidt de functie Projecteren uit het journaal afgeleide beweringen af, aansluitend bij de informatiebehoeften van specifieke (groepen van) afnemers. Bijhouden en beschikbaar stellen krijgen zo elk een eigen structuur, volgens het Command Query Responsibility Segregation(CQRS)-patroon.

Beschikbaar stellen: betrouwbare verstrekkingen

Op basis van primaire en afgeleide beweringen is de handelingsketen binnen het register terug te volgen: van een afgeleide bewering naar de primaire beweringen waarop die berust, en van daar naar de commando’s en externe bevindingen waaruit die voortkwamen. Bij verstrekking houdt dat spoor op.

Een afnemer handelt op basis van wat het register verstrekte. Wordt dat handelen later betwist, dan moet de afnemer niet alleen kunnen laten zien welke informatie voor het eigen handelen de basis vormde, maar ook dat die informatie werkelijk door het register verstrekt werd. In een betrouwbaar register kunnen daarom ook verstrekkingen binnen de registergrenzen geplaatst worden. Zo wordt geïllustreerd dat het register kan bevestigen dat het een verstrekking met een bepaalde inhoud heeft gedaan, en die zo nodig opnieuw kan leveren.

Relatie met onderdelen van het registerontwerp

De onderdelen van het registerontwerp sluiten aan bij de activiteiten van het handelingspatroon:

• Bounded contextmodel beschrijft wat het register binnen zijn context kan beweren. Dat geldt voor alle activiteiten.
• Commando’s gaat over verwerken: hoe een externe bevinding een commando wordt.
• Gevolgen gaat over registreren: hoe het register primaire beweringen optekent in het journaal.
• Projecties en Verstrekken gaan over beschikbaar stellen: hoe het register afgeleide beweringen afleidt en verstrekt.
• Betwisten gaat over wat er gebeurt als een verstrekt gegeven vermoedelijk onjuist is. Dat loopt van beschikbaar stellen terug naar inwinnen: de uitkomst van het onderzoek naar een terugmelding komt als externe bevinding weer binnen.
• Vernietigen gaat over registreren en beschikbaar stellen: hoe het register beweringen blijvend ontoegankelijk maakt als die niet langer beschikbaar mogen zijn.

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 het vertrekpunt.

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 het vertrekpunt 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 beschrijven iets dat op één moment gebeurt, zonder duur. Een gevolg is daarom altijd een gebeurenbewering die een gebeurtenis beschrijft. Geboortes, verhuizingen of huwelijken markeren geen toestand, maar beschrijven de verandering die van de ene toestand leidt naar de volgende. Toestanden en trajecten komen in het gevolgenjournaal dus alleen voor via de gebeurtenissen die ze begrenzen, zoals een verhuizing, het begin van een procedure of een voltooiing. 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 het achtergrondartikel Een register dat werkt als de overheid. 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 Wat beweringen bindt). 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. De identiteit die het register verleent, is functioneel vergelijkbaar met het anchor in Anchor modeling en de hub in Data vault.

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.

Of de adreswijziging een zelfstandig gevolg is, beslist het domein: ze komt ook zonder adoptie voor. Dat het toegangsprobleem daarmee kleiner wordt, is een bijeffect en geen reden om een gevolg op te splitsen. Wat een afnemer binnen één gevolg wel of niet mag zien, begrenzen projecties.

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.

Toesnijden betekent ook begrenzen. Niet elke afnemer mag alles inzien wat een gevolg vastlegt, ook als een deel ervan voor die afnemer wel relevant is. Een projectie kan daarom uit één gevolg alleen opnemen wat een afnemer nodig heeft en mag zien. Of het domein zo’n deel ook als zelfstandig gevolg onderscheidt, is een andere vraag, die het domein zelf beantwoordt, los van afnemerbehoeften (zie het adoptievoorbeeld bij Gevolgen).

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: toestand of gebeuren?

Een projectie-element is een afgeleide bewering, en kan elk van de vier typen toestand of gebeuren beschrijven. Uit gevolgen, die altijd een gebeurtenis beschrijven, zijn toestandsbeweringen af te leiden: gebeurtenissen begrenzen toestanden, een lopend traject levert een toestand van het betrokken ding, en op een voltooiing volgt een nieuwe toestand. Ook gebeurtenissen en trajecten zijn eruit af te leiden. Het type van een projectie-element, en daarmee de vorm van de werkingstijd, wordt dus in de projectie toegekend en niet in het journaal.

Projectiedoel bepaalt perspectief

Of een projectie-element een entiteit als toestand of als gebeuren beschrijft, staat los van de manier waarop de gevolgen zijn vastgelegd. Het perspectief wordt niet bepaald door het vastleggingsperspectief van het bronmateriaal, maar door de manier waarop we naar dat bronmateriaal willen kijken, en in het verlengde daarvan door de informatiebehoefte die de projectie invult. Uit dezelfde gevolgen kunnen voor de ene afnemer toestandsprojecties worden geproduceerd, en voor de andere gebeurenprojecties.

Afleiden is interpreteren

Een projectie-element is geen kopie van een gevolg; er zit altijd bewerking tussen. Een toestandsbewering ontstaat door gebeurtenissen te interpreteren: wat geldt op een moment, volgt uit wat er tot dan toe is gebeurd, en ook uit wat er nog niet is gebeurd.

Ook een gebeurenprojectie neemt gevolgen niet één op één over, al beschrijven die zelf gebeurtenissen. Het verschil zit in het perspectief. Het journaal beschrijft vanuit bijhoudingsperspectief zo nauwkeurig mogelijk wat er binnen een bounded context gebeurt, rond het begrip dat bij de bijhouding centraal staat. Een projectie kan het gebeurde opnieuw ordenen rond een ander begrip, waar een afnemer naar kijkt. Een gevolg ‘bezwaar ontvangen’ wordt zo, in de levensloop van een vergunning, ‘vergunning door bezwaar betwist’. Een gevolg dat vóór het begin van die levensloop ligt, zoals het ontvangen van de aanvraag, kan in zo’n projectie ontbreken.

Welke werkingstijd en systeemtijd voor afnemers relevant zijn, verschilt per bewering; zie Beweringen naar werkingstijd en systeemtijd.

Toestandsprojecties en gebeurenprojecties

Het registermodel vertaalt het onderscheid tussen toestand en gebeuren naar twee hoofdvormen van projecties. In een toestandsprojectie beschrijven de projectie-elementen toestanden; in een gebeurenprojectie beschrijven de projectie-elementen gebeurens. 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 werkingstijd 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 werkingstijd: geldigheidstijd voor toestanden en voltrekkingstijd voor gebeurens, elk in de vorm die bij het type van de bewering hoort. 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 werkingstijd zegt. Wanneer een toestand ophoudt, blijkt uit een volgend element in de reeks. Het einde in werkingstijd 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.

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, werkingstijd zonder systeemtijd, of werkingstijd 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.

Implementeringsvormen zijn geen indeling van beweringen: ze gaan over de bouwvorm van de projectie, niet over wat de projectie-elementen beschrijven (zie Beweringen naar werkingstijd en systeemtijd).

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 werkingstijd 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 Afleiden is interpreteren beschrijft.

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

Beweringen naar werkingstijd en systeemtijd

Werkingstijd en systeemtijd zijn niet voor elke bewering even relevant. Zet je de vorm van de werkingstijd (geldigheid, voltrekking of geen) af tegen de vraag of systeemtijd voor afnemers ertoe doet, dan ontstaan acht combinaties. De bovenste rij bevat de vier typen beweringen; het herlevende en het niet-herlevende ding in de afbeelding zijn de herlevende en de eenmalige toestand. Daarnaast zijn er vier bijzondere gevallen, die hieronder kort worden getypeerd.

De indeling gaat over wat in het normale verkeer aan afnemers wordt 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.

Systeemevent

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

Specificatiegegeven

Een toestandsbewering over een entiteit met beperkte veranderlijkheid, die de kaders beschrijft waarbinnen andere, meer volatiele gegevens zich bewegen. De systeemtijd daarvan hoeft afnemers daarom doorgaans niet te worden getoond. Voorbeelden: een zaaktype, een producten- en dienstencatalogus, een classificatie.

Automatische observatie

Een gebeurenbewering die zonder menselijke tussenkomst wordt vastgelegd op het moment van plaatsvinden, waardoor systeemtijd en voltrekkingsmoment per definitie samenvallen. Voorbeelden: een sensormeting, een GPS-track, een automatische transactie.

Vaste waarde

Een toestandsbewering zonder werkingstijd. De waarde staat onveranderlijk vast en kent voor afnemers geen geldigheids- of registratiehistorie. Voorbeelden: een landcode, een geslachtsaanduiding, een natuurconstante.

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 Januskop als metafoor 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 werkingstijd 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 Vertrekpunt: 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 beschouwen we in drie lagen. Werkingstijd duidt aan wanneer de toestand die een bewering beschrijft geacht wordt te gelden, of het gebeuren dat die beschrijft zich geacht wordt te voltrekken; voor toestanden heeft die de vorm van geldigheid, voor gebeurens de vorm van voltrekking. Systeemtijd duidt aan wanneer een systeem de bewering heeft geproduceerd. Domeintijd is geen kenmerk van de bewering, maar een tijdsgegeven in de inhoud ervan. 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 – systeemtijd, werkingstijd en domeintijd, 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.

TODO: bron, legitimering, verantwoordelijke, werkwijze aan de hand van PROV-O-model beschrijven en laten zien hoe die binnen de grenzen van dat model te representeren.

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.

TODO: ‘wie voor de productie van een bewering instaat’ -> vervangen door een definitie die duidelijker maakt dat we degene bedoelen die aanspreekbaar is op de inhoud van een bewering.

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 Een register dat werkt als de overheid 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.

Nieuwe bewering of kopie?

Niet elke overname van een bewering is een nieuwe schakel in de keten. Dat hangt af van aanspreekbaarheid. Een systeem dat op een bewering aanspreekbaar is, onder een eigen verantwoordelijke en volgens een eigen werkwijze, brengt een nieuwe bewering voort, met een eigen herkomst. Dat geldt ook als die werkwijze alleen uit een toets bestaat en de inhoud ongewijzigd blijft. Een replica, cache, back-up of transport brengt niets voort: de bewering blijft dezelfde, met de oorspronkelijke herkomst.

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

In registers komen we veel soorten tijd tegen: passeerdata, looptijden, ontvangstmomenten, bouwjaren. Maar als we het hebben over tijd in registers noemen we meestal slechts twee tijdsdimensies: een aan het domein ontleende geldigheidstijd en een door het systeem toegekende systeemtijd.

Deze dichotomie is te overbruggen door onderscheid te maken tussen tijd ín de bewering en tijd ván de bewering.

Tijd ín de bewering noemen we domeintijd. Binnen een bounded context kunnen allerlei soorten domeintijd voorkomen: een passeerdatum, een bouwjaar of een ontvangstmoment. Net als een naam of een adres beschouwen we domeintijd als gegeven.

Tijd ván de bewering valt uiteen in werkingstijd en systeemtijd. Deze plaatsen de bewering zelf in de tijd, en vormen zo de datering van een bewering.

Domeintijd, werkingstijd en systeemtijd

Domeintijd is een gegeven in de inhoud van een bewering, dat een moment of periode uit het domein vastlegt: een bouwjaar van een pand, peildatum voor de waarde van een WOZ-object, of de periode dat iemand voor een opleiding is ingeschreven. Betekenis, vorm en waarde van zulke tijdsgegevens worden bepaald door het vastleggende domein en beschreven in het bounded contextmodel en daarbinnen voorkomende gegevenssoorten. Daardoor kan een bewering van nul tot een oneindig aantal domeintijdstijdsgegevens bevatten. Registers verwerken tijdsgegevens niet anders dan ‘gewone’ gegevens. Dit betekent dat inwerkingsregels nodig zijn om domeintijdsgegevens geautomatiseerd te kunnen verwerken.

Domeintijd definiëren we als “gegeven dat een moment of periode aanduidt, in de vorm die in een gegevenssoort is beschreven”.

De waarde van werkingstijd wordt weliswaar ontleend aan domeintijd, maar functie en karakter verschillen wezenlijk. Werkingstijd is geen gegeven in de inhoud, maar een tijdskenmerk van de bewering zelf. Dit kenmerk geeft, in ieder domein op dezelfde manier, aan wanneer de toestand geldt of het gebeuren plaatsvindt dat de bewering beschrijft, en dateert de bewering zo op de tijdlijn van het domein. Waarop de werkingstijd betrekking heeft, hangt af van wat de bewering zegt, ofwel het predicaat daarvan: bij ‘p1 staat ingeschreven op a1’ is de werkingstijd de periode waarin de inschrijving geldt, bij ‘p1 woont feitelijk op a1’ de periode van feitelijk wonen, bij ‘p1 is verhuisd’ het moment waarop de verhuizing plaatsvond. Deze voorbeelden laten ook zien dat de vorm van de werkingstijd afhangt van wat een bewering beschrijft: een moment bij een gebeurtenis, een periode bij een traject, en bij een toestand één of meer periodes. Maar ook als er sprake is van meerdere periodes, liggen die allemaal op dezelfde tijdlijn en vormen samen één werkingstijd; meer dan één werkingstijd kan een bewering niet hebben. Omdat betekenis en vorm in elk domein gelijk zijn, kan het register zonder domeinkennis met werkingstijd werken, bijvoorbeeld om te selecteren wat op een peilmoment gold of om aansluitende periodes samen te voegen.

Werkingstijd definiëren we als “tijdskenmerk dat aanduidt wanneer de toestand die een bewering beschrijft geacht wordt te gelden, dan wel het gebeuren dat de bewering beschrijft geacht wordt zich te voltrekken”.

Net als werkingstijd is systeemtijd een tijdskenmerk van de bewering zelf. Dit kenmerk dateert de bewering echter niet in het domein, maar op de tijdlijn van het systeem dat de bewering voortbrengt. Systeemtijd is altijd een moment, met steeds dezelfde betekenis, ongeacht wat de bewering beschrijft of in welk register die wordt bijgehouden. Net als bij werkingstijd kan het register daarom zonder domeinkennis met systeemtijd werken, bijvoorbeeld om beweringen op volgorde te zetten, te selecteren wat op een peilmoment werd onderschreven of te bepalen welke bewering een eerdere opvolgt. Iedere bewering heeft precies één systeemtijd. Het systeem bepaalt de waarde, en ook welk technisch moment als voortbrengen geldt (zie Systeemtijd). Systeemtijd kan de waarde leveren voor een domeintijdsgegeven. Neem de beweringssoort ‘persoon is per inschrijvingsmoment ingeschreven op adres’: het domein bepaalt dat het inschrijvingsmoment ertoe doet, maar kan ervoor kiezen de waarde daarvan bij concrete beweringen van deze soort aan de systeemtijd te ontlenen.

Systeemtijd definiëren we als “tijdskenmerk dat aanduidt wanneer een bewering door een systeem is voortgebracht”.

Onderstaande tabel toont overeenkomsten en verschillen tussen de drie soorten tijd:

Domeintijd is beweringsinhoud en wordt door het register behandeld als een ‘gewoon’ gegeven dat onderdeel is van het bounded contextmodel. Het betrouwbaarheidsaspect tijd is met name gericht op datering. De rest van dit hoofdstuk werkt daarom werkingstijd en systeemtijd verder uit, en volgt daarna de tijd door het register heen.

Vormen van werkingstijd

Werkingstijd kent twee vormen, ieder gekoppeld aan een type bewering: geldigheid bij een bewering over een toestand en voltrekking bij een bewering over een gebeuren. Dit onderscheid is gebaseerd op de temporele vraag die je over ieder van deze beweringstypes kunt stellen. Omdat een toestand op ieder moment binnen de periode ‘geldt’, kan je daarover een geldigheidsvraag stellen. Een gebeuren voltrekt zich daarentegen van begin tot voltooiing: bij een traject liggen die uit elkaar en is het gebeuren pas voltooid aan het einde van de periode die het traject beslaat, bij een gebeurtenis vallen ze samen op één moment. Daarover stel je een voltrekkingsvraag: is het binnen een periode begonnen, voltooid of gebeurd?

Geldigheid

Geldigheid is de werkingstijd van een toestand: de periode waarin de toestand die een bewering beschrijft, geacht wordt te gelden. Binnen die periode geldt de toestand op elk moment. Een toestand is daarom op elk moment te bevragen (geldigOp, geldigVanaf, geldigTot), en twee aansluitende periodes van dezelfde toestand vormen samen één periode.

Geldigheid wordt uitgedrukt in een geldigheidsperiode, met een begin en een mogelijk nog open einde. Een open einde betekent dat de toestand voor zover bekend nog geldt, niet dat die voor altijd geldt. Is het einde van de geldigheid op voorhand bepaald, zoals bij een vergunning met een vastgestelde looptijd, dan is de periode niet open, maar heeft die een einde in de toekomst, dat al vanaf het begin deel uitmaakt van de werkingstijd (zie Werkingstijd in de toekomst).

Of er één of meer geldigheidsperiodes zijn, hangt af van het type toestand dat een bewering beschrijft: eenmalig of herlevend. Een eenmalige toestand heeft één geldigheidsperiode. Een herlevende toestand kan er meerdere hebben, gescheiden door een onderbreking. Een vergunning die wordt geschorst en na afloop van de schorsing weer in werking is, herleeft: het is dezelfde vergunning, die een tijd niet gold maar desondanks één werkingstijd kent, die meer dan één periode omvat. Voor afnemers is het belangrijk te weten of een toestand kan herleven, want dan moet die met meerdere geldigheidsperiodes kunnen omgaan.

Of een toestand in het register daadwerkelijk moet kunnen herleven, is een modelleringskeuze. Zo kan herleven van de vergunning worden voorkomen door de schorsingsperiode als domeintijd in de inhoud vast te leggen, en het bijbehorende gedrag te beschrijven in inwerkingsregels.

Misverstanden over geldigheid

In de praktijk wordt ‘geldig’ ook in andere betekenissen gebruikt, en dat leidt tot verwarring.

Geldig is niet hetzelfde als ‘waar’ of ‘juist’: literatuur spreekt in relatie tot geldigheid wel “van de tijd waarop een feit waar is”, maar een register kan niet meer zeggen dan dat een toestand in een periode geacht wordt te gelden. Het onderwerp juistheid wordt verder besproken bij betrouwbaarheidsaspect zekerheid.

Geldig is niet hetzelfde als actueel: ook een toestand die vroeger gold, heeft een geldigheid.

Geldig is niet (altijd) hetzelfde als ‘in werking’: dat is het alleen als het predicaat van de bewering zegt dat iets in werking is. Bij ‘besluit B is in werking’ is de geldigheid de periode van werking, bij ‘besluit B is onherroepelijk’ een (waarschijnlijk kortere) andere periode.

Geldig is niet (altijd) hetzelfde als ‘bestaand’: dat is het alleen als het predicaat van de bewering iets zegt over het bestaan van een entiteit. Bij ‘p1 leeft’ is de geldigheid de periode dat p1 bestaat, bij ‘p1 woont op a1’ de periode van bewoning, en die zegt niets over hoe lang p1 of a1 bestaan. Temporele conceptuele modellen geven een entiteit vaak een levensduur (lifespan of existence time): de periode waarin die bestaat, waarbinnen alle kenmerken van de entiteit moeten vallen. Deze zienswijze leidt in de praktijk tot problemen, bijvoorbeeld als na het overlijden van een persoon geen nieuw adres meer kan worden vastgelegd, zoals een correspondentieadres voor de afwikkeling van de nalatenschap, terwijl nabestaanden daar wel bij gebaat zouden zijn. Omdat wij stellen dat een register geen entiteiten bijhoudt, maar beweringen erover, is zo’n levensduur bij ons geen kenmerk van de entiteit, maar de werkingstijd van één bepaalde toestandsbewering, zoals ‘p1 leeft’. Of een adres daarbinnen moet vallen, is dan een regel die het register bij het optekenen kan toetsen, maar niet hoeft.

Deze verwarring wordt in de hand gewerkt doordat het predicaat van een toestandsbewering vaak niet zichtbaar is. Een registratie van panden toont meestal één rij per pand: ‘pand q1, geldig vanaf …’. Welke datum daar staat, hangt af van het gebeuren waarmee de geldigheid begint. Is dat het verlenen van de omgevingsvergunning op 3 maart 2019, dan betekent geldig ‘vergund’; is dat de gereedmelding van de bouw op 12 oktober 2021, dan ‘gereed’; is dat de ingebruikname op 5 januari 2022, dan ‘in gebruik’. Omdat de rij het pand vertegenwoordigt, ligt het voor de hand de geldigheid te lezen als het bestaan van het pand, maar die kan net zo goed betekenen dat het pand vergund, gereed of in gebruik is.

Hierboven staan drie verschillende beweringen, elk met een eigen werkingstijd: een juridisch, een administratief en een feitelijk perspectief op hetzelfde pand, die er niet altijd allemaal hoeven te zijn. Wie in een bewering over het gebruik toch wil vastleggen wanneer het pand vergund werd, neemt die datum op als gegeven: dan is het domeintijd in de inhoud, geen tweede werkingstijd (zie Van primaire bewering naar afgeleide bewering).

Door de beweringssoort een naam te geven die zegt wát er geldt, kunnen we duidelijker zijn over de betekenis van geldigheid bij toestandsbeweringen: ‘staat ingeschreven op’ of ‘woont feitelijk op’, in plaats van ‘adres’. In een implementatie wordt een toestandsbewering echter vaak ‘platgeslagen’ in een tabelstructuur of resourcebeschrijving. De beweringssoort moet dan blijken uit de plek waar de beweringen staan: een tabel of resource per beweringssoort, met een naam die zegt wat er geldt (‘inschrijvingen’, niet ‘adressen’). Staan beweringen van verschillende soorten in één tabel, dan noemt een kolom per rij de beweringssoort, bijvoorbeeld ‘inschrijving’ of ‘feitelijke bewoning’. Hoe die betekenis aan afnemers wordt doorgegeven, beschrijft het hoofdstuk Betekenis.

Voltrekking

Voltrekking is de werkingstijd van een gebeuren: het moment of de periode waarin het gebeuren dat een bewering beschrijft, geacht wordt zich te voltrekken. Welke van de twee het is, hangt af van het type gebeuren. Een gebeurtenis heeft een voltrekkingsmoment, gebeurd op. Een traject heeft een voltrekkingsperiode, van het begin tot een voltooiing die nog niet bereikt hoeft te zijn: zolang die ontbreekt, loopt het traject voor zover bekend nog. Wie vraagt hoe een traject er op een bepaald moment voor stond, krijgt een opsomming van gepasseerde en lopende fases. Een gebeuren bevraag je daarom op voltrekking (gebeurdVanaf, gebeurdTot).

Misverstanden over voltrekking

Voltrekking correspondeert niet (altijd) met het begin van een geldigheid: dit punt heeft te maken met de omzetting van gebeurens naar toestanden. Neem de gebeurtenis ‘p1 is op 1 mei naar a1 verhuisd’, met 1 mei als voltrekkingsmoment. Daaruit zijn twee toestanden af te leiden. ‘p1 woont feitelijk op a1’, bijvoorbeeld voor huurtoeslag, neemt het voltrekkingsmoment als begin van de geldigheid, en geldt dus vanaf 1 mei. ‘p1 staat ingeschreven op a1’ doet dat niet: die gaat in de BRP vanwege beperkende regels pas op 5 mei in. Naast domeinregels bepalen ook modelleringskeuzes of geldigheid wordt afgeleid van de voltrekking of van een domeinmoment uit de inhoud van een gebeurenbewering (zie, voor de afleiding uit primaire beweringen Van primaire bewering naar afgeleide bewering).

Voltrekking is niet hetzelfde als registratie: voltrekking is het door het domein bepaalde moment of de periode waarin iets gebeurt, systeemtijd het moment waarop een systeem de bewering daarover voortbrengt. Een registratiemoment is een moment met een door het domein bepaalde betekenis. Dat moment kan samenvallen met de systeemtijd en daaraan worden ontleend (zie Domeintijd, werkingstijd en systeemtijd). Het kan ook samenvallen met de voltrekking, bij een administratieve formulering: in ‘p1 is op 10 mei ingeschreven op a1’ is de registratie zelf het gebeuren. En het kan een ander moment zijn, zoals het moment waarop een akte is opgemaakt die als bron dient.

Voltrekking kan niet worden bevraagd als ware het geldigheid: een toestandsbewering is waar op elk moment binnen de geldigheid, en is dus op elk moment te bevragen. Een bewering over een traject is alleen waar over de voltrekkingsperiode als geheel. De zinvolle vraag is daarom niet of het traject op een moment gold, maar of het binnen een periode is begonnen, voltooid of geheel verlopen.

Systeemtijd

Systeemtijd is het moment waarop een systeem een bewering voortbrengt. Elke bewering heeft er precies één, en die dateert de bewering op de tijdlijn van dat systeem.

“Het moment waarop een systeem een bewering voortbrengt” is bewust ruim geformuleerd. Technische overwegingen bepalen welke momenten hier gekozen kunnen worden. Zo ligt het moment van daadwerkelijke beschikbaarheid in het register voor de hand, maar dat moment is pas bekend als de bewering is vastgelegd, en dan is het te laat om het nog in de bewering op te nemen. Belangrijkste is dat een systeem één moment kiest, zodat systeemtijden onderling vergelijkbaar zijn, en dat afnemers weten welke betekenis dat moment heeft.

Veel temporele modellen onderscheiden een transactietijdlijn die loopt van invoegen tot (logisch) verwijderen (zie Tijd in andere kaders). Ons registerontwerp werkt anders: een bewering krijgt bij het voortbrengen een systeemtijd, maar geen eindmoment. Een periode ontstaat pas door een onttrekking, een andere bewering met een eigen systeemtijd. Uit die periode valt een vergelijkbare conclusie te trekken: wat het register in een bepaalde periode onderschreef.

Misverstanden over systeemtijd

Een bewering heeft niet meer dan één systeemtijd: elke bewering die een systeem voortbrengt, heeft één eigen systeemtijd, ook als die bewering op een andere is gebaseerd. Moet het moment van een eerdere schakel meereizen in de keten, bijvoorbeeld omdat een landelijke voorziening wil weten wanneer de bewering bij de bronhouder is voortgebracht, dan neemt de nieuwe bewering die waarde op als domeintijd. Een bewering die in een replicatie-, of mirrordatabase, cache of back-up wordt gedupliceerd, beschouwen we als gelijk aan het origineel. Die houdt daarom de oorspronkelijke systeemtijd (zie Nieuwe bewering of kopie?).

Het moment van verstrekken is geen systeemtijd: een verstrekking, zoals een notificatiebericht of een antwoordbericht, is geen bewering maar een drager daarvan. Een afgeleide bewering die pas bij het samenstellen van een verstrekking ontstaat, heeft wel een eigen systeemtijd, maar ook die hoeft niet samen te vallen met het moment van verstrekking.

Granulariteit

Elke tijdsaanduiding heeft een granulariteit: de korrel waarin de tijd wordt uitgedrukt, zoals een dag of een seconde. Dat geldt voor domeintijd, werkingstijd en systeemtijd. Bij domeintijd bepaalt het domein welke granulariteit past, en legt die vast in de gegevenssoort; een werkingstijd neemt de granulariteit over van de domeintijd waaraan die is ontleend. Een bouwjaar heeft als domeintijd de korrel van een jaar. Een geboorte wordt op de dag vastgelegd, een sensormeting op de seconde.

De granulariteit bepaalt of een gebeuren een gebeurtenis of een traject is. Een huwelijksvoltrekking is op de dag één moment, maar op de minuut een plechtigheid met een begin en een einde. Of iets op één moment plaatsvindt, het punt waarover Allen en Galton van mening verschillen (zie het kader in Typen beweringen), hangt in een register dus af van de korrel waarin het wordt vastgelegd.

Ook of twee periodes op elkaar aansluiten, hangt af van de granulariteit. Een geldigheid tot en met 30 april sluit op dagniveau aan op een geldigheid vanaf 1 mei; op het niveau van seconden ligt daar een nacht tussen, tenzij is afgesproken dat het einde van de ene periode het begin van de volgende is. Tijden met een verschillende granulariteit zijn daarom pas te vergelijken na omrekening, en die is niet altijd eenduidig: viel een gebeurtenis ‘op 1 mei’ vóór of na 1 mei om 14:00 uur?

Systeemtijd heeft de granulariteit die het systeem kiest, in de regel fijn genoeg om beweringen op volgorde te zetten.

Tijd door het register heen

Primaire bewering

Een primaire bewering beschrijft een gebeurtenis. De werkingstijd is dus een voltrekkingsmoment, het gebeurd op van de beschreven verandering. De systeemtijd is het moment van vastleggen in het journaal. Daarnaast kan een primaire bewering domeintijd bevatten, zoals een ingangsdatum.

Van primaire bewering naar afgeleide bewering

De projectiespecificatie bepaalt hoe de werkingstijd van een afgeleide bewering tot stand komt:

• door een domeinmoment uit de inhoud als werkingstijd te nemen, zoals een ingangsdatum;
• door het voltrekkingsmoment van een primaire bewering te nemen;
• of door de werkingstijden van meerdere onderliggende primaire beweringen te combineren.

Welke manier een projectie gebruikt, is een ontwerpafweging. Een verhuizing laat zien waarom. Iemand verhuist feitelijk op 1 mei, maar doet pas op 10 mei aangifte. De inschrijving in de BRP mag maximaal vijf dagen terugwerken, en gaat daarom in op 5 mei in plaats van 1 mei. Een projectie van de inschrijving kan het gebeurd op van de verhuizing dus niet als begin van de geldigheid nemen; een projectie van de feitelijke bewoning, bijvoorbeeld voor het toekennen van huurtoeslag, juist wel.

Neemt een projectie altijd het gebeurd op als begin van de geldigheid, dan kan het projecteren zonder domeinkennis. Daar staat tegenover dat elk perspectief een eigen primaire bewering nodig heeft: naast de feitelijke verhuizing een tweede gebeurtenis voor het ingaan van de inschrijving. Een projectie met een nieuw perspectief, waarvoor die primaire beweringen ontbreken, kan dan niet met terugwerkende kracht worden opgebouwd. Een toestand die pas in de toekomst ingaat, kan bovendien pas worden vastgelegd als die ingaat, omdat een gebeurd op nooit na de systeemtijd ligt.

Neemt een projectie het begin van de geldigheid uit domeintijd in de inhoud, dan is één primaire bewering genoeg: de verhuizing op 1 mei, met de ingangsdatum van de inschrijving als domeintijd. De projectie van de inschrijving neemt die ingangsdatum, de projectie van de feitelijke bewoning het gebeurd op, en later kan een projectie worden toegevoegd zolang de benodigde domeintijd in de inhoud staat. Daarvoor is wel domeinkennis nodig: een inwerkingsregel die zegt welke domeintijd de geldigheid begint.

Combineert een afgeleide bewering meerdere gegevens, dan is de werkingstijd de periode waarin al die gegevens samen gelden. Wanneer elk gegeven afzonderlijk inging, gaat daarbij verloren; is dat nodig, dan kan dat moment als domeintijd in de inhoud. Hetzelfde geldt voor een moment uit een ander perspectief.

De keuze tussen feitelijk en administratief formuleren werkt hierop door:

• Bij feitelijke formulering is het gebeurd-op-moment een logisch startpunt voor een geldigheidsperiode.
• Bij administratieve formulering ligt het gebeurd-op-moment dichter bij het moment van registratie, en staat het feitelijke moment als domeintijd in de inhoud.

Werkingstijd en domeintijd in een afgeleide bewering

De werkingstijd van een afgeleide bewering zegt wanneer die combinatie van gegevens geacht wordt te gelden, niet hoe oud de entiteiten of gegevens erin zijn. Data als ‘geregistreerd sinds’ of ‘belanghebbend vanaf’ zijn domeintijd. Een afnemer kan de werkingstijd dus makkelijk verkeerd lezen; de betekenis moet daarom duidelijk uit de afgeleide bewering blijken.

Een afgeleide bewering draagt zo alle drie de lagen: de systeemtijd van de eigen voortbrenging, de werkingstijd die de projectie toekent, en de domeintijd uit de inhoud. Wanneer een toestand eindigt, blijkt uit een volgende bewering in de reeks (zie Projecties opbouwen).

Werkingstijd in de toekomst

Een register legt alleen vast wat al gebeurd is. Het gebeurd-op-moment van een primaire bewering ligt daarom nooit na de systeemtijd, en een uitspraak als ‘P gaat volgende week verhuizen’ kan geen primaire bewering zijn.

Wel kan een register vastleggen dat er nu iets gebeurt dat naar de toekomst verwijst, zoals een aangifte, een besluit of een voornemen. Dat gebeuren is de primaire bewering, met een voltrekkingsmoment van nu; het toekomstige moment staat erin als domeintijd. Een verhuizing kan bijvoorbeeld vanaf vier weken vooraf bij de gemeente worden aangegeven. De primaire bewering is dan ‘P heeft op 3 november aangegeven op 1 december naar A te verhuizen’, met 1 december als domeintijd.

Een afgeleide bewering kan uit die domeintijd een werkingstijd in de toekomst krijgen: ‘P woont op A vanaf 1 december’. Hetzelfde geldt voor een besluit dat op een latere datum in werking treedt, of dat een vastgestelde looptijd heeft: dan ligt niet het begin, maar het einde van de werkingstijd in de toekomst. Een vraag naar de stand op 1 december krijgt dan nu al een antwoord.

Dat antwoord kan nog veranderen. Gaat de verhuizing niet door of verschuift de datum, dan volgt een nieuw gebeuren, zoals een intrekking of een gewijzigde aangifte, en daaruit een nieuwe afgeleide bewering met een latere systeemtijd. Dat is geen correctie: de eerdere aangifte was juist vastgelegd. Dezelfde vraag op dezelfde systeemtijd levert wel steeds hetzelfde antwoord (zie de herhaalbare vraag).

Hoe vast een toekomstige toestand staat, verschilt: een besluit legt die juridisch vast, een voornemen niet. Omdat het onderliggende gebeuren in het journaal staat, blijft herleidbaar waarop de toestand rust. Hoe zeker die is, behandelt het hoofdstuk Zekerheid.

Verstrekking

Een antwoord dat meerdere onderdelen combineert, bijvoorbeeld via een expand-mechanisme, toont al die onderdelen op dezelfde systeemtijd. Anders kan een afnemer een combinatie zien die nooit zo in het register heeft gestaan. Dit is het mechanisme achter de herhaalbare vraag: dezelfde vraag op dezelfde systeemtijd levert hetzelfde antwoord.

Een tijdparameter in een vraag heeft betrekking op de werkingstijd van de geleverde bewering als geheel. Omvat een verstrekking meerdere beweringen, elk met een eigen werkingstijd, dan worden bij elk daarvan eigen tijdparameters geleverd.

Een verstrekking hoeft de systeemtijd van de geleverde beweringen niet te bevatten. Meeleveren is soms ongewenst, omdat een afnemer er bijvoorbeeld een correctie uit kan afleiden. Om de vraag toch herhaalbaar te maken, kan het register een token meegeven dat naar de systeemtijd verwijst.

Verwerkingstijd

Tussen het vastleggen van een primaire bewering en het voortbrengen van een afgeleide bewering zit verwerkingstijd, en daarna duurt het nog even voordat een afnemer de gegevens ziet. 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.

De systeemtijd zelf kan hier ook een rol in spelen. Een register kan als systeemtijd bijvoorbeeld het begin van het vastleggen kiezen, omdat het einde daarvan nog niet bekend is. Stel dat een bewering daardoor als systeemtijd 10:00 uur krijgt, maar pas om 10:05 uur beschikbaar is. Een afnemer die om 10:03 uur vraagt naar de stand van 10:02 uur, ziet die bewering niet. Stelt die afnemer om 10:06 uur dezelfde vraag, dan ziet die de bewering wel, want de systeemtijd ligt vóór 10:02 uur. Dezelfde vraag over hetzelfde moment levert dan een ander antwoord op, en daarmee is de herhaalbare vraag niet meer gegarandeerd.

Een vraag naar de stand op een bepaald moment is daarom pas betrouwbaar als er geen bewering met een eerdere systeemtijd meer onderweg kan zijn. Een register kan dat bereiken door zulke vragen te beperken tot een moment dat ver genoeg in het verleden ligt, of door beweringen na elkaar vast te leggen, zodat de volgorde van de systeemtijden gelijk is aan de volgorde van beschikbaar komen.

Bitemporaliteit

Wie werkingstijd en systeemtijd samen bijhoudt, werkt bitemporeel. Dat kan generiek, omdat beide in elk domein dezelfde betekenis hebben. Domeintijd is geen dimensie, maar inhoud.

Bitemporaliteit houdt twee vragen uit elkaar: 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, en de herhaalbare vraag kan niet zonder zodra correcties met terugwerkende kracht mogelijk zijn.

Zet je de twee tegen elkaar af, dan ontstaat het bekende bitemporele blokkendiagram. Op de ene as staat de werkingstijd, op de andere de tijdlijn van het systeem, waarop een bewering loopt van voortbrenging tot onttrekking. Een toestandsbewering wordt daarin een blok: elk punt in dat vlak betekent dat de toestand gold, en dat het register dat op dat moment onderschreef. Voor gebeurenbeweringen werkt dat beeld niet. Een gebeurtenis heeft op de werkingstijdas geen breedte, en een blok voor een traject wekt de indruk dat het traject op elk moment binnen de periode waar is. Ook een gebeurenbewering beslaat wel een periode op de tijdlijn van het systeem, maar het blokkendiagram blijft een toestandslezing.

Het ‘bi’ geldt per bewering. Een juridisch of feitelijk perspectief is geen extra tijdas, maar een andere bewering. Ook een register met journaal en projecties, of een keten van registers, voegt geen dimensies toe, wel beweringen met elk een eigen systeemtijd.

Bitemporaliteit brengt complexiteit mee die niet altijd nodig is. Welke temporaliteit een projectie nodig heeft, is een ontwerpafweging.

Afspraken over API’s

Uit de drie lagen volgt wat te standaardiseren is. Systeemtijd en werkingstijd hebben in elk domein dezelfde betekenis; daarover zijn generieke afspraken te maken, bijvoorbeeld over hoe een afnemer een peilmoment opgeeft, wat de standaard is als dat ontbreekt en hoe een antwoord herhaalbaar wordt. Domeintijdsgegevens zoals inwerkingtreding, inwinning of ontvangst verschillen per domein en horen in informatiemodellen. Die lijst kan groeien zonder dat een API-standaard meegroeit.

In API-afspraken is soms sprake van beschikbaarheidstijd, bijvoorbeeld in de temporal-extensie van het Kennisplatform API’s van Geonovum: het moment waarop de geleverde gegevens via dezelfde API beschikbaar zijn. Vanuit deze handreiking bezien is dat een moment op de systeemtijdlijn van het systeem dat het antwoord levert. Andersom is niet elke systeemtijd een beschikbaarheidstijd: de systeemtijd van een primaire bewering ligt bijvoorbeeld vóór het moment waarop een afgeleide bewering via een API beschikbaar komt (zie Verwerkingstijd).

Verdieping

• De casus Keizersgracht 42 laat de tijdstippen uit dit hoofdstuk zien in gevolgen, projecties en notificaties.
• Tijdstippen en geldigheid werkt de tijdstippen van gevolgen en projecties uit.
• Temporaliteit in projecties gaat van actuele stand via unitemporaliteit naar bitemporaliteit.
• Tijd in andere kaders zet de namen voor tijd uit standaarden, modellen en literatuur naast de drie lagen.
• 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 datering. 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. Dit hoofdstuk beschrijft hoe het register betekenis vastlegt, en hoe betekenis wordt bewaard en overgedragen op elke plek waar een bewering van vorm verandert.

TODO: beschrijven dat alle aspecten in het register dragen betekenis.

Ladder

• Document
• Zaakdossier
• Gevolg

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 het vertrekpunt.

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 Afleiden is interpreteren). 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 Januskop als metafoor). 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?