Merge branch 'main' into feat/132-medewerker-mfa

docs/architecture/fds/README.md

@@ -0,0 +1,50 @@
+# FDS-architectuur — Open Register
+
+Deze map bevat de architectuurbesluiten en de engineer-documentatie voor de FDS-kant van deze
+referentie-applicatie: deelnemen aan het Federatief Datastelsel als **afnemer**.
+
+De strategische inzet, de slices en de portfoliostatus staan in het Innovation Lab-repo,
+`Respellion/innovation-lab`, onder `projects/open-register-fd/`. Daar staan ook de
+architectuurblauwdruk, de FDS gap-analyse en de privacy-views.
+
+## Documenten
+
+| Document | Waarvoor |
+|---|---|
+| [`c4-component-view.md`](c4-component-view.md) | Componentview op niveau 3: ports en adapters, en welke views nog waarde toevoegen |
+| [`slice-1-proposal.md`](slice-1-proposal.md) | Het bouwbare eerste increment; plak dit in een `poc-voorstel`-issue |
+| `adr/` | De geaccepteerde architectuurbesluiten, ADR-0001 tot en met ADR-0006. Zie de tabel hieronder. |
+
+## Architecture Decision Records
+
+Een ADR legt een besluit vast dat **vaststaat**, met de context en de gevolgen, zodat het niet stil
+opnieuw wordt uitgevochten. Statuswaarden: `proposed` → `accepted` → (`vervangen door ADR-NNNN` |
+`deprecated`).
+
+Een geaccepteerde ADR wijzigen betekent een nieuwe ADR schrijven die de oude vervangt. Wij
+herschrijven de historie nooit.
+
+ADRs liggen naast governance. Acceptatie volgt de asynchrone bezwaarronde uit
+`Respellion/innovation-lab`, `operating-model/operating-model.md`, sectie *Besluitvorming*.
+
+| ADR | Besluit | Status |
+|---|---|---|
+| [0001](adr/0001-acl-at-every-register-boundary.md) | Anti-Corruption Layer op elke registergrens | accepted |
+| [0002](adr/0002-fsc-for-connectivity.md) | FSC voor connectiviteit tussen organisaties, geen ruwe REST | accepted |
+| [0003](adr/0003-pbac-via-opa.md) | Policy-based access control via OPA, FTV-klaar | accepted |
+| [0004](adr/0004-bounded-cache.md) | Begrensde cache; registers blijven systeem van registratie | accepted |
+| [0005](adr/0005-ldv-verwerkingenlog.md) | Verwerkingenlog via event-emissie, in lijn met LDV | accepted |
+| [0006](adr/0006-module-boundary-and-reuse.md) | Modulegrens en hergebruikstrategie: in-process → .NET-module → OpenMetadata-feed → gateway op verzoek | accepted |
+
+## Nummering
+
+Deze reeks staat los van de ADR-reeks over de referentie-applicatie zelf, die in
+[`../`](../adr-0001-loose-coupling.md) loopt van `adr-0001-loose-coupling` tot en met
+`adr-0010-bff-oidc`. Vandaar de eigen map `fds/`: beide reeksen beginnen bij 0001, en de nummers
+zouden anders over de volle breedte botsen.
+
+In de MkDocs-navigatie staan deze zes daarom als **FDS ADR-000N**, zodat de zijbalk ze niet met de
+reeks van de applicatie verwart.
+
+Nieuwe FDS-ADR: kopieer [`adr/template.md`](adr/template.md), neem het volgende nummer, en open een
+pull request.

docs/architecture/fds/adr/0001-acl-at-every-register-boundary.md

@@ -0,0 +1,42 @@
+# ADR-0001: Anti-Corruption Layer op elke registergrens
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle (Build, Lead Link)
+- **Vervangt / vervangen door:** —
+
+## Context
+
+De applicatie bevraagt meerdere registers: BRP, NHR/KVK, en ZGW via OpenZaak. Hun vocabulaires en
+schema's verschillen van elkaar en van ons domein. Zij veranderen ook zelf mee met de FDS-standaarden.
+
+Lekt registervocabulaire het domeinmodel in, dan werkt elke wijziging aan de registerzijde door in de
+bedrijfslogica. Het domein wordt dan een lappendeken van vreemde begrippen in plaats van ubiquitous
+language.
+
+## Besluit
+
+Elk register is bereikbaar via een Anti-Corruption Layer: **één adapter per register**, die een
+**port** vervult die het domein definieert.
+
+Adapters doen alleen vertalen en velden versmallen. Zij bevatten geen bedrijfslogica. Het domein
+spreekt `Persoon` en `Organisatie`, en nooit veldnamen uit BRP of NHR.
+
+## Gevolgen
+
+**Positief:** verloop in registers en FDS-standaarden blijft bij de adapter. Het domein blijft stabiel
+en testbaar. Adapters zijn onafhankelijk vervangbaar, en dat is precies wat de FSC-wissel uit
+ADR-0002 goedkoop maakt. Het patroon generaliseert naar een herbruikbare ACL-template per register,
+een Foundations-kandidaat.
+
+**Negatief en kosten:** één vertaalmap per register om te schrijven en te onderhouden, plus een extra
+indirectie die engineers moeten respecteren in plaats van omzeilen.
+
+**Vervolgwerk:** extraheer de ACL-template zodra de tweede adapter bestaat (slice 3).
+
+## Overwogen alternatieven
+
+- **Registers direct aanroepen uit de applicatieservices** — afgewezen: dit koppelt bedrijfscode aan
+  registerschema's en aan versies van FDS-standaarden.
+- **Eén generieke registeradapter** — afgewezen: registers verschillen genoeg dat een generieke
+  abstractie zou gaan lekken of opzwellen. Adapters per register zijn duidelijker.

