Ontbrekende stukken in openbesluitvorming: geen volledigheid

[guidol-ive]

Ontbrekende Stukken

Ik zie dat er stukken openbaar staan in een gemeentelijke raadssite die ook na maanden na publicatie niet terug te vinden zijn via de zoekfunctie openbesluitvorming.nl op inhoud of titel. Toch geeft de status aan dat dat orgaan volledig bijgewerkt is. De site is geen register en zal mogelijk een disclaimer moeten bevatten.

Een goed voorbeeld is dit stuk van 31 juli 2026:

https://ermelo.raadsinformatie.nl/document/17249647/2

Op https://openbesluitvorming.nl/?query=kazerne+zeewolde+ermelo&sort=date_desc komt dit stuk niet omhoog.

Ik schrik hier goed van. Als het systeem onvolledig is, maar dat niet kenbaar maakt, dan past dat qua verwachting minder goed bij de merknaam.

Andere Ontbrekende Schriftelijke Vraag

Een voorbeeld uit 2025:

https://ermelo.raadsinformatie.nl/document/16456567/1#search=%22ermelo%22

maar zonder resultaten op:

https://openbesluitvorming.nl/?query=02330000086778&sort=date_desc

Mogelijk Breder Probleem

Het lijkt in ieder geval om meerdere documenten uit de module "schriftelijke vragen" te gaan. Dat is bij deze gemeente een paar procent van de stukken, maar juist stukken die meer dan gemiddeld relevant zijn: ze hebben politieke aandacht. Volgens https://ermelo.raadsinformatie.nl/zoeken?keywords=ermelo&search=send&limit=10&sort=date_desc&show_result=show_all:

Analyse Ermelo

Er komen 53349 zoekresultaten met woord Ermelo te voorschijn volgens https://ermelo.raadsinformatie.nl/zoeken?keywords=ermelo&search=send&limit=10&sort=date_desc&show_result=show_all.

Volgens https://ermelo.raadsinformatie.nl/zoeken?keywords=ermelo&search=send&limit=10&sort=date_desc&show_result=show_all zijn er in 2025 een documentenaantal van 1392:

Volgens https://openbesluitvorming.nl/?organization=ermelo&sort=date_desc&dateFrom=2025-01-01&dateTo=2026-01-01 kent OpenBesluitvorming er ongeveer 740:

Het blijkt dat de naam van de URL parameter niet klopt, het is dateThrough ipv dateTo (exclusief). Hier zal een apart issue voor gemaakt worden.

Dit is circa 50%.

