Files
eho 321ee50dcb
CI / build (push) Successful in 1m36s
CI / lint (push) Successful in 1m45s
CI / unit (push) Successful in 2m1s
CI / frontend (push) Successful in 3m30s
CI / mutation (push) Successful in 8m4s
CI / verify-stack (push) Successful in 9m25s
docs(architecture): import the FDS architecture decisions from the lab repo (closes #159) (#160)
## What & why

Brings the engineer-facing FDS documentation next to the code it describes. Imported from `projects/open-register-fd/` in `Respellion/innovation-lab` and translated to Dutch: **six ADRs**, the ADR index and template, the **L3 component view**, and the **slice-1 proposal**.

The architecture blueprint, the FDS gap analysis and the two privacy views stay in the lab repo — the OKRs cite them and they feed tender responses. Each side names the split in a "Wat ligt waar" table, so nothing is documented twice.

Closes #159

### Why `docs/architecture/fds/` and not `docs/architecture/`

This repo's own ADR series now runs `adr-0001-loose-coupling` … `adr-0010-bff-oidc`. The imported set is numbered 0001–0006, so a flat import would collide across the whole imported range. The subfolder preserves the imported numbering, and with it roughly thirty `ADR-000N` cross-references inside the imported text that would otherwise all need rewriting.

In the MkDocs sidebar the imported six appear as **FDS ADR-000N** so they are not confused with this repo's series. `docs/architecture/fds/README.md` explains the two series.

### Mermaid support was missing

`pymdownx.superfences` had no `custom_fences`, so the imported diagrams would have published to Gitea Pages as raw code blocks. This PR adds the mermaid custom fence, the nav group, and one link under *Where to go* in the docs index.

## Definition of Done

- [x] Linked Gitea issue (above).
- [ ] Failing test committed before the implementation. — n/a, documentation only.
- [ ] Implementation makes the test pass. — n/a, documentation only.
- [x] Conventional Commits referencing the issue (`refs #159`).
- [x] Rebased on current `main`; no conflicts.
- [ ] CI green — n/a for content; the docs verification is below.
- [ ] `docker compose up` reaches green health checks. — n/a, no runtime change.
- [x] Docs updated if behaviour, contracts, or operations changed.
- [x] ADR added in `docs/architecture/` if a non-obvious decision was made. — six imported, plus the numbering decision recorded in the folder README.
- [ ] Demo note in `docs/demo-script.md`. — n/a, nothing user-visible.

## Verification run

- `mkdocs build` — clean. No missing-nav warning for any `architecture/fds/` entry. The two remaining warnings are pre-existing on `main` and untouched here: the set of pages absent from `nav`, and a broken link in `runbooks/ci.md` to `services/acl/stryker-config.json`.
- Mermaid renders as a diagram, not a code block: `site/architecture/fds/c4-component-view/index.html` contains `class="mermaid"`.
- All relative markdown links in the repo resolve.

## Notes for reviewers

- **Language.** The imported documents are Dutch; this repo's own documents remain English. Deliberate, not an oversight — the lab repo standardised on Dutch and these pages moved with it. Translating the rest is a separate decision.
- **Ownership.** This repo sits in the `eho/` namespace while it now holds the canonical FDS architecture decisions that tender answers point at. Worth deciding whether it should move to `Respellion/`.
- **Scope drift, not fixed here.** The imported text is faithful to its source, so the slice-1 proposal and the ADRs assume NHR/KVK for slice 1, while the lab-side blueprint still uses BAG as its example register. The lab-side documents carry a banner about this; Blueprint v2 (slice 5) is where the diagrams get corrected.
- **Companion PR:** `Respellion/innovation-lab` #34 holds the lab-side half of this split.Reviewed-on: #160
2026-09-03 12:35:01 +00:00

2.0 KiB

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.