docs/architecture/fds/adr/0002-fsc-for-connectivity.md

@@ -0,0 +1,44 @@
+# ADR-0002: FSC voor connectiviteit tussen organisaties, geen ruwe REST
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle, Upstream Liaison
+- **Vervangt / vervangen door:** —
+
+## Context
+
+Registerbevragingen kruisen een organisatiegrens naar systemen van bronhouders met
+persoonsgegevens. Het FDS noemt Federatieve Service Connectiviteit (FSC, de opvolger van NLX) als de
+richting voor connectiviteit: wederzijdse authenticatie op organisatieniveau, autorisatie
+gecontroleerd tegen een contract en gehandhaafd bij de bron, en symmetrische transactielogging.
+
+Een ruwe REST-client met mTLS geeft ons geen van de contractadministratie, delegatie of onafhankelijke
+tweezijdige verantwoording die een FG of auditor nodig heeft.
+
+## Besluit
+
+Het FSC Client-component stuurt alle registerbevragingen via een **FSC outway**, de
+EUPL-referentie-implementatie. De ACL-adapter hangt af van de FSC Client, en niet van een HTTP-client.
+
+FSC-zaken — contracten, identiteiten, delegatie — leven in dit component, achter de Register Port.
+
+## Gevolgen
+
+**Positief:** de autorisatie wordt bij de bron gehandhaafd, en niet op gezag van de aanroeper
+vertrouwd. Onweerlegbaar loggen aan beide uiteinden maakt onafhankelijke afstemming tegen ons LDV-log
+mogelijk. Delegatie wordt expliciet meegedragen. Wij lopen in lijn met de FDS-richting, vóór er een
+verplichting is.
+
+**Negatief en kosten:** FSC is operationeel zwaarder dan een REST-aanroep — beheer van certificaten en
+identiteiten, plus een outway die op De Werf moet draaien. De vergelijking FSC tegenover DSP loopt
+binnen het FDS nog, dus sommige details kunnen schuiven.
+
+**Vervolgwerk:** valideer het contract- en logginggedrag van de huidige fsc-nlx-implementatie
+(slice 2). Herzie dit als het FDS voor DSP kiest; ADR-0001 houdt die wissel beperkt tot één component.
+
+## Overwogen alternatieven
+
+- **Ruwe REST met mTLS** — afgewezen: geen contractlaag, geen tweezijdig log, en het wijkt af van het
+  FDS.
+- **Wachten tot het FDS FSC tegenover DSP heeft beslist** — afgewezen: de naad uit ADR-0001 laat ons nu
+  adopteren en later aanpassen. Wachten geeft het voordeel van vroege expertise weg.

docs/architecture/fds/adr/0003-pbac-via-opa.md

@@ -0,0 +1,44 @@
+# ADR-0003: Policy-based access control via OPA, FTV-klaar
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle, FG (geconsulteerd)
+- **Vervangt / vervangen door:** —
+
+## Context
+
+Elke bevraging van persoonsgegevens uit BRP of NHR is een verwerking die een grondslag en een
+begrensde doelbinding nodig heeft. Toegangsregels moeten handhaafbaar en auditeerbaar zijn, en
+wijzigbaar zonder de bedrijfscode opnieuw uit te rollen.
+
+De Federatieve Toegangsverlening (FTV) van het FDS beweegt naar policy-based access control, maar is
+nog geen afgeronde standaard.
+
+## Besluit
+
+Introduceer een Policy Decision Point met Open Policy Agent (OPA). De applicatieservices roepen de
+PDP aan — via een Authorisation Port en een PDP Client — **vóór elke registerbevraging**, en geven
+rol, doel en grondslag mee.
+
+Policies schrijven wij als code, **geversioneerd in Gitea**, en zij gaan via review naar productie. De
+PDP staat zo gepositioneerd dat wij bij de komst van FTV alleen het policy-dialect opnieuw uitdrukken,
+zonder de architectuurgrens te verplaatsen.
+
+## Gevolgen
+
+**Positief:** doelbinding en grondslag worden gehandhaafd, en niet alleen gedocumenteerd. De FG kan de
+werkelijke regels in versiebeheer lezen, waardoor het verwerkingenregister en de gehandhaafde policy
+naar elkaar toe groeien. Toegangswijzigingen zijn reviewbaar en gedateerd.
+
+**Negatief en kosten:** BRP-autorisatiebesluiten correct modelleren is juridisch werk, geen
+engineering. De PDP maakt de handhaving betrouwbaar, niet de policy juist. Daarnaast komt er een
+component bij om te exploiteren.
+
+**Vervolgwerk:** een promotiepijplijn voor policies in Gitea Actions. Policies opnieuw uitdrukken zodra
+FTV stabiliseert. Een FG-review van de policy-set vóórdat er echte persoonsgegevens in komen.
+
+## Overwogen alternatieven
+
+- **Rolcontroles in de applicatiecode** — afgewezen: niet auditeerbaar, niet wijzigbaar zonder deploy,
+  en het verspreidt toegangslogica over de codebase.
+- **Wachten op FTV** — afgewezen: de PBAC-vorm is al duidelijk. Nu OPA, later het FTV-dialect.