Zet ik de datum op 31-12-2025 dan zakt opeens het aantal resultaten met ruim 300 weg naar ongeveer 407 (zie ``https://openbesluitvorming.nl/?organization=ermelo&sort=date_desc&dateFrom=2025-01-01&dateTo=2025-12-31):

Blijkbaar zijn er ongeveer 300 documenten gedateerd op 1 januari 2026 (?). Volgens https://openbesluitvorming.nl/?organization=ermelo&sort=date_desc&dateFrom=2026-01-01&dateTo=2026-01-01 zijn dat er 141:

Twijfels over Volledigheid

Op basis van deze n=1 steekproef lijkt voor de gemeente Ermelo maar een klein gedeelte van de document (25%?) vindbaar te zijn via openbesluitvorming.nl. Ik heb ze niet uitputtend nagelopen; de afwijkingen zijn dusdanig groot qua aantallen en het belang van het type document (de schriftelijke vragen) dat dit issue gerechtvaardigd is.

Is het mogelijk om duidelijkheid te verschaffen over de levensvatbaarheid van openbesluitvorming.nl en zinvolheid gebruik betreffende:

• Zijn er criteria die gehanteerd worden door Openbesluitvorming.nl om stukken niet beschikbaar te maken die wel openbaar zijn in het raadsinformatiesysteem?
• Kan een griffie of andere beheerder van een raadsinformatiesysteem opname in openbesluitvorming.nl verhinderen, maar het wel openbaar zetten in de eigen site (ik begreep dat dat per vergadertype mogelijk kan in iBabs)?
• Is er een overzicht in hoeverre dit gebeurt en is op een makkelijke manier hiervan een verschillenlijst op te vragen?
• Hoe en op welke momenten vinden aansluitingscontroles plaats op aantal documenten tussen bron en openbesluitvorming.nl? Zijn die ergens terug te vinden?

We geven momenteel op https://besluitbron.nl/nl/status weer wat de status is van de verschillende bronnen, waaronder die via openbesluitvorming.nl uitgevraagd worden. Als de status "OK" niet door de feiten gedragen wordt, dan moeten we gebruikers van besluitbron hierover informeren met een disclaimer of zo, of een automatische analyse maken die de raadsinformatiesystemen scrapet.

Suggestie

In het werk verwerken we veel financiele data. Daar zitten op aantal gevoelige onderdelen application controls in op bijvoorbeeld aantallen. Niet elke API heeft ze of heeft ze goedkoop opvraagbaar, maar misschien is het mogelijk om voor de raadsinformatiesystemen te kijken - voor zover nog niet gedaan - of er een geautomatiseerde aansluitingscontrole in de keten opgenomen kan worden waarvan het resultaat opvraagbaar is via /api/status.

AI analyse risico's

De broncode van de voorganger door AI gehaald (snel, geen uitputtend onderzoek). Hierbij kwamen vier problemen naar voren:

Waarom stukken ontbreken terwijl de status groen staat

Vier mechanismen, alle vier onzichtbaar aan de buitenkant:

1. Harvesting op vergaderdatum, niet op publicatiedatum. De iBabs-extractor haalt vergaderingen op met GetMeetingsByDateRange over een reeks datumvensters. Een bijlage die maanden na de vergadering aan een oude vergadering wordt gehangen, valt buiten het dagelijkse venster en komt pas binnen als een bredere herhaalronde dat oude venster opnieuw raakt. In de code is voor lijstitems de datumvergelijking bewust verwijderd omdat het datumveld onbetrouwbaar is; voor vergaderingen is dat niet gedaan.

2. Documenten die structureel niet worden uitgelezen. Bij Notubiz parseert de ETL alleen agenda_items[].documents[]. Documenten onder module_items[] en onder geneste agendapunten worden overgeslagen. Dit is sinds februari 2025 gemeld als bug met hoge prioriteit en staat nog open (issue #513). De melder documenteerde het met eigen diff-tabellen: voor Waddinxveen 2024 vond hij 1120 documenten via de Notubiz-API tegen 698 in ORI, met 459 documenten die in Notubiz zitten en niet in ORI; voor Breda 2019 was dat 1915 tegen 218. Let op de betrouwbaarheid van die tabel zelf: de ORI-kolom stopt bij precies 1000 in meerdere jaren, wat op een pagineringslimiet duidt, en de melder zegt zelf dat ook zijn eigen scraper documenten mist. De orde van grootte is niettemin niet marginaal.
   GitHub

3. Configuratie-filters per bron. In de iBabs-extractor staan per bron een include- en een exclude-regex op de beschrijving van het vergadertype. Vergadertypes die daar niet doorheen komen, verdwijnen inclusief alle onderliggende stukken. Daarnaast wordt een vergadering waarvan het MeetingtypeId niet in de opgehaalde typenlijst voorkomt, stil geskipt met het commentaar dat zo'n type "soms geen echte vergadering" is. Voor lijsten (ingekomen stukken, moties, toezeggingen) geldt hetzelfde: alleen lijsten waarvan de naam matcht met de geconfigureerde regex worden opgehaald.

4. Stille faalpaden. Per lijst geldt een default van 100 pagina's van 300 records. Een XML-parsefout op een pagina laat de hele pagina van 300 records vallen en de loop gaat verder. Op twee plekken staat in de broncode een TODO dat deze missers eigenlijk geregistreerd zouden moeten worden. Ze worden dus niet geteld en tellen ook niet mee in enige statusindicatie.

Voeg daaraan toe: niet vindbaar is niet hetzelfde als niet aanwezig. Een gescande PDF zonder tekstlaag staat wel in de index maar komt niet uit een woordzoekopdracht. Controleer daarom via de API op document-URL of vergadering-id, niet via de zoekinterface.

[guidol-ive]

Mogelijk gerelateerd 1

#255

Maar @rrommel-sudo spreekt niet over "schriftelijke vragen". Het is mij onbekend hoe die groepen samengesteld worden en of dat seeded of setup data is.

Mogelijk gerelateerd 2

#226

Deze gaat voornamelijk over iBabs (en de melding gaat over Notubiz). En gaat over relatief klein deel documenten. De verschillen hierboven geven aanleiding om te vermoeden dat er tientallen procenten kan ontbreken cq. niet controleerbaar is qua aantallen. Wel wordt onder "Wat dit niet zegt" nog Notubiz / Lochem aangehaald.

[guidol-ive]

Analyse Lochem

N.a.v. #226 is Lochem bekeken.

Op https://openbesluitvorming.nl/?query=lochem&organization=lochem&sort=date_desc&dateFrom=2025-01-01&dateTo=2025-12-31 komen in 2025 er 57 documenten te voorschijn in Lochem:

Volgens https://lochem.raadsinformatie.nl/zoeken?keywords=lochem&limit=10&document_type=&search=send zijn er in 2025 echter 844 documenten:

Dit zou betekenen dat meer dan 90% van de documenten ontbreekt in openbesluitvorming.nl van Lochem uit 2025. Dit lijkt op de eerder genoemde mogelijk 75% die ontbreekt bij Ermelo.

Aansluiting met ORI

De ORI-website is helaas al vervangen, maar de API lijkt nog te werken. Via besluitbron.nl een vergelijking gedaan, maar zoeken op orgaan is niet mogelijk. Toch geeft het indruk dat ORI beduidend meer geindexeerd heeft. Per bron maximum opgehaald wat blijkbaar ingseteld is als 1000:

Dan kent ORI in ieder geval 126 stukken in 2025 met het woord "Lochem" (wat ook best een Groenlo's stuk kan zijn dat spreekt over Lochem), terwijl OpenBesluitvorming er maar 44 kent in 2025 met een zelfde steekproefgrootte:

Het kan best zijn dat de steekproeven qua grootte identiek zijn, maar skewed. Dit geeft uitsluitsel cq zekerheid dat ORI het beter doet, maar is wel een indicator voor verder onderzoek.

[rrommel-sudo]

Mogelijk gerelateerd 1

#255

Maar @rrommel-sudo spreekt niet over "schriftelijke vragen". Het is mij onbekend hoe die groepen samengesteld worden en of dat seeded of setup data is.

Het gaat hier om Notubiz en we hebben in Casstricum ipv commisie vergadering Carrousel vergaderingen, maar die lijken dus niet meegenomen te worden. De carrousel vergaderingen zijn de formele vergaderingen die vooraf gaan voor de raadsvergadering.

[guidol-ive]

Vergelijking ORI en openbesluitvorming.nl

ORI Lochem: 8277 documenten

ORI heeft in ieder geval meer documenten van Lochem (de website is offline maar API draait nog):

https://besluitbron.nl/scenario/ori/count-all-documents

geeft 8277 documenten in de index Lochem (wat een andere tijdsperiode kan zijn):

Openbesluitvorming.nl Lochem: 5044 documenten

Terwijl openbesluitvorming.nl er ongeveer 5044 geeft op https://openbesluitvorming.nl/?query=lochem&organization=lochem&sort=date_desc:

ORI Lochem 2025: 900 (last discussed at)

Met de body:

{
  "size": 0,
  "track_total_hits": true,
  "query": {
    "bool": {
      "filter": [
        {
          "range": {
            "last_discussed_at": { "gte": "2025-01-01", "lt": "2026-01-01" }
          }
        }
      ]
    }
  }
}

Komt er uit: 900 documenten.

Openbesluitvorming.nl: 57 documenten

Bij https://openbesluitvorming.nl/?query=lochem&organization=lochem&sort=date_desc&dateFrom=2025-01-01&dateTo=2025-12-31 komt er veel minder uit in 2025:

Waarbij discussie mogelijk is over WELKE datum. De verschillen zijn echter enorm; Lochem bevat ondanks OK bericht vrijwel geen enkel document in de onderzochte periode.

Statuspagina:

   {
      "sourceKey": "lochem",
      "sourceRef": "notubiz:gemeente:lochem",
      "label": "Lochem",
      "supplier": "notubiz",
      "organizationType": "gemeente",
      "cbsId": "GM0262",
      "state": "ok",
      "lastSuccessAt": "2026-09-04T00:19:20.133Z",
      "lastRunAt": "2026-09-04T00:00:00.448Z",
      "lastRunStatus": "succeeded",
      "latestContentDate": "2026-09-10T17:30:00.000Z",
      "lastIndexedAt": "2026-09-04T00:19:06.000Z"
    }

[guidol-ive]

Gerelateerde issues aangemaakt:

• Semantiek datumveld is onduidelijk #259
• Status uitbreiden met aantallen geindexeerde, eventueel apart voor laatst afgesloten periode t.b.v. aansluitingcontrole #260
• Verkeerde interpretatie datum tot versus datum tot/met in zoekscherm #261

[guidol-ive]

Mogelijk gerelateerd 1

#255
Maar @rrommel-sudo spreekt niet over "schriftelijke vragen". Het is mij onbekend hoe die groepen samengesteld worden en of dat seeded of setup data is.

Het gaat hier om Notubiz en we hebben in Casstricum ipv commisie vergadering Carrousel vergaderingen, maar die lijken dus niet meegenomen te worden. De carrousel vergaderingen zijn de formele vergaderingen die vooraf gaan voor de raadsvergadering.

Dank voor aanvulling! Lijkt meer mis te zijn.

[joepio]

Dank voor de precieze melding. Ik heb het nagemeten, en de kern klopt: voor 2025 en 2026 missen we bij Notubiz-gemeentes het grootste deel van wat de oude ORI wél had. De omvang die je afleidt uit de zoekpagina is te somber, maar het mechanisme erachter is echt. Hieronder de meting, de oorzaak, en wat we eraan doen.

Meting: per document vergeleken met ORI

Voor Ermelo en Lochem heb ik de documentverzamelingen van openbesluitvorming.nl en van de oude ORI-index (nog beschikbaar) per Notubiz-documentnummer naast elkaar gelegd.

	openbesluitvorming	ORI	in beide
Ermelo, alle jaren	25.275	8.660	5.472
Ermelo 2025	170 van ORI's 1.547
Ermelo 2026	46 van ORI's 725
Lochem 2025	95 van ORI's 520
Lochem 2026	36 van ORI's 373

Tot en met 2024 hebben we vrijwel alles wat ORI heeft, en over de hele historie voor Ermelo drie keer zoveel. Van wat ORI in 2025 en 2026 heeft, hebben wij tien tot twintig procent. Dat is het gat dat je ziet.

Oorzaak: registers

De ontbrekende stukken hangen aan vergaderingen die we wél hebben. De Notubiz-API levert ze alleen niet meer onder de agendapunten (agenda_items[].documents), maar als module-items: registers zoals Ingekomen stukken, Raadsvoorstellen, Schriftelijke vragen en Toezeggingen. Van een steekproef van 40 ontbrekende Ermelo-stukken uit 2025 zaten er 24 in Ingekomen stukken, 11 in Raadsvoorstellen en 1 in Moties. Wij importeren bij Notubiz alleen de module Moties; ORI haalde alle modules op. Sinds 2025 zetten Notubiz-gemeentes juist deze registers zwaar in, en dat verklaart waarom het gat recent is en niet historisch.

Het stuk over de kazerne (17249647) staat in het register Schriftelijke vragen van Ermelo. ORI heeft het overigens ook niet, net als 16456567.

Voor iBabs speelt hetzelfde met de lijsten (ingekomen stukken, raadsvragen, toezeggingen); dat staat in #226.

Wat er niet klopt aan de aantallen op de zoekpagina

• Het getal boven de resultaten is een benadering: de zoekscan stopt na 6.000 rijen, en het API-antwoord meldt dat met totalIsApproximate: true. Voor organization=ermelo in 2025 staat er daardoor 407 waar het werkelijke aantal in de index anders is. De pagina moet dat duidelijker tonen; daar maak ik een apart issue van.
• De brontelling (1.392 en 844) is een zoekopdracht op het woord "ermelo" respectievelijk "lochem" in het raadsinformatiesysteem, geen documententelling. Die vergelijking meet iets anders dan dekking.

Op je vragen: er zijn geen criteria waarmee wij openbare stukken bewust weglaten, en een griffie kan opname niet per stuk verhinderen anders dan door het niet openbaar te zetten. Er is nu geen periodieke aansluitcontrole per bron, en de status "bijgewerkt" zegt alleen dat de laatste import zonder fouten is verlopen. Dat is precies de zwakte die je aanwijst.

Wat we doen

1. Registers importeren, voor Notubiz en iBabs in één ontwerp: elk register-item wordt een entiteit met zijn bijlagen als documenten, gevolgd door een backfill per bron. De client-aanroepen bestaan al (moties lopen er al doorheen).
2. Een aansluitcontrole per bron: periodiek het aantal documenten per bron bij de leverancier vergelijken met wat wij hebben, en het verschil tonen op de statuspagina in plaats van alleen "OK".
3. Het benaderde totaal eerlijk labelen op de zoekpagina.

Ik houd dit issue open tot 1 en 2 gedaan zijn en meld de metingen hier.

[guidol-ive]

Dank!

Poging gewaagd om de drie bronnen aan te sluiten, maar de eerste twee RIS waren al down cq. totaal onbruikbaar traag.

Suggestie 1: qua periodiciteit stel ik me voor dat dit automatisch aan einde elke import gebeurt, waarbij 10 stukken verschil geaccepteerd wordt (er is altijd kans dat nog iemand om 0:00 bezig is met mutaties).

Suggstie 2: kan (2) uitgebreid worden met die aansluitcontrole ook terugmelden in de status API?

Verder: ik heb de indruk dat er een datumbereik opgehaald wordt van meetings. Als:

1. stukken van bijvoorbeeld 1 april 2026 echter initieel niet getoond worden om wat voor reden dan ook,
2. het datumvenster voor ophalen schuift zover op dat 1 april 2026 er buiten valt
3. de stukken worden alsnog op openbaar gezet

Vraag 3: Komen die stukken dan ooit nog in de index? Is er een soort bezemwagen? Of blijven de indexen ook onder vaker publiek / niet-publiek wisselingen netjes de eenmaal publiekgemaakte documenten tonen en toegevoegde in het verleden opnemen?

[joepio]

Stand 5 september, 09:30 UTC. #264 is gemerged en live: registers worden geïmporteerd voor Notubiz en iBabs, en de aansluitcontrole bestaat.

Aansluitcontrole, eerste metingen op productie (venster: laatste twaalf maanden, alleen wat de leveranciers-API zelf toont):

bron	leverancier	in index	ontbreekt	dekking
Ermelo (Notubiz)	2.072	147	1.925	7%
Schiermonnikoog (iBabs)	870	823	47	95%

De controle draait vanaf nu wekelijks (zondag 05:00) over alle bronnen en het resultaat komt per bron als coverage op /api/status, met een steekproef van ontbrekende document-ids. Daarmee is "OK" op de statuspagina straks controleerbaar.

Backfill gestart: 1.172 importruns (293 Notubiz- en iBabs-bronnen, 2025-01-01 tot nu in halfjaarvensters) staan in de wachtrij en draaien op vier workers. De ontbrekende registerdocumenten worden daarmee alsnog opgehaald en geëxtraheerd; dat kost naar verwachting enkele dagen. Ik meld hier de dekking van Ermelo en Lochem als de backfill klaar is.

[guidol-ive]

Stoer! De teller staat al op 5.301.847 op zondag 01:09, was 5.221.110 op zaterdag om 12:48. In 12 klokuren op zaterdag zal gemeentelijk Nederland geen 80.000 stukken vastleggen. Bedoeld of met de nieuwe data betere analyses te maken zijn.

[joepio]

Tussenstand. De oorzaak van het gat (registers/modules werden niet geïmporteerd, #226) is gerepareerd en uitgerold; de backfill die 2025–2026 voor alle Notubiz- en iBabs-bronnen opnieuw ophaalt draait sinds gisterochtend en is naar verwachting over een tot twee dagen klaar. Vandaag zijn daar ook twee dingen bij gekomen die per document meetellen: Notubiz-documenten worden nu in hun actuele versie opgehaald in plaats van altijd /1 (#269), en vergaderingen ónder een raadsplein-avond worden nu wel geïmporteerd (#255, Castricum).

De wekelijkse dekkingscontrole (coverage op /api/status, zie de API-documentatie) start ik zodra de backfill klaar is; de eerste run vanochtend moest ik afbreken omdat hij bovenop de backfill het iBabs-budget overschreed. Zodra die heeft gedraaid post ik hier de cijfers voor Ermelo en Lochem tegenover ORI.

[guidol-ive]

Geweldig! De taart kan alvast klaargezet worden voor doorbreken 5,5 miljoen stukken:

00:46 = 5.499.484 vergaderstukken

Onze eigen interpretatie van de /api/status klaagt nog over veel problemen, zie plaatje:

• Bronsysteem GemeenteOplossingen: idle, 32 organen, 0 van 0 importruns geslaagd. Laatst geslaagd 2026-09-05 07:28 UTC.
• Bronsysteem iBabs: idle, 161 organen, 0 van 0 importruns geslaagd. Laatst geslaagd 2026-09-06 21:50 UTC.
• Bronsysteem Notubiz: down, 124 organen, 0 van 50 importruns geslaagd. Laatst geslaagd 2026-09-07 20:35 UTC.
• Bronsysteem Parlaeus: idle, 3 organen, 0 van 0 importruns geslaagd. Laatst geslaagd 2026-09-05 08:13 UTC.

We zijn er niet dieper ingedoken; we wachten eerst de uitkomst van deze stevige en waardevolle load af.