Ga naar hoofdinhoud

Gevolgen

Gevolg​

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

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

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

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

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

Gevolgenjournaal​

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

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

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

Hoe een gevolg tot stand komt​

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

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

Gevolgdelen​

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

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

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

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

Identiteit​

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

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

Herkenbaar bijhouden​

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

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

Feitelijk of administratief formuleren​

Gevolgen kunnen we op twee manieren formuleren:

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

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

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

Feitelijk versus administratief

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

Correcties​

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

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

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

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

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

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

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

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

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

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

Onttrekking​

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

Aanleidingen voor onttrekking​

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

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

Vervolgens kunnen we ten minste de volgende aanleidingen onderscheiden:

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

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

Onttrekking in het journaal​

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

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

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

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

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

Twijfelen​

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

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

Ontwerpafwegingen voor gevolgen​

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

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

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

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

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

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

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

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

Voorbeeld – adoptie in de BRP

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

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

interface NaamGewijzigd {
    val nieuweGeslachtsnaam: String
}

interface AdresGewijzigd {
    val nieuwAdres: Adres
}

interface GezagGewijzigd {
    val nieuweOuders: List<Persoon>
}

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

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