docs/architecture/fds/adr/0004-bounded-cache.md

@@ -0,0 +1,48 @@
+# ADR-0004: Begrensde cache; registers blijven systeem van registratie
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle, FG (geconsulteerd)
+- **Vervangt / vervangen door:** —
+
+## Context
+
+*Data bij de bron* verbiedt het behandelen van registerdata als lokale bron van waarheid. Maar BRP of
+NHR bij elke interactie bevragen is onpraktisch en vergroot de blootstelling.
+
+Persoonsgegevens zijn de data die wij het minst willen opbouwen. Een onbegrensde cache wordt stil een
+schaduwregister, met een onbeheerde bewaarverplichting als gevolg.
+
+## Besluit
+
+Een **begrensde cache** staat achter een Cache Port, beheerd door een Cache Manager. Vier grenzen
+gelden.
+
+| Grens | Wat die betekent |
+|---|---|
+| **Tijd** | Een TTL die aan het doel hangt |
+| **Omvang** | Alleen de werkset van een actieve zaak |
+| **Gezag** | Antwoordt nooit wat de bron niet zou antwoorden; geen systeem van registratie |
+| **Adresseerbaarheid** | Gesleuteld op subject, zodat verwijderen op verzoek kan |
+
+Purge-triggers: het verstrijken van de TTL, het sluiten van de zaak, en een verwijderingsverzoek.
+
+## Gevolgen
+
+**Positief:** de prestaties van een lokale kopie, zonder een onbevoegd register te worden. Bewaartermijn
+en het recht op verwijdering zijn echte operaties, geen hoop. Dit is consistent met zowel
+AVG-dataminimalisatie als FDS-data-bij-de-bron.
+
+**Negatief en kosten:** de mapping van doel naar TTL is een beleidsbesluit, samen met de FG en de
+autorisatievoorwaarden, en geen engineeringconstante. Die is dus makkelijk fout te krijgen. Daarnaast
+komt de complexiteit van cache-invalidatie erbij.
+
+**Vervolgwerk:** definieer het beleid voor doel naar TTL met de FG. Maak een toestandsdiagram voor de
+levensloop van een cache-entry. Documenteer de aanvaardbare veroudering per register.
+
+## Overwogen alternatieven
+
+- **Geen cache; altijd de bron bevragen** — afgewezen: onpraktische latency en belasting, en meer
+  blootstelling per aanroep.
+- **Een onbegrensde of algemene cache** — afgewezen: die wordt een schaduwregister, precies de
+  faalvorm waar de AVG en het FDS beide tegen duwen.

docs/architecture/fds/adr/0005-ldv-verwerkingenlog.md

@@ -0,0 +1,42 @@
+# ADR-0005: Verwerkingenlog via event-emissie, in lijn met LDV
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle, FG (geconsulteerd)
+- **Vervangt / vervangen door:** —
+
+## Context
+
+AVG art. 30 vereist een register van verwerkingsactiviteiten. De FDS-bouwsteen Logboek
+Dataverwerkingen (LDV) wijst naar een gestandaardiseerd verwerkingslog dat de burger kan bevragen.
+
+Database-CDC met Debezium legt *datawijzigingen* vast, en niet *verwerkingsgebeurtenissen met
+doelbinding*. Het is dus geen verwerkingenlog.
+
+## Besluit
+
+Elke registeradapter stuurt een **verwerkingsactiviteit-event** naar een eigen Redpanda-topic, via een
+Verwerking Port en een LDV Emitter. Het event bevat: subjectcategorie, register, velden, doel en
+doelbinding, grondslag, bevragende rol, en tijdstempel. **Nooit de opgehaalde waarden.**
+
+Een projectie maakt het log bevraagbaar. De emissie is asynchroon, maar niet over te slaan: de adapter
+die de Register Port vervult, is dezelfde code die het event uitstuurt.
+
+## Gevolgen
+
+**Positief:** het spoor voor art. 30 en LDV ontstaat als neveneffect van de bevraging, dus het kan niet
+uit de pas lopen met de werkelijkheid. Het is af te stemmen tegen de tweezijdige logs van FSC
+(ADR-0002). Het is onderscheidend in een tender.
+
+**Negatief en kosten:** een topic en een projectie om te exploiteren. Het ontsluiten van het log naar
+de burger valt buiten de huidige scope; wij produceren het log. Het eventschema vraagt governance.
+
+**Vervolgwerk:** definieer het schema van het verwerkingsevent. Bouw de bevraagbare projectie. Sluit
+aan op de LDV-standaard zodra die volwassen wordt; dit is een upstream-kandidaat.
+
+## Overwogen alternatieven
+
+- **Debezium-CDC hergebruiken als log** — afgewezen: dat legt datawijzigingen vast, en geen verwerking
+  met doelbinding. Verkeerde semantiek.
+- **Synchroon loggen in het aanroeppad** — afgewezen: dat koppelt de latency van de bevraging aan het
+  log. Asynchroon maar niet over te slaan geeft zowel snelheid als garantie.

