Herkomst

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

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

De herkomstkenmerken

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

Bron

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

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

Vragen bij het vastleggen van de bron

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

Verantwoordelijke

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

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

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

Legitimering

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

Open vraag: legitimering bij projectie-elementen

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

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

Werkwijze

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

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

Van werkwijze naar verantwoordelijke

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

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

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

Softwarebeheer als werkwijze

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

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

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

Eerdere indeling: verwerkingsverantwoording

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

Herkomst van gevolgen en van projectie-elementen

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

Kenmerk	Gevolg	Projectie-element
Bron	De externe bevinding (of het document waarin die is vastgelegd) die via een commando tot het gevolg leidde	Het gevolg waaruit het element is afgeleid en, als het element voortbouwt op een eerder element in dezelfde reeks, ook dat voorgaande element
Verantwoordelijke	Wie het gevolg heeft vastgesteld; bij handmatige verwerking ten minste de betrokken medewerker	Wie voor het projecteren instaat; in de regel te herleiden via de werkwijze, maar zo nodig expliciet vastgelegd, bijvoorbeeld als verschillende partijen elementen van één projectie produceren
Legitimering	De bevoegdheid om iets met rechtsgevolg vast te stellen, zoals de bevoegdheid van een gemeente om iemand op een adres in te schrijven	Nog niet besloten: zie de open vraag hierboven
Werkwijze	De procedure of het algoritme van de bijhouding, waaronder de vormingsspecificatie	De projectiespecificatie en de software die haar uitvoert, met een versie die eenduidig naar een revisie in het versiebeheer verwijst

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

De herkomstketen

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

Op hoofdlijnen: van gevolg naar gevolg

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

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

In detail: door het register heen

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

Van de oorsprong naar de afnemer gelezen:

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

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

Herkomst bij herstel

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

Herkomst in opslag en verstrekking

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