docs/architecture/fds/adr/0006-module-boundary-and-reuse.md

@@ -0,0 +1,68 @@
+# ADR-0006: Modulegrens en hergebruikstrategie voor de governed-access spine
+
+- **Status:** accepted
+- **Datum:** 2026-06-13
+- **Deciders:** Lab Circle (Lead Link, Build, Upstream Liaison)
+- **Vervangt / vervangen door:** —
+
+## Context
+
+De compliance-spine uit slice 1 bestaat uit de PDP-controle (ADR-0003), gegoverneerd uitgaand verkeer
+via FSC (ADR-0002), emissie van het verwerkingenlog (ADR-0005), en de begrensde cache (ADR-0004),
+allemaal achter ports (ADR-0001). Die spine is mogelijk breder herbruikbaar dan alleen in de
+referentie-applicatie.
+
+Er spelen twee hergebruikvragen: welke verpakkingsvorm kiezen wij, en hoe verhoudt de spine zich tot
+andere omgevingen zoals het OpenMetadata-datagovernanceproject?
+
+Twee verduidelijkingen bepalen het besluit.
+
+1. **OpenMetadata is geen afnemer.** In het datagovernanceproject is het de catalogus- en
+   lineage-laag over (synthetische) data. Het bevraagt geen BRP of NHR. FSC of de begrensde cache
+   daarin inbouwen zou zinloos zijn. De juiste aansluiting is **integratie van de output van de
+   spine**, en niet het inbouwen van de spine.
+2. **FSC en de begrensde cache zijn zaken die alleen een afnemer aangaan.** "Maak het herbruikbaar"
+   mag deze niet uitsmeren over componenten die geen registerdata bevragen.
+
+Nu al een taalonafhankelijke gateway bouwen — vóórdat er een tweede, niet-.NET afnemer bestaat — zou
+de valkuil van speculatieve architectuur herhalen, die wij voor de capability-laag al hebben
+afgewezen.
+
+## Besluit
+
+Wij nemen een **vraaggestuurde reeks van vier stappen** aan. Elke stap hangt af van echte behoefte, en
+niet van verwachte behoefte.
+
+| Stap | Wat | Wanneer |
+|---|---|---|
+| 1 | **In-process bewijzen.** Bouw de spine als gewone componenten achter ports, binnen de .NET register-applicatie. Nog geen extractie. Doel: de compliance-invarianten één keer echt valideren. | Slice 1 |
+| 2 | **Extraheren als .NET-module.** Zodra een tweede .NET-afnemer in zicht is, haal de spine eruit als een geversioneerde .NET-library of SDK. Dit is de ACL-template-extractie die het charter al plant. Herbruikbaar voor .NET-afnemers, en dat is genoeg voor register-reference en zijn broertjes. | Slice 3 |
+| 3 | **De feed LDV naar OpenMetadata aansluiten.** Route verwerkingsevents uit de LDV-emitter naar OpenMetadata als access- en usage-metadata bij het geclassificeerde asset: wie las welk persoonsgegevensveld, met welk doel, hoe vaak. Optioneel laten classificatietags uit OpenMetadata terugstromen om veldminimalisatie in de ACL aan te sturen. Dit is de concrete brug tussen beide anchor-projecten: integratie, geen inbouw. | Na stap 2 |
+| 4 | **Alleen op verzoek een taalonafhankelijke gateway bouwen.** Heeft een echte niet-.NET afnemer gegoverneerde registertoegang nodig, verpak de spine dan als zelfstandige sidecar of proxy met een dunne lokale API, met PDP, FSC-egress en LDV erachter. Niet eerder. | Op verzoek |
+
+## Gevolgen
+
+**Positief:** eigen software blijft minimaal. Hergebruik volgt op validatie in plaats van eraan vooraf
+te gaan. Beide anchor-projecten krijgen een concreet, benoemd integratiepunt (stap 3). Zaken die
+alleen een afnemer aangaan, blijven ingesloten.
+
+**Negatief en kosten:** de .NET-module uit stap 2 dient geen niet-.NET afnemers. Dat aanvaarden wij,
+omdat stap 4 dat geval dekt zodra het echt is. Stap 3 vraagt een afgesproken schema voor het
+verwerkingsevent, stabiel genoeg voor OpenMetadata om te consumeren.
+
+**Vervolgwerk:**
+
+1. Neem stap 3 als expliciet integratiepunt op in beide projectpagina's in het Innovation Lab-repo:
+   `projects/open-register-fd/README.md` en `projects/openmetadata/README.md`.
+2. Herzie de trigger van stap 4 bij elke portfolio-review. Bouw niet vooruit.
+3. Regel governance op het schema van het verwerkingsevent; dat is een gedeelde afhankelijkheid van
+   stap 1 en stap 3.
+
+## Overwogen alternatieven
+
+- **De taalonafhankelijke gateway vooraf bouwen** — afgewezen: speculatieve architectuur voordat er een
+  tweede afnemer bestaat. De latency en de operationele kosten zijn niet te rechtvaardigen.
+- **De spine in OpenMetadata inbouwen** — afgewezen: OpenMetadata is geen afnemer. Dit is een
+  categoriefout.
+- **De spine permanent in-process houden, zonder extractie** — afgewezen: dat geeft het hergebruik
+  tussen projecten en applicaties weg, en dat is een kerndoel van de Open Register-inzet.

docs/architecture/fds/adr/template.md

@@ -0,0 +1,27 @@
+# ADR-NNNN: <titel>
+
+- **Status:** proposed
+- **Datum:** JJJJ-MM-DD
+- **Deciders:** <rollen>
+- **Vervangt / vervangen door:** —
+
+## Context
+
+<De krachten die spelen: het probleem, de beperkingen, de FDS- en AVG-drijfveren. Waarom er nu een
+besluit nodig is.>
+
+## Besluit
+
+<De keuze, eenvoudig gesteld.>
+
+## Gevolgen
+
+**Positief:** <wat dit oplevert>
+
+**Negatief en kosten:** <wat het kost, en wat wij aanvaarden>
+
+**Vervolgwerk:** <welk werk dit oproept>
+
+## Overwogen alternatieven
+
+<De afgewezen opties, en waarom.>

docs/architecture/fds/c4-component-view.md

@@ -0,0 +1,127 @@
+# C4-componentview — register-applicatie en capability-laag
+
+> Niveau 3, de componentview. Deze view zoomt in op de container van de .NET register-applicatie uit
+> het L2-containerdiagram. Zij verbindt het geheel op componentniveau — domein, ports, adapters en de
+> FDS-capability-componenten — en toont waar elk onderdeel externe tooling raakt.
+>
+> De hexagonale structuur is expliciet: het domein hangt alleen af van **ports** (interfaces). Elke
+> concrete capability is een **adapter** die aan een port is gebonden.
+>
+> De containerview (L2), de blauwdruk en de privacy-datastroomviews staan in het Innovation Lab-repo,
+> `Respellion/innovation-lab`, onder `projects/open-register-fd/`.
+
+```mermaid
+C4Component
+    title Componentview — register-applicatie (.NET) en de FDS-capability-laag
+
+    Person(user, "Behandelaar", "Behandelt zaken")
+    Container(spa, "Frontend", "Angular + NL Design System", "Zaakinterface")
+
+    Container_Boundary(app, "Register-applicatie (.NET, hexagonaal)") {
+        Component(api, "API / application services", ".NET", "Orkestreert use cases; verklaart doelbinding per vraag")
+        Component(domain, "Domeinmodel", ".NET / DDD", "Ubiquitous language; geen registervocabulaire")
+
+        Component(portReg, "Register Port", "interface", "De vraag van het domein: Personen / Organisaties")
+        Component(portPol, "Authorisation Port", "interface", "mag-deze-verwerking-doorgaan?")
+        Component(portLog, "Verwerking Port", "interface", "leg de verwerkingsgebeurtenis vast")
+        Component(portTm, "Terugmelding Port", "interface", "meld een vermoedelijke fout")
+        Component(portCache, "Cache Port", "interface", "doelgebonden lezen, schrijven en verwijderen")
+
+        Component(aclBrp, "BRP-adapter", ".NET", "Vertaalt domein<->BRP; minimale velden")
+        Component(aclKvk, "NHR/KVK-adapter", ".NET", "Vertaalt domein<->NHR; UBO-bewust")
+        Component(pdpClient, "PDP Client", ".NET -> OPA", "Roept de policy engine; geeft doel en grondslag mee")
+        Component(ldvEmit, "LDV Emitter", ".NET", "Bouwt het verwerkingsevent; publiceert naar Redpanda")
+        Component(fscClient, "FSC Client", ".NET", "Stuurt contractuele aanroepen via de outway")
+        Component(cacheMgr, "Cache Manager", ".NET", "TTL en verwijderen op subjectsleutel")
+        Component(tmHandler, "Terugmelding Handler", ".NET -> Flowable", "Start het terugmeldproces")
+        Component(procClient, "Process Client", ".NET -> Flowable", "Uitvoering van BPMN en DMN")
+    }
+
+    System_Ext(opa, "OPA (PDP)", "Policies geversioneerd in Gitea")
+    System_Ext(fsc, "FSC Outway", "EUPL-referentie-implementatie")
+    System_Ext(flowable, "Flowable", "BPMN + DMN")
+    ContainerDb_Ext(cache, "Begrensde cache", "PostgreSQL")
+    System_Ext(redpanda, "Redpanda", "LDV-topic + CDC")
+    System_Ext(brp, "BRP", "via FSC inway")
+    System_Ext(kvk, "NHR / KVK", "via FSC inway")
+    System_Ext(kanidm, "Kanidm", "OIDC")
+
+    Rel(user, spa, "Gebruikt")
+    Rel(spa, api, "REST/JSON")
+    Rel(kanidm, api, "OIDC", "authenticatie")
+    Rel(api, domain, "Roept aan")
+    Rel(api, portPol, "Controleert vóór de bevraging")
+    Rel(api, portReg, "Vraagt data")
+    Rel(api, portTm, "Dient melding in")
+    Rel(api, procClient, "Voert proces uit")
+
+    Rel(portPol, pdpClient, "gebonden aan")
+    Rel(pdpClient, opa, "besluitverzoek")
+
+    Rel(portReg, aclBrp, "gebonden aan")
+    Rel(portReg, aclKvk, "gebonden aan")
+    Rel(aclBrp, fscClient, "via")
+    Rel(aclKvk, fscClient, "via")
+    Rel(aclBrp, portLog, "stuurt event")
+    Rel(aclKvk, portLog, "stuurt event")
+    Rel(aclBrp, portCache, "leest en schrijft")
+    Rel(aclKvk, portCache, "leest en schrijft")
+    Rel(fscClient, fsc, "contractuele aanroep")
+    Rel(fsc, brp, "mTLS + contract")
+    Rel(fsc, kvk, "mTLS + contract")
+
+    Rel(portLog, ldvEmit, "gebonden aan")
+    Rel(ldvEmit, redpanda, "publiceert")
+    Rel(portCache, cacheMgr, "gebonden aan")
+    Rel(cacheMgr, cache, "slaat op")
+    Rel(portTm, tmHandler, "gebonden aan")
+    Rel(tmHandler, flowable, "start proces")
+    Rel(procClient, flowable, "voert uit")
+```
+
+## Hoe je dit leest
+
+1. **De ports zijn de naad.** Het domein en de application services hangen af van de vijf interfaces,
+   en nooit van adapters. FSC wisselen voor DSP, of OPA voor de latere FTV-client, verandert een
+   adapter — geen port, en niet het domein. Dit is de clock-speed boundary, concreet gemaakt.
+2. **De compliance-componenten zijn adapters, geen domeinlogica.** De PDP-client, de LDV-emitter, de
+   FSC-client en de cache manager staan allemaal aan de adapterzijde. Een bevraging kan er fysiek niet
+   langs, omdat de adapter die de Register Port vervult dezelfde code is die het LDV-event uitstuurt
+   en via FSC routeert.
+3. **Slechts twee componenten raken de registers**: de BRP-adapter en de NHR/KVK-adapter. Beide
+   bereiken ze uitsluitend via de FSC-client. Er is geen vierde pad.
+
+## Componenten tegenover verplichtingen
+
+| Component | Omvang eigen bouw | Verplichting die het afdekt |
+|---|---|---|
+| Domeinmodel | het product | correctheid van de bedrijfsregels |
+| BRP- en NHR-adapters | dun | dataminimalisatie: vertalen en velden versmallen |
+| PDP Client | klein | handhaven van grondslag en doelbinding |
+| LDV Emitter | klein | verwerkingenlog (AVG art. 30 en LDV) |
+| FSC Client | klein | geautoriseerde, gelogde connectiviteit |
+| Cache Manager | klein | grenzen aan bewaring, en verwijdering |
+| Terugmelding Handler | klein | de terugmeldplicht van de afnemer |
+
+---
+
+## Aanvullende views die voor engineers waarde hebben
+
+De diagrammen tot hier verklaren *structuur* en *compliance-intentie*. Engineers die dit bouwen,
+hebben er nog een aantal nodig. Wij tekenen geen view voordat er iets echt is om te beschrijven, dus
+elke regel noemt de trigger.
+
+| # | View | Wat het toevoegt | Trigger |
+|---|---|---|---|
+| 1 | **Deploymentview** (C4 deployment, topologie) | Waar elke container op De Werf draait: k3s-namespaces, welke services sidecar zijn en welke een eigen pod (is OPA een sidecar of centraal? waar eindigt de FSC outway?), netwerkpolicies tussen de vlakken van de vertrouwensgrens, en beheer van secrets en mTLS-certificaten voor FSC. Hier worden de privacy*grenzen* echte firewall- en netwerkregels. | Vóór de eerste deploy met meerdere services. **Hoogste waarde als volgende.** |
+| 2 | **Sequences voor de niet-gelukkige paden** | Wij hebben het gelukkige pad. Engineers hebben de lastige nodig: PDP-*deny* midden in een transactie, een verlopen of ingetrokken FSC-contract, een register-timeout terwijl er een verouderde cache-entry ligt, en een gedeeltelijk NHR-antwoord waarbij een UBO-veld is achtergehouden. Dit bepaalt de foutafhandeling, en hier verstoppen de compliance-randgevallen zich. | Direct na slice 1. |
+| 3 | **Domeinmodel en ERD** | De bounded contexts en aggregates in het domein, plus het cacheschema: welke persoonsgegevens blijven staan, op welke sleutel, en met welke purge-kolom. Dit is tegelijk het artefact dat de FG beoordeelt voor bewaartermijnen. | Zodra het domein in slice 1 stabiliseert. |
+| 4 | **Dataclassificatie- en catalogusview** | Elk veld dat een grens kruist, getagd — persoonsgegeven? bijzondere categorie? UBO-beperkt? — en gemapt op zijn classificatie in OpenMetadata. Dit stuurt de GDPR-scrubbingregels en de lineage-tags. | Beter *uit* OpenMetadata gegenereerd zodra die gevuld is, dan met de hand getekend. |
+| 5 | **Toestandsdiagram: levensloop van een cache-entry** | `fetched` → `valid` (binnen TTL) → `stale` → `purged` (TTL verstreken \| zaak gesloten \| verwijderingsverzoek). Klein, maar het pint de bewaarsemantiek vast die "begrensde cache" nu alleen in prose beschrijft. | Samen met ADR-0004-vervolgwerk. |
+| 6 | **BPMN-view: de terugmelding-workflow** | Het Flowable-proces zelf: ingediend → verstuurd naar bronhouder → bevestigd → opgelost of afgewezen. Dit is uitvoerbaar BPMN, dus het diagram en de implementatie zijn hetzelfde artefact. | Wanneer de terugmelding-slice start. |
+| 7 | **Threat model en vertrouwensgrensview** (STRIDE-stijl) | Dreigingen over de vertrouwensgrens leggen: tokendiefstal, cache poisoning, replay tegen FSC, policy bypass, en manipulatie van logs. Past natuurlijk bij de FSC-zoom, en is het anker van het securitygesprek. | Vóór het verwerken van echte persoonsgegevens. |
+| 8 | **CI/CD- en policy-promotieview** | Hoe OPA-policies en BPMN/DMN-modellen van een pull request naar draaiende configuratie gaan. "Toegangsbeheer is configuratie in Gitea" geldt alleen als er een pijplijn is die review en promotie handhaaft. | Samen met het vervolgwerk uit ADR-0003. |
+
+**Voorstel voor de volgende twee.** De **deploymentview**, omdat die de privacygrenzen omzet in
+handhaafbare netwerkpolicy. En de **sequences voor de niet-gelukkige paden**, omdat compliance daar
+werkelijk breekt.

docs/architecture/fds/slice-1-proposal.md

@@ -0,0 +1,103 @@
+# POC-voorstel — slice 1: walking skeleton (één register, gegoverneerde bevraging)
+
+> Klaar om in een `poc-voorstel`-issue te plakken, met de labels `build` en `poc`. Dit is het bouwbare
+> eerste increment dat de architectuurdocumenten beschrijven. Het bewijst met opzet de
+> *compliance-spine* end-to-end op de dunst mogelijke functionaliteit.
+
+## Probleem en strategische vraag
+
+Kunnen wij een registerbevraging demonstreren die *structureel* gegoverneerd is — onmogelijk uit te
+voeren zonder gehandhaafde grondslag en een automatische regel in het verwerkingenlog — op onze
+soevereine stack?
+
+Dit is de geloofwaardigheidstoets achter de hele Open Register-inzet (slice 1 van het charter) en
+achter de FDS gap-analyse.
+
+## Hypothese
+
+Wij verwachten dat het doorverbinden van één registerbevraging door de volledige capability-spine —
+Register Port → ACL-adapter → PDP-controle → FSC-aanroep → LDV-emissie → begrensde cache — de claim
+"compliance is structureel" bewijst.
+
+Wij weten dat wij het goed hebben als een geautomatiseerde test aantoont dat een bevraging **niet** kan
+voltooien als de PDP weigert, en **altijd** een LDV-event oplevert als de PDP toestaat.
+
+## Scope ter grootte van één blok
+
+**Wel in scope**
+
+| Onderdeel | Wat |
+|---|---|
+| Register | **NHR/KVK**, basisgegevens over onderneming en bestuurder. Gekozen boven BRP; zie de slotnotitie. |
+| Use case | Geef bij een KVK-nummer de geregistreerde organisatie terug aan het domein, voor één verklaard doel. |
+| Ports | De vijf ports als interface. Concrete adapters: NHR-ACL, PDP-client (OPA), FSC-client met sandbox- of test-outway, LDV-emitter (Redpanda-topic), en cache manager (PostgreSQL met TTL). |
+| Policy | OPA draait met één handgeschreven voorbeeldpolicy in Gitea: één allow-regel en één deny-geval. |
+| Log | Verwerkingsevent-schema v0 plus een minimale bevraagbare projectie; een tabelweergave is genoeg. |
+| Tests | Tests die de twee compliance-invarianten vastleggen: deny blokkeert, allow logt. |
+
+**Niet in scope** — even belangrijk om op te schrijven.
+
+1. Afgewerkte interface of NL Design System-schermen, verder dan een dev-harness.
+2. BRP en paden met veel persoonsgegevens. Die gaan naar slice 2, met een door de FG beoordeelde
+   policy.
+3. UBO-data. Het regime van beperkte toegankelijkheid valt buiten deze slice.
+4. De terugmelding-workflow (latere slice), DCAT-export, en Superset-dashboards.
+5. Echte register-endpoints. Alleen sandbox en stubs.
+
+## Definition of Done
+
+- [ ] Een bevraging op KVK-nummer geeft een domein-`Organisatie` terug via de NHR-ACL-adapter, zonder
+      registervocabulaire in het domein (ADR-0001).
+- [ ] De aanroep loopt via de FSC-client naar een sandbox-outway, en niet via een ruwe HTTP-client
+      (ADR-0002).
+- [ ] Er vindt geen bevraging plaats tenzij de PDP allow teruggeeft voor de combinatie rol, doel en
+      grondslag (ADR-0003).
+- [ ] Elke toegestane bevraging stuurt precies één verwerkingsevent naar Redpanda, bevraagbaar in de
+      projectie, zonder opgehaalde waarden (ADR-0005).
+- [ ] Cache-entries dragen een TTL en een subjectsleutel; een purge-aanroep verwijdert ze (ADR-0004).
+- [ ] **De tests op de compliance-invarianten slagen in CI:** (a) PDP-deny betekent geen FSC-aanroep;
+      (b) PDP-allow betekent precies één LDV-event; (c) te ruim gevraagde velden bereiken het domein
+      nooit.
+- [ ] Het geheel draait lokaal uit een gedocumenteerd `compose`- of k3s-manifest met stubs, zonder
+      echte registertoegang.
+- [ ] ADR-0001 tot en met ADR-0005 zijn vanuit de code gelinkt. Eén nieuwe ADR als er in slice 1 een
+      besluit ontstaat.
+
+## Acceptatiedemo (bewijs voor de week-3-toets)
+
+Live: een geslaagde bevraging plus de bijbehorende LDV-regel. Zet daarna de policy op deny en toon
+dezelfde bevraging geweigerd, zonder registeraanroep en zonder data.
+
+Dat contrast *is* de demo.
+
+## Ontvangende Delivery Circle (voorlopig)
+
+De register-reference Delivery Circle. De Handoff-ontvanger krijgt bij de kickoff een naam.
+
+Waarschijnlijke adoptie: de capability-spine wordt het herbruikbare substraat voor de
+register-reference-applicatie.
+
+## Upstream-kandidaten
+
+| Project | Wat wij kunnen bijdragen |
+|---|---|
+| fsc-nlx | Ergonomie van de sandbox en testomgeving, plus documentatie |
+| OPA | Policy-patronen voor het modelleren van Nederlandse grondslagen |
+| OpenMetadata | Later een DCAT-AP-NL exporter; dit verbindt het OpenMetadata-project |
+
+## AVG- en soevereiniteitsoverwegingen
+
+Alleen NHR-basisgegevens, over onderneming en bestuurder, en in slice 1 **gestubd**. Er worden geen
+echte persoonsgegevens verwerkt.
+
+Een FG-review is een voorwaarde voor slice 2, met echte data en BRP. Alle componenten draaien
+zelfgehost op De Werf; OPA-policies en BPMN staan in Gitea.
+
+## Slotnotitie: waarom NHR vóór BRP voor het skeleton
+
+Beide registers bevatten persoonsgegevens, dus geen van beide is "gratis". NHR-basisgegevens over
+onderneming en bestuurder zijn echter minder gevoelig dan BRP-gegevens over inwoners, en er is een
+duidelijker verhaal rond een publieke sandbox.
+
+Zo bewijst slice 1 het *mechanisme*, voordat slice 2 BRP oppakt onder een door de FG beoordeelde
+policy. UBO-data blijft buiten scope tot het toegangsregime is gemodelleerd.

docs/index.md

@@ -9,6 +9,9 @@ should teach.
 - **[Product Requirements](PRD.md)** — what we're building and why.
 - **[ADR-0001: Loose coupling](architecture/adr-0001-loose-coupling.md)** — the
   non-negotiable integration stance; the template for future ADRs.
+- **[FDS architecture](architecture/fds/README.md)** — participating in the Federatief
+  Datastelsel as an afnemer: FDS ADR-0001…0006, the L3 component view, the slice-1 proposal.
+  In Dutch; the strategic framing lives in `Respellion/innovation-lab`.
 - **[Working in Gitea](gitea-workflow.md)** — issues, milestones, branches, PRs.
 - **[CI runbook](runbooks/ci.md)** — the pipeline and the `make ci` local gate.
 

mkdocs.yml

@@ -32,6 +32,17 @@ nav:
       - "ADR-0008: Read projection store": architecture/adr-0008-read-projection-store.md
       - "ADR-0009: External-task job worker": architecture/adr-0009-external-task-job-worker.md
       - "ADR-0010: BFF OIDC validation": architecture/adr-0010-bff-oidc.md
+  - FDS-architectuur:
+      - Overzicht: architecture/fds/README.md
+      - Componentview (L3): architecture/fds/c4-component-view.md
+      - "Slice 1: walking skeleton": architecture/fds/slice-1-proposal.md
+      - "FDS ADR-0001: ACL op elke registergrens": architecture/fds/adr/0001-acl-at-every-register-boundary.md
+      - "FDS ADR-0002: FSC voor connectiviteit": architecture/fds/adr/0002-fsc-for-connectivity.md
+      - "FDS ADR-0003: PBAC via OPA": architecture/fds/adr/0003-pbac-via-opa.md
+      - "FDS ADR-0004: Begrensde cache": architecture/fds/adr/0004-bounded-cache.md
+      - "FDS ADR-0005: Verwerkingenlog via events": architecture/fds/adr/0005-ldv-verwerkingenlog.md
+      - "FDS ADR-0006: Modulegrens en hergebruik": architecture/fds/adr/0006-module-boundary-and-reuse.md
+      - "FDS ADR-template": architecture/fds/adr/template.md
   - Working in Gitea: gitea-workflow.md
   - Frontend decisions: frontend-decisions.md
   - Demo script: demo-script.md
@@ -42,7 +53,11 @@ markdown_extensions:
   - admonition
   - toc:
       permalink: true
-  - pymdownx.superfences
+  - pymdownx.superfences:
+      custom_fences:
+        - name: mermaid
+          class: mermaid
+          format: !!python/name:pymdownx.superfences.fence_code_format
 
 # Many docs referenced by PRD.md land in later slices; don't fail the build on them.
 validation: